機能検証とは、 論理設計が 仕様に準拠していることを検証する作業です。 [ 1 ] [ 2 ] [ 1 ] 機能検証は、より包括的な設計検証 の一部であり、設計検証では、機能検証に加えて、タイミング、レイアウト、電力などの非機能的な側面も考慮します。[ 3 ]
背景 ムーアの法則 によればトランジスタの数は指数関数的に 増加しているが、設計の作成に必要なエンジニアの数と時間は線形的に しか増加していない。トランジスタの複雑さが増すにつれて、コーディングエラーの数も増加する。ロジックコーディングのエラーのほとんどは、不注意なコーディング（12.7%）、コミュニケーションの誤り（11.4%）、マイクロアーキテクチャの 課題（9.3%）に起因する。[ 1 ] 電子設計自動化（EDA）ツールが開発されている。Verilogや VHDL などの言語は、EDAツールとともに導入されている。[ 1 ]
機能検証は、単純な設計であっても存在するテストケースの膨大な量のため、非常に困難です。多くの場合、80 プログラム検証 に匹敵し、NP困難 、あるいはそれ以上に困難であり、あらゆる場合にうまく機能する解決策はまだ見つかっていません。
検証プロセスと戦略
検証計画 機能検証プロジェクトは検証計画に基づいて進められます。これは、プロジェクト全体の設計図となる基礎的な文書です。設計サイクルの初期段階で作成される生きた文書であり、スコープの定義と進捗状況の追跡に不可欠です。計画では通常、以下を定義します。[ 4 ]
検証範囲： 検証が必要な設計上の特徴と機能の一覧。方法論： 使用する技術（例：シミュレーション、エミュレーション、形式手法）および標準化された方法論（例：UVM ）。 必要なリソース： エンジニアリングチーム、EDA ツール、および計算インフラストラクチャ。成功基準： 検証が完了したとみなされるために満たさなければならない具体的なカバレッジ目標。
カバレッジ指標 検証作業の完全性を測定するために、エンジニアはカバレッジ 指標に頼ります。[ 4 ]
コードカバレッジ：これは、 ハードウェア記述言語 （HDL）のソースコードがテスト中にどれだけ徹底的に実行されたかを測定するものです。ステートメントカバレッジ、ブランチカバレッジ、トグルカバレッジなどの指標が含まれます。機能カバレッジ： これは、検証計画に記載されている意図された機能がテストされたかどうかを測定するものです。エンジニアは対象となる特定のシナリオやデータ値を定義し、検証ツールはこれらのケースが実行されたかどうかを追跡します。
検証における抽象化レベル 機能検証は単一のモノリシックなタスクではなく、チップの開発に伴って設計抽象化のさまざまなレベルで適用される継続的なプロセスです。この階層的なアプローチは、現代のSoCの膨大な複雑さを管理するために必要です。[ 5 ] [ 4 ]
ユニット/ブロックレベルの検証: これは最も細かいレベルで、個々の設計モジュールまたは「ユニット」（たとえば、単一の FIFO、ALU、またはデコーダ）が個別にテストされます。目標は、設計の小さな部分がより大きなシステムに統合される前に、その機能を徹底的に検証することです。[ 5 ] サブシステム/IPレベルの検証: この段階では、複数のユニットが統合されて、サブシステムまたは知的財産 (IP) コア (完全なメモリコントローラ やプロセッサコアなど) と呼ばれる、より大きな機能ブロックが形成されます。このレベルでの検証は、統合されたユニット間の結合された機能と相互作用に焦点を当てます。この段階での一般的な戦略は、ブロックの高レベルの機能表現であるビヘイビアモデルを使用することです。これらのモデルは、詳細な RTL コードよりも高速にシミュレートされ、最終設計が完了する前に検証を開始できるため、インターフェース仕様を形式化し、バグを早期に発見するのに役立ちます。[ 4 ] SoC/チップレベルの検証: すべてのサブシステムとIPブロックが利用可能になったら、それらを統合して完全なシステムオンチップ(SoC)を形成します。チップレベルでの機能検証は、これらすべての主要ブロック間の正しい接続と相互作用の検証に重点を置いています。システムレベルのシミュレーションを実行して、 ASIC 間のインターフェースを証明し、複雑なプロトコルエラー条件をチェックします。[ 4 ] システムレベルの検証： これは最も抽象度の高いレベルで、検証対象のチップの機能が、他のチップ、周辺機器、ソフトウェアなどを含む完全なシステムのコンテキストでテストされます。ハードウェアエミュレーションはこの段階で重要な技術であり、その高速性により、デバイスドライバや設計上での完全なオペレーティングシステム の起動など、実際のソフトウェアを実行できます。これにより、シミュレーションでは再現が非常に難しい「豊富な刺激」が得られ、システムレベルのバグを見つけるのに非常に効果的です。[ 4 ]
検証方法 徹底的なテストは不可能であるため、検証問題に取り組むには複数の手法を組み合わせる必要がある。これらは大きく分けて、動的アプローチ、静的アプローチ、およびハイブリッドアプローチに分類される。
動的検証 とは、与えられた一連の入力刺激を用いて設計モデルを実行し、その出力が正しい動作をしているかどうかを確認することです。これは最も広く用いられている手法です。[ 1 ]
論理シミュレーション ：エミュレーション とFPGAプロトタイピング：FPGA ボード）にマッピングします。シミュレーションよりも桁違いに高速に動作するため、オペレーティングシステムの起動など、実際のソフトウェアを使用したより広範なテストが可能になります。 [ 5 ] シミュレーション高速化： これは、専用ハードウェアを使用して論理シミュレーションの一部を高速化するものです。現代のシミュレーションテストベンチは、複雑なソフトウェア環境です。主要な構成要素としては、刺激を生成するジェネレータ（多くの場合、制約付きランダム生成手法を使用）、刺激をピンレベルの信号に変換するドライバ、出力を監視するモニタ、そして参照モデルと比較して結果を検証するチェッカー（またはスコアボード）などがあります。
静的検証 静的検証は、テストベクトルを使用して実行せずに設計を分析します。[ 1 ]
形式検証 ：リンティング ： HDL 専用のリンティングツールを使用して、一般的なコーディングスタイルの違反、構文エラー、およびコード内の潜在的に問題のある構造をチェックする作業です。
ハイブリッド技術 これらのアプローチは、複数の検証技術を組み合わせてより良い結果を得る。例えば、形式手法を用いて、到達困難なコーナーケースを対象とした特定のテストを生成し、それをよりスケーラブルなシミュレーション環境で実行することができる。[ 6 ]
シミュレーション環境の構成要素 シミュレーション環境は通常、いくつかの種類のコンポーネントで構成されています。
ジェネレータは SATソルバー を利用します。他のタイプのジェネレータには、手動で作成されたベクトルやグラフベースのジェネレータ（GBM）などがあります。最新のジェネレータは、設計のランダムな部分を検証するために統計的に駆動される、方向性のあるランダム刺激とランダム刺激を生成します。ランダム性は、利用可能な入力刺激の膨大な空間にわたって高い分布を実現するために重要です。この目的のために、これらのジェネレータのユーザーは、生成されるテストの要件を意図的に過小指定します。このギャップをランダムに埋めるのがジェネレータの役割です。このメカニズムにより、ジェネレータはユーザーが直接検索していないバグを明らかにする入力を作成できます。ジェネレータはまた、ロジックをさらにストレスを与えるために、刺激を設計のコーナーケースに偏らせます。偏りとランダム性は異なる目的を果たし、それらの間にはトレードオフがあるため、異なるジェネレータはこれらの特性の異なる組み合わせを持っています。設計の入力は有効でなければならず、バイアスなどの多くの目標値も維持する必要があるため、多くのジェネレーターは制約充足問題 （CSP）手法を用いて複雑なテスト要件を解決します。設計入力の有効性とバイアス設定の妥当性がモデル化され、モデルベースのジェネレーターはこのモデルを用いて目標設計に適した刺激を生成します。 ドライバは、 アセンブリ言語 といった高レベルの抽象度で入力を生成します。ドライバは、この入力を、設計のインターフェース仕様で定義された実際の設計入力に変換します。 シミュレータは モニターは チェッカーは 、スコアボードの内容が正当であることを検証します。ジェネレーターが入力値に加えて期待される結果を生成する場合があります。このような場合、チェッカーは実際の結果が期待される結果と一致することを検証する必要があります。 仲裁管理者は、 上記のすべての要素をまとめて管理します。
専門的な設計領域における検証
低消費電力検証 最新のSoCは 、パワーゲーティングや複数の電圧ドメインなど、エネルギーを節約するための高度な電力管理技術を採用しています。これらの低消費電力機能が正しく動作することを検証することは、電源オフおよび電源オンシーケンス中にロジック状態が正しく分離、保持、復元されることを保証するという重要なタスクです。これは通常、検証ツールをガイドするUnified Power Format （UPF）などの標準化された形式で電力インテントを指定することによって管理されます。[ 4 ]
新たなトレンド
機能検証における機械学習 機械学習 （ML）は、効率と有効性を向上させるために、機能検証のさまざまな側面に適用されています。MLモデルは、検証プロセスからの大規模なデータセットを分析してパターンを特定し、予測を行うことができます。主なアプリケーションは次のとおりです。[ 7 ]
自動テスト 生成：バグの 予測と特定：カバレッジ分析： 残りのカバレッジの穴を埋めるのに最も効果的なテストを予測することで、カバレッジ目標を達成するプロセスを最適化し、回帰テストの長さを短縮します。
ハードウェアセキュリティ検証 電子システムが重要なアプリケーション（AI、自動車など）に統合されるにつれて、ハードウェアのセキュリティを確保することが検証の重要な部分となっています。現在、このプロセスは機能的なバグに加えてセキュリティの脆弱性を検出するように適応されています。これには、次のような脅威のテストが含まれます。[ 8 ]
ハードウェアトロイの木馬 ：これらは、バックドアを作成したり、特定の条件下でシステムを故障させたりする可能性のある、設計に対する悪意のある隠れた改変です。検証では、このような意図しない悪意のある機能を発見するよう努める必要があります。 サイドチャネル攻撃 ：これは、消費電力や電磁波放射などの物理的特性を通じて情報が漏洩する脆弱性です。従来はシリコン製造後の問題とされていましたが、現在ではシリコン製造前の検証を用いて、このような攻撃に対する設計の脆弱性を分析するようになっています。
参考文献 1 2 3 4 5 6 Molina, A; Cadenas, O (2006年9月8日). "機能検証: アプローチと課題" . Latin American Applied Research . 37. ISSN 0327-0793 . 2022年10月16日にオリジナルからアーカイブ済み。 2022年 10月12日 取得 。 ↑ Rezaeian, Banafsheh; Rodrigues, Dr. Joachim; Rath, Alexander W. 「混合信号車載ICのシミュレーションと検証方法」 . ルンド大学、電気情報技術学部 . ↑ ストラウド、チャールズ E; チェンジ、ヤオチャン (2009). 「第 1 章 – はじめに」 . デザイン検証 . pp. 1–38 . doi : 10.1016/B978-0-12-374364-0.50008-4 . ISBN 978-0-12-374364-0 2022年10月12日にオリジナルからアーカイブされました。2022年 10月11日 に取得されました 。1 2 3 4 5 6 7 8 Mehta, Ashok B. (2018). ASIC/SoC 機能設計検証 . doi : 10.1007/978-3-319-59418-7 . ISBN 978-3-319-59417-0 。1 2 3 Evans, Adrian; Silburt, Allan; Vrckovnik, Gary; Brown, Thane; Dufresne, Mario; Hall, Geoffrey; Ho, Tung; Liu, Ying (1998-05-01). "大規模ASICの機能検証" . 第35回設計自動化会議（DAC '98）議事録 . ニューヨーク州ニューヨーク、米国：Association for Computing Machinery. pp. 650–655 . doi : 10.1145/277044.277210 . ISBN 978-0-89791-964-7 。↑ Bhadra, Jayanta; Abadir, Magdy S.; Wang, Li-C.; Ray, Sandip (2007 年 3 月). "機能検証のためのハイブリッド技術の調査". IEEE Design & Test of Computers . 24 (2): 112–122 . Bibcode : 2007IDTC...24..112B . doi : 10.1109/MDT.2007.30 . ISSN 1558-1918 . ↑ A.、 イスマイル 、 カレド、ガーニー、モハメド A. アブド エル (2021 年 1 月)。 「 機能検証プロセスを強化する機械学習アルゴリズムに関する調査」 。Electronics。10 ( 21 ) : 2688。doi : 10.3390/electronics10212688。ISSN 2079-9292 。 {{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)↑ O, Emma; Packwood, Jack; Oistein, Michael. "ASIC設計検証の将来動向：AIシステムにおける機械学習とハードウェアセキュリティの融合" . researchgate.net . 