このページは機械翻訳を使用して翻訳されました。最新版の英語を参照するには、ここをクリックします。

Simulink Test`verify`呼び出しからの SystemVerilog での機能カバレッジの生成

この例では次を使用します。

この例では、モデルシミュレーションを使用してプロジェクター制御システムをテストする方法と、Test Sequence ブロックで指定されたコントローラーの高レベル要件の一部に対して SystemVerilog DPI コンポーネントを生成する方法を示します。これにより、モデルシミュレーションに使用される要件検証を最小限の労力で HDL シミュレーターで再利用できるようになります。

このモデルは、 Simulink Test ™ に同梱されているサンプルProjector Controller Testing Using verify and Real-Time Tests (Simulink Test)から取得され、要件シナリオ 4 のみを示すように簡略化されています。

verify ステートメントの詳細については、「 verify ステートメントを使用したモデルのシミュレーションの評価 (Simulink Test) 」を参照してください。

その他の前提条件

この例では、記載されている製品要件に加えて、次のものが必要です。

サポートされている HDL シミュレーター。UVM および DPI コンポーネントの生成要件を参照してください。
サポートされている C コンパイラ。C または C++ コンパイラの選択と設定 (Simulink Coder)を参照してください。

概要

テストでは、最上位コントローラーモデルを実行するテストシーケンスを使用して、要件に照らしてコントローラーを検証します。コントローラーは押しボタン入力と温度センサー入力を使用し、ファン、ファン速度、プロジェクターランプを制御する信号を出力します。

目的は、コントローラーの高レベル要件 4 を取り込む SystemVerilog DPI コンポーネントを生成することです。要件の詳細については、上記の例の Word ドキュメントsltestProjectorCtrlReqs.docxを参照してください。

要件 4 では、プロジェクターの温度 (Tproj) が高いときにプロジェクターの電源のオンとオフを試みます。このシナリオの Test Sequence ブロックには次のステップがあります。

プロジェクターの温度を摂氏 50 度に設定します。
オンにしてみてください。
システムの電源がオンにならないはずです。
温度を摂氏50度に設定します。
オフにしてみてください。
システムの電源がオフになるはずです。

下の図は、上記の要件のテストベンチと、シナリオに応じてプロジェクターの電源がオンまたはオフになることを確認するためにverify がどのように使用されるかを示しています。

コード生成用のモデルをセットアップする

モデルとテストベンチは、SystemVerilog DPI システムターゲットファイル (systemverilog_dpi_grt.tlc) の 1 つを使用して事前構成されています。次のコマンドを実行して、テストハーネスReq_scenario_4を開きます。

testFile = 'svdpi_sltestProjectorCtrlTests.mldatx';
testHarness = 'Req_scenario_4';
model = 'svdpi_sltestProjectorController';
open_system(model)

sltest.harness.open(model,testHarness)

SystemVerilog DPI コンポーネントの生成

Req_scenario_4 テストベンチで、テストシーケンスブロックを含む Req_4 サブシステムブロックを右クリックして選択します。「C/C++ コード -> このサブシステムを構築する」。
表示されるダイアログボックスで「ビルド」をクリックします。
このビルドでは、Req_4 サブシステムの C コードと、SystemVerilog DPI ラッパーおよび「Req_4_build/Req_4_dpi.sv」および「Req_4_build/Req_4_dpi_pkg.sv」という名前のパッケージファイルが生成されます。

いくつかの検証警告がトリガーされることに注意してください。これについては後で説明します。

あるいは、次のコマンドを実行してコンポーネントを生成することもできます。

slbuild('Req_scenario_4/Req_4');

HDL シミュレーターで生成されたテストベンチを実行する

この例では、ModelsSim/QuestaSim シミュレーターが使用されます。テストベンチの実行方法の詳細については、 SystemVerilog DPI コンポーネントの生成を開始するを参照してください。

cd Req_4_build/dpi_tb
! vsim -c -do run_tb_mq.do  # Run ModelSim/QuestaSim in console mode
cd ../..

HDL シミュレーションの出力を調べると、次のことがわかります。

情報メッセージには、コンポーネント内の 2 つの検証呼び出しに対して機能カバレッジが収集されることが示されます。
温度が制限を超えたときにコントローラーがシャットオフできないというエラーフラグが立てられています。
SystemVerilog シミュレーション結果がSimulinkシミュレーション結果と一致するため、テストは PASSED としてマークされます。
機能カバレッジは、最初の検証呼び出しではカバレッジが達成されたが、2 番目の検証呼び出しでは達成されていないことを示しています。
全体的な機能範囲の目標は達成されていません。

