generate parameterized uvm test bench from simulink -凯发k8网页登录
this example shows how you can develop a design and test bench in simulink® and generate an equivalent simulation for a universal verification methodology (uvm) environment using uvmbuild
. related examples show how you can extend this test bench to refine your verification using protocol-specific drivers, constrained random sequences, and parameterized scoreboards.
introduction
this example walks you through a top-down design development process of an hdl implementation. in such a workflow, you design a behavioral algorithm in simulink and test it using surrounding blocks for stimulus generation and results checking. once the simulation confirms that the design meets its requirements, you deliver any collateral needed to the downstream hdl implementation team. you need to re-verify the hdl implementation meets the requirements as simulated in simulink as well as any other unique aspects of the design such as protocol interfaces that were not modeled in simulink.
ordinarily the hand-off process can be tedious and the source of many errors. the hdl implementation and hdl design verification (dv) engineers must:
translate written specifications to hdl and testing environments.
understand the run-time behavior of the simulink simulation environment such as how the stimulus is created, processed, and checked.
translate the run-time behaviors to systemverilog implementations.
integrate the stimulus, design, and response checking into a runnable systemverilog to confirm that the translated behaviors behave the same as the original simulink simulation.
integrate these main systemverilog components into a uvm context in order to allow extending the simulink testing with dv-authored verification. this extended testing might include randomized testing, systemverilog assertions, functional coverage, and code coverage.
using the hdl verifier™ uvm generation capabilities, this hand-off process is automated. the dv engineer gets a verified uvm test environment that matches the testing performed in simulink and can easily update that environment to meet their downstream verification needs.
design and test in simulink
write your algorithm and add a test bench to it. the model consists of typical subsystems for a test bench such as stimulus generation, the design under test (dut), and response checking.
in this design, the source subsystem creates a random pulse of 64 samples of information embedded at a random location in a 5000 sample frame of noise. it also generates a set of 64 optimal matched filter coefficients for detection of the pulse. the inputs are fed to both the design and the response checker. the response checker verifies that the pulse is detected at the right location in the noisy waveform. proper operation is confirmed through console output. if the expected power of the detected signal is not within certain limits, an assertion is fired.
simulating the model provides confirmation that in five generated pulses, five are detected. a three paneled figure shows a tx signal (the original pulse), an rx signal (the pulse embedded in noise), and the filtered output of a reference implementation that shows where a peak is detected. the output signal is delayed by one frame.
[framenum= 0] peak location=2163.000000, mag-squared=0.280 using global max [framenum= 0] peak detected from impl=2163 error(abs)=0 [framenum= 0] peak mag-squared from impl=0.280, error(abs)=0.000 error(pct)=0.017 [framenum= 1] peak location=2163.000000, mag-squared=0.200 using global max [framenum= 1] peak detected from impl=2163 error(abs)=0 [framenum= 1] peak mag-squared from impl=0.199, error(abs)=0.000 error(pct)=0.190 [framenum= 2] peak location=2163.000000, mag-squared=0.224 using global max [framenum= 2] peak detected from impl=2163 error(abs)=0 [framenum= 2] peak mag-squared from impl=0.223, error(abs)=0.000 error(pct)=0.183 [framenum= 3] peak location=2163.000000, mag-squared=0.200 using global max [framenum= 3] peak detected from impl=2163 error(abs)=0 [framenum= 3] peak mag-squared from impl=0.200, error(abs)=0.000 error(pct)=0.043 [framenum= 4] peak location=2163.000000, mag-squared=0.255 using global max [framenum= 4] peak detected from impl=2163 error(abs)=0 [framenum= 4] peak mag-squared from impl=0.255, error(abs)=0.000 error(pct)=0.031 [framenum= 5] peak location=2163.000000, mag-squared=0.241 using global max [framenum= 5] peak detected from impl=2163 error(abs)=0 [framenum= 5] peak mag-squared from impl=0.241, error(abs)=0.000 error(pct)=0.187 [framenum= 6] peak location=2163.000000, mag-squared=0.241 using global max [framenum= 6] peak detected from impl=2163 error(abs)=0 [framenum= 6] peak mag-squared from impl=0.241, error(abs)=0.000 error(pct)=0.019 [framenum= 7] peak location=2163.000000, mag-squared=0.225 using global max [framenum= 7] peak detected from impl=2163 error(abs)=0 [framenum= 7] peak mag-squared from impl=0.225, error(abs)=0.000 error(pct)=0.032 [framenum= 8] peak location=2163.000000, mag-squared=0.239 using global max [framenum= 8] peak detected from impl=2163 error(abs)=0 [framenum= 8] peak mag-squared from impl=0.239, error(abs)=0.000 error(pct)=0.037 [framenum= 9] peak location=2163.000000, mag-squared=0.225 using global max [framenum= 9] peak detected from impl=2163 error(abs)=0 [framenum= 9] peak mag-squared from impl=0.225, error(abs)=0.000 error(pct)=0.146 [framenum= 10] peak location=2163.000000, mag-squared=0.207 using global max [framenum= 10] peak detected from impl=2163 error(abs)=0 [framenum= 10] peak mag-squared from impl=0.207, error(abs)=0.000 error(pct)=0.134
generate an executable uvm test bench
use the uvmbuild
function to export your design to a uvm environment. the uvm test bench provides structure to the hdl verification process and allows for all of the simulink test bench components and test cases to be reused by the implementation verification team. standard component definitions separate the pieces of the environment by their role in the simulation. for this example:
pulsedetector
is mapped to the dut systemverilog modulegenpulse
subsystem is mapped to thesequence_item
creation for the sequencer uvm componentcheckdetection
subsystem is mapped to the scoreboard uvm component.
the generated uvm test bench is shown below:
% generate a uvm test bench design = 'prm_uvmtb/pulsedetector' sequence = 'prm_uvmtb/genpulse' scoreboard = 'prm_uvmtb/checkdetection' uvmbuild(design, sequence, scoreboard)
each of the highlighted pieces of the uvm test bench are implemented by wrapping generated c-code from the simulink subsystem and calling its entry points using dpi. the following image shows a couple of the function declarations for the pulsedetector subsystem.
the systemverilog/uvm code determines the timing of the dpi calls. for example, in the pulsedetector systemverilog module:
the "initialize" dpi call is triggered by an "initial" code block.
the "terminate" dpi call is triggered by a "final" code block.
the "reset" dpi call is triggered by an active reset signal.
the "output" and "update" dpi calls are triggered by a rising clock edge where reset is not active and the clock enable is active.
run the uvm test bench
the uvmbuild
process also generates a script to run a simulation of the uvm test. scripts are generated for the following simulators:
mentor graphics® modelsim® and questa®: run_tb_mq.do
cadence® xcelium™: run_tb_xcelium.sh
synopsys® vcs®: run_tb_vcs.sh
the generated script for modelsim is shown.
execute the generated script to verify the uvm execution matches the simulink execution. because the sequence is parameterized with the snr input port, its default value will be 0.0 in uvm. in order to properly compare the simulation runs, we need to change its default value to 2.0 (which has a bit value of 0b10_000000), to match simulink; this can be done via a plusarg which we pass to the script via an environment variable.
% 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 an snr of 2.0 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_xcelium.sh % xcelium (console) ! ./run_tb_vcs.sh % vcs (console) cd ../../..
the simulation log shows the same diagnostic messages:
and the waveform shows the timing of the dut interface signals. the cursor is placed at a frame boundary and shows the instantaneous update of the matched filter coefficients.