FPGAを用いてビデオ処理システムを設計すると、多くの技術的な利点が得られる。その半面、設計が複雑になってしまう場合が多い。その複雑さに比例して困難になるのが、システムの検証作業である。本稿では、こうした検証作業の際に留意すべき点や、設計上の誤りを回避するための方法について解説する。
民生機器の市場に参入すれば、多くのメリットが得られる可能性がある。確かにそのとおりなのだが、この市場では製品投入までに許される期間が非常に短いので、設計チームの負担が大きくなる。そのため、多くのシステム設計者にとっては、FPGAベースの設計が第一の選択肢となっている。一方、民生機器ではマルチメディア対応への要求が高まっているので、多くの組み込み製品において、DSPやストリーミングインターフェースが必須コンポーネントとなっている。FPGAベンダーの中には、DSPコアとストリーミングインターフェースを搭載するFPGA製品を供給しているところがいくつかある。そうしたFPGA製品は、技術的には最新の設計要件を十分に満たすものであるものの、複雑さが増してしまうという側面も持っている。
このようなシステムでは、FPGAはインターフェースを介して、DSPコアとの間で高速ビデオデータのストリーミングをやり取りする。非常に複雑な設計を要するシステムとなることから、その検証も困難になる。そのため、設計サイクルの終盤になって重大な誤りが検出されるという事態が生じ、システムボードの再スピンという恐ろしい結果を招く可能性がある。再スピンに大きなコストがかかるのは明らかだ。そのような事態を避けるためには、検証方法を慎重に検討し、再スピンが生じるリスクを抑えなければならない。
FPGAでは、ベースとなるアーキテクチャがあらかじめ定義されている。そのため、設計の初期段階において必要なテストシナリオの範囲がわかるという利点がある。検証チームはこれを頭に置いて、実際のシステムアーキテクチャを模倣する検証環境を構築することができる。
実際の検証作業では、外部の周辺機能に加え、設計に使用するDCM(Digital Clock Manager)やブロックRAMなど、FPGA内部の回路エレメントも検証する必要がある。このため、検証作業は膨大なものとなり、すべてのテストケースの実施完了までにかかる時間が製品開発期間に大きな影響を及ぼすことになる。当然、検証環境は時間の面で効率の良いものでなければならない。適切な検証環境を初期段階で設計し、テストケースの記述とボードの立ち上げを正確に行うためには、FPGA設計のエレメントとその周辺に配置される外部デバイスについて理解することが必要不可欠となる。
FPGAベンダーは、DCMやブロックRAMなど、きちんと検証を済ませたFPGAプリミティブを提供している。ただし、これらのプリミティブをFPGAの設計に使用するには、一定のガイドラインに従う必要がある。
FPGAに設計情報をロードする前に、誤った使い方をしている部分を検出しておくことは非常に重要である。例として、DCMの制約の1つである入力クロック上の許容クロックジッターについて考えてみよう。テストケースにおいて、DCMには低速モード時のクロックジッターが±300psという制約がある。設計の仕様によって、DCMの入力クロック周波数は、16.384MHz、22.5792MHz、または24.576MHzの場合がある。しかし、検証時に検証エンジニアが入力クロック周波数を切り替えると、必然的に周波数は入力クロックジッターの制約に反し、DCMはロックを解除する。そのため、入力クロック周波数の切り替え時にDCMをリセットする機構を実装するよう設計を修正することになる。フロントエンド部を検証する際にこのようなバグが検出できていなければ、ボードの立ち上げ時には、このバグを特定するだけで1週間以上を費やしてしまうことになるだろう。
また、技術の進歩に伴い、現在のFPGAにはシングルまたはデュアルポートのブロックRAMが搭載されるようになった。デュアルポートRAMの場合は、両方のポートで同時に同一のメモリーセルにアクセスすることができる。しかし、設計者がRAMのコントローラを適切に実装していないと、両方のメモリーポートが、単一のRAM領域に異なるデータを同一のサイクルに書き込もうとする恐れがある。このような事態に対応するには、検証チームはそのためのテストを用意する必要がある。こうした理由から、FPGAの設計エンジニアだけでなく、FPGAの検証エンジニアも、FPGA内部のコンポーネントの要件や制約を認識することが重要となるのである。
FPGAへの入力信号には、ルーティングパスにおける遅延や信号品質の劣化が生じる。
FPGAの検証計画を策定する際には、入力スティミュラス信号の生成時に生じるタイミングのばらつきやシグナルインテグリティの劣化について考慮する必要がある。例えば、ドリフトが生じていてもFPGAがスムーズに機能することを検証できるようにするには、入力信号にどの程度のドリフトが生じ得るかを知っておいたほうがよいだろう。複数のインターフェースが同期しており、外部デバイスによってクロックを駆動する場合は、この要件が重要となる。加えて、データ、制御、クロックのそれぞれに、ルーティングパスの遅延、送信デバイスにおけるクロックから出力までの遅延、受信デバイスの入力セットアップ時間に基づく異なる遅延が生じる可能性がある。これらの制約により、高速動作時には、FPGAが入力データをキャプチャするためのサンプリング時間が短くなる恐れがある。検証を行う際には、FPGAへのスティミュラス入力において、このような実際の遅延を考慮する必要がある。
また実世界では、入力クロックに、ばらつきのあるジッターやドリフトが加わる。DCMを使用すればこれらのばらつきに対処することもできるが、DCMには入力クロックのばらつきの許容範囲の面で独自の制約がある。検証エンジニアは、実際のシステムに生じ得るクロックのばらつきの範囲を知り、検証環境における入力クロックの生成時に、それと同じばらつきを再現する必要がある。これを行うことにより、FPGA回路の制約を把握し、開発フェーズの初期段階において是正策を講じることが可能になる。
Copyright © ITmedia, Inc. All Rights Reserved.