uvm component generation overview -凯发k8网页登录

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.

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 .
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 (simulink).

required simulink model structure

image shows a block diagram with a sequence, a dut, and a scoreboard subsystem. an arrow connects from the sequence to the dut, and another arrow connects from the dut to the scoreboard.

in addition to the previous structure, you can optionally include these blocks or subsystems.

a driver subsystem
a monitor subsystem
a predictor subsystem
a block (or several)

note

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 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 block.

expanded simulink model structure

image shows a block diagram with a sequence, a dut, and a scoreboard subsystem. there is a driver subsystem between the sequence and the dut, a monitor subsystem between the dut and the scoreboard, and a predictor subsystem between the sequence and the scoreboard. the model also includes a sequence feedback block carrying data back from the scoreboard to the sequence subsystems.

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 systemverilog_dpi_ert.tlc. 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 test bench from simulink.

generated uvm structure

use the function 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 .

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:

top_model_dpi_components – this directory includes all generated dpi components.
top_model_uvm_testbench – this directory includes the uvm testbench, the generated dut, and shared libraries.

where top_model is the name of your top-level simulink model. you can change the default directory by setting the builddirectory property in the configuration object.

the top_model_dpi_components directory contains directories for each one of the subsystems in the top model (dut, sequence, scoreboard, driver, monitor, or predictor) named subsystem_build. each directory includes:

subsystem_dpi_pkg.sv – systemverilog package file with function declarations for the component
subsystem_dpi.sv – 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

the top_model_uvm_testbench directory 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 dut_build folder.
driver (optional) – this folder is generated if you specified a driver subsystem to the uvmbuild function. this folder contains a uvm driver, a copy of the systemverilog package, and a shared library file (dll-file or so-file) from the driver_build folder.
monitor (optional) – this folder is generated if you specified a monitor subsystem to the uvmbuild function. this folder contains a uvm monitor, a copy of the systemverilog package, and a shared library file (dll-file or so-file) from the monitor_build folder.
predictor (optional) – this folder is generated if you specified a predictor subsystem to the uvmbuild function. 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 predictor_build folder.
scoreboard – this folder contains a copy of the systemverilog package and a .dll file from the scoreboard_build 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 sequence_build 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_dut_agent.sv – this file includes a uvm agent that instantiates sequence, driver, and monitor.
- mw_dut_environment.sv – this file includes a uvm environment, that instantiates an agent and a scoreboard.
- mw_dut_if.sv – 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_dut_monitor_input.sv – this file includes a pass-through uvm monitor. the monitor samples signals from the driver to the scoreboard or predictor.
- mw_dut_test.sv – this file includes a uvm test, that instantiates an environment and sequence. the test module starts the transactions by calling seq.start.
- mw_dpi_types_pkg.sv – this file contains definitions of generated systemverilog types, such as enum and struct, exposed by uvm component interfaces. only uvm components which use these types import this package.
- mw_dut_driver.sv – this file includes a pass-through uvm driver by default. when specifying a driver subsystem to the uvmbuild function, this module includes a scheduler and the api calls to the dpi component driver_dpi_pkg.sv.
- mw_dut_monitor.sv – 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 uvmbuild function, this module includes a scheduler and the api calls to the dpi-component monitor_dpi_pkg.sv.

this image shows the generated directory structure for a top level model named drv_and_mon_uvmtb.

generated directory structure for a top level model named drv_and_mon_uvmtb. a directory named

supported simulink data types

supported simulink data types are converted to systemverilog data types, as shown in this table.

generated systemverilog types

matlab^®	systemverilog
matlab^®	compatible c type	logic vector	bit vector
`uint8`	`byte unsigned`	`logic [7:0]`	`bit [7:0]`
`uint16`	`shortint unsigned`	`logic [15:0]`	`bit [15:0]`
`uint32`	`int unsigned`	`logic [31:0]`	`bit [31:0]`
`uint64`	`longint unsigned`	`logic [63:0]`	`bit [63:0]`
`int8`	`byte`	`logic signed [7:0]`	`bit signed [7:0]`
`int16`	`shortint`	`logic signed [15:0]`	`bit signed [15:0]`
`int32`	`int`	`logic signed [31:0]`	`bit signed [31:0]`
`int64`	`longint`	`logic signed [63:0]`	`bit signed [63:0]`
`boolean`	`byte unsigned`	`logic [0:0]`	`bit [0:0]`
fixed-point	the port is sign extended to a built-in c type, such as `int`, `int unsigned`, `byte`, `byte unsigned`, etc.	`logic [n-1:0]` `logic signed [n-1:0]` the logic vector length (`n`) is equal to the `wordlength`. the sign is inherited from the fixed point type.	`bit [n-1:0]` `bit signed [n-1:0]` the bit vector length (`n`) is equal to the `wordlength`. the sign is inherited from the fixed point type.
`single`	`shortreal`
`double`	`real`
`complex`	you can choose between a systemverilog `struct` data type or flattened ports for real and imaginary parts in the systemverilog interface. to choose between these options, in the left pane of the configuration parameters dialog box, select code generation > systemverilog dpi, and then set the composite data type parameter to `structure` or `flattened`.
vectors, matrices	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. for example, a two-element vector of type `uint32` in simulink generates this systemverilog vector port: input logic [31:0] vecinput [0:1] when you select scalarize matrix and vector ports, the generated systemverilog includes these two ports, each of type `logic [31:0]`: 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.
nonvirtual bus	you can choose between a systemverilog `struct` type or flattened ports for separate component signals in the systemverilog interface. to choose between these options, in the left pane of the configuration parameters dialog box, select code generation > systemverilog dpi section, and set composite data type to `structure` or `flattened`.
enumerated data types	`enum`

limitations

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.
the uvmbuild function 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 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 (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.

uvm component generation overview -凯发k8网页登录

uvm component generation overview

uvm component generation overview