デザインに入り込むハードウェアバグは、

　A. ヒューマンエラーによる設計時のバグ

　B. 自動化されたインプリメンテーション・ツールチェーンに起因するバグ

の2タイプに分類されます。

A は通常、機能検証によって見つけることが可能です。B は論理合成や配置配線のフェーズで混入し、検出やデバッグはとても困難ですが、通常、FPGA ではインプリメンテーション・フェーズ間の検証はおこなわれません。

日々進化する論理合成や配置配線の最適化技術は、複雑なアルゴリズムで実行されていますが、この最適化に不具合があると、ネットリストに問題が生じ、実機で不具合を起こしてしまいます。また、よく「トロイの木馬」に例えられる不正ロジックをインプリメンテーション・フェーズで挿入されてしまう可能性も考慮する必要があります。そのため、インプリメンテーション・フェーズにおいても、RTL の機能がネットリストに正しく実装されていることを検証する必要があります。

これら、インプリメンテーションに由来する不具合や課題を解決するには、ASIC 開発で使われている等価性検証を利用します。FPGA であっても RTL とネットリストの等価性検証をおこなう事は、主要な機能安全規格でも推奨されています。

本ウェビナーでは、FPGA 向け等価性検証技術で、いかにインプリメンテーション時の不具合の混入リスクや課題を克服するか、そして、必要な検証手法と顧客事例をご紹介いたします。

大規模 FPGA における等価性検証の事例