「FPGA のデバッグ手法」について、前回の「ステップ3」と今回の「ステップ4」の2回に分けて紹介している。ステップ3ではFPGA内部のロジックのデバッグ手法を取り上げた。ステップ4ではその続編として、外部インタフェースのタイミング検証に有効なデバッグ手法をわかりやすく解説する。この2つの機能を組み合わせてFPGAのデバッグを行うことで、設計した回路に不具合が生じた場合でも、原因の切り分けが比較的容易に、かつ迅速に行え、デバッグの作業効率を改善することができる。

 ステップ3では、アルテラ社の開発ソフトウエア「Quartus II 」が備えているデバッグ機能の『SignalTap II Logic Analyzer』について紹介した。ステップ4ではもう1つの『Debug GUI』機能を用い、比較的簡単な操作で実行できるデバッグ手法について解説する。

外部インタフェースのタイミング検証に最適『Debug GUI』

 FPGAのデバッグ環境が整っていても、不具合が発生した場合に、その原因が「FPGAチップ内部の問題か」、「外部インタフェースに起因する問題なのか」を切り分けもせずに、漠然とデバッグ作業を繰り返しても、早期に課題を解決することは難しく、作業効率は悪い。原因の切り分けを行うにしても、実際にある程度の経験がなければ、どこから切り分けたらいいのかわからないことも多くある。

 このような状況下で、原因の切り分けを行うのに有効なツールの1つが、外部インタフェースのタイミング検証に適したDebug GUI 機能である。Quartus II に新しく追加されたこの機能は、アルテラ社が用意しているIPコア「DDR2 SDRAM High Performance Controller 」が実装されていれば利用することができる。

 DDR2 SDRAMインタフェース回路には、メモリ側からデータを読み込むときの、DQとDQSの位相シフト角を最適化するためのキャリブレーション回路が組み込まれている。それでも、「データレートの高速化」や「製造プロセスのばらつき」などの影響を受けて、複数あるデータラインでそれぞれ信号遅延が生じてしまうことがある。

図1:GUIに表示されるキャリブレーション結果
図1:GUIに表示されるキャリブレーション結果
[画像のクリックで拡大表示]

 このような場合に、Debug GUI 機能を用いると、キャリブレーション結果を「バリッド・データ・ウィンドウ」という形で、パソコンのGUI 上に表示することができる(図1)。バリッド・データ・ウィンドウでは、「どこの信号(データライン)でエラーが発生しているのか」、「データラインごとにどれくらいのマージンがあるのか」などをオンボード上で簡単に確認することができる。この機能により、設計者が原因の切り分けに要する工数を削減することができる。

 Debug GUI 機能は、ステップ3で紹介したSignalTap II Logic Analyzerと同様に、Quartus II より JTAG ポート経由で FPGA にプログラミングできる環境があれば利用することができる。操作方法も非常に簡単で、DDR2 SDRAM High Performance Controller のデザイン・ファイルを一カ所変更し、Debug GUI 機能を有効にすればいい。あとは上位階層でDebug GUI 機能を有効にしたことによって追加されたポートを宣言するだけである。デバイスのピン配置の設定などを変更する必要はなく、最上位階層の変更もない。

 上記の説明だけでは、簡便な操作性を十分に理解してもらえないかもしれないが、基本的な操作としては、以下にあげる3つの作業を行うだけで、Quartus II のDebug GUI 機能を実行することができる。

【作業1】Debug GUI 機能を"イネーブル"とし、専用ノードを追加

 前々回のステップ2でも説明したように、DDR2 SDRAM High Performance Controller デザイン・ファイル内の記述をDebug GUI が"イネーブル"になるように変更("false" を "true" に1ワードだけ変更)するだけである。

表1:DDR2 SDRAM High Performance Controller デザイン・ファイル内の記述を
表1:DDR2 SDRAM High Performance Controller デザイン・ファイル内の記述を"false"から"true"に変更
[画像のクリックで拡大表示]
図2:DDR2 SDRAM High Performance Controller のデザイン・ファイル内の記述を変更した後、リジェネレートを行う
図2:DDR2 SDRAM High Performance Controller のデザイン・ファイル内の記述を変更した後、リジェネレートを行う
[画像のクリックで拡大表示]

 変更した後は、DDR2 SDRAM High Performance Controllerのリジェネレートを行う。これによってDebug GUI 用のポートが追加されるので、コンポーネントの変更を行う(コンポーネント変更箇所などは Debug GUI のユーザ・ガイドに記載されており、基本的にユーザ・ガイドに記述された内容をコピー・アンド・ペーストで貼り付けるだけで終了となる)。

【作業2】コンパイル・プログラミング

 作業 1 が終了したら、その次にコンパイルを実行する。コンパイルが終了した後、FPGA にプログラミングを行う。

