cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using the Methodology Report Part Two: Effect of Methodology Violations on QoR

Xilinx Employee
Xilinx Employee
7 1 488

The analysis in this blog entry is based on a real customer issue where they were seeing poor QoR on one OS vs another. Although it was understood that Xilinx does not guarantee repeatability between different OS's as documented in (Xilinx Answer 61599), the magnitude of the difference in this case warranted further investigation.

Initially better results were seen with Windows, but later better results were seen with Linux. In the end, the issue was related to having certain Super Critical Methodology Violations in the design.

 

Issue Explanation:

The user was seeing significant timing differences between Linux and Windows on an identical design.

Running the exact same design on each OS produced: WNS = -0.439ns on Linux and WNS = +26ps on Windows.

The user ran the builds several times on different machines but got the same results for each OS.

Timing violations from the Linux run are shown in the screenshot of the Design Timing Summary below. The Windows run is Timing clean.

Note: You can check the Timing Summary for a design yourself using the options below:

  • In the Vivado GUI Go to Reports tab -> Timing -> Report Timing Summary
  • Run the Tcl command below:
report_timing_summary -file <filepath>/timingreport.txt

 

Linux Run:

dsheils_0-1601642673496.png

Windows Run:

dsheils_1-1601642673504.png

Root cause analysis:

The first thing to verify is that all design sources, constraints sets, Synthesis and Implementation directives, and Vivado Tool settings are identical between the two runs. Also made sure that no Vivado Patches are being used in one OS and not the other and that no tool parameters are being set in the Vivado_Init.tcl file.

Digging into the design some more, we  can do a write_xdc from the Tcl Console after Place and Route. This allows us to verify that both builds have the same constraints applied.

To check the warnings/critical warnings related to clocking/architecture/CDC etc., open the methodology report.

To open the methodology report in the Vivado GUI go to Report tab -> Report Methodology or in the Tcl console use report_methodology.

Once the report opens up you might see several warnings and critical warnings related to your design.

While going through this report we have found a few warnings on bad practices related to clock relationships in the design (the IDs of these warnings are TIMING-6, and TIMING-7) as shown below.

dsheils_2-1601642673521.png

The Timing-6 Critical Warning is saying that Vivado has found two clocks that are timed together but have no common primary clock.

The two clocks reported are considered related and timed as synchronous by default even if they are not derived from a common primary clock and do not have a known phase relationship. The DRC warning is reporting that the timing engine cannot guarantee that these clocks are synchronous.

The Timing-7 Critical Warning is saying that Vivado has found two clocks that are timed together but have no common node. This DRC is reporting that the timing engine cannot guarantee that these clocks are synchronous in hardware as it could not determine a common node between the two clock trees.

Certain Methodology Critical Warnings can have implications for QoR on a design, that is to say that having any of these Critical Warnings can sometimes lead to inconsistent results from one run to the next. The Methodology Critical Warnings that should be treated as Super Critical are:

  • TIMING-6
  • TIMING-7
  • TIMING-8
  • TIMING-14
  • TIMING-35

No design should have any of these violations present and the user should take action to resolve them as soon as possible as they can impact QoR.

TIMING-6 and TIMING-7 - How to resolve these warnings/critical warnings:

The resolution depends on whether the two clock domains are asynchronous or synchronous. In the case of the clocks being asynchronous, the paths between the two domains should be covered by a timing exception (such as set_max_delay -datapath_only, set_clock_groups, or set_false_path).

After analyzing the design it was found that a set_false_path was the correct constraint for this DRC.

To find a timing path between these clocks, run the following command:

report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>].

See (UG906) for in-depth details on TIMING-6, TIMING-7 and all other Critical Warning and Warnings from the report_methodology.

 

Resolution and Conclusion:

Once the TIMING-6 and TIMING-7 violations were corrected, the design produced consistent results in both Windows and Linux.

Although Xilinx does not guarantee repeatability between different OS’s, having any of the above mentioned Super Critical Warnings in a design can lead to poor QoR. In this case one OS producing a worse result than the other was due to having these violations.

 

 

 

1 Comment

@dsheils 

I very much appreciate your blog, although I wish the title had been something like "When Synchronous is Asynchronous" to highlight the problem rather than the solution.

The critical warnings from the Methodology report that you highlight are (as you say) Super Critical.  However, I think Vivado could and should do more towards identifying clocks that may not be synchronous. 

Please see the following post for less obvious situations when clocks are not synchronous.

https://forums.xilinx.com/t5/Timing-Analysis/creating-mesochronous-clocks/m-p/986500#M17064