The Methodology report is a feature in the Vivado tool which helps to streamline the design process and achieve better QoR using the UltraFast Design Methodology (UFDM).
Methodology analysis is a special form of design rule check that specifically checks for compliance with design methodology, and identifies common errors that arise from the process. The tool's algorithms work optimally when our UFDM guidelines are followed. The methodology report flags when these are not being followed. Not addressing them can cause the tool to give poor QoR.
It follows a specific set of rules which specify the individual methodology checks to perform during the Report Methodology command.
Note:It is essential to run the Methodology report after every stage (synth_design, opt_design, place_design and it is a must to run it after route_design). Doing this will give you more clarity and helps to resolve the design issues well in advance of signing off on a design.
This report will return critical warnings and warnings about the following:
Timing closure failures
Design is under constrained
Possible cause of hardware failures
Sub-optimal clocking topologies
Synthesis inference, Netlist instances
Constraints being overridden and bad practices
Physical configuration issues and many more
Critical methodology warnings (CW) will point out functional or QoR issues. When these are not reviewed and real issues are not resolved, debugging the issues that subsequently arise can be extremely time-consuming, taking days or even weeks.
When you open the methodology report, you might see hundreds or even thousands of warnings and critical warnings with your design. You do not need to afraid of such high numbers. If you have determined that those warnings/CWs are not causing any problems at that point in time then you can use waivers to waive those warnings/CWs. See (UG906) for more information on how to create waivers via the GUI or Tcl.
Note:If you see warnings with TIMING-6,7,14, 24, or 35 IDs in the report then you need to review it on a priority basis and resolve it in order to avoid other issues in the last period of your design cycle.
This entry is the master entry for six sub-blogs which show how the Methodology Report helps to improve Design QoR and saves you time in debugging the root cause.
These sub-blogs have been created based on real customer issues. They show the conventional approach to debug each issue and comparatively how the methodology report helps with its critical warnings and warnings to resolve those issues.
The analysis in this blog entry is based on a real customer issue where they were seeing incorrect functionality on the hardware even though the timing was met. In the end, the issue was related to Clock Domain Crossing, so this entry covers the steps to debug these types of issues.
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.
The analysis in this blog entry is based on a real customer issue where they were seeing DDR4 Calibration errors in hardware. The failures were inconsistent from one board to another and from build to build. This blog shows some of the debug techniques we used to narrow down the root cause and fix the issue.
The analysis in this blog entry is based on a real customer issue where they were seeing rare bit flips in the field. This blog entry shows some of the debug techniques we used to narrow down the root cause and fix the issue.
The analysis in this blog entry is based on a real customer issue where they were seeing DDR4 post calibration data errors in hardware. The issue turned out to be timing related, but there was no violation in the timing report. The Methodology report was not the initial method used to pinpoint the root cause, but this blog shows you how this report would help to speed up the debug, or even to avoid the hardware failure entirely.
The analysis in this blog entry is based on a real customer issue where their DFX design was not consistently routable and facing routing overlap. This blog shows some of the debug techniques we used to narrow down the root cause and to fix the issue.
How the Methodology report will help your design:
Following this methodology report will help you to reduce your Design cycle Time and Cost drastically. Below is a graphical representation which shows the effect of following UFDM and not following UFDM on your design cycles:
Figure 1: Cost, debug time, and design cycle time when you do not follow proper UFDM techniques
Figure 2: Cost, debug time, and design cycle time when you follow proper UFDM techniques
Note: This report is not 'noise' or miscellaneous information. It is important to read it and understand each violation. It is as important as the Timing Summary report and the DRC report when signing off on a design. In upcoming Vivado releases, we are planning to make the methodology report more visible and user friendly.
Below are some useful links to understand more about the UltraFast Design Methodology Techniques and the Methodology report: