メインコンテンツ

Reduce Resource Utilization and Achieve Timing Closure

Since R2026a

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 class

  • post_synth_util_hier.rpt — Hierarchical post‑synthesis utilization that attributes resource counts per instance

  • post_route_util.rpt — Flat post‑route utilization for each resource class

  • post_route_util_hier.rpt — Hierarchical post‑route utilization that attributes resource counts per instance

  • post_route_timing_summary.rpt — High-level timing summary that details timing closure

  • post_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.

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:

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 DUTOutputAntenna property of the usrp System 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 LevelDebugging CapabilityRun-Time Flexibility
Change DUT Antenna ConnectionsChange Sample Rate
NoneYes — Specify additional capture and transmit antenna connections to exercise the DUT.Yes — Change antenna connections at run-time.Yes — Change to any supported value.
ModerateYes — 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*.
HighYes — 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*.
MaximumNo — 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 DeviceMinimum DUT Clock FrequencyMaximum DUT Clock Frequency

    USRP™ E320

    6.25 MHz

    741 MHz

    USRP N310, N320, N321, or X310

    4.69 MHz709 MHz

    USRP X410

    6.25 MHz667 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).

See Also

Topics