先日、ある講習会の講師を務めた際、出席者の1人から「デバッグが最も難しいのはどのようなケースか」と尋ねられた。筆者は即座に答えた。「2週間に1度起こるような類の不具合だ」と。不具合の発生頻度がもっと低いなら、不具合なしと判断してそのまま出荷することもできよう。頻度がもっと高ければ、その原因を見つけ出せる可能性が高い。2週間に1度といったように、「たまに起きる不具合」が最悪なのだ。
まれにしか発生しない不具合のデバッグを行う際には、直ちに「改善」に取り組もうとするのはやめたほうがよい。改善のための対策を施すたびにテストを行うことになるので、途方もないテストサイクルが発生して開発スケジュールが完全に狂ってしまうからだ。最初に行うべきことは、「改善」ではなく、「問題を悪化させる」ことである。不具合のトリガーとなっている事象を見極め、その発生頻度を高めるのだ。
問題を悪化させるといっても、ハンマーで殴るようなことはしてはならない。そうではなく、その症状を引き起こす原因の手がかりを見つけてパラメータを調整し、症状の発生頻度を高めるのである。頻度が高くなれば問題を扱いやすくなる。症状に関連する手掛かりを2〜3つも見つけられれば上等だ。
デジタル回路の不具合の場合、タイミング面でのマージン不足や衝突といったことが原因であるケースが多いので、その観点から出発するとよい。問題のシステムが複数個の大規模ICから構成され、おのおののクロックが1個のクロックリカバリICから供給されているケースを想定しよう。その場合、まずはあるICから次段のICへのデータバスについて考えてみる。前段のICのクロックにわざと遅延を持たせれば、次段のICにおいてセットアップ時間の問題を発生させることができる。バスのタイミングに十分なマージンがあるなら、クロックのタイミングをわざとずらしてもエラーは生じないだろう。一方、バスのタイミングに余裕がない場合には、このような手法によって不具合と同様の現象を誘発することができる。
バスのタイミングの問題への対処と同様の手法で、クロストークの問題をピンポイントに把握できる可能性がある。クロックのタイミングをずらすと、問題の原因となる電圧スパイクの到達時間が相対的に変化することになるので、クロストークの量が変化する。つまり、クロックのタイミングをずらすことにより、クロストークの劣化原因となるスパイクの位置をデータ判定ウインドウの外にシフトすることで、その影響が避けられるのである。
では、クロックのタイミングはどのようにしてずらせばよいのだろうか。場合によっては、クロックラインのパターンに指を置くだけで、クロックのエッジを遅らせるのに十分な浮遊容量を形成できる。少し実験してみれば、指をどのように置くとどのような変化を生じさせられるか判断できるようになるだろう。
マイクロ波分野のエンジニアは、この種の手法をもう少しコントロールしやすい方法で利用している。彼らは1/4インチ角の銅板を鉛筆や木製棒の先端に貼り付け、それを信号ラインのパターンに接触させる方法を使う。この銅板とグラウンドとの間で形成される容量によって、位相を微妙に調整するのである。タイミングを進める必要がある場合には、遅延量が負になる回路を使用すればよい*1)。
それでは、クロックパターンが内層にあり、手で触れることができない場合にはどうするのか。これについては、そもそも、基板設計に関する重要なポイントを満たしていないので、そこから見直したほうがよい。クロック用のパターンはタイミングを調整できるよう、表層に置いてアクセス可能にすべきである。
複数のクロックが存在するシステムのテストは複雑になる。2系統のクロックが同期している場合、1つの位相関係によってのみ問題が生じるケースがある。このような状況でテストを行うには、2系統のクロックを発生し、相互の位相を調整できる外付けのフェーズロッククロック発生器を用意する。これによりシステムにクロックを供給しつつ、クロック間の位相を調整しながら、通常よりもエラーが増加する位相関係が存在するか否かをチェックする。例えば、2系統のクロックを完全に同位相にしたりわずかにずらしたりして、グラウンドバウンスやクロストークあるいはメタステーブルの状態を観測してみよう。そのようにしてエラーが顕著に増える位相を見つけることができたら、その症状に焦点を当ててデバッグを進めればよい。
<筆者紹介>
Howard Johnson
Howard Johnson氏はSignal Consultingの学術博士。Oxford大学などで、デジタルエンジニアを対象にしたテクニカルワークショップを頻繁に開催している。ご意見は次のアドレスまで。www.sigcon.comまたはhowie03@sigcon.com
脚注
※1…Johnson, Howard, "Negative delay," EDN, Aug 30, 2001, p.24.
Copyright © ITmedia, Inc. All Rights Reserved.