Guidelines for Using Delays and Goto and From Blocks for HDL Code Generation - MATLAB & Simulink (original) (raw)
These guidelines illustrate the recommended settings for modeling delays in your model. You model delays by using blocks available in the Discrete Library. Each guideline has a severity level that indicates the level of compliance requirements. To learn more, see HDL Modeling Guidelines Severity Levels.
Appropriate Usage of Delay Blocks as Registers
Guideline ID
2.6.1
Severity
Recommended
Description
For blocks in your model to be inferred as a flipflop on the target FPGA, useDelay blocks instead of memory blocks. You can specify a local reset and enable signal for each Delay block.
By default, the Delay length of the block is set to2. In this case, the input to the block passes to the output after two time steps. If the Delay length is set to0, the input passes to the output without any delay. The generated HDL code treats the block as a wire. To infer a flipflop or register on the target device, set theSource to dialog and specify a Delay length greater than zero.
When using a Delay block that has an external enable port or that is inside the Enabled Subsystem block, it is recommended to use the State Control block in synchronous mode. Similarly, when you use a Delay block that has an external reset port or that is inside the Resettable Subsystem block, it is recommended to use the State Control block in Synchronous mode. To learn more, see HDL Code Generation in Delay.
Do not use the Unit Delay Enabled, Unit Delay Resettable, and Unit Delay Enabled Resettable blocks for HDL code generation. These blocks have been removed. Instead, replace these blocks with the Unit Delay Enabled Synchronous, Unit Delay Resettable Synchronous, and Unit Delay Enabled Resettable Synchronous blocks. These blocks use theState Control block in synchronous hardware mode. To perform this block replacement in your model, run the model check Check for obsolete Unit Delay Enabled/Resettable Blocks.
Absorb Delays to Avoid Timing Difference
Guideline ID
2.6.2
Severity
Recommended
Description
Certain block implementations, floating-point operations, and optimization settings such as distributed pipelining introduce latency in the generated HDL code and the generated model. The additional latency results in a timing difference between the original model and the generated model. To avoid this timing difference, such as when you are using a control system with feedback loop, use a modeling pattern that can absorb delays. To absorb the delays:
- Place a Delay block after the block that is introducing latency.
- Set the Delay block Delay length value equal to the block latency.
By adding the Delay block to your original model, you can simulate your original model with latency.
These blocks can introduce latency:
- Divide, Sqrt, and Reciprocal blocks that have custom latency value greater than zero.
- Trigonometric Function blocks that have Function set to
sin,cos,sincos,cos+jsin, oratan2and HDL architecture set toCORDIC - Native floating-point operators that have LatencyStrategy set to
Max,Min, or a custom value greater than zero.
For more information, see Use Delay Absorption While Modeling with Latency.
Map Large Delays to Block RAM
Guideline ID
2.6.3
Severity
Recommended
Description
To save area, when your design contains large design delays and pipeline delays, you can map the delays to block RAM and UltraRAM resources on the FPGA. Design delays are delays that you manually insert in your design by usingDelay blocks, or other blocks that have state includingQueue, HDL FIFO, or Buffer blocks. Pipeline delays are delays that are generated by optimization settings or block implementation settings such as Newton-Raphson implementation.
To map design delays to RAM:
- In the HDL Block Properties dialog box of Delay blocks, set UseRAM to
on. To learn how you can set this option on Delay blocks in your design programmatically, see Set HDL Block Parameters for Multiple Blocks Programmatically. - To map significantly large delays to UltraRAM resources, you can specify the
ram_styleattribute in the generated HDL code.
-- This VHDL code shows the ramstyle attribute set to ultra:
attribute ram_style: string;
attribute ram_style of ram : signal is "ultra";
// This Verilog code shows the ramstyle attribute set to ultra:
(* ram_style = "ultra" *) - As described in Effects of Streaming and Distributed Pipelining, even ifUseRAM is
off, you can map large delays that exceed a threshold value by using theRAM mapping threshold parameter. You can change this threshold value depending on how large a delay you want to map to RAM. - When you use MATLAB Function blocks, you can map persistent variables in your MATLAB® code to RAM by setting HDL architecture to
MATLAB DatapathandMapPersistentVarsToRAMHDL block property toon.
For pipeline delays that are inserted by optimizations, delay balancing automatically inserts matching delays in parallel paths. If the delay length at the critical path and the number of vector elements in the parallel path take large values, the pipeline delays can also become significantly large.
To map these large delays to Block RAM:
- Enable the Map pipeline delays to RAM parameter.
- Adjust the RAM mapping threshold (bits) parameter to a value that is smaller than the required RAM size.
To calculate the total RAM size, use this formula:
RAMSize = Delay length * Word length * Vector length * ComplexityComplexityis 2 for a complex data type or 1 for a real datatype.
For more information, see Apply RAM Mapping to Optimize Area.
Required HDL Settings for Goto and From Blocks
Guideline ID
2.6.4
Severity
Mandatory
Description
When you generate HDL code for the DUT Subsystem that usesFrom and Goto blocks:
- Do not use From and Goto blocks across the boundary of the DUT subsystem. To connect the input and output ports of the DUT, use Inport andOutport blocks instead.
- Do not use From and Goto blocks across the boundary of an Atomic Subsystem. To connect the input and output ports of the DUT, useInport and Outport blocks instead.
Using From and Goto blocks across a subsystem hierarchy can impact the readability of the model. Before generating HDL code, it is recommended that you use From and Goto blocks in the same subsystem and use local orScoped visibility. When you generate HDL code, in the generated model, each Goto and From block becomes a pair of From and Goto subsystems connected back to back.