デザインに入り込むハードウェアバグには大きく2つのタイプがあり、1つは、ヒューマンエラーによる設計時のバグです。通常、これは機能検証によって見つけることが可能です。もう1つは、自動化されたインプリメンテーション・ツールチェーンに起因するバグです。このバグは、論理合成や配置配線のフェーズで混入し、検出やデバッグはとても困難ですが、通常、FPGAではインプリメンテーション・フェーズ間の検証は行われません。いずれにしても開発者は、どちらのバグ混入リスクも製品から排除しなければなりません。
日々進化する論理合成や配置配線の最適化技術は、複雑なアルゴリズムで実行されていますが、この最適化に不具合があると、ネットリストに問題が生じ、実機で不具合を起こしてしまいます。また、よく「トロイの木馬」に例えられる不正ロジックをインプリメンテーション・フェーズで挿入されてしまう可能性も考慮する必要があります。そのため、インプリメンテーション・フェーズにおいても、RTLの機能がネットリストに正しく実装されていることを検証する必要があります。この検証には、RTL検証で使用したテストベンチを使ったゲートレベルの機能シミュレーションが考えられますが、ゲートレベルシミュレーションはRTLシミュレーションより多くの時間がかかります。さらに、配置配線後のネットリストがRTLと等価であることを担保するには、検証の網羅性という観点からみて不十分です。
次に、FPGA設計者が直面する課題として、サプライチェーンの問題などで、レガシーデバイスから新しいデバイスにデザインを乗せ換える場合があります。乗せ換え時に使う最新の論理合成ツールは、設計言語の解釈や最適化手法が当時のものと異なるため、同等の合成結果を得られない可能性があります。 これら、インプリメンテーションに由来する不具合や課題を解決するには、ASIC開発で使われている等価性検証を利用します。FPGAであってもRTLとネットリストの等価性検証を行う事は、主要な機能安全規格でも推奨されています。
本ウェビナーでは、FPGA向け等価性検証技術で、いかにインプリメンテーション時の不具合の混入リスクや課題を克服するか、そして、必要な検証手法と顧客事例をご紹介いたします。
プログラム
セッション: FPGA設計プロセスにおけるリスクの排除と課題の克服
Q&A

シニア・アプリケーション・エンジニア
團 真彦は、1991年にシーメンスEDAジャパン株式会社(旧メンター・グラフィックス・ジャパン株式会社)に入社しました。大阪支店を拠点として、HDL設計検証に関する技術分野を中心に活動し、現在では機能安全系の分野にも携わっております。機能検証、機能安全など、主に上流系のアプリケーション・エンジニアとして、お客様の課題解決に向けて取り組んでおります。