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

Adoption Of The Methodology Report

Moderator
Moderator
5 0 350

What is the Methodology Report?

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

 

Sub-blog Entries:

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. 

  1. Timing is Met But Getting Wrong Functionality on Hardware

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.

  1. Effect of Methodology Violations on QoR

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.

  1. Timing is met but there are DDR4 calibration failures in hardware.

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.

  1. Rare Bit Flips

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. 

  1. DDR4 IP post-calibration hardware failures that indicate a timing issue but no violations in the timing report

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.

  1. Design is not consistently routable

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:

top1.PNG

         Figure 1: Cost, debug time, and design cycle time when you do not follow proper UFDM techniques 

 

top2.PNG

            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.

Useful Links:

Below are some useful links to understand more about the UltraFast Design Methodology Techniques and the Methodology report:

(UG949) - https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug949-vivado-design-methodology.pdf

(UG906), Appendix A - https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug906-vivado-design-analysis.pdf#page=283

(UG835) - https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug835-vivado-tcl-commands.pdf#page=1373

(UG1292) - https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug1292-ultrafast-timing-closure-quick-reference.pdf

Video on UltraFast Design Methodology  - https://www.youtube.com/watch?v=U_16tKynK7Y&list=PL35626FEF3D5CB8F2

Quick-take video on UltraFast Design Methodology - https://www.xilinx.com/video/hardware/ultrafast-design-methodology-for-vivado-into.html