Delay Balancing

To achieve more efficient hardware usage and higher clock rates in your model, HDL Coder™ has several optimizations, block implementations, and options that introduce discrete delays into your model. Optimizations such as output pipelining, streaming, or resource sharing can introduce delays. Some block implementations, such as the Newton-Raphson and CORDIC architecture, inherently introduce delays in the generated code.

When optimizations or block implementation options introduce delays along the critical path in a model, the numerics of the original model and generated model or HDL code can differ from each other because equivalent delays are not introduced on other, parallel signal paths. Manual insertion of compensating delays along other paths is possible, but is prone to error and does not scale well to large models that have many signal paths or multiple sample rates.

To avoid this issue, HDL Coder provides delay balancing. By default, delay balancing is enabled on the model. HDL Coder detects introduction of new delays along one path, and then inserts matching delays on the other paths. When you enable delay balancing, the generated model is functionally equivalent to the original model. It is not recommended that you disable delay balancing on the model. If you disable this setting, HDL Coder generates a warning that numeric differences can occur in the validation model. To fix this warning, enable delay balancing on the model or run the model check Check delay balancing setting.

Specify Delay Balancing

You can set delay balancing for the ports in your device under test (DUT) subsystem, subsystems within the top-level DUT subsystem, or an entire model. Disabling delay balancing for an entire model is not recommended. You can disable delay balancing for specific parts of your design by using the HDL block property BalanceDelays for input and outputs ports and subsystems. See Delay Balancing Considerations.

Disable Delay Balancing for Constant Sources

A stable path is a path where the initial source to the path is constant. If your model contains a stable path outside the DUT and connects to the top-level DUT subsystem and you want to reduce the amount of resources needed, you can disable delay balancing for the stable path by disabling the HDL block property BalanceDelays on the DUT-level Inport block. The BalanceDelays property affects only DUT-level Inport blocks. For example, in this model, you can disable BalanceDelays for the DUT_Subsystem Inport block and input port h_in1 because the input to the Inport block is a Constant block.

DUT subsystem with a constant input coming into the DUT through an Inport block

To disable the HDL block property BalanceDelays for an Inport block using the HDL Block Properties dialog box:

Right-click the Inport block.
Select HDL Code > HDL Block Properties.
Set BalanceDelays to off.

To disable delay balancing for an Inport block from the command line, use the hdlset_param function.

If you have a subsystem hierarchy in your DUT and you disable BalanceDelays on the DUT-level Inport block, delay balancing on the stable path does not occur at lower-level hierarchy if the stable path propagates to the lower-level hierarchy. For an example, see the Constrain Delay Balancing to the Data Path section in Control the Scope of Delay Balancing.

When you disable delay balancing for a subsystem, that setting takes precedence over the on setting for the BalanceDelays property of Inport blocks in the subsystem. For example, if you disable delay balancing for a model or subsystem that contains an Inport block with BalanceDelays set to on, you do not need to disable delay balancing for that Inport block.

Note

When you disable BalanceDelays on DUT-level Inport blocks for stable paths and distributed pipelining is enabled for the model, change the Pipeline distribution priority configuration parameter from Numerical Integrity to Performance if you see delays inserted on stable paths in the generated model. For more information, see Pipeline distribution priority.

If your model contains a stable path that originates in the DUT, meaning that there is a Constant block as an input in the DUT, and a parallel path to the stable path has latency introduced from optimizations, delay balancing does not insert a matching delay on the stable path that contains the Constant block because the output value of the block is a constant. Not inserting the delay results in less resources needed for the design, but also results in an initial simulation mismatch. To resolve the simulation mismatch, add matching delays to the Constant block path by setting the HDL block property OutputPipeline to the number of matching delays needed at the output of the Constant block.

Disable Delay Balancing for a Subsystem

You can disable delay balancing for a specific subsystem in your model to localize delay balancing. Disabling delay balancing for a subsystem is only recommended in advanced use cases and can result in a mismatch in the validation model. To disable delay balancing for a subsystem, use the subsystem HDL block property BalanceDelays.

Delay Balancing Considerations

When you generate HDL code, delay balancing is an essential part of code optimizations. If any optimizations are enabled, you must balance pipelines introduced as a part of those optimizations. Failure to balance automatically inserted pipeline delays causes issues in generated code deployed in hardware. The recommended way to balance these delays is to keep BalanceDelays enabled for the model.

When you disable delay balancing for the model, HDL Coder does not compensate for latency inserted due to optimizations or block implementations. Unbalanced delays can lead to a mismatch in simulation results between HDL code and your Simulink^® model and unexpected and untested behavior of hardware implementation. It is recommended that you generate the validation model and observe effects of such unbalanced delays. To generate a validation model, see the configuration parameter Validation model. For examples of delay balancing and the validation model, see Delay Balancing and Validation Model Workflow in HDL Coder and Resolve Numeric Mismatch with Delay Balancing.

For multirate models, HDL Coder might generate a large number of pipeline registers that can prevent the HDL design from fitting onto an FPGA. Before you disable delay balancing for the model, see Delay Balancing on Multirate Designs and Optimize Generated HDL Code for Multirate Designs with Large Rate Differentials.

