Failing timing path analysis is defined as investigating one or more timing paths that have negative slack to determine what to do to achieve timing closure.

Detailed timing analysis of individual timing paths should not be the first analysis step used when a design is failing timing. The design should first be analyzed from a system perspective to determine if there are factors that affect large areas of the design and not just the highest failing individual paths.

A helpful guide in this process is (UG1292) – UltraFast Design Methodology Timing Closure Quick Reference Guide.

This blog post addresses the Timing Baselining Flow in the document, specifically post place when WNS < 0ns or WHS < -.5ns and post-route WNS < 0ns or WHS < 0ns  (circled in red).

To address these timing failures, users can employ a method for timing path analysis to prioritize timing failures after the place, phys_opt, and route implementation steps.

The first step is to generate a set of reports with the commands listed below.

In the non-project mode in Vivado, these commands can be added into the Tcl script used to run the flow. In project mode in Vivado, these commands can be added into Tcl hook scripts (see the “Defining Tcl Hook Scripts” section of (UG894)) .

report_design_analysis -timing -routes -logic_level_distribution -of_timing_paths [get_timing_paths -routable_nets -max_paths 10000 -slack_lesser_than 0] -file timing_vios.rpt
report_timing -of [get_timing_paths -routable_nets -max_paths 1000 -slack_lesser_than 0] -file timing_paths.rpt -rpx timing_paths.rpx

These commands generate the text reports timing_vios.rpt and timing_paths.rpt which can viewed in any text editor. These commands also generate the interactive report timing_paths.rpx that can be used for cross-probing in the Vivado GUI. These reports display information about the top failing paths in the design. They can be used together to progress quickly to timing closure.

timing_vios.rpt

This report shows properties of the top failing timing paths (Up to 10,000 per Tcl command parameters) . At the bottom of the report is a histogram that shows how many failing timing paths there are per endpoint clock, grouped by logic levels. This histogram can be a good high-level view to help narrow down which clock domains contribute to the failing timing most significantly.

Users should start with failures for the clock domains that have the most failures. In multi-SLR devices, many failures with zero logic levels can indicate that not enough pipelining exists or that poor SLR partitioning could be the root cause for the timing violations.

These are all clues but not true causes of timing failure. It is important to narrow down the biggest problem areas before jumping to solutions. Understanding the nature of the worst negative slack timing violations helps users to prioritize what mitigating steps should be taken. An example simple histogram (only 1 clock with failing paths) is shown below.

The rest of the report can be read in a text editor but can be hard to read due to line wrapping. A much easier way to analyze the data is to bring it into Microsoft Excel.  The below process will convert the text editor report to a comma separated report.

1. Create a copy of the timing_vios.rpt and rename it to timing_vios.csv.
2. Using a text editor, remove the header, header separator row, and footer from the report (shown in red boxes below) .
3. If the -show_all option was used with the report_design_analysis Tcl command, replace commas (,) with colons (:) in the file.
4. Replace all pipe characters (|) with commas (,) and save the file.
5. Close the file.

Top of timing_vios.rpt

Bottom of timing_vios.rpt

6. Open the csv file in Microsoft Excel.
7. Remove column A, as it is an empty column.
8. Insert a blank row at the top.
9. Add the below equation to generate the percentage of slack in the report that is not filtered out, (unfiltered slack percentage). This percentage will help guide the analysis. The larger the percentage, the worse the failure signature impacts timing.

=SUBTOTAL(109,G:G)/SUM(G:G)*100

10. Highlight row 2 of the excel document, which should be the header row of columns and select Data -> Filter.

Use this report with filtering to find the failure types that have the most impact on the design.

Frequently, this report alone will not provide the exact cause of a timing failure, but it can help guide the user to the paths that should be investigated further using the interactive timing report (timing_paths.rpx; tips and tricks for this report will be provided later).

By filtering, users can see similar paths (for example, paths within a bus) with similar properties (logic levels, start point pins, etc) that are failing. Users can use the unfiltered slack percentage to help guide them. Also, use the records found line (shown below) with filtering, and pay attention to the row numbers displayed after filtering (lower rows numbers in the spreadsheet means worse failing timing paths are being displayed).

Below are a few helpful tips on filtering.

Using Text Filters -> Contains is helpful for Start Point Pin, End Point Pin, and Logical Path filtering. The following columns can be displayed in timing_vios.csv (definitions are from (UG835) v2020.1 p.1324-1325) .

