Critical path is a combinational path between an input and output that has the maximum delay. Use the HDL Coder™ software to find the critical path in your design. To make the critical path timing meet the target frequency that you want your design to achieve, break the critical path by adding delays. The additional delays do increase the latency and register usage on the target FPGA.
To quickly identify the most likely critical path in your design, use critical path estimation. With critical path estimation, you do not have to run synthesis or generate HDL code. Critical path estimation speeds up this iterative process of finding the critical path, and then optimizing the critical path until your design timing meets the target frequency that you want.
Estimating the critical path without using synthesis tools can lead to inaccurate timing results. Critical path estimation is intended to speed up the design iteration process. Critical path estimation is an alternative to annotating the critical path by performing FPGA Synthesis and Analysis with the HDL Workflow Advisor.
HDL Coder finds the estimated critical path by performing static timing analysis with timing data from target-specific timing databases. HDL Coder has timing databases for these target devices:
Altera® Cyclone V
Intel® Stratix V
Xilinx® Virtex®-7, speed grade -1
Xilinx Zynq®, speed grade -1
To create timing databases, HDL Coder characterizes basic design components, such as Simulink® blocks, block architectures, and subcomponents of those blocks, for specific target devices.
The code generator analyzes your model design to decompose it into the blocks and subcomponents in the timing databases. If your design consists of blocks or subcomponents in the timing databases, the code generator can estimate the timing critical path more accurately. If your design uses components that are not in the timing databases, a separate highlighting script is generated to show the uncharacterized blocks. If the timing data is incomplete for parts of your design, it is possible that the estimated critical path does not match your actual critical path.
If your target hardware is one of the target devices supported for critical path estimation, the timing numbers and estimated critical path are more accurate. If your target hardware is not a supported device, or is not in the same device family, you can estimate the critical path, but it is possible that the timing numbers are not accurate.
You can estimate the critical path for your design either in the Configuration Parameters dialog box or at the command line. To estimate the critical path in the Configuration Parameters dialog box:
Enable generation of critical path estimation report.
In the Apps tab, select HDL Coder. The HDL Code tab appears.
Select Settings > Report Options, and then select Generate high-level timing critical path report.
Disable HDL code generation for your model. In the HDL Code Generation > Global Settings > Advanced tab, clear the Generate HDL Code check box.
To estimate the critical path in your design, you do not have to run the complete code generation process. When you disable HDL code generation, you run the process until HDL Coder creates the generated model and displays the critical path estimation script. You avoid running a larger portion of the code generation process, which saves time in estimating the critical path, especially for large models.
If your design contains floating-point data types, enable the
Native Floating Point
mode. In the Configuration
Parameters dialog box, on the HDL Code Generation > Floating Point pane, set Floating Point IP Library
to Native Floating Point
.
Generate a critical path estimation report. In the HDL Code Generation pane, click Apply, and then click Generate.
HDL Coder generates a critical path estimation report and displays messages in the MATLAB® Command Window that include a link to a highlighting script and a script that clears the highlighting.
To script this workflow or generate the report at the command line, enter these
commands. Specify the modelname
and dutname
based on the design that you want to estimate the critical path for. This example
uses the sfir_single
model.
% Specify the model and Subsystem names modelname = 'sfir_single'; dutname = 'sfir_single/symmetric_fir'; open_system(modelname) % Disable HDL code generation for faster generation % of critical path estimation report hdlset_param(modelname, 'CriticalPathEstimation', 'on'); hdlset_param(modelname, 'GenerateHDLCode', 'off'); % If your design contains single data types, % enable native floating-point support fpconfig = hdlcoder.createFloatingPointTargetConfig('NativeFloatingPoint'); hdlset_param(modelname, 'FloatingPointTargetConfig', fpconfig); % Generate the report makehdl(dutname)
When you click the link to the criticalpathestimated
script,
the code generator highlights the critical path in the generated model. In the
generated model, you see the critical path timing information and blocks that are on
this path. This figure shows a section of a Simulink model that has the critical path annotated. The native floating-point
operators are highlighted in light blue and the delays are highlighted in orange.
The block that is part of the critical path is highlighted in dark blue with the
critical path value annotated beside the block. To learn more about the different
colors, see Generated Model and Validation Model.
You can clear the highlighting by clicking the link to the
clearhighlighting
script.
To optimize the critical path, break the critical path by adding pipeline
registers. If you are using Native Floating Point
, set the
LatencyStrategy to Max
to
improve timing. Regenerate the critical path estimation report and the script that
highlights the critical path in your design. You can repeat this process until your
design timing meets the target frequency that you want.
This table shows blocks that are characterized with fixed-point and single-precision native floating-point types. These blocks are part of the timing database for each supported target device.
Math Operations
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Abs | ✓ | ✓ |
Add | ✓ (The block cannot have more than two inputs) | ✓ |
Subtract | ✓ | ✓ |
Product | ✓ | ✓ |
Gain | ✓ | ✓ |
Divide | ✓ | ✓ |
HDL Reciprocal | ✓ | ✓ |
Rounding Function | ✓ | ✓ |
Unary Minus | ✓ | ✓ |
Sign | ✓ | ✓ |
Reshape | ✓ | ✓ |
Complex to Real-Imag | ✓ | ✓ |
Math Functions
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Reciprocal | ✓ | ✓ |
Hypot | - | ✓ |
Rem | - | ✓ |
Mod | - | ✓ |
Sqrt | ✓ | ✓ |
Reciprocal Sqrt | ✓ | ✓ |
Trigonometric Functions
Exponent/Logarithm/Power
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Exp | - | ✓ |
Gain to power of two | - | ✓ |
Pow10 | - | ✓ |
Log | - | ✓ |
Log10 | - | ✓ |
Conversions and Comparisons
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Data Type Conversion | ✓ | ✓ |
Float Typecast | - | ✓ |
Relational Operator | ✓ | ✓ |
Compare To Constant | ✓ | ✓ |
MinMax | ✓ | ✓ |
Logic and Bit Operations
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Bit Concat | ✓ | - |
Extract Bits | ✓ | - |
Bit Shift | ✓ | - |
Bit Slice | ✓ | - |
Bitwise Operator | ✓ | - |
Logical Operator | ✓ | ✓ |
Delays and Signal Routing
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Unit Delay | ✓ | ✓ |
Delay | ✓ | ✓ |
Bus Creator | ✓ | ✓ |
Bus Selector | ✓ | ✓ |
Demux | ✓ | ✓ |
Multiport Switch | ✓ | ✓ |
Selector | ✓ | ✓ |
Switch | ✓ | ✓ |
HDL Operations and HDL RAMs
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Counter Free-Running | ✓ | ✓ |
Counter Limited | ✓ | ✓ |
HDL Counter | ✓ | ✓ |
Dual Port RAM | ✓ | ✓ |
Dual Rate Dual Port RAM | ✓ | ✓ |
Simple Dual Port RAM | ✓ | ✓ |
Single Port RAM | ✓ | ✓ |
Deserializer1D | ✓ | ✓ |
Serializer1D | ✓ | ✓ |
Signal Attributes and Lookup Tables
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
Constant | ✓ | ✓ |
1-D Lookup Table | ✓ | ✓ |
2-D Lookup Table | ✓ | ✓ |
n-D Lookup Table | ✓ | ✓ |
Rate Transition | ✓ | ✓ |
Signal Conversion | ✓ | ✓ |
Signal Specification | ✓ | ✓ |
User-Defined Functions
Simulink Blocks | Fixed Point | Single (Native Floating Point) |
---|---|---|
MATLAB Function | - | ✓ |
When you use MATLAB Function blocks and generate code by using the
MATLAB Datapath
architecture, HDL Coder converts the MATLAB algorithm to a Simulink block diagram. In the generated model, critical path estimation can
annotate the critical path inside the MATLAB Function
block and
across the MATLAB Function
block boundary with other Simulink blocks. See also HDL Optimizations Across MATLAB Function Block Boundary Using MATLAB Datapath Architecture.
Critical path estimation does not consider the clock gating information to different sequential elements in your design.
If your model contains multiple sample rates or uses speed and area optimizations that insert pipeline registers, your design becomes multirate and can have multicycle paths. For multirate models, critical path estimation treats the slow and fast data paths to be running at the same rate. A data path that has a faster clock rate might be highlighted as the critical path when the design has another data path at a slower rate. This might cause critical path estimation to report inaccurate timing results.
To verify the estimated critical path information, open the HDL Workflow
Advisor and run the Generic ASIC/FPGA
workflow for
your target device to the Annotate model with synthesis
result task.
If you have single
data types in your design and you use
the Native Floating Point
mode, the critical path estimation
script sometimes highlights a single floating-point operator in the generated
model. The code generator highlights a single block because floating-point
algorithms are computation-intensive, and the critical path can be an internal
register-to-register path within the floating-point operator.
In this case, to optimize the critical path timing, set the
LatencyStrategy to Max
for
the Simulink block corresponding to that operator.
In addition, critical path estimation with native floating-point does is not
supported for blocks with LatencyStategy set to
Custom
.
When you enable critical path estimation, it is possible that the generated HDL code is different from the report for a Delay block that has an external reset or an enable port. In addition, for blocks such as MinMax, the number of generated HDL files might differ when you enable critical path estimation. This change occurs due to certain optimizations performed by the code generator when you enable this optimization. The optimization only changes how the code appears and does not affect the functionality.
Following are the Simulink blocks for which the generated HDL code can potentially be different.
Delay block that has external reset or enable port
MinMax
Unit Delay Enabled Synchronous
Unit Delay Resettable Synchronous
Unit Delay Enabled Resettable Synchronous
Enabled Delay
Resettable Delay
Tapped Delay
Discrete FIR Filter
Biquad Filter
MATLAB Function
Critical path estimation tries to account for routing delay by using an estimation factor. Without running place and route, it is difficult to accurately account for routing delay.
HDL Coder infers uncharacterized blocks that are combinational in nature as zero-delay combinational blocks. The code generator treats other blocks as registers.
If your target device does not have timing characteristics that are similar to one of the supported target devices, critical path estimation cannot accurately compute your critical path.
hdlcoder.FloatingPointTargetConfig
| makehdl