EDA Simulator Link™ DS

Preparing for Cosimulation

Overview

The EDA Simulator Link DS HDL Cosimulation block serves as a bridge between the Simulink and the HDL simulator domains. The block represents an HDL component model within the Simulink software. Using the block, Simulink software writes (drives) signals to and reads signals from the HDL model under simulation in the Synopsys VCS MX simulator. Signal exchange between the two domains occurs at regularly scheduled time steps defined by the Simulink sample time.

As you develop an EDA Simulator Link DS cosimulation application, you should be familiar with how signal values are handled across the simulation domains with respect to the following cases:

• How Simulink drives cosimulation signals

• Representation of simulation time

• Handling multirate signals

• Handling frame-based signals

• Avoiding race conditions

• Block simulation latency

• Interfacing with continuous time signals

• Setting Simulink configuration parameters

• Setting the communication link

• Starting the HDL simulator

Back to Top

How Simulink Software Drives Cosimulation Signals

Although you can bind the output ports of an HDL Cosimulation block to any signal in an HDL model hierarchy, you must use some caution when connecting signals to input ports. Ensure that the signal you are binding to does not have other drivers. If it does, use resolved logic types; otherwise you may get unpredictable results.

If you need to use a signal that has multiple drivers and it is resolved (for example, it is of VHDL type STD_LOGIC) , Simulink applies the resolution function at each time step defined by the signal's Simulink sample rate. Depending on the other drivers, the Simulink value may or may not get applied. Furthermore, Simulink has no control over signal changes that occur between its sample times.

Note   Verify that signals used in cosimulation have read/write access. A tab file is included in the simulation via the required launchDiscovery property "AccFile".

Back to Top

Representation of Simulation Time

The representation of simulation time differs significantly between the HDL simulator and Simulink. Each application has its own timing engine and the link software must synchronize the simulation times between the two.

In the HDL simulator, the unit of simulation time is referred to as a tick. The duration of a tick is defined by the HDL simulator resolution limit. The default resolution limit is 1 ns, but may vary depending on the simulator or the model.

See the HDL simulator documentation for how to determine the current HDL simulator resolution limit

Simulink maintains simulation time as a double-precision value scaled to seconds. This representation accommodates modeling of both continuous and discrete systems.

The relationship between Simulink and the HDL simulator timing affects the following aspects of simulation:

• Total simulation time

• Input port sample times

• Output port sample times

During a simulation run, Simulink communicates the current simulation time to the HDL simulator at each intermediate step. (An intermediate step corresponds to a Simulink sample time hit. Upon each intermediate step, new values are applied at input ports, or output ports are sampled.)

To bring the HDL simulator up-to-date with Simulink during cosimulation, you must convert sampled Simulink time to HDL simulator time (ticks) and allow the HDL simulator to run for the computed number of ticks.

Defining the Simulink and HDL Simulator Timing Relationship

The differences in the representation of simulation time can be reconciled in one of two ways using the EDA Simulator Link DS interface:

• By defining the timing relationship manually (with Timescales pane)

  When you define the relationship manually, you determine how many femtoseconds, picoseconds, nanoseconds, microseconds, milliseconds, seconds, or ticks in the HDL simulator represent 1 second in Simulink.

• By allowing EDA Simulator Link DS to define the timescale automatically (with Auto Timescale on the Timescales pane)

  When you allow the link software to define the timing relationship, it attempts to set the timescale factor between the HDL simulator and Simulink to be as close as possible to 1 second in the HDL simulator = 1 second in Simulink. If this setting is not possible, the link product attempts to set the signal rate on the Simulink model port to the lowest possible number of HDL simulator ticks.

Setting the Timing Mode with EDA Simulator Link DS

The Timescales pane of the HDL Cosimulation block parameters dialog box defines a correspondence between one second of Simulink time and some quantity of HDL simulator time. This quantity of HDL simulator time can be expressed in one of the following ways:

• In relative terms (i.e., as some number of HDL simulator ticks). In this case, the cosimulation is said to operate in relative timing mode. The HDL Cosimulation block defaults to relative timing mode for cosimulation. For more on relative timing mode, see Relative Timing Mode.

• In absolute units (such as milliseconds or nanoseconds). In this case, the cosimulation is said to operate in absolute timing mode. For more on absolute timing mode, see Absolute Timing Mode.

The Timescales pane lets you choose an optimal timing relationship between Simulink and the HDL simulator, either by entering the HDL simulator equivalent or by clicking on Auto Timescale. The next figure shows the default settings of the Timescales pane.

For instructions on setting the timing mode either automatically or manually, see Timescales Pane in the HDL Cosimulation block reference.