Resolving Delay Balancing Errors in a Feedback Loop Design

When you enable delay balancing on a model and that model contains a feedback loop in the DUT subsystem, during HDL code generation, you may see this error:

Delay balancing unsuccessful because an extra 3 cycles of latency introduced in the feedback loop cannot be absorbed. Consider increasing the latency budget by adding more design delays in the feedback loop or using clock-rate pipelining. If clock-rate pipelining is already enabled, refer to "highlightClockRatePipelining.m" for further diagnostics.

In this situation, the error is a result of pipelining in feedback loops that introduces latency and breaks the functional equivalence between the original and generated model. However, disabling delay balancing for the entire model results in a simulation mismatch between your original model and the generated model. To resolve this issue, either:

Use clock-rate pipelining. See the Use Clock-Rate Pipelining section in Resolve Simulation Mismatch When Pipelining with a Feedback Loop Outside the DUT.
Increase the latency budget by adding more design delays. See the Model with Latency in a Feedback Loop section in Use Delay Absorption While Modeling with Latency.

Disable Global Delay Balancing

If you must disable global delay balancing, you can disable the model setting by:

Disabling the BalanceDelays option for the model at the command line. See the Command-Line Information section for the Balance delays parameter. Starting in R2021b, you cannot disable this parameter from the Configuration Parameters window.
Changing the diagnostic option TreatBalanceDelaysOffAs to Warning or None. This option highlights when disabling BalanceDelays results in unbalanced delays in the model. For more information, see Check for presence of unbalanced delays in generated HDL code.

When you disable delay balancing for your model:

Turn off features that generate pipelines or add latency, such as optimizations like resource sharing, streaming, pipelining, or enabling the MapToRAM HDL block property of a lookup table (LUT) block. Manually balance the delays instead. For more information, see Resource Sharing for Area Optimization, Streaming: Area Optimization, Distributed Pipelining: Speed Optimization, and MapToRAM.
Use local delay balancing where possible to save time on manually balancing delays for your entire DUT. For more information on how to apply local delay balancing to specific parts of your model, see Control the Scope of Delay Balancing and Set Delay Balancing For a Subsystem.
Check for the command-line messages about additional latency, such as The code generation and optimization options you have chosen have introduced additional pipeline delays, and remove optimization settings that insert latency. For an example, see Delay Balancing and Validation Model Workflow in HDL Coder.
Run the Check for blocks that have nonzero output latency Model Advisor check. For more information, see Check for blocks that have nonzero output latency.

Delay Absorption During Delay Balancing

The delay balancing optimization applies delay absorption to your model, which uses design delays in place of pipeline delays introduced from optimizations to prevent unused latency from being added in your design. Similar to other pipeline optimizations, such as distributed pipelining, delay absorption moves existing delays to the point where an optimization introduces latency. Delay absorption allows you to model with latency, which means that you can add design delays in the original design to simulate the extra delays introduced by optimizations in the generated design. If there are enough design delays, the extra delays introduced by optimizations are absorbed and no additional cycles of latency are reported at the DUT output ports. Modeling with latency prevents timing differences between the original model and generated model and allows HDL Coder to generate a functionally equivalent model to the generated HDL code. Modeling with latency at the clock rate is useful for high-frequency, high-throughput applications, such as signal processing and wireless system design. For more information, see Use Delay Absorption While Modeling with Latency.

For delay absorption to run during HDL code generation:

Delay balancing must be on for the model.
Place a Delay block with a delay length equal to or greater than the block latency after the block that introduces latency. You can place the Delay block anywhere downstream on the data path from the block that introduces latency. For example, if you have a series of floating-point operators that accumulate to create a large amount of latency, you can place a single Delay block with a delay length equal to the total latency from the operators at the end of the series of operators.
For delay absorption to take place inside of a triggered subsystem, enable the model parameter Use trigger signal as clock.

For more information on floating-point operations and delay absorption, see Latency Considerations with Native Floating Point.

Delay Balancing Report

To see the delay balancing information in the report, before you generate code for each subsystem or model reference, enable the optimization report. In the HDL Code Generation tab, select Report, and then select Generate optimization report.

When you generate code for each subsystem, model reference, or MATLAB Function block, HDL Coder produces the optimization report. Select the Delay Balancing section of the report.

The Delay Balancing Report shows latency changes, pipeline and phase delay at the output ports, delay absorption information, and the number of pipelines added at the output ports to match the delays. If delay balancing fails, the report displays the criteria that was violated and the link to any block or subsystem that caused delay balancing to fail.

Delay Balancing Limitations

Subsystem-Level Restrictions

HDL Coder does not support delay balancing if:

The BalanceDelays block property for all instances of an Atomic Subsystem or Model Reference resolves to a different value.
To fix this error, enable BalanceDelays for all instances of the Atomic Subsystem or Model Reference.
A subsystem with BlackBox Architecture has the ImplementationLatency block property set to a negative value.
To fix this error, for ImplementationLatency, enter a nonnegative integer.

Sample Time Restrictions

HDL Coder does not support delay balancing if you introduce latency from optimizations and:

The sample time is continuous.
Your design has an infinite sample time output.