デジタル機器の Keysight Infiniium 最新デバッグ手法 90000 DSO/DSA Series Oscilloscopes Engineered for unmatched ～オシロスコープだけでは限界！様々な測定器を使った効率的なデバッグのノウハウ real-time measurement accuracy Application Note 02 | Keysight | デジタル機器の最新デバッグ手法デジタルの世界ではゴールは｛1｝｛0｝を正しく通信させる事であります。｛1｝｛0｝を間違えて、機器間あるいはチップ間を正しく情報が伝達されないと困ります。だからオシロスコープでアイパターンやジッタを測定して、このようなビットエラーが起きていないかをエンジニアは確認します（図１）。評価においてアイパターンやジッタの測定はどのような場合でも必要ですが、デバッグとなると話が違います。定常的あるいは高確率で波形に異常がある場合には有効です。アイパターンが潰れた瞬間を捉えたり、大きなジッタが発生した際のノイズ源を探し当てることは比較的容易です。ところが、昨今急増している突発的なトラブルの場合はそのままでは通用しません。数秒に１回の異常や、色々な条件が複雑に絡み合った際に起こる波形異常をオシロスコープで観測するのは容易ではありません。何時間もオシロスコープで波形を重ね続けていても、捉える事ができない可能性が高いのです。デジタル・オシロスコープは本質的にデッドタイムという物が存在し、流れている波形の 90% 以上は見落としているからです（図２）。どんなに波形更新が速いオシロスコープであっても、それは程度の差に過ぎません。数時間に 1 回の異常だと話になりません。異常を観測できなければ、デバッグのしようがありません。図１：アイパターンの測定（Keysight DSA90000A シリーズ）左はアイが開いて｛１｝｛０｝の判別が容易。右はアイが潰れて｛１｝｛０｝のエラーが起きやすくなっている。このように問題が複雑化、突発的になっている現状ではオシロスコープ単独で異常を捉えるのは困難です。他の測定器を組み合わせて使用する事により道が開けてきます。中でもロジックアナライザは全体像を把握するにも、複雑な条件でトリガをかけるのにも優れた測定器です。現在の複雑なデバッグには欠かせないツールと言えるのですが、残念ながら多くのエンジニアが依然としてオシロスコープだけで格闘しています。市場のトラブルで最も多いのが DDR メモリ周りです。毎週のようにお問い合わせを頂いています。各インタフェースのシリアル化・差動化が進む中、DDR メモリの信号はパラレル・シングルエンドだからと言えるでしょう。本稿では私が経験したお客様との DDR のデバッグ事例をいくつか具体的に挙げながら、デバッグの一般的な手順や様々な測定器を組み合わせたノウハウをご紹介します。オシロスコープだけで出来るデバッグ先に述べたように、あくまでもある程度以上の頻度で起こる異常に限りますが、オシロスコープだけでも機能を駆使すれば高度なデバッグが可能です。ジッタトレンド波形とノイズ源波形を同時に表示オシロスコープ単独のデバッグで、最初に出来ることとしてはジッタ解析です。クロック信号あるいはデータ信号のジッタの挙動（ジッタトレンド）を見れば、信号に重畳したノイズが分かります。空いているチャネルを使ってノイズ源になりそうな信号をプロービングします。ジッタトレンド波形と相関があれば、その信号が犯人です。図３の例ではジッタトレンドが電源波形と大きな相関を示しています。電源ノイズが信号に乗っかり、ジッタを増やしてしまっているのです。対策を施すと、図４のようにジッタの減少に成功しています。DDR メモリの場合、ノイズ源としては電源、源信、 ODT の３つが非常に多いです。また、もしジッタスペクトラムに明らかなピークが立っていれば、話はもっと簡単になります。ピークの周波数を調べることにより、ノイズ源を容易に推測する事ができるからです。図２：デッドタイム。オシロスコープは 90%以上の波形を見落としている。数年前まではオシロスコープで波形を見ればトラブルは解決できた例が多いのですが、現在は非常に難しくなっています。何故でしょうか？それはシステム LSI のように多数の機能を 1 個のチップに詰め込む傾向が顕著になっているからです。小型化、高性能化、コスト削減というメリットがある反面、複雑になっているので思わぬ所で関係のなさそうな機能が作用し、問題を起こすことがあります。少量のデータあるいは単一のアプリケーションだけを走らせていると問題はないのに、データ量を増やしたり、複数のアプリケーションを同時に走らせると、いくつかの条件が重なり、問題が発生する場合があります。図３：ジッタトレンドと電源波形の相関図４：対策後、ジッタは減少 03 | Keysight | デジタル機器の最新デバッグ手法マスク・アンフォルド機能とシームレス・デバッグ多くの規格の場合、アイパターンのマスクが定義されています。アイパターンがマスクにかからなければ｛1｝｛0｝が問題なく判別できる事を保証しています。マスクテストに Fail した時、そのままではいつ、どのように Fail したのか分かりません。マスク・アンフォルド機能を使えば Fail した瞬間の波形を調べることが出来ます（図５）。この時にジッタトレンドや他の信号を同時に表示しておけば相関を確認できます。このように異なる機能を複数駆使したデバッグをシームレス・デバッグと呼んでいます。図６は USB2.0 のマスクテストに Fail した原因が電源の揺れによるものだという事例です。 Read/Write が連続する際にエラーが起きやすく、電源の揺れが疑われていた事例がありました（図７）。まず Read/Write が連続の場合にトリガがかかるように、DQS 波形に対しソフトウェアトリガを設定します。次に電源の揺れが Read/Write のタイミングと重なるというトリガ条件を電源波形に対し課します（図８）。ノイズの多い DQ 波形と思っていましたが、実際にトリガをかけてみると想像以上に DQ が電源の影響を受けていました。これだけ揺れていると｛１｝｛０｝のエラーが起きてもおかしくありません。図７：電源の揺れが疑わしい図５：マスク・アンフォルド機能図８：DQ が予想以上に電源の影響を受けていたこのようにソフトウェア・トリガは直観的で、どのような複雑なトリガであっても容易に設定が可能です。容易で自由度の高いトリガは、効率良くデバッグを進めるには非常に重要です。 USB デバイスを接続すると止まってしまうカーナビゲーションの事例最近急増しているのが外部の USB デバイスを接続すると異常が起こるデジタル機器です。ここで取り上げるのは USB デバイスを接続すると、何回かに 1 回それまでの動作モードがおかしくなってしまうカーナビゲーションの事例です。カーナビゲーションは多機能化に伴う処理のマルチタスク化が進み、またリヤカメラなどの搭載により高速画像処理が必要になって来ています（図９）。メモリと定期的にやり取りをしなければいけないプログラムが複数走っている中、新たに USB デバイスを接続すると、割り込みによりメモリへのアクセスが過剰になり、規定時間内に処理が終わらないプログラムが暴走すると考えられます。図６：USB のマスク Fail と電源の揺れのタイミングが一致直観的なソフトウェア・トリガを使って仮説を効率良く検証。デバッグでは仮説を立てて、その条件の波形を取得し検証するという作業を繰り返します。そのため素早くトリガを設定できる事が重要になります。トリガ設定に時間がかかるようでは効率の良いデバッグは不可能です。ところが条件が増えるごとに、従来のトリガ設定は急激に難しさを増します。せっかく時間をかけて設定したのに思った通りに動かなかったり、そもそもかけたいトリガ機能がなく不可能な場合もあります。従来のトリガでは不可能でも、ソフトウェアトリガを使うといとも簡単に要求する複雑なトリガが実現できます。オシロスコープの画面上にマウスで四角形を描き、そこを波形が通る・通らないでトリガを設定します。図９：処理のマルチタスク化 04 | Keysight | デジタル機器の最新デバッグ手法 RAS、CAS、WE の信号をオシロで観測し、DDR メモリへのアクセスを追いかけようとしても大変です。100 だから WRITE、101 だから READ と波形から読み取るのは手間です（図１０）。デジタル信号付きの MSO（ミックスド・シグナル）・オシロスコープを用いても、コマンド単位のデコードはしてくれますが、どのタスクのメモリアクセスなのかは教えてくれません。MSO 機能はデコードには優れていても、全体状況を把握したり、特定できていないエラーを探すのには不向きです（図１１）。そもそも USB のアクセス処理は数秒間かかります。それをオシロスコープで観測するのは不可能です。ロジック・アナライザの出番です（図１２）。それが分かれば両者のリクエスト前後のメモリアクセスを詳細に比較し、違いを探します（図１５）。メモリのアクセスしているアドレスを見ればどのタスクの処理を行っているのかが分かります。 DDR メモリの解析はロジック・アナライザの得意とする分野です。デコーダやパフォーマンス解析ソフトウェアを使えば効率的にアクセスを解析できます（図１６）。図１５：（左）OK (右)NG 図１０：オシロスコープで RAS, CAS, WE を観測図１１：MSO では全体像を把握するのは困難図１６：（左）DDR デコーダ（右）DDR パフォーマンス解析ソフトウェアロジック・アナライザの膨大なメモリ長を使えば数秒間のトレースも問題なく捉えられますし、何よりもチャネル数が圧倒的に多いのがメリットです。DDR メモリのコマンド信号だけでなく、データおよびアドレスも全て見ることができますし、USB のデータ信号および VBUS 信号、その他の画像信号や制御信号も全て観測できます。図１３に示すようにオシロスコープとロジック・アナライザでは情報量が桁違いなのです。例えば USB の処理が入った際にたまたま大きな画像データを処理していたのか、複数のプログラムが並行して走っていたのか、状況を把握します。そしてそれを回避するためにタスクの優先順位を変更するとか、プログラムを書き換えるなどを行います。この例ではちょうどメインアプリケーションがアイドル中に USB 処理が入り込んでしまい、時間内に処理が終わらなかったため、メインアプリケーションが暴走してしまっていました。デバッグの一般的な手順図１２：ロジック・アナライザ（Keysight 16900 シリーズ）図１３：オシロスコープとロジック・アナライザの情報量の差システムが止まってしまった場合（NG）と止まらなかった場合（OK）の双方をロジック・アナライザで観測し、比較します。NG は USB が IN（リクエスト）と NAK（エラー）を繰り返している事が判明しました。OK はスムーズにリンクを成功しています（図１４）。図１４：NG の場合と OK の場合のリンクの流れ次の事例に行く前に、ここでデバッグの一般的な手順を紹介します。 ① 最初にエラー現象を測定器上で観測する必要があります。これは実は非常に難しいのです。どのようなデータ値だったらエラーなのか、どのようなコマンドが出たらエラーなのか分かっていないと測定器を止めようがありません。オシロスコープは短時間しか観測できないので、運良くエラーが保存したデータ内にあれば良いですが、そんなあまい物ではありません。ロジック・アナライザは比較的長時間観測できますが、何がエラーなのか分かっていないと、保存したデータから探し出すのは困難です。エラーが起きたら何らかの信号を出すなどの細工ができれば、①だけでなく、次の②も一気に解決します。 ② エラー現象が測定器上で捕捉できたら、そのエラーでかかるトリガを設定します。そのエラーのデータ値やアドレス値でトリガを設定して、トリガとエラーが毎回連動するか確認します。たまたまそのデータ値でエラーだった可能性もあります。エラー現象を何度か捉えて、それらの共通点を探します。トリガの設定も試行錯誤が必要です。 ③ 無事エラーでトリガをかける事ができたら、やっと原因探しです。エラーに至った経緯を測定器のデータを遡って、注意深く解析します。以上が一般的なデバッグの流れですが、その前にもやる事があります。エラーの頻度を上げる事です。エラー頻度が低いと①が困難になるからです。数時間、数日に一度しか起こらないエラーは論外です。エラーが起こりやすい条件は何なのかを探します。プログラムの種類かもしれませんし、温度や電源電圧、終端抵抗値などのパラメータに依存するかもしれません。またこの作業を通し仮説が立てやすくなります。 05 | Keysight | デジタル機器の最新デバッグ手法まとめると図１７になります。エラーが起こりやすい条件を探る ↓ エラーを測定器上で捉える ↓ トリガを設定する ↓ エラー原因を探るコントローラ ⇔ ディスプレイ間のロジック・アナライザのプロービングポイントがあったのが幸いし、比較的容易にエラー（ライン）でトリガがかけられました。単色画面を表示させている中、ラインが現れるので、RGB のデータに変化があるからです。この場合は RGB の信号にバースト状のデータが時々見えたので、そのバーストでトリガをかけることにしました。するとロジック・アナライザのトリガがかかるタイミングと画面にラインが現れるタイミングが完全に一致したので、エラーでトリガをかけることに成功したと言えます。トリガ点の少し前の DDR メモリのオシロスコープの波形を見ると、異常な READ データ信号を発見しました。正常だったら｛101010｝を繰り返すはずのデータが、｛0｝が続く異常なデータでした（図２１）。オシロスコープは DDR の DQ 信号 1 本しか見ていないので、ロジック・アナライザで全 DQ 信号を確認しました。正常なら 8000 から始まるはずのデータが 0000 から始まっていました（図２２）。図１７：デバッグの流れ画面に意図しないラインやドットが入ってしまうテレビの事例画面にラインやドットが入ってしまうテレビを度々見かけますが（図１８）、原因は DDR メモリのデータ化けによるものである。ここで紹介する事例は、オシロスコープとロジック・アナライザの長所を最大限に活かしつつ、お互いの機能を補ったデバッグ手法です。まずオシロスコープで Read および Write のアイパターンを確認したが、十分に開いていました。やはり突発的なエラーの場合、オシロスコープでは捉えきれません（図１９）。そこでコントローラ ⇔DRAM 間のやり取りをオシロスコープおよびロジック・アナライザで、コントローラ⇔ディスプレイ間のやり取りをロジックアナライザで観測しました（図２０）。オシロスコープの波形をロジック・アナライザ上にインポートする事が可能なので、これら全てのデータをロジック・アナライザ上で単一の画面で表示し、解析します。図２１：RGB のバーストでトリガ。その少し前に異常な DDR READ 信号。図２２：ロジック・アナライザのデータ値。異常なデータを確認。図１８：画面にラインが入る図２０：測定セットアップ図１９：（左）READ アイパターン（右）WRITE アイパターン 06 | Keysight | デジタル機器の最新デバッグ手法 READ データが異常ということは、同じアドレスへの WRITE 時からデータが異常だったのか、それとも WRITE 時は正常だったのに途中で化けてしまったのかのどちらかになります。要するにコントローラが悪いのか、メモリが悪いのか。それを見極めるために同じアドレスへの直前の WRITE を確認します。ロジック・アナライザのデコーダは Bank Address, Row Address, Column Address と分かりやすく表示してくれますので、サーチ機能と組み合わせて探します。この場合は 1.75ms 前に同じアドレスへの WRITE がありました。データ値を見ると WRITE は正常な 8000 から始まっています（図２３）。オシロスコープの波形も確認すると、 WRITE 時は｛101010｝だった波形が、READ 時には｛0｝が続く波形に変わってしまっています（図２４）。コントローラではなく、メモリがエラーの原因と疑われます。振幅が減衰する異常が起きていると分かってしまえば、オシロスコープ単独でも容易にトリガをかけられます。ラント・トリガという２つのスレッショルド電圧を設定して、片方は通過するけど、もう片方は通過しないというトリガです。オシロスコープ単独でトリガがかけられるようになると、犯人探しは楽になります。空いているプローブで疑わしい信号を当てて行きます。この場合はコントローラのインピーダンス制御信号に異常があった直後に、DQS 信号・DQ 信号の振幅が減衰していました（図２６）。図２５：WRITE の振幅が減衰していた。図２６：インピーダンス制御信号の異常が原因でした。この事例ではロジック・アナライザがその実力を発揮しています。オシロスコープ単独では、しばらく走らせても WRITE の振幅減衰はまったく見えていませんでした。ロジック・アナライザの圧倒的なチャネル数とメモリ長によって状況を把握し、複雑なトリガやデコード、サーチ機能を使って問題の箇所を突き止めました。ですが最後はやはりオシロスコープを使って波形を確認します。このようにデバッグにおいて重要なのは測定器の長所を理解し、それらを組み合わせて上手に使いこなすことです。図２３：異常 READ と同じアドレスへの直前の WRITE を確認。映像画面が止まってしまう画像処理ボードの事例次は映像画面が止まってしまう画像処理ボードの事例です。映像の種類によって止まったり、止まらなかったり、電源電圧を変えると止まる頻度が変わるボードでした。この事例で苦労したのは、画面を見ていてもいつ止まったのか分からないところです。動きがある画像なら良いのですが、動きが少ない模様だったので、止まった事に気付きづらいのです。デバッグの第一歩はエラーを測定器上で捉える事と説明しましたが、いつ止まったか分からないとそれが出来ないのです。電源電圧によりエラーの頻度が変わるので、電源に注目しました。まずオシロスコープで電圧を測定しましたが、オシロスコープでの電圧・電流測定はプローブのノイズに埋もれていて細かい挙動が分かりづらいのです（図２７）。図２４：WRITE 時は波形が｛101010｝と遷移しているのに、READ 時は｛0｝が続く。ところが WRITE 時のオシロスコープ波形をズームアウトすると、 WRITE の DQS 信号と DQ 信号の振幅が減衰してします。 DDR2 は Vac=1.15V 以上を｛1｝と判定しますが、それを下回っていました（図２５）。つまりコントローラは｛101010｝と書いているつもりでも、振幅が減衰していたため、メモリは｛000000｝と受け止めていたのです。（ロジック・アナライザは Vref=900mV で｛1｝｛0｝判定をしているため、｛101010｝と表示していました）そこで今回は電源アナライザ（図２８）を用いて電源を詳しく解析しました。電源アナライザは DC 電源の代わりに使用してボードの負荷変動を解析できます。最大４つの電源を内蔵し、シーケンシャルな出力タイミング、任意波形発生に対応しています。スコープ・ビューを使えば、電圧・電流・電力の波形を確認できます。自分自身が出している電圧・電流なので、ノイズに埋もれていない非常にシャープな波形観測が可能です。 07 | Keysight | デジタル機器の最新デバッグ手法電源アナライザを使って画像処理ボードの電圧・電流の様子を見ていると、READ と WRITE を繰り返しながら、READ 時よりも WRITE 時に電源変動が大きいのが分かりました。そして大きな電流が流れた直後に WRITE をしなくなっていました（図２９）。図２７：オシロスコープでは電圧波形がノイズに埋もれる図２９：大きな電流が流れて、その後 WRITE しなくなる図２８：電源アナライザ（Keysight N6705A）状況が分かったので、オシロスコープに戻ります。オシロスコープで大きな電圧変動でトリガ設定をし、エラーでしっかりとトリガがかかるかを確認しました。何度かトライしていると、トリガ後に WRITE が止まってしまう波形を得ることができました（図３０）。解析すると、クロックの大きな Cycle-to-Cycle Jitter（周期の急激な変動）があり、しばらくして止まってしまったようです（図３１）。特定のパターン発生時に、電源周りが不安定になり、クロックジッタへ影響している事が分かりました。電源回路の見直し、グランドの取り方・配置を工夫することが必要になります。図３０：電源スパイク後、 WRITE が止まる図３１：クロックの大きな Cycle-toCycle Jitter クロストークが問題になっていたデジタルカメラの事例最後の事例はクロストークにより誤動作を起こしていたデジタルカメラです。図３２のように、DDR のあるアドレス信号は他のアドレス信号が遷移すると 300mV くらいクロストークを受けてしまっています（図３２）。300mV も動いてしまうので、実際に誤動作を起こしていました。ところがシミュレーションではそのようなクロストークは発見できませんでした。そこで生基板を用意し、ネットワーク・アナライザを使って実測してみることにしました。図３３を見て下さい。赤いラインの A7 が被害者アドレス信号ですが、加害者として青いラインの A9 と緑のラインの A２を想定しました。A9 はこの図で A7 と隣り合っています。A2 はこの図では離れていますが、ちょうど上下の関係にある区間があるので、層間のクロストークを疑いました。ネットワーク・アナライザはそれぞれのポートがサイン波を出力し、同時にそれぞれのポートがレシーバにもなります。この場合は４ポートのネットワーク・アナライザを使用し、コントローラ側とメモリ側の被害者信号と容疑者信号に半田付け接続しました（図３４、図３５）。容疑者信号のコントローラ側から信号を入力し、メモリ側の被害者信号から信号が出てきたら、まさにクロストークが起きていることの証明になります。ネットワーク・アナライザはサイン波を低周波から高周波までスイープしますが、様々な計算処理ができます。この場合はあたかも 1V のステップパルスを入力したかのような計算処理を行いました。図３２：クロストーク図３４：ネットワーク・アナライザで測定 (Keysight E5071C）図３３：回路パターン図３５：半田付け接続まず A9 の結果ですが、A9 のコントローラ側（ポート２）から 1V のパルスを入力すると、A7 のメモリ側（ポート４）から 250mV のパルスが出てきました。これはまさにクロストークです。次に同様の事を A2 に行いますと、今度は 50mV 程度のパルスが出てきました（図３６）。A7 のクロストークは A2 より A9 の方が影響が大きいのが分かりました。この測定によりクロストークの存在が実測で確認でき、犯人も分かりました。また、どこでクロストークが起きたのかも分かります。線路の途中でカップリングが起き、信号が乗り移るわけですが、戻ってきた信号のタイミング（ニアエンド・クロストーク）を調べればカップリングの位置が導かれます。A9 の測定結果を再度見ると、A7 のコントローラ側（ポート１）に信号が戻って来たタイミングはネットワーク・アナライザの原点です（図３６）。つまり、信号がコントローラの A9 のパッドを出た瞬間に、A7 に乗り移っていることが分かりました。図３６：測定結果この結果を得て、再度コントローラ周りのシミュレーションを詳しく行うと、クロストークを発見することができました。コントローラ直下のグランドが弱かったのが理由です。基板全体を細かくシミュレーションするのは非常に時間がかかり現実的ではないですが、問題のある場所を実測である程度絞ってしまえば、細かくシミュレーション解析することも可能になるのではないでしょうか。まとめデータ量の増加、信号の高速化、またシステム LSI に代表される多機能化により、エラーは複雑化しています。そのような背景の中、オシロスコープ単独でのデバッグは難しくなっています。本稿では事例を元に、ロジック・アナライザ、電源アナライザ、ネットワーク・アナライザなど、他の測定器を組み合わせた最新デバッグ手法を紹介して来ました。デバッグの第一歩はエラー現象を捕まえることですが、何がエラーか分かっていないとオシロスコープでは困難を極めます。もちろん、エラー箇所を特定できたらオシロスコープは最強のツールであり、最後はオシロスコープでの波形品質確認に行きつくのは間違いありません。また突発的なエラーの場合、流しているプログラムについて分かっていないとなかなかデバッグしきれません。ハードウェア担当者だけでなくソフトウェア担当者との連携が必要になって来ます。同様に実測担当者だけでなく、シミュレーション担当者との連携も必要になって来ます。ここで紹介したデバッグ手法がお役に立てれば幸いです。キーサイト・テクノロジー合同会社本社〒192-8550 東京都八王子市高倉町 9-1 計測お客様窓口受付時間 9:00-18:00（土・日・祭日を除く） TEL 0120-421-345 (042-656-7832) FAX 0120-421-678 (042-656-7840) Email [email protected] ホームページ www.keysight.co.jp 記載事項は変更になる場合があります。ご発注の際はご確認ください。 ©Keysight Technologies. 2014 Published in Japan, December 08,2014 5990-8259JAJP 0000-08A