Relative Timing Mode

Relative timing mode defines the following one-to-one correspondence between simulation time in Simulink and the HDL simulator:

This correspondence holds regardless of the HDL simulator timing resolution.

The following pseudocode shows how Simulink time units are converted to HDL simulator ticks:

InTicks = N * tInSecs

where InTicks is the HDL simulator time in ticks, tInSecs is the Simulink time in seconds, and N is a scale factor.

Operation of Relative Timing Mode.   The HDL Cosimulation block defaults to relative timing mode, with a scale factor of 1. Thus, 1 Simulink second corresponds to 1 tick in the HDL simulator. In the default case:

• If the total simulation time in Simulink is specified as N seconds, then the HDL simulation will run for exactly N ticks (i.e., N ns at the default resolution limit).

• Similarly, if Simulink computes the sample time of an HDL Cosimulation block input port as Tsi seconds, new values will be deposited on the HDL input port at exact multiples of Tsi ticks. If an output port has an explicitly specified sample time of Tso seconds, values will be read from the HDL simulator at multiples of Tso ticks.

Relative Timing Mode Example.  

The model contains an HDL Cosimulation block (labeled HDL_Cosimulation1) simulating an 8-bit inverter that is enabled by an explicit clock. The inverter has a single input and a single output. The following code excerpt lists the Verilog code for the inverter:

module inverter_clock_vl(sin, sout,clk);

input [7:0] sin;
output [7:0] sout;
input clk;
reg [7:0] sout;


always @(posedge clk) 
  sout <= ! (sin);
endmodule

A cosimulation of this model might have the following settings:

• Simulation parameters in Simulink:

  • Timescales parameters: 1 Simulink second = 10 HDL simulator ticks

  • Total simulation time: 30 s

  • Input port (inverter_clock_vl.sin) sample time: N/A

  • Output port (inverter_clock_vl.sout ) sample time: 1 s

• HDL simulator resolution limit: 1 ns

Absolute Timing Mode

Absolute timing mode lets you define the timing relationship between Simulink and the HDL simulator in terms of absolute time units and a scale factor:

In absolute timing mode, all sample times and clock periods in Simulink are quantized to HDL simulator ticks. The following pseudocode illustrates the conversion:

tInTicks = tInSecs * (tScale / tRL)

where:

• tInTicks is the HDL simulator time in ticks.

• tInSecs is the Simulink time in seconds.

• tScale is the timescale setting (unit and scale factor) chosen in the Timescales pane of the HDL Cosimulation block.

• tRL is the HDL simulator resolution limit.

For example, given a Timescales pane setting of 1 s and an HDL simulator resolution limit of 1 ns, an output port sample time of 12 ns would be converted to ticks as follows:

			tInTicks = 12ns * (1s / 1ns) = 12
 	

Operation of Absolute Timing Mode.   To configure the Timescales parameters for absolute timing mode, you select a unit of absolute time that corresponds to a Simulink second, rather than selectingTick.

To understand the operation of absolute timing mode, you will again consider the example model discussed in Operation of Relative Timing Mode. Suppose that the model is reconfigured as follows:

• Simulation parameters in Simulink:

  • Timescale parameters: 1 s of Simulink time corresponds to 1 s of HDL simulator time.

  • Total simulation time: 60e-9 s (60ns)

  • Input port (/inverter/inport) sample time: 24e-9 s (24 ns)

  • Output port (/inverter/outport ) sample time: 12e-9 s (12 ns)

  • Clock (inverter/clk) period: 10e-9 s (10 ns)

• HDL simulator resolution limit: 1 ns

Given these simulation parameters, the Simulink software will cosimulate with the HDL simulator for 60 ns, during which Simulink will sample inputs at a intervals of 24 ns, update outputs at intervals of 12 ns, and drive clocks at intervals of 10 ns.

Timing Mode Usage Considerations

When setting a timescale mode, you may need to choose your setting based on the following considerations.

• Timing Mode Usage Restrictions

• Non-Integer Time Periods

Timing Mode Usage Restrictions.   The following restrictions apply to the use of absolute and relative timing modes:

• When multiple HDL Cosimulation blocks in a model are communicating with a single instance of the HDL simulator, all HDL Cosimulation blocks must have the same Timescales pane settings.

• If you change the Timescales pane settings in an HDL Cosimulation block between consecutive cosimulation runs, you must restart the simulation in the HDL simulator.

• If you specify a Simulink sample time that cannot be expressed as a whole number of HDL ticks, you will get an error.

Non-Integer Time Periods.   When using non-integer time periods, the HDL simulator cannot represent such an infinitely repeating value. So the simulator truncates the time period, but it does so differently than how Simulink truncates the value, and the two time periods no longer match up.

