このページは機械翻訳を使用して翻訳されました。
翻訳品質のアンケートに 1 分ご協力ください。
車載 ASIC 開発におけるモデルベース検証の適用
著者 Allegro MicroSystems 社 Aswini Tata 氏、Sanjay Chatterjee 氏、Kamel Belhous 氏、および Cyient 社 Surekha Kollepara 氏
顧客からの要求がますます厳しくなり、納期が短縮されていく中、当社が採用したモデルベースの検証アプローチのおかげで、チームはさらに短いスケジュールでより洗練されたアルゴリズムとシステムを市場に投入できるようになりました。
自動車業界にサービスを提供する半導体企業では、エンジニアリング チームに厳しいスケジュール内でますます複雑化するシステムを提供することが求められています。これらの厳しい期限を守るには、後期段階のテストに関連する困難が伴います。たとえば、RTL が利用可能になるまで待ってから機能検証を開始すると、コスト超過や納期遅延のリスクが生じます。この段階で見つかった設計上の欠陥や要件の問題は、修正コストが高額で修正も困難であり、チームは非現実的なシナリオのデバッグに貴重な時間を浪費します。このような環境において、シフトレフトテストを開発サイクルのできるだけ早い段階で検証活動を実施することで、このような後期段階のテストの課題に対処します。
Allegro MicroSystems 社のチームの一部は、ミックスドシグナル ASIC の HDL コードの生成と、RTL レベルの検証用のユニバーサル検証方法論 (UVM) テストベンチの生成を組み込んだ、DSP ブロックのモデルベース設計を使用した新しいシフトレフト アプローチを採用しました。 このモデルベースの検証アプローチにより、Simulink® とシステム エンジニアと検証チーム間のコラボレーションを容易にする設計のシステム レベルのビューで早期機能検証のメリットが得られます。(図 1)。早期のモデル検証により、コード生成前に高レベルの設計と要件の問題が検出され、排除されるため、HDL 品質が向上します。この早期のバグ検出により、検証作業を 2 か月節約できると期待しています。さらに、UVM 環境での HDL 実装の厳格なテストと、プロジェクト間でのモデルやテスト資産の再利用からもメリットを得られます。
要件から実行可能な仕様、そして実装まで
従来の開発ワークフローでは、システム エンジニアがテキストベースの要件を作成し、デジタル設計チーム (システム アーキテクトと RTL エンジニア) がそれを使用して仕様を作成し、そこから RTL 設計を作成します。デジタル検証チームの私たちのグループは、仕様と機能検証に基づいてテスト計画を作成し、RTL 設計が仕様に準拠していることを確認する責任を負います。このワークフローでは、欠陥が検出された場合 (通常は開発ライフサイクルの後半)、欠陥の根本原因が実装、仕様、または元の要件のいずれにあるかを判断するのに長い時間がかかることがあります。
現在のアプローチでは、ワークフローはアーキテクチャと要件の検証をより早い段階で行えるように設計されています。システムエンジニアにより要件が Jama Connect® で定義されると、デジタル設計チームは Simulink でアーキテクチャ仕様モデルを作成します。このモデルは、システムの実行可能な仕様として機能します。このモデルを使用してシミュレーションを実行することにより、チームはモデルインザループのユニットテストと統合テストを実行し、要件を検証してアーキテクチャを検証します (図 2)。このアプローチを使用した最初のプロジェクトでは、これらのシミュレーションにより、条件文が互いに矛盾し、一部の入力刺激の組み合わせに対して無効な出力が生じるシナリオなど、いくつかの問題を特定することができました。
開発の次の段階では、チームは HDL Coder™ によるコード生成に備えて、アーキテクチャ モデルをより「ハードウェアに適した」実装モデルに変換します。これには、たとえば、アルゴリズムを浮動小数点から固定小数点に変換したり、フレームベースの処理からストリーミングに切り替えたりすることが含まれます。
Simulink でのテストベンチ モデルと検証
デジタル設計チームが実装モデルでコンポーネントを構築すると、それらのコンポーネントの Simulink テストベンチ モデルが並行して開発されます。各 Simulink テストベンチ モデルには、UVM コンポーネントに対応する次のサブシステムが含まれています: シーケンス、ドライバー、DUT、予測子、モニター、スコアボード (図 3)。HDL Verifier™ を使用したテストベンチ生成には、シーケンス、DUT、スコアボード サブシステムのみが必要です。
シーケンス サブシステムは、テスト対象のデバイス (DUT サブシステム) に対して刺激を生成します。このワークフローでは、Simulink で作成された実装モデルが使用されます。このサブシステムは MATLAB® コードとテストシーケンスブロックを含む Simulink ブロックを用いて刺激を作成してランダム化します。シード入力は、 MATLAB 乱数ジェネレーターを初期化するために使用されます。スコアボード サブシステムは DUT の出力を収集し、それを DPI-C のアサーション ブロック経由で予想出力と比較します。これは、SystemVerilog アサーションを含む DPI-C コンポーネントを生成するために使用されます (図 4)。(SystemVerilog ダイレクト プログラミング インターフェイス [DPI] は、SystemVerilog と C などの外部プログラミング言語との間のインターフェイスです。HDL Verifier は、C コードと SystemVerilog ラッパー コードで構成される DPI-C コンポーネントを生成できます。生成された DPI-C コンポーネントは、SystemVerilog をサポートする HDL シミュレーターで実行できます。)
Simulink Test™ などのさまざまなモデル検証および妥当性確認ツールとともにテストベンチ モデルを使用して Simulink でシミュレーションを実行すると、要件に対して実装モデルをさらに検証できます。要件ベースのテストを容易にするために、これらのシミュレーションの結果を Simulink から Jama に戻します。さらに、Simulink Design Verifier™ を使用して、モード内のデッド コード ロジックを識別することもできます。
コード生成、テストベンチ生成、HDLシミュレーションとテスト
実装モデルとテストベンチ モデルが構築され、Simulinkでのワークフローの設計検証フェーズを完了するために使用されたら、次のフェーズを開始します。HDL コードの生成と検証。このフェーズでは、HDL Coder を使用して、実装モデル コンポーネントから合成可能な HDL コードを生成します。また、HDL Verifier (具体的には ASIC テストベンチアドオンからの uvmbuild
関数) を使用して、Simulink のテストベンチ モデルから完全な UVM テストベンチを生成します (図 5)。(ASIC テストベンチに含まれる別の関数、dpigen
は、UVM 環境を使用していない設計チーム向けに、MATLAB コードまたは Simulink モデルから DPI-C コンポーネントを生成します。)
生成されたテストベンチを使用して、UVM 環境でテストを実行します。これは、実装モデルから Cadence® Xcelium™ シミュレータなどのデジタルシミュレータを使用して生成されたコードに対して実行されます(図 6)。必要に応じて、生成された UVM テストベンチを拡張し、より複雑な制約付きランダム化、アサーション チェッカー、および機能カバレッジ分析用の SystemVerilog カバー グループを追加します。UVM 環境でテストが失敗した場合、失敗したテストのシードとメモリ構成を使用して、 Simulink シミュレーションで障害状態を再現します。これにより、HDL レベルで直接デバッグする場合と比較して、設計エンジニアが障害をデバッグして修正することがはるかに簡単になります。
次のステップ
顧客からの要求がますます厳しくなり、納期が短縮されていく中、当社が採用したモデルベースの検証アプローチのおかげで、チームはさらに短いスケジュールでより洗練されたアルゴリズムとシステムを市場に投入できるようになりました。私たちは、このシフトレフトの概念を他のプロジェクトにも拡張することを計画しており、検証チームによるモデルと関連する Simulink テスト環境の再利用により、Allegro の中程度の複雑度のプロジェクトでの開発作業をさらに 2 か月節約できると期待しています。今後は、システム エンジニアリング チームとお客様がモデルを再利用する機会も模索していきます。
公開年 2024