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

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

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

この例では、モデルシミュレーションを使用してプロジェクター制御システムをテストする方法と、テストシーケンスブロックで指定されているコントローラーの高レベル要件の一部に対して 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) が高いときにプロジェクターの電源をオン/オフにしようとします。シナリオには、テストシーケンスブロックに次の手順があります。

プロジェクターの温度を 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 チェックサブシステムを変更する必要があります。他の要件 verify_sc4_on は、Simulink Test と SystemVerilog カバレッジ結果の両方に示されているように満たされています。

SystemVerilog エラーを Simulink まで追跡する

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

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

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

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

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

HDL シミュレーターで検証評価ステータスチェックをフィルター処理するには、フィルター処理する評価の SID を plusargs 引数として HDL シミュレーターに指定します。このようなフィルターは、エラーがなく、その評価に対してカバレッジがチェックされないことを意味します。たとえば、HDL シミュレータに引数「+Req_scenario_4:32:60」を指定することで、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 とマークされます。
機能カバレッジは、有効な評価に対してカバレッジが達成されていることを示しています
全体的な機能カバレッジ目標は達成されます。

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

また、plus 引数に正の値を指定することにより、任意の評価の目的の機能カバレッジ目標を変更することもできます。デフォルトの目標は、検証呼び出しに対して少なくとも 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 plus 引数を追加することで、フィルタリングされていないすべての 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 エラーとして表示されることに注意してください。