The following example demonstrates how to set the timing relationship in the following scenario: you want to use a sample period of in Simulink, which corresponds to a non-integer time period.

The key idea here is that you must always be able to relate a Simulink time with an HDL tick. The HDL tick is the finest time slice the HDL simulator recognizes..

However, a 3 Hz signal actually has a period of 333.33333333333... ms, which is not a valid tick period for the HDL simulator. The HDL simulator will truncate such numbers. But Simulink does not make the same decision; thus, for cosimulation where you are trying to keep two independent simulators in synchronization, you should not assume anything. Instead you have to decide whether it is convenient to truncate or round the number.

Therefore, the solution is to "snap" either the Simulink sample time or the HDL sample time (via the timescale) to valid numbers. There are infinite possibilities, but here are some possible ways to perform a snap:

• Change Simulink sample times from 1/3 sec to 0.33333 sec 1 second in Simulink = 1 second in the HDL simulator If you are specifying a clock in the HDL Cosimulation block Clocks pane, its period should be 0.33333 sec.

• Keep Simulink sample times at 1/3 sec. 1 second in Simulink = 6 ticks in the HDL simulator If you are specifying a clock in the HDL Cosimulation block Clocks pane, its period should be 1/3. Briefly, this specification tells Simulink to make each Simulink sample time correspond to every (1/3*6) = 2 ticks, regardless of the HDL time resolution. If your default HDL simulator resolution is 1 ns, that means your HDL sample times are every 2 ns. This sample time will work in a way so that for every Simulink sample time there is a corresponding HDL sample time; however, , Simulink thinks in terms of 1/3 sec periods and the HDL in terms of 2 ns periods. Thus, you could get confused during debug. If you want this to match the real period (such as to 5 places, i.e. 333.33ms), you can follow the next option listed.

• Keep Simulink sample times at 1/3 sec. 1 second in Simulink = 0.99999e9 ticks in the HDL simulator. If you are specifying a clock in the HDL Cosimulation block Clocks pane, its period should be 1/3.

Setting HDL Cosimulation Port Sample Times

In general, Simulink handles the sample time for the ports of an HDL Cosimulation block as follows:

• If an input port is connected to a signal that has an explicit sample time, based on forward propagation, Simulink applies that rate to that input port.

• If an input port is connected to a signal that does not have an explicit sample time, Simulink assigns a sample time that is equal to the least common multiple (LCM) of all identified input port sample times for the model.

• After Simulink sets the input port sample periods, it applies user-specified output sample times to all output ports. Sample times must be explicitly defined for all output ports.

If you are developing a model for cosimulation in relative timing mode, consider the following sample time guideline:

Back to Top

Handling Multirate Signals

EDA Simulator Link DS software supports the use of multirate signals, signals that are sampled or updated at different rates, in a single HDL Cosimulation block. An HDL Cosimulation block exchanges data for each signal at the Simulink sample rate for that signal. For input signals, an HDL Cosimulation block accepts and honors all signal rates.

The HDL Cosimulation block also lets you specify an independent sample time for each output port. You must explicitly set the sample time for each output port, or accept the default. Using this setting lets you control the rate at which Simulink updates an output port by reading the corresponding signal from the HDL simulator.

Back to Top

Handling Frame-Based Signals

This section discusses how to improve the performance of your cosimulation by using frame-based signals. An example is provided.

• Overview

• Using Frame-Based Processing

Overview

The HDL Cosimulation block supports processing of single-channel frame-based signals.

A frame of data is a collection of sequential samples from a single channel or multiple channels. One frame of a single-channel signal is represented by a M-by-1 column vector. A signal is frame based if it is propagated through a model one frame at a time.

Frame-based processing requires the Signal Processing Blockset software. Source blocks from the Signal Processing Sources library let you specify a frame-based signal by setting the Samples per frame block parameter. Most other signal processing blocks preserve the frame status of an input signal. You can use the Buffer block to buffer a sequence of samples into frames.

Frame-based processing can improve the computational time of your Simulink models, because multiple samples can be processed at once. Use of frame-based signals also lets you simulate the behavior of frame-based systems more accurately.

See "Working with Signals" in the Signal Processing Blockset documentation for detailed information about frame-based processing.

Using Frame-Based Processing

You do not need to configure the HDL Cosimulation block in any special way for frame-based processing. To use frame-based processing in a cosimulation, connect one or more single-channel frame-based signals to one or more input ports of the HDL Cosimulation block. All such signals must meet the requirements described in Frame-Based Processing Requirements and Restrictions. The HDL Cosimulation block automatically configures any outputs for frame-based operation at the appropriate frame size.