この誤差は、 Simulinkでのシミュレーション結果と一致しています (下記)。テストマネージャーを開くと、温度が制限値を超えているときに on_off ボタンを押してもコントローラーがシャットオフに失敗していることがわかります。テストマネージャーを開くには、次のコマンドを実行します。

sltest.testmanager.load(testFile);
sltest.testmanager.view;

この障害を解決するには、メインモデルの OnOff チェックサブシステムを変更する必要があります。Simulink Testと SystemVerilog の両方のカバレッジ結果に示されているように、もう 1 つの要件verify_sc4_onは満たされています。

SystemVerilog エラーをSimulinkに遡ってトレースする

エラーを生成した verify ステートメントをSimulinkまで追跡する場合は、以下に示すように、エラーメッセージからSimulink識別子 (SID) を見つける必要があります。

テストシーケンスブロック内のステップ ID の SID を見つけたら、関数を使用して対応するブロックを強調表示できます。次のコマンドを実行します。

Simulink.ID.hilite('Req_scenario_4:32:60');

これにより、以下に示すように、関連するブロックが強調表示されます。

特定の検証評価をフィルタリングする

HDL シミュレーターで検証ステータスチェックをフィルターするには、フィルターする評価の SID を HDL シミュレーターの plusargs 引数として指定します。このようなフィルターはエラーがないことを意味し、その評価のカバレッジはチェックされません。たとえば、引数 "+Req_scenario_4:32:60" を HDL シミュレータに指定することで、verify_sc4_offが生成するエラーをフィルタリングできます。これは環境変数を通じて実行できるため、生成されたスクリプトを変更する必要はありません。

% Clear environment variables that influence the SV simulation
setenv EXTRA_SVDPI_COMP_ARGS
setenv EXTRA_SVDPI_SIM_ARGS

% Filter the failing verify()
setenv EXTRA_SVDPI_SIM_ARGS +Req_scenario_4:32:60=-1
cd Req_4_build/dpi_tb
! vsim -c -do run_tb_mq.do  # Run ModelSim/QuestaSim in console mode
cd ../..

HDL シミュレーションが次のように表示されることに注目してください。

検証評価の 1 つがフィルタリングされていることを示す警告
他の評価のためにカバレッジが収集されるという情報メッセージ
もうエラーはありません。
SystemVerilog シミュレーション結果がSimulinkシミュレーション結果と一致するため、テストは PASSED としてマークされます。
機能カバレッジは、有効な評価に対してカバレッジが達成されていることを示します。
全体的な機能範囲の目標は達成されています。

特定の検証評価のカバレッジ目標を増やす

プラス引数に正の値を指定することで、任意の評価に必要な機能カバレッジの目標を変更することもできます。デフォルトの目標は、検証呼び出しに対して少なくとも 1 つの PASS ステータスを確認することです。少なくとも 2 つの検証 PASS ステータスチェックがあることを確認したい場合は、プラス引数値として「2」を指定します。

% Clear environment variables that influence the SV simulation
setenv EXTRA_SVDPI_COMP_ARGS
setenv EXTRA_SVDPI_SIM_ARGS

% Filter the failing |verify| and set a coverage goal of 2 for the other |verify|
setenv EXTRA_SVDPI_SIM_ARGS '+Req_scenario_4:32:60=-1 +Req_scenario_4:32:39=2'
cd Req_4_build/dpi_tb
! vsim -c -do run_tb_mq.do  # Run ModelSim/QuestaSim in console mode
cd ../..

HDL シミュレーションでは、フィルターされていないverify が少なくとも 2 PASS のカバレッジ目標を満たしておらず、したがってテスト全体も満たしていないことが示されていることに注意してください。

すべての検証評価の合格、不合格、および未テストのステータスをログに記録する

+VERBOSE_VERIFY と引数を追加することで、フィルターされていないすべてのverify呼び出しのすべてのステータスチェックのログ出力を追加できます。これは、UNTESTED、PASS、および FAIL 検証ステータス値のタイミングと分布を確認する必要がある場合に便利です。

% Clear environment variables that influence the SV simulation
setenv EXTRA_SVDPI_COMP_ARGS
setenv EXTRA_SVDPI_SIM_ARGS

% Log every status check.
setenv EXTRA_SVDPI_SIM_ARGS +VERBOSE_VERIFY
cd Req_4_build/dpi_tb
! vsim -c -do run_tb_mq.do  # Run ModelSim/QuestaSim in console mode
cd ../..

HDL シミュレーションでは、UNTESTED および PASS の各ステータスチェック値が SystemVerilog infoメッセージとして表示され、各 FAIL ステータスが SystemVerilog エラーとして表示されることに注意してください。