DPI Generation Overview

If you have a Simulink^® Coder™ license, you can generate SystemVerilog DPI components using one of two methods.

Supported Simulink Data Types

Supported Simulink data types are converted to SystemVerilog data types, as shown in this table.

You can choose a bit vector, logic vector, or a compatible C type. Choose in Configuration Parameters dialog box, in the Code Generation > SystemVerilog DPI section, under SystemVerilog Ports > Ports data type.

input logic [31:0] vecInput [0:1]

input logic [31:0] vecInput_0,
input logic [31:0] vecInput_1

Generated SystemVerilog Wrapper

• Generated Control Signals

• Generated SystemVerilog Module Interface

set_param(bdroot, 'DPIPortConnection','Interface')

SystemVerilog Wrapper for Combinational Design

You can generate a SystemVerilog wrapper for a combinational model by selecting Code Generation > SystemVerilog DPI on the left pane, and then under Component Template set Component template type to Combinational.

When generating a combinational SystemVerilog wrapper, the interface does not include clk, clk_enable, or reset ports.

For example:

module MyMod_dpi(
    /* Simulink signal name: 'in1' */
    input real in1 ,
    /* Simulink signal name: 'out1' */
    output real out1 
);

...
endmodule

Command-Line Alternative: Use the set_param (Simulink) function and set the DPIComponentTemplateType parameter to either 'Sequential' or Combinational'.

Combinational SystemVerilog Limitations

Generated Component Functions

SystemVerilog code generated by the SystemVerilog DPI generator contains these functions:

    // Declare imported C functions
    import "DPI" function chandle DPI_subsystemname_initialize(chandle existhandle);
    import "DPI" function void DPI_subsystemname_output(input chandle objhandle, 
            input real In1, inout real Out1);
    import "DPI" function void DPI_subsystemname_terminate(input chandle objhandle);

And for sequential designs, the code also includes the following functions:

    import "DPI" function chandle DPI_subsystemname_reset(input chandle objhandle,
            input real In1, inout real Out1);
    import "DPI" function void DPI_subsystemname_update(input chandle objhandle, 
            input real In1);

Here, subsystemname is the name of the subsystem you generated code for.

If your model also contains tunable parameters, see Parameter Tuning.

The function details in the SystemVerilog code generated from your system vary. You can examine the generated code for specifics. For an example of the generated functions in context, see Get Started with SystemVerilog DPI Component Generation.

Parameter Tuning

You can run different simulations with various values for the parameters in your Simulink model. If your system has tunable parameters, the generated SystemVerilog code also contains a Set Parameter function for each tunable parameter.

The DPI component generator generates a Set Parameter function for each tunable parameter in the format DPI_subsystemname_setparam_tunableparametername.

In this example, the tunable gain parameter has its own setparam_gain function.

import "DPI" function void DPI_dut_setparam_gain(input chandle objhandle, input real dut_P_gain);

The generated SystemVerilog code does not call this function. Instead, the default parameters are used. To change those parameters during simulation, explicitly call the specific setparam function. For example, in the subsystem titled dut, you can change the gain during simulation to a value of 6 by inserting the following call:

DPI_dut_setparam_gain(objhandle, 6);

To make a parameter tunable, create a data object from your subsystem before generating the SystemVerilog code. See Tune Gain Parameter During Simulation.

Test Point Access Functions

This feature enables you to access internal signals of the SystemVerilog DPI component in your HDL simulator. You can designate internal signals in your model as test points and configure the SystemVerilog DPI generator to create individual or grouped access functions.

You can also enable logging on test points. With logging enabled, you can use the generated testbench to compare logged data from Simulink with values observed while running the SystemVerilog component.

See SystemVerilog DPI Component Test Point Access and Get Started with SystemVerilog DPI Component Generation.

Extra Sample Delay

Compared with the original Simulink model, the generated SystemVerilog module introduces one extra sample delay at the output. For example, in the following Simulink model, the output is one-sample delayed version of the input signal.

The generated C code preserves this behavior, and the output comprises a one-sample delayed version of the input signal. However, in the SystemVerilog wrapper file, the clock signal is used to synchronize the input and output signals:

always @(posedge clk) begin
    DPI_blk2_output(blk2_In1, blk2_Out1);
    DPI_blk2_update();
end

The output of the SystemVerilog module can only be updated on the rising edge of the clock. This requirement introduces an extra sample delay.

Multirate System Behavior

By default, Simulink subsystems have a fundamental sample time variable (FundST) that indicates when, during simulation, the subsystem produces outputs and updates its internal state. With multirate systems, you can specify different sample times for different ports. For additional information, see What Is Sample Time? (Simulink).

When a multirate subsystem generates a DPI component, the DPI component runs at a sample time that is equal to the greatest common divisor of all sample times in the subsystem.

For example, assume a subsystem has a fundamental sample time of 0.01 (that is, FundST is 0.01) and sample times ST1 and ST2 of 0.5 and 0.7, respectively.

ST1=0.5, ST2=0.7. The DPI component runs at a sample time of 0.1 (because 0.1 is the greatest common divisor of 0.5 and 0.7). To successfully acquire a signal with a sample time of 0.5 (ST1) or 0.7 (ST2), the HDL clock signal must toggle five or seven times, respectively.

When a DPI component is generated from the top level, the component executes at the fundamental sample time.

This diagram shows the relationship between the HDL input clock and sample times ST1, and ST2.

Customization

You can customize the generated SystemVerilog wrapper by modifying the template included with HDL Verifier (svdpi_grt_template.vgt). Alternatively, you can create your own custom template. Provide anchors for the generated code in your template to verify that the template generates valid SystemVerilog code.

The default SystemVerilog template, provided by HDL Verifier, is svdpi_grt_template.vgt. In this template, special clken_in and clken_out control signals are added to the SystemVerilog module interface.

You can generate SystemVerilog DPI components from multiple subsystems and connect them together in an HDL simulator. When you do so, these control signals determine the execution order of those components. They also minimize the delay between the Simulink signal and the SystemVerilog signal.

You can also specify your own template file with the following conditions:

You can use these optional tokens to customize the generated code by inserting them inside comment statements throughout the template:

See Customize Generated SystemVerilog Code for instructions on customizing your code.

Limitations

For best results, avoid exporting multiple subsystems separately because it can be difficult to achieve the correct execution order. Instead, combine multiple subsystems into one and generate code from the newly created, single subsystem.