UVM Component Generation Overview
UVM Component Generation Overview
If you have a Simulink® Coder™ license, you can generate a Universal Verification Methodology (UVM) test bench and additional components from a Simulink model. Generating UVM components enables a direct transition from your Simulink environment to a UVM framework.
HDL Verifier™ exports Simulink subsystems as generated C code inside UVM components with a direct programming interface (DPI). You can integrate these generated components into your existing UVM environment. You can also use the generated UVM test bench to test an HDL DUT by replacing the generated behavioral DUT with your detailed HDL design.
This feature requires the ASIC Testbench for HDL Verifier add-on.
Prepare Simulink Model for UVM Component Generation
Your Simulink model must include these subsystems.
A DUT subsystem. This subsystem generates a SystemVerilog DPI (SVDPI) behavioral model of your DUT. For more information about SystemVerilog DPI Generation, see DPI Component Generation with Simulink.
A sequence subsystem. This subsystem creates stimulus and drives it to the DUT.
A scoreboard subsystem. This subsystem collects and checks the output of the DUT.
The sequence can also drive signals directly to the scoreboard, as illustrated in red in the Simulink Model Structure figure.
For details on how to create a subsystem, see Create Subsystems (Simulink).
Required Simulink Model Structure
In addition to the previous structure, you can optionally include these blocks or subsystems.
A driver subsystem
A monitor subsystem
A predictor subsystem
A Sequence Feedback block (or several)
All the subsystems in your Simulink model must have names that start with a letter and use a combination of alphanumeric characters and underscores.
When adding a monitor, driver, or predictor subsystem, this feature supports these configurations.
All signals coming out of the sequence must be connected to the driver, predictor, or the scoreboard. Other output signals are ignored for UVM generation.
If your model includes a driver subsystem, then all signals coming out of the driver must be connected to the DUT.
If your model includes a driver subsystem, then all input signals to the driver must originate in the sequence.
If your model includes a monitor subsystem, then all signals coming out of the DUT must be connected to the monitor.
If your model includes a monitor subsystem, then all signals coming out of the monitor must be connected to the scoreboard.
If your model includes a predictor subsystem, then all input signals to the predictor must originate in the sequence. Additional inputs are ignored for UVM generation.
If your model includes a predictor subsystem, then all output signals from the predictor must connect to the scoreboard. Additional outputs are ignored for UVM generation.
If your model includes a Sequence Feedback block, then its input must be driven from the scoreboard subsystem, and its output must connect to the sequence subsystem.
This image shows a Simulink model that includes a driver, a monitor, and a predictor subsystem, as well as a Sequence Feedback block.
Expanded Simulink Model Structure
Select System Target
Because UVM generation utilizes the technology for generating SystemVerilog DPI, you
must first select a supporting system target file. Open the configuration parameters
dialog box, and select Code Generation from the left pane. For
System target file, click Browse,
and then select
systemverilog_dpi_grt.tlc from the list.
Alternatively, if you have the Embedded Coder® product, you can select target
This target enables you to access additional code generation options when you select
Code Generation from the left pane of the Configuration
Parameters dialog box.
For an example of UVM generation, see Generate Parameterized UVM Testbench from Simulink.
Generated UVM Structure
to generate this structure of UVM components.
Top – This module instantiates a generated behavioral DUT and the test environment. The top module has clock and reset signals that propagate into the design.
DUT – a behavioral design-under-test module is generated from your Simulink DUT subsystem.
Test – This module includes the UVM environment and sequence class.
Sequence – This UVM object defines a set of transactions. The sequence object is generated from your Simulink sequence subsystem.
Environment – This module includes the agent and generated scoreboard, and optionally a predictor.
Scoreboard – The UVM scoreboard is generated from your Simulink scoreboard subsystem. The scoreboard compares expected results with output from the DUT.
Agent – The UVM agent includes a sequencer, driver, and monitor. If a direct path exists from the Simulink sequence subsystem to the Simulink scoreboard subsystem, an additional monitor is included to monitor that signal.
Sequencer – This module controls the flow of sequence transactions to the DUT.
Driver – This module is generated from your Simulink driver subsystem and transforms each transaction from the Sequence to signals that the behavioral DUT understands. If your Simulink module does not include a driver subsystem, the driver is a pass-through UVM driver.
Monitor – This module is generated from your Simulink monitor subsystem and it samples the signals from the behavioral DUT and generates transactions that are sent to the UVM scoreboard. If your Simulink module does not include a monitor subsystem, the monitor is a pass-through UVM monitor.
Monitor Input – This module is generated if you have a predictor or a direct connection from the sequence to the scoreboard subsystem. The monitor input samples the signals from the sequence and generates transactions that are sent to the UVM predictor or the scoreboard.
Predictor – This module is generated from your Simulink predictor subsystem. The predictor represents a golden model of the DUT. It receives input from the sequence, calculates the results, and drives the results to the scoreboard to compare against the DUT results.
For more information about the UVM components and structure, see UVM reference guide.
Generated Files and Folder Structure
When generating UVM components, HDL Verifier generates SystemVerilog DPI (SV-DPI) components from your DUT, sequence, and
scoreboard subsystems, as well as optional SV-DPI components for driver, monitor or
predictor subsystems if your model includes them. The artifacts of DPI generation are placed
in a directory named
uvm_build in your working directory, that includes
these two directories:
– This directory includes all generated DPI components.
– This directory includes the UVM testbench, the generated DUT, and shared libraries.
is the name of
your top-level Simulink model. You can change the default directory by setting the
buildDirectory property in the
uvmcodegen.uvmconfig configuration object.
contains directories for each one of the subsystems in the top model (DUT, sequence,
scoreboard, driver, monitor, or predictor) named
. Each directory includes:
– SystemVerilog package file with function declarations for the component
– The generated SystemVerilog component
DPI component and header files with extensions .c and .h
Metadata and information files with extensions .mat, .txt, .dmr, .tmw, and .def
A makefile for compiling the components into .o and .so files
includes several subfolders for the various generated UVM components:
DPI_dut– This folder contains a copy of the SystemVerilog package, module files, and a .dll file from the
driver(optional) – This folder is generated if you specified a driver subsystem to the
uvmbuildfunction. This folder contains a UVM driver, a copy of the SystemVerilog package, and a shared library file (dll-file or so-file) from the
monitor(optional) – This folder is generated if you specified a monitor subsystem to the
uvmbuildfunction. This folder contains a UVM monitor, a copy of the SystemVerilog package, and a shared library file (dll-file or so-file) from the
predictor(optional) – This folder is generated if you specified a predictor subsystem to the
uvmbuildfunction. This folder contains a UVM predictor, a copy of the SystemVerilog package, a predictor transaction, and a shared library file (dll-file or so-file) from the
scoreboard– This folder contains a copy of the SystemVerilog package and a .dll file from the
folder. This folder also includes the UVM scoreboard class, a scoreboard configuration object, and a scoreboard transaction that defines the input transaction type for the scoreboard.
sequence– This folder contains a copy of the SystemVerilog package and a .dll file from the
folder. This folder also includes the UVM sequencer, the sequence class, and a sequence transaction that defines the transaction type from the sequencer to the driver.
top– This folder contains the SystemVerilog package and module files for the top Simulink model. This folder also contains scripts for HDL-simulator execution.
uvm_artifacts– This folder contains these SystemVerilog files.
mw_– This file includes a UVM agent that instantiates sequence, driver, and monitor.
mw_– This file includes a UVM environment, that instantiates an agent and a scoreboard.
mw_– This file defines the DUT SystemVerilog interface type. It contains DUT inputs and outputs, as well as ports for clock, reset, and clock-enable signals.
mw_– This file includes a pass-through UVM monitor. The monitor samples signals from the driver to the scoreboard or predictor.
mw_– This file includes a UVM test, that instantiates an environment and sequence. The test module starts the transactions by calling
mw_dpi_types_pkg.sv– This file contains definitions of generated SystemVerilog types, such as
struct, exposed by UVM component interfaces. Only UVM components which use these types import this package.
mw_– This file includes a pass-through UVM driver by default. When specifying a driver subsystem to the
uvmbuildfunction, this module includes a scheduler and the API calls to the DPI component
mw_– This file includes a pass-through UVM monitor. The monitor samples signals from the DUT to the scoreboard. When specifying a monitor subsystem to the
uvmbuildfunction, this module includes a scheduler and the API calls to the DPI-component
This image shows the generated directory structure for a top level model named
Supported Simulink Data Types
Supported Simulink data types are converted to SystemVerilog data types, as shown in this table.
Generated SystemVerilog Types
|Compatible C Type||Logic Vector||Bit Vector|
The port is sign extended to a built-in C type, such as
The logic vector length (
The bit vector length (
You can choose between a SystemVerilog
You can choose between SystemVerilog arrays or scalar ports. To choose between these options, in the left pane of the Configuration Parameters dialog box, select Code Generation > SystemVerilog DPI, and then select the Scalarize matrix and vector ports parameter.
example, a two-element vector of type
input logic [31:0] vecInput [0:1]
you select Scalarize matrix and vector
ports, the generated SystemVerilog
includes these two ports, each of type
input logic [31:0] vecInput_0, input logic [31:0] vecInput_1
When generating vector and array ports, the coder flattens matrices in column-major order.
You can choose between a SystemVerilog
|enumerated data types|
By default, HDL Verifier converts matrices and vectors to one-dimensional arrays in SystemVerilog. For example, a 4-by-2 matrix in Simulink is converted to a one-dimensional array of eight elements in SystemVerilog. To generate multiple scalar ports in the SystemVerilog interface, select Scalarize matrix and vector ports in the configuration parameters.
uvmbuildfunction ignores Simulink components that are not specified as a DUT, sequence, scoreboard, driver, monitor, or predictor subsystems.
You can use feedback loops inside any of the subsystems. You can also create feedback from the scoreboard to the sequencer by using a Sequence Feedback block. Other feedback loops between subsystems are not allowed.
The sequence, scoreboard, and predictor subsystems must operate at a single rate, and the fundamental sample times of their subsystems must be equal. For more information about sample times, see Sample Times in Systems (Simulink).
The fundamental sample times of the driver, DUT, and monitor subsystems must be equal. Their ports can be multirate, but the greatest common divisor (GCD) or fundamental sample time must be the same.
The sample time of the sequence, scoreboard, and predictor subsystems must be greater than or equal to the fundamental sample time of the driver, DUT, and monitor.
- DPI Component Generation with Simulink
- Generate Parameterized UVM Testbench from Simulink
- Generate Cross-Platform UVM Components