В этом примере показано, как добавить ограниченную случайную верификацию к испытательному стенду универсальной методологии верификации (UVM), сгенерированному Simulink ®. И параметры Simulink, и входные порты к генерации стимула приводят к случайным представителям данных класса последовательности в испытательном стенде UVM. Благодаря использованию стандартных наследований классов UVM и заводских переопределений инженер по верификации проекта может добавить новые и ценные ограниченные случайные тестовые шкалы в свой тестовый набор UVM.
Этот пример расширяет испытательный стенд UVM генерации импульсов, чтобы добавить ограниченные случайные проверки. См. пример 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)
В модели генерация стимула параметризируется с помощью диалогового параметра для местоположения импульса и входа порта для отношения сигнал/шум (ОСШ). В сгенерированном UVM эти параметры являются представителями данных mw_PulseDetector_sequence класс с ограничениями, которые отражают информацию из модели.
См. mw_PulseDetector_sequence.sv.
pPulseLocation: Этот диалоговый параметр GenPulse подсистема указывает начальное местоположение 64 импульса дискретизации в большей 5000 системе координат выборки. Для сохранения в SystemVerilog используйте Simulink. Параметр. В этом параметре значение по умолчанию является 2100, а допустимая область значений - [0, 4936]. (Импульс должен находиться полностью в системе координат 5000 выборки.)
В сгенерированном коде UVM на представителя импульсной последовательности местоположения накладываются два ограничения для значения по умолчанию и минимальной максимальной области значений, как показано на этом фрагменте кода:
Порт ОСШ: Этот входной порт в подсистему генерации указывает отношение общей величины сгенерированного импульса к сгенерированному шуму. Его тип данных является ufix8_En6 фиксированный номер точки с внутренней областью значений [0, 3.984375]. Самому порту был задаваема более ограниченная область значений [0, 2.984375], который соответствует значениям битов с фиксированной точкой 0b00_000000, 0b10_111111.
Поскольку это вход порт, в Simulink нет понятия значения по умолчанию. В сгенерированном коде UVM на представителя последовательности накладываются два ограничения для минимальной максимальной области значений, а также значение по умолчанию, которое совпадает с минимальным. Код также добавляется для поддержки переопределения значения по умолчанию в командной строке через плюс arg. Пример кода:
Генерация последовательности по умолчанию body() следует обычному шаблону получения гранта, рандомизации элемента последовательности, отправки его вместе с секвенсором, а затем ожидания его завершения.
Из-за значения по умолчанию ограничений, если вы запускаете тест по умолчанию, то для параметров будут использоваться фиксированные значения. Для этой модели это означает начальное положение импульса 2100 и ОСШ 0,0. ОСШ 0,0 приведет к отсутствию обнаруживаемых импульсов, поэтому плюсарг задает более интересное значение по умолчанию. Значение битов с фиксированной точкой 8 'b10000000 является значением с плавающей точкой 2,0.
% 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 override cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_SIM_ARGS +SNR_default_inp_val=10000000 ! 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 ../../..
Можно использовать стандартные методы UVM, чтобы добавить рандомизированное поведение к генерации стимула. В этом примере план тестирования вызывает использование значений ОСШ между 0,75 и 1,00, чтобы определить, насколько надежен алгоритм в обнаружении импульсов в этой области значений. Для этого случая местоположение импульса не имеет значения и фиксируется в конце 5000 систем координат выборки.
См. mw_PulseDetector_SEQCRT_param_overrides.sv.
Для достижения этой цели тестового плана создается класс производной последовательности. Это имеет следующее дополнительное поведение:
в pre_body() переопределить, использование ограничений значений по умолчанию отключено
в post_randomize() переопределите, рандомизированное значение распечатывается так, чтобы значения ОСШ могли быть связаны с тем, обнаруживаются импульсы или нет. Он использует служебную функцию класса fixed2real придать дружелюбное значение.
в randomize_params() переопределение, линейное ограничение «randomize with» ограничивает значения ОСШ в диапазоне от 0,75 до 1,0. (Можно получить эти битовые значения из MATLAB с помощью переменной fi и его метода bin.)
Создается новый тест, который сообщает фабрике использовать новый класс последовательности при построении испытательного стенда.
Чтобы запустить симуляции UVM с использованием этих новых классов, можно использовать исходные скрипты с дополнительными аргументами, заданными через переменные окружения.
% Simulate the UVM test bench using inlined constraint overrides cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_COMP_ARGS '-f ../../../overrides_SEQCRT/extra_comp_args.f' setenv EXTRA_UVM_SIM_ARGS +UVM_TESTNAME=mw_PulseDetector_test_inlineCRT ! 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,75, 1,00], а начальное положение импульса всегда является 4936. При такой области значений ОСШ наблюдайте, что иногда обнаруживается импульс, а иногда его нет.
Встроенные ограничения хороши для хонинга при определенных условиях тестирования. Для случайной проверки с ограничениями можно создать новые блоки оператора ограничений в производном классе последовательности. Здесь план тестирования требует, чтобы положение импульса изменялось по всей системе координат с помощью определенных «блоков» интересных местоположений в начале, середине и конце системы координат. Специальное положение 0 гарантирует, что, когда импульс не создается, импульс не обнаруживается. Аналогичным образом для ОСШ задается несколько категорий интересных областей значений ОСШ, таких как SNR_never_detected и SNR_always_detected. Теперь автор теста может легко использовать эти ограничения, чтобы охватить эти сценарии.
См. mw_PulseDetector_SEQCRT_param_overrides.sv.
Чтобы достичь этих целей, класс производной последовательности имеет следующее дополнительное поведение:
добавить представитель «loc_bucket», объявленный как «randc».
используйте этот loc_bucket представитель, чтобы подразумевать области значений местоположений.
добавить snr_bucket «представителя». Он не рандомизирован, а скорее установлен тестовщиком.
используйте выбранную snr_bucket, чтобы подразумевать рандомизацию в определенных областях значений ОСШ.
отключите конфликтующие ограничения значений по умолчанию
распечатать рандомизированные значения для проверки во время симуляции
Создается новый тест, который сообщает фабрике UVM использовать новый класс последовательности при построении испытательного стенда, а также устанавливает конкретный блок ОСШ через uvm_resource_db.
Чтобы запустить симуляции UVM с использованием этих новых классов, можно использовать исходные скрипты с дополнительными аргументами, заданными через переменные окружения.
% Simulate the UVM test bench using derived sequence class overrides cd uvm_build/prm_uvmtb_uvm_testbench/top setenv EXTRA_UVM_COMP_ARGS '-f ../../../overrides_SEQCRT/extra_comp_args.f' setenv EXTRA_UVM_SIM_ARGS +UVM_TESTNAME=mw_PulseDetector_test_classCRT ! 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.4844, и начальное положение импульса посещает каждый из областей значений, заданных для loc_bucket. Можно также подтвердить, что, когда местоположение 0, поскольку импульс не создается, импульс не обнаруживается.
Сгенерированные последовательности выше используют рандомизацию, чтобы повлиять на входные параметры и аргументы базовых функций GenPulse DPI-C. Фактические значения транзакций являются выходами этих функций. Если необходимо взять под полный контроль фактические транзакции, доставленные в секвенсор, можно обойти обычные вызовы DPI и рандомизировать req представитель данных.
См. mw_PulseDetector_SEQCRT_param_overrides.sv.
В этом случае, поскольку импульс, коэффициенты и шум все взаимосвязаны, полная рандомизация их значений не даст допустимых тестов. Но этот метод полезен для других типов транзакций.
В полном окружении UVM всякий раз, когда вводится рандомизация, обычно важно включать покрытие и обеспечивать, чтобы различные части окружения знали, какие случайные значения были сгенерированы. В этих примерах рандомизированные значения просто распечатываются. Добавление покрытия для сгенерированных ОСШ и значений местоположения - и связывание их с обнаружением и порогами ошибок - является упражнением, оставленным читателю.