Use of frame-based signals affects only the Simulink side of the cosimulation. The behavior of the HDL code under simulation in the HDL simulator does not change in any way. Simulink assumes that HDL simulator processing is sample based. Simulink assembles samples acquired from the HDL simulator into frames as required. Conversely, Simulink transmits output data to the HDL simulator in frames, which are unpacked and processed by the HDL simulator one sample at a time.

Frame-Based Processing Requirements and Restrictions.   Observe the following restrictions and requirements when connecting frame-based signals in to an HDL Cosimulation block:

• Connection of mixed frame-based and sample-based signals to the same HDL Cosimulation block is not supported.

• Only single-channel frame-based signals can be connected to the HDL Cosimulation block. Use of multichannel (matrix) frame-based signals is not supported in this release.

• All frame-based signals connected to the HDL Cosimulation block must have the same frame size.

Frame-based processing in the Simulink model is transparent to the operation of the HDL model under simulation in the HDL simulator. The HDL model is presumed to be sample-based. The following constraint also applies to the HDL model under simulation in the HDL simulator:

Back to Top

Avoiding Race Conditions in HDL Simulation

In the Synopsy VCS MX simulator, you cannot control the order in which clock signals (rising-edge or falling-edge) defined with launchDiscovery are applied, relative to the data inputs driven by these clocks. If you are careful to ensure the relationship between the data and active edges of the clock, you can avoid race conditions that could create nondeterministic cosimulation results.

For more on race conditions in hardware simulators, see Race Conditions in HDL Simulators.

Back to Top

Block Simulation Latency

Simulink and the EDA Simulator Link DS Cosimulation blocks supplement the hardware simulator environment, rather than operate as part of it. During cosimulation, Simulink does not participate in the HDL simulator delta-time iteration. From the Simulink perspective, all signal drives (reads) occur during a single delta-time cycle. For this reason, and due to fundamental differences between the HDL simulator and Simulink with regard to use and treatment of simulation time, some degree of latency is introduced when you use EDA Simulator Link DS Cosimulation blocks. The latency is a time lag that occurs between when Simulink begins the deposit of a signal and when the effect of the deposit is visible on cosimulation block output.

As the following figure shows, Simulink cosimulation block input affects signal values just after the current HDL simulator time step (t+δ) and block output reflects signal values just before the current HDL simulator step time (t-δ) .

Regardless of whether you specify your HDL code with latency, the cosimulation block has a minimum latency that is equivalent to the cosimulation block's output sample time. For large sample times, the delay can appear to be quite long, but this length occurs as an artifact of the cosimulation block, which exchanges data with the HDL simulator at the block's output sample time only. Such length may be reasonable for a cosimulation block that models a device that operates on a clock edge only, such as a register-based device.

For cosimulation blocks that model combinatorial circuits, you may want to experiment with a faster sampling frequency for output ports in order to reduce this latency.

Back to Top

Interfacing with Continuous Time Signals

Use the Simulink Zero-Order Hold block to apply a zero-order hold (ZOH) on continuous signals that are driven into an HDL Cosimulation block.

Back to Top

Setting Simulink Software Configuration Parameters

When you create a Simulink model that includes one or more EDA Simulator Link DS Cosimulation blocks, you might want to adjust certain Simulink parameter settings to best meet the needs of HDL modeling. For example, you might want to adjust the value of the Stop time parameter in the Solver pane of the Configuration Parameters dialog box.

You can adjust the parameters individually or you can use the M-file dspstartup, which lets you automate the configuration process so that every new model that you create is preconfigured with the following relevant parameter settings:

The default settings for SaveTime and SaveOutput improve simulation performance.

You can use dspstartup by entering it at the MATLAB command line or by adding it to the Simulink startup.m file. You also have the option of customizing dspstartup settings. For example, you might want to adjust the StopTime to a value that is optimal for your simulations, or set SaveTime to "on" to record simulation sample times.

For more information on using and customizing dspstartup, see the Signal Processing Blockset documentation. For more information about automating tasks at startup, see the description of the startup command in the MATLAB documentation.

Running and Testing a Hardware Model in Simulink

If you design a Simulink model first, run and test your model thoroughly before replacing or adding hardware model components as EDA Simulator Link DS Cosimulation blocks.

Back to Top

Simulink and HDL Simulator Communication Options

Select shared memory or socket communication. See Communicating with MATLAB or Simulink and the HDL Simulator.

Back to Top

Starting the HDL Simulator

See Starting the HDL Simulator.

Back to Top

Introduction to Cosimulation

Incorporating Hardware Designs into a Simulink Model