Using Vivado reporting commands for design check & sign-off

Once an FPGA design is completed, it should undergo some form of design review and sign-off to ensure that it meets all the requirements and is constructed correctly.

When deciding on a sign-off procedure, it should be made as rigorous as necessary, taking into consideration the design complexity and the possible impact of malfunctions due to a poor, non-robust design. In some cases, there may be contractual requirements such as compliance to DO-254 that need to be met.

At a minimum, the sign-off review should include the following:

  • Make sure that the design does what it was supposed to do.
    • This requires a Functional Specification to be drafted before starting the design so that the designers know what they are supposed to build. The designers should document how they have implemented each requirement and how they have tested/verified the design to ensure the Functional Specification has been met − this is probably best done with a Functional Compliance Matrix document.
  • Verification and Simulation results.
    • Exactly what constitutes an adequate simulation is a matter of some debate. Today’s FPGAs are so large and complex, especially if they include processors, that a full post-route timing simulation is next to impossible. Aa a minimum, a high level of code coverage during behavioural simulation should be required.
  • Reports and logs generated by the tools that show that the design is robust, follows correct methodologies, has adequate timing constraint coverage and that it fully meets those timing constraints.


In this article I will cover the last point in the above list and I’ll tell you how Xilinx’s Vivado toolset can provide reports to be used as part of a sign-off procedure. what we want to do here is verify that our design methodologies are correct, the timing constraints are correct and cover the entire design and that we can actually meet those timing constraints.

Design Methodology Correctness

Design methodology correctness is checked by running two different commands:

  • Report DRC.
  • Report Methodology.

Report DRC

Vivado has a very complete and thorough set of Design Rules that can used to check your design as it progresses from the first lines of code to a fully routed implementation. I highly recommend that you run Design Rules Checks (DRCs) long before getting to the sign-off procedure as the cost of having to make last minute code changes is high.

The steps for running DRCs from the Vivado GUI are as follows:

  1. Generate the bitstream and then open the implemented design.
  2. From the menu, select Report -> Report DRC….
  3. Set the options as for figure 1 with a text file to collect the results.


Figure 1: DRC checks for design correctness

The equivalent Tcl command is:

  • report_drc -name drc_1 -file design_correct.txt -ruledecks {default opt_checks placer_checks router_checks bitstream_checks incr_eco_checks eco_checks}



Note that some users might find the number of warning regarding DSP48 pipelining to be distracting. It can be disabled by unchecking the appropriate DRCs.


Figure 2: Disabling DSP48 pipelining checks

Report Methodology


Figure 3: Report Methodology for design correctness

The steps for running Methodology checks from the Vivado GUI are as follows:

  1. Generate and then open the implemented design..
  2. From the menu, select Report → Report Methodology…
  3. Set the options as for figure 3 with a text file to collect the results.

The equivalent Tcl command is:

  • report_methodology -name ultrafast_methodology_2 -file design_correct.txt -checks {PDRC-204 PDRC-190 CLKC-54 CLKC-53 CLKC-9 CLKC-5 CLKC-38 CLKC-37 CLKC-36 CLKC-35 CLKC-4 CLKC-18 CLKC-3 CLKC-2 CLKC-1 REQP-1959 LUTAR-1 HPDR-1 NTCN-1 CKLD-2 CKLD-1 DPIR-1 CKBF-1 SYNTH-14 SYNTH-13 SYNTH-12 SYNTH-11 SYNTH-10 SYNTH-9 SYNTH-16 SYNTH-15 SYNTH-6 SYNTH-5 SYNTH-4}

Timing Constraint Correctness

Getting your RTL code right is not all there is a to a successful FPGA design. Most synthesis and implementation tools are timing driven and so require the timing constraints to be both correct and complete.

Timing constraint correctness is checked by running two different commands:

  • Report Methodology with XDC and Timing options.
  • Check timing.

Report Methodology with XDC and Timing options