【作業3】サンプリング

 Debug GUI Tool を起動すれば、JTAGポートに接続されたデバイスが自動的に認識され、FPGA内部の信号をサンプリングすることができる。

 Debug GUI 機能を用いると、キャリブレーション結果を GUI 上で確認することができ、問題がありそうなデータラインを一目で判断できることから、誤動作の原因を切り別ける作業にとても役に立つ。しかも、早期に原因を切り分けられることは、デバッグ全体の工数削減にも大きく影響してくることになる。

図3:表示されたキャリブレーション結果から誤動作の原因を切り別ける
図3:表示されたキャリブレーション結果から誤動作の原因を切り別ける
[画像のクリックで拡大表示]

その他のオンチップ・デバッグ機能

 これまで、Quartus II が備えている代表的な2つのオンチップ・デバッグ機能を紹介してきた。Quartus II にはこれら以外にも、JTAGポートを利用したオンチップ・デバッグ機能がある。その一例としていくつかの機能を簡単に紹介する。

  • SignalProbe
図4:SignalProbe機能の操作画面
図4:SignalProbe機能の操作画面
[画像のクリックで拡大表示]

 「SignalProbe 」機能は、すでに配置配線が完了している領域を避けて、空いている配線リソースを検索し、観測したい内部信号から指定されたデザイン上の未使用ピンへの配線を行う。その上で、外部に接続したロジック・アナライザやオシロスコープを使って、FPGA内部の信号を検証するための機能である。このため、ユーザがデザインを終えた配置配線のタイミングに影響を与えることはない。

  • Logic Analyzer Interface (LAI)

 外部に接続したロジック・アナライザに、FPGA 内部の信号を送信して解析することができる機能である。これによって、外部のロジック・アナライザまたはミックスド・シグナル・オシロスコープが備えている最新機能を活用した解析ができる。 一例だが、内部ノードの信号名をロジック・アナライザ側に自動的に反映させることで、デバッグ作業者にわかりやすく表示させることができる。

 また、多数の内部デバイス信号をデバッグするために、必要に応じて出力信号をデザインI/O ピンでマルチプレクス化することもできる。具体的には多数の出力したい信号をいくつかのグループに分け、観測したい信号が含まれるグループのみを少ないピン数で外部に取り出す、という手法である。例えば80出力ピンが必要だったものを、8ピンずつ10グループに分け、FPGA内部に設けられたセレクタ回路を使って、その中から必要な1グループのみの信号を取り出し、観測することができる。

図5:Logic Analyzer Interface (LAI)機能の操作画面
図5:Logic Analyzer Interface (LAI)機能の操作画面
[画像のクリックで拡大表示]
  • In-System Sources and Probes

 この機能は、カスタマイズされたレジスタ・チェインを設定して、ロジック・デザインに組み込まれたノードをドライブまたはサンプリングし、シンプルな仮想スティミュラスを提供し、組み込まれたノードの現在値をキャプチャすることができる。 SignalTap II Logic Analyzerを使用してトリガ条件を設定し、外部のテスト装置を使用しないでデザインをエキササイズするための単純なテスト・ベクタを作成する。そして、JTAG チェインを使用してランタイム・コントロール信号をダイナミックに制御することができる。

図6:In-System Sources and Probes機能の操作画面
図6:In-System Sources and Probes機能の操作画面
[画像のクリックで拡大表示]
  • In-System Memory Content Editor

 JTAG ポートを介してFPGA オンチップ・メモリおよび定数への読み出し/書き込みアクセスを提供し、システム内でデバイスが動作している間に、FPGA のメモリ内容および定数値への変更を、より簡単にテストできるようにする機能である。例えば、エラーが発生した時に、オンチップ・メモリ内部のデータを外部から書き換えて、異なる条件での検証を行うことができる

図7:In-System Memory Content Editor機能の操作画面
図7:In-System Memory Content Editor機能の操作画面
[画像のクリックで拡大表示]

 以上で「DDR2の実装からデバッグ手法」についての連載は完了する。「開発期間の短縮」や「コストダウン」といった、機器設計者が抱える悩みを解決できる手段の1つとしてFPGAの認知度が高まっている。そこで、これだけ知っていればFPGAの設計ができる「FPGAの設計開発フロー」と、ボードを使ってDDR2 SDRAMインタフェース回路の設計を行う「DDR2の実装からデバッグ手法」についてわかりやすく解説してきた。FPGAやその開発ツールが、「より使いやすく」進化を続けていることを理解していただけたであろうか。

この記事は、アイティメディア社『FPGA Insights』に掲載されていたコンテンツを、アイティメディア/EDN Japanの許可を得て転載しています。

目次