AR# 53083


Vivado Timing Analysis - How can I find out what is causing the Pulse Width-Max Skew problem in a component? (PCIe)


I have a design which is not meeting timing.

The problem is reported under the "Pulse Width" category in the Timing Report.

When I check the clock name failing for this problem, I see the problem is related to the "Max Skew" limits.

What is this "Max Skew" limits check, and How can I find out what is causing the problem?


The Skew is the difference between the delays of all loads driven by a given net/signal.  

The "Max Skew" limit checks are defined parameters for some critical blocks such as: BRAM, PCI, GTX ...  

If this value is not met, then it must be fixed by the designer.

To determine why there is a Max Skew Timing violation, first check the topology of the clock tree paths which are reported as failing paths.  

One of the clock paths will be referred to as the "Reference path" and the other will have the Skew above the specifications.  


Once the 2 clocks paths involved are identified, a common node point where those 2 clocks join must be found. 

The 2 clocks are likely to be generated from same source (if they are not independent and unrelated).

As a result there should be a "common point",  for example an MMCM or PLL.

In Vivado, you can trace back the clock signal path by using the command below:

report_timing -to [get_pin <full_hierarchy_pin_failing_clock_skew/CLK>]

This command should report the delay from the input Port clock to the PIN of the device, and the common node clocking resource.  


Generating this report for both input pins, it is possible to establish the Max skew difference in the clocks. 

Ideally, the clock paths should be the same until the "common point" where they should diverge.

As an example, take the PCIe with 2 clocks generated from the same source (MMCM = "common point"):

The Skew is the delay difference between the "Reference Path" (in this case MMCM/CLKOU2) and the path from MMCM/CLKOUT3 to USERCLK and USERCLK2 respectively.

Linked Answer Records

Associated Answer Records

AR# 53083
Date 01/14/2015
Status Active
Type General Article
People Also Viewed