When designing synchronous systems with a clock it is important to make sure that your circuit meets all of the timing constraints. The Vivado design suite have a number of tools to help you in the process of making sure your circuit meets the timing constraints. This tutorial summarizes the steps to take to add timing constraints and the timing analysis tools to check to see if your implemented design meets these constraints.

Synchronous systems have an oscillating clock that is used to latch data into the flip-flops of the design. The frequency of this clock is very important and the next state logic in synchronous designs must operate fast enough to meet the setup times imposed by the clock ¹⁾. The timing analysis tools must know the frequency of the clock in order to determine if the system meets all of these timing constraints.

Like all top-level I/O pins in a design, the clock pin must be added to the constraints file. The following example demonstrates the constraint to assign the global 100 MHz clock on the NEXYS 4 board to its proper pin location:

# IO_L12P_T1_MRCC_35 Sch=clk100mhz
set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { clk }];

In addition to the I/O placement constraint, all clocks should also have a timing constraint. The timing constraint is added to the .xdc constraints file by using the create_clock tcl command. The following example demonstrates how to assign add a 10 ns timing constraint to the system clock:

create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {clk}];

Your .xdc file should have two TCL constraints associated with the clock: 1) a constraint to set the location of the clock pin and 2) a constraint indicating the clock period. These commands are available in the master XDC file and can be used by uncommenting it in your project-specific XDC file.

During the implementation process, the Vivado design tools will use the clock constraint to analyze your design to determine if your design meets the timing constraints. This timing analysis is actually run several times during the implementation to make sure that no implementation decisions will violate the timing constraints. A special timing report will be generated that summarizes how well your design meets the timing constraints of the top-level clock. The following example from the Vivado implementation log shows the execution of the timing analysis.

Phase 10 Post Router Timing
INFO: [Route 35-57] Estimated Timing Summary | WNS=4.427  | TNS=0.000  | WHS=0.103  | THS=0.000  |

INFO: [Route 35-327] The final timing numbers are based on the router estimated timing analysis. For a complete and accurate timing signoff, please run report_timing_summary.
Phase 10 Post Router Timing | Checksum: 131b6bc2f

This example indicates that the post router timing analysis was run and provides a high-level overview of the timing. The number that is most important to us is the “Worst Negative Slack” or WNS. This number indicates the worst case timing path in the design ²⁾. If this number is negative, then the design did not meet the minimum timing. If it is positive, as in this case, it means that the design meets the timing constraints. This number indicates how much timing slack there is in the design. In this case, there is a slack of 4.427 ns in the design or in other words, the design could operate at a 10.0 ns - 4.427ns = 5.573 ns clock (179 MHz).

A detailed timing report can be found in the “Timing Summary Report”. You can find the details of the worst negative slack path as well as details of other paths in your design. You can also find the WNS for your design in this file. You will be asked to refer to this file as you analyze your designs after implementation.