1.1.2. Reduce Logic Levels
Excessive logic levels can impact the Fitter's quality of results because the design critical path influences Fitter processing order and duration.
The Fitter places and routes the design based on timing slack. The Fitter places longer paths with the least slack first. The Fitter generally prioritizes higher logic-level paths over lower-logic level paths. Typically, after the Fitter stage is complete, the critical paths remaining are not the highest logic level paths. The Fitter gives preferred placement, routing, and retiming to higher level logic. Reducing the logic level helps to ensure that all elements of the design receive the same Fitter priority.
Run in the Timing Analyzer to generate reports showing the levels of logic in the path. If the path fails timing and the number of logic levels is high, consider adding pipelining in that part of the design to improve performance.
Logic Depth in Path Report
Reporting Logic Level Depth
After the Compiler's Plan stage, you can run report_logic_depth in the Timing Analyzer Tcl console to view the number of logic levels within a clock domain. report_logic_depth shows the distribution of logic depth among the critical paths, allowing you to identify areas where you can reduce logic levels in your RTL.
report_logic_depth -panel_name <name> -from [get_clocks <name>] \
-to [get_clocks <name>]
Figure 5. report_logic_depth Output
To obtain data for optimizing RTL, run report_logic_depth after the Compiler's Plan stage, before running remaining Fitter stages. Otherwise, the post-Fitter reports also include results from physical optimization (retiming and resynthesis).
Reporting Neighbor Paths
After running the Fitter (Finalize) stage, you can run report_neighbor_paths to help determine the root cause of the critical path (for example, high logic level, retiming limitation, sub-optimal placement, I/O column crossing, hold-fix, or others):
report_neighbor_paths -to_clock <name> -npaths <number> -panel_name <name>report_neighbor_paths reports the most timing-critical paths in the design, including associated slack, additional path summary information, and path bounding boxes.
Figure 7. report_neighbor_paths Output
report_neighbor_paths shows the most timing-critical Path Before and Path After each critical Path. Retiming or logic balancing of the path can simplify timing closure if there is negative slack on the Path, but positive slack on the Path Before or Path After.
To enable retiming, make sure the following options are turned on:
- For Registers—enable
- For RAM Endpoints—enable
- For DSP Endpoints—enable
If further logic balancing is required, you must manually modify your RTL to move logic from the critical Path to the Path Before or Path After.
Note: If a register's output is connected to its input, one or both of the neighbor paths may be identical to the current path. When looking for neighbor paths with the worst slack, all operating conditions are considered, not just the operating conditions of the main path itself.
Visualizing Logic Levels in Technology Map Viewer
The Technology Map Viewer also provides schematic, technology-mapped, representations of the design netlist, and can help you see which areas in a design can benefit from reducing the number of logic levels. You can also investigate the physical layout of a path in detail in the Chip Planner.
To locate a timing path in one of the viewers, right-click a path in the timing report, point to Locate Path, and select Locate in Technology Map Viewer.