より高い抽象度での検証

アルデックのKrzysztof Szczurは、FPGAアプリケーションがセーフティクリティカルである場合、トランザクションレベルのモデリングが認証レベルの検証を行う際に役立つと話しています。

 

Henderson, NV, USA – 2022年6月22日 – Fアビオニクスアプリケーション（航空電子機器）向けFPGAデザインでは、より高い性能を実現するために高速インターフェースバスの採用が進んでおり、アプリケーションがセーフティクリティカルである場合、認証目的のデザイン検証は困難なものとなっています。

 

アビオニクスバスは、ハーネス/ロームの配線数を減らすためにパラレルではなくシリアルでデータ転送を行い、EMIや感受性の低減のために差動信号とする傾向があります。標準化され、機器やサブシステムの接続手段として広く採用されていることから、アビオニクス界で普及しつつあるプロトコルの1つがPCI Express（PCIe）です。PCI Expressは、8b/10bまたは128b/130bのラインエンコード方式の高速インターフェースで、厳密なインピーダンス整合により優れたパフォーマンスを提供します。また、クロッキングが信号内に埋め込まれていることも利点の一つあります。

 

FPGAベンダやサードパーティが提供する組込み向けのハードIPも豊富にあります。これはデザインサイクルを短縮するために非常に有効となります。

 

ただしPCIe伝送を信号レベルで解析するには、プロトコルアナライザなどの追加機器を使用しない限り不可能です。PCIeは「ポイント・ツー・ポイント」であるため、他デバイスと共有できないことに注意してください。 厳密なインピーダンス整合が要求されるため、物理的にモニタリングやデバッグ目的でプローブを行うことは困難となります。

 

FPGAデザインがデザイン保証レベル（DAL：Design Assurance Level）AまたはBの場合、DO-254準拠では要件ベースのアプローチによるターゲットデバイスのインハードウェア（およびアットスピード）テストが必要になります。

 

図 1a: 非決定性効果をシフトまたは再順序化した例

図 1b: ビットレベルの波形比較で欠陥として検出されるが、実際には正しい動作であり、認証時に説明と正当性が必要な転送

 

ボードレベルテスト

これはDO-254で最も一般的なアプローチであり、シンプルなFPGAデザインに適しています。 より複雑なデザインの場合、FPGA I/Oへのアクセスやボード上のインターフェースの制御性が制限されるため、FPGAレベルの要件をすべて検証できることはほとんどありません。解決策の１つは、シミュレーション中にキャプチャしたテストベクトルを、テスト対象デザイン（DUT）を含むFPGAのピンに適用することです。

 

アルデックが提案するソリューションの1つが、コンプライアンスツールスイート（CTS）です。これは、ソフトウェアコントローラ、マザーボード、およびドーターカード（ターゲットデザインとFPGAに合わせてカスタマイズされます）で構成されています。シミュレーションでキャプチャされたテストベクタは、DUTのピンに適用されます。次に、シミュレーションと物理テストの結果が比較されます。何百ものDAL AおよびBプロジェクトが検証されており、この検証方法は設計保証のために受け入れられるものとして認証機関に認識されています。

 

PCIe 関連要件の検証は、テスト中に PCIeインターフェースが何をしているかを簡単に確認する方法がないため困難です。ソフトウェア（システム内にマイクロプロセッサがある場合）またはハードウェアのいずれかで、追加のテストメカニズムを実装することは可能ですが、この方法には3つの大きな欠点があります。

 

1つ目は、FPGAレベルの要件をテストするために、システムレベルのテストケースを作成する必要がありますが、すべてのシナリオが可能であるとは限りません。

 

2つ目は、システムの残りの部分とそのテストメカニズムが利用可能になるまで待つ必要があります。これは、システム全体ではなく、FPGAのみの設計を担当する組織にとっては難しいことです。シミュレーションとバス機能モデル（BFM）は一般的なアプローチですが、これらは簡略化されており、FPGAベンダが提供するBFMはシミュレーション専用あり、インハードウェアテスト用ではありません。またPCIeの場合、BFMで検証できるのはIPブロックとのインターフェースのみになります。プロトコルの物理層はシミュレーションされません。

もう一つの方法は、PCIeブロックの抵抗-トランジスタ論理（RTL）バージョンの完全なシミュレーションを行うことです。デメリットとしては、所要時間が長くなることと、検証用IPを追加する必要があることが挙げられます。

 

最後に、非決定論的な振る舞いをするデザインを検証することは問題です。ハードウェアには、異なるクロックドメイン間でデータが受け渡されることによる非決定性があり、ソフトウェアの実行には、多くの非相関イベントを処理する非決定論的OSカーネル（Linuxなど）によってシステムが通常制御されることによる非決定性が存在します。

 

インハードウェア検証においてテストベクタを使用し、ビットレベルでデザインインターフェースを解析することは非常に困難であり、テストシナリオに厳密な制約がない限り、再現性のある一貫した結果を得ることは不可能になる可能性さえあります。図1aと1bに、キャプチャしたビットレベルの波形を比較した際に観察された、データ転送のシフトや順序の変更による典型的な影響を示します。

 

この記事の続きは、electronicsweeklyをご覧ください。