The steps for running Methodology checks from the Vivado GUI are as follows:

  1. Generate and then open the implemented design..
  2. From the menu, select Report → Report Methodology…
  3. Set the options as for figure 4 with a text file to collect the results.


Figure 4: Report Methodology for timing constraint correctness

The equivalent Tcl command is:

  • report_methodology -name ultrafast_methodology_1 -file design_correct.txt -checks {TIMING-43 TIMING-42 TIMING-41 TIMING-40 TIMING-39 TIMING-38 TIMING-37 TIMING-36 TIMING-35 TIMING-34 TIMING-33 TIMING-32 TIMING-31 TIMING-30 TIMING-29 TIMING-28 TIMING-27 TIMING-26 TIMING-25 TIMING-24 TIMING-23 TIMING-22 TIMING-21 TIMING-20 TIMING-19 TIMING-18 TIMING-17 TIMING-16 TIMING-15 TIMING-14 TIMING-13 TIMING-12 TIMING-11 TIMING-10 TIMING-9 TIMING-8 TIMING-7 TIMING-6 TIMING-5 TIMING-4 TIMING-3 TIMING-2 TIMING-1 XDCV-2 XDCV-1 XDCH-2 XDCH-1 XDCC-8 XDCC-7 XDCC-6 XDCC-5 XDCC-4 XDCC-3 XDCC-2 XDCC-1 XDCB-5 XDCB-4 XDCB-3 XDCB-2 XDCB-1}

Check Timing

The steps for running Check Timing from the Vivado GUI are as follows:

  1. Generate and then open the implemented design.
  2. From the menu, select Report → Timing → Check Timing..
  3. Set the options as for figure 5 below with a text file to collect the results.


Figure 5: Check Timing for timing constraint correctness

The equivalent Tcl command is:

  • check_timing -name timing_1 -file timing_checks.txt

Clock Domain Crossing

Uncontrolled clock-domain crossing paths can lead to all sorts of problems in your design and must be detected and dealt with. Finding clock-domain crossing paths with Vivado can be done in two ways:

  • Report CDC.
  • Report Clock Interaction.

Report CDC


Figure 6: Clock Domain Crossing report

The steps for running Report CDC from the Vivado GUI are as follows:

  1. Generate and then open the implemented design.
  2. From the menu, select Report → Timing → Report CDC..
  3. Set the options as for figure 6 below with a text file to collect the results.

The equivalent Tcl command is:

  • report_cdc -name cdc_1 -file cdc.txt

Report Clock Interaction

Vivado can also generate a graphical representation of the inter-clock paths and show whether they are ″safe″ or ″unsafe″. This particular report is very useful during development for finding CDC paths early in the design cycle.

  1. Generate and then open the implemented design.
  2. From the menu, select Report → Timing → Report Clock Interaction..
  3. Set the options as for figure 7 below with a text file to collect the results.


Figure 7: Clock Interaction report

The equivalent Tcl command is:

  • report_clock_interaction -delay_type min_max -significant_digits 1 -name timing_1 -file clock_interact.txt

The graphical output of this command is a matrix representation of source and destination clocks with a coloured block which indicates if paths between them exist and if those paths are ″safe″ or ″unsafe″:


Figure 8: Clock Interaction source-destination matrix

Timing Constraints met

This is probably the easiest of the reporting commands to understand as it is something that FPGA designers have been doing since the beginning.

  1. Generate and then open the implemented design.
  2. From the menu, select Report → Timing → Report Timing..
  3. Set the options as for figures 9-11.


Figure 9: Report timing – Targets tab


Figure 10: Report timing – Options tab


Figure 11: Report timing – Advanced tab

The equivalent Tcl command is:

  • report_timing -delay_type min_max -max_paths 10 -slack_less_than 0 -sort_by group -significant_digits 2 -name timing_1 -file timing_met.txt

Scripting the design review

The entire design check/review flow can be captured in a tcl script which produces a single report file - an example script can be downloaded here.