Reduce Resource Utilization and Achieve Timing Closure
If your bitstream build fails due to over-utilization of the available resources on the FPGA, or the bitstream build is successful but fails to achieve timing closure, you can use utilization and timing reports to identify the cause and apply targeted fixes. This topic guides you through how to identify the root cause and the steps you can take to reduce the resource utilization or negative slack in your design.
Interpret Utilization and Timing Reports
To identify the root cause or causes of the over-utilization or timing failure, use the
utilization and timing summary reports that are generated in the project folder, for
example, <projectFolder>/build_N320_HG/build-N320_HG. The files to
review are:
post_synth_util.rpt— Flat post‑synthesis utilization for each resource classpost_synth_util_hier.rpt— Hierarchical post‑synthesis utilization that attributes resource counts per instancepost_route_util.rpt— Flat post‑route utilization for each resource classpost_route_util_hier.rpt— Hierarchical post‑route utilization that attributes resource counts per instancepost_route_timing_summary.rpt— High-level timing summary that details timing closurepost_route_timing.rpt— Detailed timing report of the slack in each path
In MATLAB®, navigate to the build directory in the Files panel. Right-click the file and select Open as text.
Utilization Reports
The post-route utilization report, post_route_util.rpt, summarizes
the resource utilization after place-and-route. Use this report to evaluate the
utilization of FPGA resources. If your design is unroutable, the post-route utilization
report is not generated. Use the post-synthesis utilization report,
post_synth_util.rpt, to determine if over-utilization of FPGA
resources may be contributing to the place-and-route failure.
The hierarchical utilization reports, post_route_util_hier.rpt and
post_synth_util_hier.rpt, detail the resource utilization per
instance. Use this report to evaluate the resource utilization of the DUT compared to the
resource utilization of the design external to the DUT.
Timing Summary Report
Use the post-route timing summary report,
post_route_timing_summary.rpt, to identify the root cause of a timing
closure failure.
The Design Timing Summary provides high-level overview of the worst negative slack (WNS), total negative slack (TNS), and the number of negative slack failing endpoints.
The Timing Details provide a path-by-path breakdown of the most critical timing paths.
Use these files to identify whether violations are driven by long chains of combinational logic, excessive routing delay from congestion or detours, near-capacity resource utilization, or other factors.
Decide Next Steps
Use the root cause or causes you have identified to determine your next steps.
Possible Solutions for Over-Utilization
First, take steps to reduce the resource utilization of your DUT.
Optimize the design of your model. For details, see Improve Model.
Use HDL Coder™ area optimizations. For details, see Configure HDL Code Generation Optimizations.
If you cannot reduce the resource utilization inside the DUT, you can reduce the resource utilization external to your DUT by leveraging reference design optimization. For details, see Configure Reference Design Optimization.
Possible Solutions for Timing Violations
If the excessive negative slack is driven by long chains of combinational logic inside the DUT, consider these possible solutions:
Optimize the design of your model. For details, see Improve Model.
Use HDL Coder speed optimizations. For details, see Configure HDL Code Generation Optimizations.
Configure a custom DUT clock rate if your design is not required to operate at a clock rate close to the maximum supported MCR of your radio device. For more information, see Use Custom DUT Clock.
If the resource utilization is close to 100% and the overcrowding is the root cause of the excessive negative slack, consider the possible solutions of over-utilization.
Improve Model
Consider making changes to your model that reduce resource utilization or routing pressure. For example:
Use HDL-optimized library blocks instead of generic versions.
Remove non-essential logic from the DUT. For example, move scopes and measurement logic to the top level model.
Simplify arithmetic where possible.
Serialize parallel copies of the same computation to reduce the utilization of multipliers and adders.
Insert delay blocks in long control paths or complex operations to shorten combinational paths and reduce routing pressure.
Configure HDL Code Generation Optimizations
HDL Coder provides various speed and area optimizations that help to generate more hardware-efficient HDL code. To configure these options, use the HDL Code Generation > Optimization pane in the Configuration Parameters dialog box. For more information, see Introduction to Optimizations in HDL Coder (HDL Coder).
Configure Reference Design Optimization
When you generate a bitstream for your design using the targeting workflow, Wireless Testbench™ uses dynamic connections and includes all available RF channels, the PL DDR buffer, and resampling logic by default, even if your design does not require them. This configuration provides maximum run-time flexibility, which enables you to take any of these actions using your deployed bitstream:
Change the sample rate to any supported value for your radio device, which is a supported MCR divided by a supported decimation or interpolation factor. For details, see Baseband Sample Rate in NI USRP Radios.
Change the antenna connections to your DUT. For example, change the transmit antenna connected to your DUT using the
DUTOutputAntennaproperty of theusrpSystem object™.Use any antenna that is not connected to the DUT as a transmit or capture antenna to exercise the DUT for debugging.
To reduce the resource utilization of your design, use reference design optimization to remove logic in the reference design that is outside of your DUT. To specify a reference design optimization level, use the Reference Design Optimization reference design parameter in the HDL Code Generation > Target pane in the Configuration Parameters dialog box. The optimization level you choose is a trade-off between run-time flexibility and resource utilization. The options are:
| Reference Design Optimization Level | Debugging Capability | Run-Time Flexibility | |
|---|---|---|---|
| Change DUT Antenna Connections | Change Sample Rate | ||
None | Yes — Specify additional capture and transmit antenna connections to exercise the DUT. | Yes — Change antenna connections at run-time. | Yes — Change to any supported value. |
Moderate | Yes — Specify additional capture and transmit antenna connections to exercise the DUT. | No — DUT antenna connections are fixed based on the interface mapping table. | MCR only if Sample Rate is set to an MCR value; otherwise, any supported value*. |
High | Yes — Specify one additional capture antenna and one additional transmit antenna connection to exercise the DUT. | No — DUT antenna connections are fixed based on the interface mapping table. | MCR only if Sample Rate is set to an MCR value; otherwise, any supported value*. |
Maximum | No — No antennas available for debugging. | No — DUT antenna connections are fixed based on the interface mapping table. | MCR only if Sample Rate is set to an MCR value; otherwise, any supported value*. |
| * If you set the Sample Rate reference design parameter to an MCR value, the design does not include resampling logic, so you can change the sample rate only to other MCR values at run-time. If you do not set the parameter to an MCR value, the design includes resampling logic, and you can set the sample rate to any supported value for the radio device. | |||
Reducing the resource utilization of your design can also ease timing constraints by leaving more space available for efficient routing.
Use Custom DUT Clock
You can reduce the timing constraints on your design by synthesizing your DUT at a lower clock frequency. The default behavior in the targeting workflow uses the MCR of the target radio device to ensure that the generated bitstream can operate at any supported frequency. If you do not require your design to operate at the higher end of this range, you can configure a custom DUT clock and synthesize at a lower frequency.
To perform HDL synthesis at a lower frequency, specify these options in the HDL Code Generation > Target pane in the Configuration Parameters dialog box:
Set the DUT Clock Source reference design parameter to
Custom.Set the Target Frequency (MHz) objective setting to the highest value at which you need your design to operate within the supported target frequency range for your radio device.
Note
The custom DUT clock is generated independently from the radio clock. To avoid overflows due to clock misalignment, set the custom DUT clock frequency to a value that is greater than the sample rate.
The valid range depends on the radio.
Radio Device Minimum DUT Clock Frequency Maximum DUT Clock Frequency USRP™ E320
6.25 MHz
741 MHz
USRP N310, N320, N321, or X310
4.69 MHz 709 MHz USRP X410
6.25 MHz 667 MHz
Use this strategy only if you have additional FPGA resources available. Implementing a custom DUT clock frequency requires additional IP in the design that consumes resources.
Verify and Iterate
Once you have identified and implemented the most impactful steps to reduce the resource utilization or negative slack in your design, regenerate the bitstream. If your bitstream build still fails due to over-utilization of the available resources on the FPGA, or the bitstream build is successful but fails to achieve timing closure, analyze the utilization and timing logs and iterate.
To identify the combinational path between an input and output that has the maximum timing delay without running synthesis, you can use HDL Coder critical path estimation. For more information, see Critical Path Estimation Without Running Synthesis (HDL Coder).