close

Enter

Log in using OpenID

DDR-SDRAM 搭載PCI Express 対応画像入出力ボードの

embedDownload
DDR-SDRAM
搭載
PCI Express 対応画像
Keysight
Infiniium
入出力ボードのデバッグに見る計測器を
90000 DSO/DSA Series
組み合わせて効率を上げるデバッグ手法
Oscilloscopes
Engineered for unmatched
(ロジック・アナライザ、ストレージ・
オシロスコープ、etc)
real-time measurement accuracy
02 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
はじめに
近年、デジタルシステム開発において、様々な技術の進歩によ
り、高速化、大規模化、複雑化したシステムの設計が増えていま
す。技術の進歩に応じて、発生する不具合も複雑化し、スケジュ
ール遅延等の一要因にもなってきています。
不具合には様々な原因が考えられますが、この原因にたどり着
くまでにデバッグ時間の多くを費やします。 どちらかと言うと、
不具合の原因さえ分かれば、その修正にはそれほど時間を使う
必要がないケースが多く、原因究明までがデバッグの中心と考
えても良いと言えます。(後で振り返ってみれば、設計時の単純
なミスだったという事は非常に多い)
しかしながら、昨今の複雑なシステムでは、複数のエンジニアが
様々な階層の設計をしており、各エンジニアレベルで、勘を頼り
に手探りをしていてもなかなか不具合の原因に辿りつけません。
また、ソフトウェアの不具合のように見えて、実はハードウェアの
不具合だったなど、見えている不具合がハードウェア、ファーム
ウェア、ソフトウェアのどのレベルで起きているかわかりにくくな
ってきています(図 1)。システムレベルのデバッグでは、表面上
起きている現象を順序よく解析し、下位のブロックレベル、担当
者レベルに早期に落とし込んでいくことが重要になります。
本章ではデジタルシステム実機デバッグ時の、複雑なハードウェ
ア、ファームウェア、ソフトウェアの不具合の原因を効率良く切り
分けるための測定器の使い方、また、測定器同士を連携したデ
バッグ・解析方法について、より実践的に具体的にご紹介します。
信 号 処 理 系 統 と し て は 、 画 像 デ ー タ が DVI(Digital Visual
Interface)からシステムに入力され、FPGA で処理されたのち、
DDR メモリに一旦バッファリングされます。バッファされたデータ
は、PCI Express を経由して、PC に取り込まれます(図3)。 PC
の画面上で画像データを確認してみると、画像のライン数が異
なる、ドットの色が化けてしまっている、または、フレームレートが
仕様通りでないなど問題が発見された場合、不具合の原因とし
て考えら れるのは、FPGA 内 部、DDR メモリ・ アクセス、PCI
Express の転送部分など様々です。
図 3 システムのブロック図
このシステムでは、画像データが入力されてから PC 上に表示さ
れるまでに様々な高速インタフェースや、論理ブロックを通過す
るため、不具合現象を見るだけでは、どこの部分が原因か検討
がつきません。スケジュールは詰まっており、早期に解決しない
といけません。どうすれば良いのでしょうか?
2.検証計画の立案
いきなり測定器などを使ったデバッグや、シミュレーション、また
は、コードの見直しなどに入るのではなく、まずは、システム全体
を見て、検証計画を立てます。
図 1 システムに潜む不具合原因
1.実際のターゲット・ボード
今回は、画像入出力ボード TB-5V-LX50T-PCIEXP(東京エレク
トロンデバイス社製)を例に FPGA,DDR メモリ, PCI Express など、
最近のトレンドとして使用されることの多い、実際のデバッグを
考えます。(図2)
図 2 今回のデバッグシステムおよびターゲット
① システム内部のデータ処理の流れの確認
システム全体のハードウェア・ソフトウェア構成を理解し、データ
の流れを確認します。今回の画像システムの場合、上位レベル
で流れを見ると、入力データは FPGA へ入力され、パソコンへ転
送されていますが、詳細に見てみると、入力データはシリアル・
パラレル変換された後、FPGA 経由にて DDR2 メモリへライトさ
れ、その後、FPGA がメモリをリードし、PCI Express というシリア
ルバスを経由してパソコンへ転送されている事が分かります。
② 評価ポイントのリストアップ
システム全体のデータの流れを確認すると、今回論理検証とし
て疑うべきポイント、検証すべき順番が見えてきます。 FPGA へ
の画像入力に始まり、DDR メモリのライトアクセス、および、リー
ドアクセス、PCI Express の FPGA 内部 IP 周辺、そして、最後に
ボードと PC 接続部分の PCI Express バスなどが考えられます。
パソコン上のファームウェア・ドライバレベルの検証も含めると、
さらに検証項目は多くなります。
③ 検証計画のフローチャート
このシステムにおける検証計画のフローチャートを示します。(図
4)今回は DVI からの画像入力、DDR メモリ・アクセス、PCI
Express の 3 点に分け、それぞれのインタフェースを確認して問
題の切り分けを行って行きます。フローチャートを作ることにより、
このように抜けのない検証計画を立てることができます。
03 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
3.DVI 画像入力の確認
デバッグ開始
DVI レシーバの出力信号をロジック・アナライザで測定すること
によって、DVI レシーバから設計通りの信号がシステムに出力さ
れているかどうか確認が出来ます。
FPGA入力部分
の確認
RGB入力は
正常
FPGA入力
波形確認
NO
YES
FPGA内部への
取り込みの確認
内部FIFO
データは正常
FPGA内部ロジックのデ
バッグ
NO
YES
図 5 DVI 画像入力部の構成
DDRメモリへの
書き込みの確認
WRITEの
ロジックは正常
DDRメモリコントローラ
のデバッグ
NO
YES
DDRメモリからの
読み出し確認
Write側の波形・
タイミングのチェック
(Writeがデバイス側で正常に行われな
かった可能性が高い)
READ
は正常
NO
YES
PCI-Express
パケット解析
PC側の問題
(ドライバ等)のデバッグ
エラーや、
パフォーマンス等
は正常か
NO
PCI-Express波形
のチェック
YES
デバッグ終了
図 4 検証フローチャート
検証対象のデータの流れから導いた、検証計画のフローチャー
ト。データの流れに沿って段階を追って検証することにより、問
題切り分けを迅速に行う。
プロービングポイントは(図5)のように、コネクタレス・プローブを
用いて DVI レシーバと FPGA 間の伝送路上にてデータを取得し
ま す 。 ロ ジ ッ ク ・ ア ナ ラ イ ザ で OutputDataclock お よ び
Hsync/Vsync 信号と RGB[各 8bit,計 24bit]の信号を測定するこ
とにより、各信号のタイミング、Setup/Hold 時間等が正しいか、
ロジック・レベルで測定することが可能です。この段階で不具合
が発見された場合は、DVI レシーバとして使用している IC の仕
様のチェック、オシロスコープで DVI レシーバ周辺のアナログ信
号の評価などに検証が移行します。
ロジック・アナライザで観測したデータは VisualBasic(表記チェッ
ク)などの外部プログラムで関数として読み出すことが出来ます。
今まで波形やリスト表示での確認だけではなく、画像処理プログ
ラムを作成すると図のようにロジック・アナライザのデータを使用
し画像として確認を行うことも可能です。これにより、DVI に出力
した画像データと DVI レシーバから出力された画像データを比
較することが可能になり、画像のライン数が異なる、ドットの色が
化けてしまっているなどの視覚的な現象を簡単に確認すること
が出来ます。
続いて FPGA 内部に正しくデータが入力されているか確認しま
す。FPGA を使用する上での注意点の一つに、外部クロック同期
で FPGA に入ってくる信号の取り扱いがあります。FPGA 内部の
クロック信号へ入力データを乗せ換えるために、通常は非同期
FIFO を用います。実際には OutputDataclock に同期した Data
および Sync 信号を FPGA 内部の Systemclock に乗せ換えま
す。ここで、FIFO の後のユーザロジック間のデータをロジック・ア
ナライザに再度出力すると FPGA 内部でデータが正しく入力お
よび乗せ換えが出来ているか確認を行うことが可能です。
最近のロジック・アナライザでは複数のクロックに同期したステ
ート測定も可能です。DVI レシーバの出力信号を OutputData
Clock に同期して、FPGA 内部の入力データを System Clock に
同期して同時に確認することが出来ます(図6)。これにより、
FPGA 内部の入力データに不具合が発見された時に DVI レシー
バの出力信号に同様の現象が出ていないか確認をすることで、
FPGA 入力段の切り分けを行うことが可能です。
実際に、この段階で不具合が発見された場合は、FPGA の入力
部分の Setup/Hold の確認や FIFO の設計の確認など FPGA 入
力部分の検証を行います。
04 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
多くの場合は、上位ソフトウェア(ファームウェア)からのメモリコ
ントローラへの設定誤りです。
図 6 DVI 出力及び FPGA 内部信号の同時観測
4.DDR メモリのアクセス確認
DDR メモリの高速化にともない、メモリ・アクセスがトラブルを引
き起こす可能性が飛躍的に増加しています。例えば、DDR2 の
400 から 667 に変更した途端システムが動かなくなった、メモリ
ベンダを変更したら動作が不安定になったなどです。このような、
DDR メモリに起因するトラブルが原因で、プロジェクトが数か月
止まってしまうような状況も発生しています。そのような時、効果
的に測定器を使うことで、DDR メモリコントローラとメモリ間の検
証、デバッグを進める事が出来ます。
① コントローラからメモリへのアクセス(Write)の検証
メモリへの Write に関しては、下記代表的な項目について、測
定器で検証します。
Setup/Hold の検証:
オシロスコープを用いて DRAM 端で波形を観測し、Setup/Hold
時間などに違反がないかチェックします(図中②)(図10)。もし、
このタイミングがおかしければ、DRAM 側でうまくデータを受け
取れていないと考えられます。特に Write 時にはデータのストロ
ーブ(DQS)とデータ(DQ)の位相関係が 90 度ずれている必要が
あり、重要な検証項目です。
モードレジスタの設定確認:
最初に行う事は、初期化時などにおいてメモリデバイスの仕様
に応じたモードレジスタの設定がコントローラ側から行われてい
るかの確認です。この場合、ロジック・アナライザを使用して、モ
ードレジスタへの書き込み部分へトリガを設定し、その箇所のト
レースを観測します。(図7)トレース結果を見て、設定内容がデ
バイスの仕様と異なる場合は、メモリコントローラの見直しが必
要です。
コマンドの検証:
メモリコントローラが正しくメモリを操作出来ているか確認します。
主要なポイントとしては、リフレッシュコマンドの発行間隔や個数、
または、コマンドシーケンスのタイミングがスペック通りに動いて
いるかをチェックします。(図8: tRCD チェック等)
コマンドの検証については、ロジック・アナライザの波形表示上
で確認することも出来ますが、最近では、コマンドシーケンスの
自動測定ツールも出てきています。(図9: プロトコルチェック機
能)
メモリコントローラの動作がデバイスの仕様と異なる場合は、コ
ントローラへ設定されているパラメータの確認が必要となります。
② メモリからコントローラへのアクセス(Read)の検証
Write のロジックおよびタイミングが正常であることを確認できた
ら、次に DRAM から Read したデータのロジックを確認します。
具体的には、FPGA 内部の入力段の I/O ラッチ直後のデータを
観測します。このロジックが異常であれば、Write 時と同じように
波形のタイミング等に問題がないかチェックします。 また、FPGA
入力段 I/O バッファで DELAY 等を設定している場合は、その値
のチェック・調整等も必要なケースがあるでしょう。問題発見時に
は、FPGA 内部信号と、DDR メモリバス上の信号をロジック・ア
ナライザ上で、同時に観測し、解析して行きます。(図11)
また、ロジック・アナライザのストア条件を用いると、メモリに保存
する条件を指定することが可能です。例えば NOP は保存しない
設定や、特定のアドレスに Write、Read しているときだけ保存す
るなど、任意のデータのみの現象を測定することができます。
05 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
最近のロジック・アナライザはメモリ(サンプル)長が数 100M と
長いものもあります。画像データなどで、ライトとリードの時間間
隔があいている場合でも長時間の測定が可能です。
さらに、最近ではロジック・アナライザとオシロスコープが連動し
て使用できるようにもなっています。 これにより、波形品質とロ
ジック異常の関係なども確認することが出来ます。(図12)
特に、発生頻度が少ない現象を測定する場合、ロジック・アナラ
イザのパターン・トリガ、シーケンス・トリガ、およびオシロスコー
プのトリガを有効に使い、コマンド、データパターン、アドレスなど
絞り込んでいくデバッグが有効です。クロストークなどで、特定の
データ遷移(FF→00 など)があった時だけ Write か Read に不
具合が発生するような場合、ロジック・アナライザでは 0 または
1 のロジック・レベルしか観測できませんが、オシロスコープを連
動して使うことにより、アナログ波形がどのようになっているか観
測することが可能です。
コラム: DDRメモリのプロービングについて
近年の傾向として、BGA パッケージになっている部品が多いですが、DDR メモリもそのひとつです。BGA パッケージの特徴として、ピンが外に出ていな
いため、ロジック・アナライザによる信号の測定は非常に困難でした。最近では、BGA プローブ(図)といった基板とメモリの間に挟み込むことにより、メモ
リのライト/リードのアクセスの測定を可能にする製品も提供されるようになっております。また、DIMM インターポーザ(図)は PC やサーバで使用される
DIMM の測定を可能にし、ミッドバスで使用されるコネクタレスプローブ(図)は従来のコネクタを取り除くことで低容量を実現し、より高速な信号を観測可
能にします。
コラム: 適切なサンプリングポジジョンの設定
DDR2 の 400 から 533、667 あるいは DDR2 から DDR3 というように、使用するレートが上がっていくと、低いレート時と比較して、ノイズやジッタ、チャ
ンネル間のスキューの影響などが大きくなります。これらは、ロジック・アナライザでの不要なエラーの要因となりますので、これを防ぐためにも、より精
確なサンプリングポジションを設定することが要求されます。近年では、多チャンネルの Eye パターンを書く機能もありますので、これを使用すれば波形
品質のチェックとサンプリングポジションの設定を全チャンネルまとめて行うことができます。
06 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
5.PCI Express インタフェース
最近は PCI Express が標準 I/O インタフェースとして広く使用さ
れるようになっています。PCI Express は非常に高度なエラーハ
ンドリング機能を持っており、基本的にデータが化けたり欠落し
たりすることはありません。しかし PCI Express にはエラーハンド
リングを含め様々な機能が組み込まれており、その中身はブラ
ックボックスとして扱われることが多く、問題が存在していても開
発者やユーザがそれを見落としてしまうケースが多くあります。
ここでは PCI Express ロジック・プロトコル解析ツールとそれを使
用した問題解析例について解説します。
① PCI Express の基本的な動作の確認
まずはエラーやパフォーマンスといった、PCI Express インタフェ
ースが正常に動作しているかどうかを確認します。これにはプロ
トコル・アナライザを用います(図5-1)。ここでポイントとなるの
は、アナライザを接続するプロービング方法です。一般的な方法
としては CEM(Card Electro-Mechanical)インタフェースのため
のスロット・インターポーザ、ミッドバス・プローブ、差動レーン個
別に接続するフライングリード・プローブがあります(写真5-1)
が、いずれの場合も被測定システムに影響を与えず確実にデー
タを測定できる高性能プローブを選択する必要があります。
PCI Express では最初にトレーニングシーケンスを実行してデバ
イス(ポート)間のリンクを確立します。トレーニングシーケンスは
TS1、TS2、InitFC などのパケットのやりとりで構成されています
が、これをアナライザで確認します。画像入出力ボードがパソコ
ン側から認識されている場合は、PCI Express リンクは確立して
いますが、本来とは違う狭い幅でリンクが確立してしまい(たとえ
ば、x8 のはずなのに x4 でリンクする)、所望のパフォーマンス
が出ないといったリンク初期化のトラブルがあるので要注意です。
プロトコルエラーが発生しているかどうかの確認には、アナライ
ザのエラー検出機能を用います。これによりエラーでトリガをか
けて動作の詳細を確認したり、エラーの数をカウンターで数える
ことによりエラーレートを計算したりすることができます(写真5-
2)。CRC エラーやディスパリティエラーのようなビットレベルのエ
ラーが発生している時は物理層の不具合が考えられます(コラ
ム:PCI Express の物理層評価とコンプライアンス・テスト)。パケ
ットに対する否定応答の Nak が送信されたり、トランザクション
がエラーで完了している場合は、PCI Express のロジックやユー
ザロジック、それらのインタフェースに不具合があることが考えら
れます。
リンクの使用率やスループットといった PCI Express のパフォー
マンスも、アナライザの性能測定機能で確認できます。全体的な
性能では予想通りのデータ量が転送されているか、リンクの使
用率が高くなりデータ転送のボトルネックになっていないか、な
どを確認します(写真5-3)。トランザクションレベルでは、クレ
ジット(バッファ)が不足してデータの転送が滞留していないか、ト
ランザクションは遅延することなく完了しているか、といったことを
測定したトレースデータから確認します。
② FPGA への PCI Express 実装の検証
PCI Express のロジックやユーザロジックに問題があると考えら
れる場合は、プロトコル・アナライザにロジック・アナライザを組
み合わせた解析が有効です(図5-2)。
PIPE(Parallel Interface for PCI Express)は Intel 社が策定した
PCI Express の PHY/MAC インタフェースです(図5-3)。PCI
Express ロジック部を FPGA に実装し PHY を外付けにする場合
は PIPE で接続することになりますが、PIPE の実装には各社で
細かな違いや独自機能があり、うまく接続できているかの確認
が必要です。PIPE は 8 ビットまたは 16 ビット、125MHz~
500MHz の同期バスなので、ロジック・アナライザで測定可能で
す。
PCI Express のロジック部分は既製 IP を利用する場合が多いと
思います。ユーザロジックとのインタフェースは通常 DMA インタ
フェースですが、この部分の接続がうまくできているかをロジッ
ク・アナライザで確認します。
PIPE、DMA インタフェースのタイミングに問題がある場合、ここ
でデータ化けが発生する可能性があります。PCI Express のロジ
ックは渡されたデータを正しいものとして送受信するので、この
不具合をエラーとして検出することができません。この場合はプ
ロトコル・アナライザで画像データだけをフィルタしてキャプチャし、
ソフトウェアで画像に戻すことによりデータが正しいかを目視で
確認できます(図5-4)。
③ PCI Express のデバッグ
PCI Express 部分に問題があると分かった場合はデバッグする
ことになりますが、発生する不具合が物理層エラーのように確率
的なものであったり、ある条件下でのみ発生するものであったり
すると、デバッグが困難なことがあります。その場合はプロトコ
ル・エクセサイザやジャマーを用いて不具合条件を意図的に再
現することによりデバッグ効率を上げることが可能です(コラム:
プロトコル・エクセサイザとジャマー)。
コラム:PCI Express の物理層評価とコンプライアンス・テスト
PCI Express は 2.5GT/s や 5GT/s といった高速シリアルバスな
ので、電気的にうまく動作しているかどうか(0/1 の伝送が正確
にされているかどうか)を最初に検証しておく必要があります。こ
れは物理層でのエラーがプロトコルレベルのエラーを引き起こし、
最終的にパフォーマンスなどに影響を与える可能性があるから
です。最悪の場合は物理層が不安定で PCI Express のリンクが
立ち上がらず、全く動作しないということもあり得ます。
PCI Express ではトランスミッタ側の試験にリアルタイム・オシロ
スコープを用いたアイマスク、ジッタ、PLL ループ帯域試験など
が行われます。またレシーバ側の試験にはシリアル BERT(Bit
Error Ratio Tester)を用いたループバック試験が行われます。
PCI Express の規格に準拠した製品であるかどうかを確認する
場として、規格化団体である PCI-SIG がワークショップを定期的
に実施しています。ここでは物理層、プロトコル、様々な製品間
での相互接続性が試験され、合格することにより製品の「PCI
Express 規格準拠」を謳うことができます。
コラム:プロトコル・エクセサイザとジャマー
プロトコル・アナライザはロジック・アナライザのようにプロトコル
を「見る」ための測定器ですが、プロトコル・エクセサイザやジャ
マーを併用することにより能動的な試験が可能になります。プロ
トコル・エクセサイザはシステムやデバイスをエミュレーションす
る機能を持っていて、デバイスの単体試験、コンプライアンス・テ
スト、リンクトレーニングに関連する LTSSM(Link Training and
Status State Machine)の検証を行うことができます。またジャマ
ーは実際にシステム内に組み込むことにより、通常は発生しな
い様々なエラー条件を生成し、エラーリカバリなどのシステム動
作を検証することが可能です。(コラムの図)
07 | Keysight | DDR-SDRAM 搭載 PCI Express 対応画像入出力ボードのデバッグに見る計測器を組み合わせて効率を上げる
デバッグ手法
まとめ
今回は、画像入力ボードを例にデバッグ時の不具合原因の切り
分けテクニックについて、より実践的かつ具体的にご紹介させて
いただきました。デバッグ時には相互に複雑に絡み合うハードウ
ェア、ファームウェア、ソフトウェアの現象を、あらゆる観点から
効率的に切り分けて行くことが求められています。ロジック・アナ
ライザ、オシロスコープ、プロトコル・アナライザ等を上手に使うこ
とで、物理層、論理層、プロトコル層などの各レイヤ間の壁を越
えた効率的なシステム統合デバッグが可能になります。
(出典:CQ 出版社、Interface 2009年9月)
キーサイト・テクノロジー合同会社
本社〒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-8728JAJP
0000-08A
Author
Document
Category
Uncategorized
Views
1
File Size
883 KB
Tags
1/--pages
Report inappropriate content