Distributed Pipelining Using Synthesis Timing Estimates
Distributed pipelining is a speed optimization that increases clock frequency for your target device by distributing pipelines in your generated HDL code. For more information, see Distributed Pipelining. Synthesis timing estimates can more accurately reflect how components function on hardware. You can use them for distributed pipelining to more effectively maximize the clock frequency for your specific target device.
Synthesis Timing Estimates in Distributed Pipelining
When applying distributed pipelining to a subsystem, HDL Coder™ calculates an approximate propagation delay for each component in your design to determine where to place the added delays. Synthesis timing estimates are propagation delay estimates for each component in your design.
Without synthesis timing estimates, HDL Coder calculates propagation delay for the components in your design by assigning each component an equal weight, except for wire components, such as Selector blocks and Bit Concat blocks, that are assigned zero propagation delay.
Using synthesis timing estimates, HDL Coder calculates propagation delays for the components in your design by
assigning different weights to varying components, based on how the components
function on hardware. This information is derived from a target-specific timing
database that HDL Coder supports, or that you create by using the
genhdltdb function. Critical path estimation uses the same timing
databases to estimate the critical path in a design. See Critical Path Estimation Without Running Synthesis. Using synthesis timing estimates for
distributed pipelining is typically applied when you specify a synthesis tool for
the model because the optimization option is platform-specific.
How Distributed Pipelining Works By Using Synthesis Timing Estimates
For an example of how distributed pipelining works using by synthesis timing estimates, in the following model, there is a delay of 2 at the output. Multipliers on hardware take longer to compute than adders, meaning their actual propagation delay is longer than adder propagation delay. To simplify the calculations for this example, assume adders have a propagation delay of one nanosecond and multipliers have twice as long of a propagation delay as adders, two nanoseconds.
Without using synthesis timing estimates for distributed pipelining, the adders and multipliers are given equal weights for their propagation delays and the distributed pipelining algorithm cannot tell the difference between the components. The pipelines are distributed as shown in the figure. The critical path length then becomes the delay of the first adder and multiplier, three nanoseconds.
Using synthesis timing estimates for distributed pipelining, the adders and multiplier are now given weights for their propagation delays that more accurately reflect how the components function on hardware. The delays are redistributed so that the critical path contains just the multiplier, making the critical path length the propagation delay of just the multiplier, two nanoseconds.
Using synthesis timing estimates for distributed pipelining most effectively minimizes the critical path to maximize the clock frequency for your design when:
Your synthesis tool and target hardware have been characterized by using a timing database that HDL Coder supports or by using a timing database that you create by using the
All of the blocks in your design are characterized, meaning the blocks are part of the timing database for each supported target device. See Characterized Blocks.
Requirements for Synthesis Timing Estimates for Distributed Pipelining
To use synthesis timing estimates for distributed pipelining, specify distributed pipelining for at least one subsystem or MATLAB Function block in your design.
If you specify a synthesis tool using the model parameter
SynthesisTool, HDL Coder sets default values for the model parameters
SynthesisToolSpeedValue. If you do not specify a value for
SynthesisTool or for
SynthesisToolSpeedValue, HDL Coder generates a warning when generating HDL code. HDL Coder sets the default values for
-1 respectively. To prevent the warning, specify the
Specify Distributed Pipelining to Use Synthesis Timing Estimates
To use synthesis timing estimates for distributed pipelining, you can:
In the Configuration Parameters dialog box, enable the parameter Use synthesis estimates for distributed pipelining, located in HDL Code Generation > Optimization > Pipelining tab.
hdlset_paramfunction. Set the parameter to
onat the command line. For example, to enable this parameter for the model
sfir_fixed, use this command:
For more information, see the Use Synthesis Timing Estimates for Distributed Pipelining section in the Distributed Pipelining: Speed Optimization example.
The run time to generate HDL code from your model is approximately 10x more than the run time of using equal weights to calculate the propagation delays of the components in your design.
If there are uncharacterized blocks in the model that are not supported, the distributed pipelining results might be less optimal than not using synthesis timing estimates for distributed pipelining. The uncharacterized blocks in the model appear as a message in the HDL Code Generation Check Report and the Resource Utilization Report, and as a link to a script to highlight the blocks in the MATLAB® Command Window.
If you have a MATLAB function block in your design with the HDL Block Property Architecture set to
MATLAB Function, when using synthesis timing estimates for distributed pipelining, you might see the MATLAB function block appear as an uncharacterized block in the reports. To characterize the MATLAB function block, set the Architecture to
- Distributed Pipelining: Speed Optimization
- Distributed Pipeline Insertion for MATLAB Function Blocks
- Iteratively Maximize Clock Frequency by Using Speed Optimizations