Main Content

Allocate Sufficient Delays for Floating-Point Operations

Problem

Sometimes, when generating code from your floating-point algorithm in Simulink®, HDL Coder™ generates an error that it is unable to allocate sufficient number of delays.

Cause

This error message generally occurs when you have Simulink® blocks performing floating-point operations inside a feedback loop. These blocks have a latency. HDL Coder™ is unable to allocate delays to compensate for the latency, because the code generator needs to add delays and balance them to maintain numerical accuracy.

If you open this example model RunningSum.slx, you see a Simulink model that uses single data types.

To generate HDL code for the CumSum_Sl Subsystem, right-click the subsystem and select HDL Code > Generate HDL for Subsystem. During code generation, HDL Coder generates an error:

By using the path to the block mentioned in the error message, navigate to the Add block in the model. This block is inside a feedback loop.

The Add block has a latency of 11. When generating code, HDL Coder cannot allocate 11 delays for the block, because it cannot add matching delays to other paths.

This model serves as an example to illustrate the various strategies to solve this problem.

Solution

Strategy 1: Global Oversampling

This modeling paradigm uses the clock-rate pipelining optimization to oversample your design to a clock-rate much faster than the DUT sample rate. To enable this optimization, specify a global oversampling factor for your Simulink model. The floating-point delays then operate at the faster clock-rate and can be allocated successfully. For more information, see Clock-Rate Pipelining.

  1. Specify an oversampling factor that is equal to or greater than the latency of the floating-point operators that are unable to allocate delays. For the RunningSum model, specify an oversampling factor at least equal to 12. To learn about the latency values of the floating-point operators, see Simulink Blocks Supported by Using Native Floating Point.

    To specify the oversampling factor:

    1. In the Apps tab, select HDL Coder. The HDL Code tab appears.

    2. Click Settings. In the HDL Code Generation > Global Settings tab, set Oversampling factor to 12.

  2. Enable hierarchy flattening on the DUT and make sure that subsystems inside the DUT inherit this setting. For the RunningSum model, select the CumSum_sl subsystem and click HDL Block Properties on the HDL Code tab, and then set FlattenHierarchy to on.

Strategy 2: Local Oversampling

To model your design at the data rate and selectively increase the sample rate of blocks for which HDL Coder™ is unable to allocate delays, use local oversampling. These blocks then operate at the faster clock rate and can accommodate the required number of delays.

If you open the RunningSum_OSmanual model and navigate to the Add block, it shows how you can increase the sample rate of the Add block and allocate delays.

  • The blocks that are within the boundary of the Repeat and Zero Order Hold blocks operate at the clock rate that is 12 times faster than the sample rate of the model.

  • The subsystem has a Delay block of length 12 at the output of the Add block. When generating code, the Add block absorbs this Delay block, which compensates for the latency of the operator. To balance delays, the subsystem contains Delay blocks of length 12 in other paths.

You can now generate HDL code for the CumSum_sl subsystem. To generate HDL code for the CumSum_Sl Subsystem, right-click the subsystem and select HDL Code > Generate HDL for Subsystem.

Strategy 3: Delay Blocks

Use this modeling paradigm to model your entire design at the Simulink data rate. For blocks that are unable to accommodate the required number of delays, add a Delay block with a sufficient Delay length at the output of the blocks. Specify a Delay length that is equal to the latency of the floating-point operator. Make sure that you add matching delays in other paths.

For the RunningSum model, you can add a Delay block of length 12 at the output of the Add block. When generating code, the Add block absorbs this delay, because the block has a latency of 12.

For more information, see Latency Considerations with Native Floating Point.

Strategy 4: Use Custom Latency

You can use the Latency Strategy for various blocks to specify a custom latency value and absorb the additional delays. Using this strategy can optimize your design for trade-offs between:

  • Clock frequency and power consumption.

  • Oversampling factor and sampling frequency.

To learn more about the trade-offs and blocks for which you can specify a custom latency, see LatencyStrategy.

Note: When you use the custom latency strategy, make sure that the Subsystem that contains the block for which native floating-point is unable to allocate delays is not a conditional subsystem. That is, the Subsystem must not contain trigger, reset, or enable ports.

To see how using a custom latency can resolve the delay allocation issue, open the model RunningSum_Custom.slx.

The model is similar to the original RunningSum model but does not have the Enable block. Using the Enable block can prevent the custom latency strategy from absorbing delays. Specify a custom latency of one for the Add block. The Add block can then absorb the Unit Delay adjacent to the Add block.

You can now generate HDL code for the CumSum_sl subsystem.

Strategy 5: Zero Latency

You can use the zero latency strategy setting for blocks in your design for which native floating point is unable to allocate delays. By default, blocks in your design inherit the native floating-point settings that you specify in the Configuration Parameters dialog box. To specify a zero latency strategy setting for a block, in the HDL Block Properties dialog box for that block, on the Native Floating Point tab, set LatencyStrategy to Zero.

For the RunningSum example, set the LatencyStrategy of the Add block to Zero. To choose the native floating point library and specify zero latency strategy, at the command line, enter:

fc = hdlcoder.createFloatingPointTargetConfig('NativeFloatingPoint');
hdlset_param('RunningSum/CumSum_sl/Subsystem/Add', ...
                                  'LatencyStrategy', 'Zero');

Note

To obtain good performance on the target FPGA device, it is not recommended to set Latency Strategy to Zero from the Configuration Parameters dialog box.

See Also

Related Examples

More About