Listed below are a several checks to try and find low hanging fruit upon first generating the spreadsheet. These checks are more focused on post-design causes and fixes for timing failures. A designer can also choose to change HDL to reduce path length or reduce clock rates, along with other fixes that are not addressed below.

1. In the clock relationship column, are all of the timing failing paths Safely Timed? If not, are timing constraints appropriate for the other paths?
2. Are there any timing failing paths that have clock skew > .5ns? If so, see page 8 of (UG1292) v2020.1 for skew recommendations.
3. For SSI devices, what is the unfiltered slack percentage for paths that cross an SLR? If this is high, see (UG1292) v2020.1 p.7.
4. What percentage of failing timing paths have pblocks associated with them? If this is a considerable percentage of failures, see (UG1292) v2020.1 p.7 .
5. Is there a large set of failing timing paths with a high fanout (>=512)? In (UG1292) v2020.1 p.6, it is recommended to optimize high fanout nets with 512 endpoints if the tool is struggling with net delay.
6. Are there any timing failing paths that have DONT_TOUCH or MARK_DEBUG? Are these timing paths in logic that are not third-party or Xilinx IP? These properties prevent optimizations by the tools that can improve timing.
7. What is the percentage of paths that have a start point pin primitive or end point pin primitive that are not register types (not FDPE, FDCE, FDRE, FDSE)? Are there similar failure signatures?
8. For post-route, what percentage of timing paths have non-zero hold detour?

timing_paths.rpt

This is a text-based report of the timing analysis on the top failing timing paths (up to 1K depending on Tcl command parameters) in the design. It can be helpful to generate a list of failing sources and destinations of the top 1K paths through the use of a simple Linux grep.  For example, a user can identify the top 100 timing startpoints or endpoints as follows:

grep -m 10 "Source:" place_paths.rpt > top_100_startpoints.rpt
grep -m 10 “Destination:” place_paths.rpt > top_100_endpoints.rpt

timing_paths.rpx

This is the interactive report version of timing_paths.rpt . The three most useful windows are the device, hierarchy, and schematic windows.

Once a failure signature has been determined to have a large impact on the timing of the design, the timing_paths.rpx report can be used to dig into it. Using the timing_paths.rpx report in Vivado, users can determine why the timing failure signature occurs, using the top failing path that has the failure signature.

To view the information for each path that is contained in timing_path.rpt, double click on an individual timing path in the interactive report in Vivado. A path report summary window should appear with the path information, including clocks and datapath. It is useful to view the path in the schematic. Using the schematic, the clocks that source the sequential elements in the data path can be viewed. Along with this, the datapath can be better understood by including stages before and after the failing timing path.

Cell properties, net properties, and pin properties can also be viewed in the schematic, which can show the fixed placement cells (for example, transceivers) or limited placement cells (for example, block memories) close to the failing timing path.

Users can also highlight paths in the timing report which will highlight the modules in the hierarchy window as well. If a user selects the top 10, 100 or 1000 paths, they can see if the timing path failures are concentrated in a certain section of the hierarchy. Knowing where paths are in the hierarchy can help focus the timing closure effort on understanding why an area of the design has more failures.

Finally, users can highlight paths in the timing report, and these paths will also appear in the device window, showing where logic is placed in the physical device (shown below) .

Using the schematic window, cells can be marked within timing paths to help users navigate between the schematic, hierarchy, and device window (shown below)

Putting the Building Blocks Together

This blog post provides a method for timing path analysis prioritization in the timing baselining flow of (UG1292). The below topics were covered in this blog.

1. How to generate important reports for this analysis (timing_vios.rpt and timing_paths.rpx) .
2. Analysis of timing_vios.rpt, including placing it into an Excel format (timing_vios.csv) that is easier to analyze.
3. Using timing_paths.rpx to help determine causation of timing failures.

In large failing designs, a user will iterate between the two reports ( timing_vios.csv and timing_paths.rpx). The timing_vios.csv reports gives a high level view of the failures (i.e.a forest level view) . The timing_paths.rpx report including the schematic window, the device window, and the path report provides the specifics of individual paths (i.e. individual tree view).

You can keep returning to timing_vios.csv to find common failure signatures. Just like if you were a detective, a lot of leads will not work out. The highest negative slack paths might not have an easy explanation for why they are failing. If that is the case, then the next highest negative slack group of timing paths should be analyzed to see why they are failing.

The goal is to move forward as fast as possible by finding causes to the most common timing failures. Hopefully this leads to faster timing closure and less stomach aches. Good hunting!

Source: https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Supercharging-Timing-Path-Analysis/ba-p/1151867