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 genhdltdb function.

• 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 SynthesisToolChipFamily and SynthesisToolSpeedValue. If you do not specify a value for SynthesisTool or for SynthesisToolChipFamily and SynthesisToolSpeedValue, HDL Coder generates a warning when generating HDL code. HDL Coder sets the default values for SynthesisToolChipFamily and SynthesisToolSpeedValue as virtex7 and -1 respectively. To prevent the warning, specify the SynthesisToolChipFamily and SynthesisToolSpeedValue parameters.

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.

• Use the hdlset_param function. Set the parameter to on at the command line. For example, to enable this parameter for the model sfir_fixed, use this command:

  hdlset_param('sfir_fixed','UseSynthesisEstimatesForDistributedPipelining','on')

For more information, see the Use Synthesis Timing Estimates for Distributed Pipelining section in the Distributed Pipelining: Speed Optimization example.

Limitations

• 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 MATLAB Datapath.