すべてではないにしても、多くの人がFPGAについて聞いています。 おそらく彼らと密接に連携した人もいましたが、FPGAプロジェクトの検証に出くわした人ははるかに少ないと思います。 今日は、検証プロセスについてお話します。
FPGAの機能検証は、FPGAの構成（以下、ファームウェアと呼びます）のエラーを見つけて修正するプロセスです。 ハードウェアのFPGAデバッグ段階ですべてを修正できるため、検証が必要な理由を教えてください。 可能ですが、非常に困難です。
まず、機能エラーのハードウェア検索では、かなり面倒で時間がかかるプロセスです。 これにより、プロジェクトの完了が遅れます。 かなり深刻なプロジェクトの場合、デバッグには数週間または数か月かかる場合があります。 ただし、検証を使用すると、モデル段階でほとんどの機能エラーを検出して修正できます。
経験豊富なFPGA開発者が間違いを犯さないか、非常に少ないと考えていますか？ します！ そしてかなりたくさん。
検証により、現在のエラーだけでなく、ブロックを使用して将来のプロジェクトで発生する可能性のある潜在的なエラーも検出できます。
検証は次の段階に分けることができます。
- TKの開発。
- 検証計画の開発。
- メンテナンス開発;
- テスト;
1.検証のための技術仕様の開発
ご存じのように、TKの開発に対する有能なアプローチは、プロジェクト全体の多くの問題を排除します。 検証のためのTKは、チェックが必要なユニットの機能と機能の完全かつ包括的なセットを記述する必要があります。 理想的には、検証用のTKが検証グループのチームリーダーを作成する必要があります。 これは、テストに携わる検証者の経験が少ない場合は特に重要です。 TKには次のアイテムが含まれている必要があります。
•プロジェクトの一部であり、作業を確認する必要があるすべてのブロックのリスト。
•検証が必要なすべての動作モード、機能、プロジェクト機能のリスト。
•他のプロジェクトから再利用される関数とメンテナンスクラスの列挙（たとえば、チェックサムの計算やデータ転送インターフェイスの操作のための関数セット）。
当然、TORの作成は、このプロジェクトに関するすべての必要な情報を受け取った後に開始する必要があります。
2.検証計画の開発
計画プロセスは、おそらく機能検証の最も重要で最も軽視されている段階です。 検証計画の作成は、開始前にプロジェクトを操作するための戦略と戦術の開発によって決定されます。 検証計画は、プロジェクトチームのガイドです。 適切な検証計画がないと、チームは多くの場合、エラーを見つけるために間違った方法を選択します。
検証計画には、詳細な説明を含むすべてのテストのセットが含まれます。
検証計画は、FPGA検証チームの主要なドキュメントです。 以降のすべての作業は、このドキュメントに基づいて行われます。 シノプシスとケイデンスのチップに基づくシステムのすべての「外来モンスター」は、メンテナンスの開発を開始する前に検証計画から開始することをお勧めします。 本質的に、検証計画は検証のためのより詳細なToRを提示します。
各テストの詳細な説明では、必要なすべてのプログラム可能なパラメーター、現在の動作モード、入力、出力、および参照データを示す必要があります。
3.メンテナンスの開発
FPGAコンフィギュレーションの開発とメンテナンスの開発は、並行して開始および実行する必要があることに注意してください。 検証プロセスはプロジェクト全体の開発時間の70％以上を要するため、この順序はプロジェクトの最小開発時間の観点から最適です。
これまでのすべての手順の情報に基づいて、テスト環境（以下、MOTと呼びます）の作成を開始できます。 MOTは通常、検証用に特別に作成されたプログラミング言語で記述されています。これは、MOTに必要なツールがすべて揃っているためです。 System Verilogは最適な言語の1つです。 この言語は、カプセル化、ポリモーフィズム、継承とともにC ++に非常に似ています。
テスト環境を開発するときは、「再利用性」を忘れないことを強くお勧めします。 適切な関数がない場合は、将来の使用の可能性を考慮して記述してください。 関数がある場合は、使用します。 他のテストに損傷を与える可能性なしに各テストを変更できるように、メンテナンスを編成する必要があります。 これにより、テストプロセス中にTOコードにいくつかの変更を入力する必要があるため、将来の問題を回避できます。
4.テスト
この段階では、検証者は開発者と最も密接に連携する必要があります。 テスト中にエラーが検出され、それらが検出されます。 そうでない場合、MOTは正常に動作していません。 エラーを検出した後、開発者にエラーについて通知する必要があります。 次に、修正後、検証者はテストを再度実行し、エラーが解決されたことを確認する必要があります。
理想的な方法は、バグ追跡システムを使用して、検証者と開発者の間で通信することです。 これにより、特定のプロジェクトまたは特定の開発者で頻繁に発生する問題を後で追跡できます。 同時に、検証者が自分のパンを食べても無駄ではないという証拠になります。
すべての開発者が自分の間違いを常に認めるとは限らないことを付け加えるべきだと思います。 この場合、プロジェクトの作業を明確に説明する作業指示書を参照する必要があります。