В этом примере показано, как управлять параметрами средства проверки отклика на тестовом стенде UVM, созданном на основе Simulink ®. Такая параметризация помогает инженеру по проверке проекта повторно использовать табло при различных сценариях тестирования. Параметры simulink для проверки приведут к объекту конфигурации, значения которого могут быть заданы в производном классе теста (рандомизированном или нет) или непосредственно через командную строку плюс arg.
См. пример Generate Parameterized UVM Test Bench from Simulink описание конструкции и предыстории создания испытательного стенда UVM. Чтобы создать тестовый стенд по умолчанию для этого примера, выполните следующее:
% Generate a UVM test bench design = 'prm_uvmtb/PulseDetector' sequence = 'prm_uvmtb/GenPulse' scoreboard = 'prm_uvmtb/CheckDetection' uvmbuild(design, sequence, scoreboard)

В модели проверка отклика параметризуется пороговой переменной ошибки, используемой в блоке проверки утверждения. Он обозначается как параметр для сохранения в SystemVerilog с помощью Simulink.Parameter, pErrorThreshold. В этой спецификации ему присваивается значение по умолчанию 1,95 процента, которое отражает допуск разности ошибок между золотой привязкой и фактической DUT. (В этом испытании расхождение обусловлено двойной точностью по сравнению с реализацией логики обнаружения с фиксированной точкой.)

В сгенерированном коде UVM параметр помещается в объект конфигурации, mw_PulseDetector_scoreboard_cfg_obj,
Смотрите mw_PulseDetector_scoreboard_cfg_obj.sv.

который создается в build_phase теста, mw_PulseDetector_test:
Смотрите mw_PulseDetector_test.sv.

и установить через uvm_config_db на табло, mw_PulseDetector_scoreboard, в его start_of_simulation_phase:
Смотрите mw_PulseDetector_scoreboard.sv.

Первоначально план тестирования предусматривал допуск 1,95 процента. Если позже спецификация проекта была ужесточена, чтобы отразить более критическое требование безопасности до 0,50%, это можно сделать с помощью командной строки. В наших сценариях поддержки мы используем переменную среды, чтобы повлиять на аргумент SystemVerilog command line plus.
% Clear environment variables that influence the UVM simulation setenv EXTRA_UVM_SIM_ARGS setenv EXTRA_UVM_COMP_ARGS setenv UVM_TOP_MODULE
% Simulate the UVM test bench using plusarg overrides cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_SIM_ARGS '+SNR_default_inp_val=01000000 +RTWStructParam_pErrorThreshold=0.50' ! vsim -do run_tb_mq.do % ModelSim/QuestaSim (gui) ! vsim -c -do run_tb_mq.do % ModelSim/QuestaSim (console) ! ./run_tb_incisive.sh % Incisive (console) ! ./run_tb_xcelium.sh % Xcelium (console) ! ./run_tb_vcs.sh % VCS (console) cd ../../..

Обратите внимание, что при SNR 1,0 конструкция иногда нарушает 0,50-процентное пороговое значение ошибки.
Можно создавать и устанавливать значения непосредственно из теста, поскольку объект конфигурации табло является членом. Здесь мы рандомизируем порог в диапазоне [0,050, 0,500] процентов. Обратите внимание, что пороговое значение имеет тип real и поэтому не может быть рандомизирован напрямую.
Смотрите mw_PulseDetector_SCRPRM_param_overrides.sv.

Для выполнения моделирования UVM с использованием этих новых классов мы можем использовать исходные сценарии с дополнительными аргументами, заданными через переменные среды.
% Simulate the UVM test bench using randomized configuration object setting cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_COMP_ARGS '-f ../../../overrides_SCRPRM/extra_comp_args.f' setenv EXTRA_UVM_SIM_ARGS '+SNR_default_inp_val=01000000 +UVM_TESTNAME=mw_PulseDetector_test_SCRPRM' ! vsim -do run_tb_mq.do % ModelSim/QuestaSim (gui) ! vsim -c -do run_tb_mq.do % ModelSim/QuestaSim (console) ! ./run_tb_incisive.sh % Incisive (console) ! ./run_tb_xcelium.sh % Xcelium (console) ! ./run_tb_vcs.sh % VCS (console) cd ../../..

Обратите внимание, что в этом прогоне выбирается порог 0,150% и что несколько кадров в конечном итоге нарушают этот порог.
Можно также создать более сложную рандомизацию настроек конфигурации, создав производный объект конфигурации табло. В этом примере план тестирования требует, чтобы пороговое значение падало в различных интересных диапазонах, которые отражают различные рабочие среды детектора.
Смотрите mw_PulseDetector_SCRPRM_param_overrides.sv.
Для достижения этой цели производный объект конфигурации имеет следующие дополнительные варианты поведения:
добавить член «threshold_bucket», объявленный как randc
использовать этот член threshold_bucket для определения пороговых диапазонов
распечатать рандомизированные значения для проверки во время моделирования

Создается новый тест, который предписывает фабрике UVM использовать новый объект конфигурации и рандомизировать его настройки во время build_phase.

Для выполнения моделирования UVM с использованием этих новых классов мы можем использовать исходные сценарии с дополнительными аргументами, заданными через переменные среды.
% Simulate the UVM test bench using randomized derived configuration object cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_COMP_ARGS '-f ../../../overrides_SCRPRM/extra_comp_args.f' setenv EXTRA_UVM_SIM_ARGS '+SNR_default_inp_val=01000000 +UVM_TESTNAME=mw_PulseDetector_test_SCRPRM2' ! vsim -do run_tb_mq.do % ModelSim/QuestaSim (gui) ! vsim -c -do run_tb_mq.do % ModelSim/QuestaSim (console) ! ./run_tb_incisive.sh % Incisive (console) ! ./run_tb_xcelium.sh % Xcelium (console) ! ./run_tb_vcs.sh % VCS (console) cd ../../..

Обратите внимание, что для этого прогона выбрано пороговое значение 1,01 процента и что все кадры находятся ниже этого порогового значения.
В полной среде UVM каждый раз, когда вводится рандомизация, обычно важно включать охват и гарантировать, что различные части среды знают, какие случайные значения были сгенерированы. В этих примерах рандомизированные значения просто распечатываются. Добавление покрытия для сгенерированных пороговых значений ошибок и анализ фактических ошибок сигнала по крупности многих прогонов моделирования - это упражнение, оставленное читателю.