Другие необходимые условия

В дополнение к заявленным требованиям к продукту этот пример требует:

Обзор

Тест проверяет контроллер на соответствие его требованиям с помощью тестовых последовательностей, которые используют модели контроллеров верхнего уровня. Контроллер использует вход кнопки и вход датчика температуры, и выводит сигналы, управляющие вентилятором, скоростью вентилятора и лампой проектора.

Цель состоит в том, чтобы сгенерировать компонент DPI SystemVerilog, который захватывает требование высокого уровня 4 контроллера. Для получения дополнительной информации о требованиях см. документ word sltestProjectorCtrlReqs.docx в примере, указанном выше.

Требование 4 пытается включить и выключить проектор, когда температура проектора (Tproj) высока. Сценарий имеет следующие шаги в блоке Test Sequence:

На рисунке ниже показан испытательный стенд для вышеуказанного требования и как verify используется для проверки включения или выключения проектора в зависимости от сценария.

Настройте модель для генерации кода

Модель и испытательный стенд предварительно сконфигурированы с одним из системных целевых файлов DPI SystemVerilog (systemverilog_dpi_grt.tlc). Откройте тестовую обвязку Req_scenario_4 при выполнении:

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

sltest.harness.open(model,testHarness)

Сгенерируйте компонент DPI SystemVerilog

Обратите внимание, что некоторые предупреждения о верификации будут срабатывать, это будет объяснено позже.

Также можно сгенерировать компонент путем выполнения:

slbuild('Req_scenario_4/Req_4');

Запустите сгенерированный тестбенч в Симулятор HDL

В данном примере будет использоваться симулятор ModelsSim/QuestaSim. Подробные инструкции по запуску теста см. в разделе «Начало работы с генерацией компонентов DPI SystemVerilog».

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

Исследуйте выходы симуляции и заметьте следующее:

Ошибка согласуется с результатами симуляции в Simulink (ниже). Открытие Test Manager показывает, что контроллер не выключается, когда кнопка on_off нажата, когда температура выше предела. Чтобы открыть менеджер тестов, можно выполнить:

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

Для разрешения отказа потребуется изменить подсистему проверки OnOff в основной модели. Другое требование, verify_sc4_on, удовлетворен, как показано как в Simulink Test, так и в результатах покрытия SystemVerilog.

Трассировка ошибки SystemVerilog назад в Simulink

Если вы хотите проследить оператор проверки, который сгенерировал ошибку назад в Simulink, вам нужно найти Simulink Identifier (SID) из сообщения об ошибке, как показано ниже:

Как только вы найдете SID для идентификатора шага в блоке тестовой последовательности, вы можете использовать программные API Simulink, чтобы выделить соответствующий блок. Для получения дополнительной информации смотрите Simulink Identifiers (Simulink). Выполните следующую команду:

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

Будет выделен соответствующий блок, как показано ниже.

Фильтрация определенной проверки

Чтобы фильтровать все проверки состояния проверки в Симулятор HDL, укажите SID оценки, которую вы хотите фильтровать как аргумент plusargs, в Симулятор HDL. Такой фильтр будет означать отсутствие ошибок и отсутствие покрытия для этой оценки. Для образца можно фильтровать ошибку, которая verify_sc4_off приводит путем подачи аргумента «+ Req _ scenario _ 4:32:60» в симулятор HDL. Вы можете сделать это через переменную окружения, поэтому вам не нужно изменять сгенерированный скрипт.

% 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 теперь показывает:

Увеличение цели покрытия конкретной проверки

Можно также изменить требуемую функциональную цель покрытия для любой оценки, предоставив положительное значение плюс arg. Цель по умолчанию состоит в том, чтобы увидеть по крайней мере 1 состояние PASS для проверяемого вызова. Если вы хотите убедиться, что было по крайней мере 2 проверки статуса PASS, вы поставляете значение «2» в качестве значения плюс arg.

% 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, и поэтому тест в целом также не является.

Log Pass, Fail и Untested Status for All Verify Assessment

Можно добавить выход журнала для всех проверок состояния для всех нефильтрованных verify вызовы путем добавления + VERBOSE _ VERIFY плюс arg. Это может быть полезно, если необходимо проверить время и распределение значений статуса проверки 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.

Заключение

Генерация компонентов SystemVerilog DPI и блок Test Sequence из Simulink Test™ могут использоваться, чтобы перенести логику верификации из Simulink в Симулятор HDL с минимальными усилиями.