cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
470 Views
Registered: ‎04-12-2012

Clock Path Skew of source synchronous input

Jump to solution

Hello,

I have a source synchronous center aligned input interface.
I'm using same edge capture with the input clock being driven to an MMCM that generates a zero phase shift clock that's used for an IDDRE1 primitive.
I wrote the following timing constraints:

set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -max 2.8 [get_ports {INPUT_RGMII_RD_AVB*}]
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -min 1.0 [get_ports {INPUT_RGMII_RD_AVB*}]
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -max 2.8 [get_ports {INPUT_RGMII_RD_AVB*}] -clock_fall -add_delay
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -min 1.0 [get_ports {INPUT_RGMII_RD_AVB*}] -clock_fall -add_delay
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -max 2.8 [get_ports {INPUT_RGMII_RX_CTL_AVB}]
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -min 1.0 [get_ports {INPUT_RGMII_RX_CTL_AVB}]
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -max 2.8 [get_ports {INPUT_RGMII_RX_CTL_AVB}] -clock_fall -add_delay
set_input_delay -clock [get_clocks {INPUT_RGMII_RXC_AVB}] -min 1.0 [get_ports {INPUT_RGMII_RX_CTL_AVB}] -clock_fall -add_delay

I get a negative hold slack of around -1.6 nS.
Investigating the issue further reveals that the "Clock Path Skew" is more then 2.8 nS.
How is the "Clock Path Skew" calculated ?

clock_path_skew.JPG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
333 Views
Registered: ‎01-23-2009

Sorry - I thought this was an output interface, not an input interface. The argument is the same, but reversed;

The data path delay (DPD) is from your "start of the timing path" to the capture flip-flop. In an input interface the "start of the timing path" is the input port - really, the model of the device that is just outside (before) the data input port. This "model of the device" is specified by the set_input_delay - you tell it that the tools that the source is a device, clocked on the system synchronous clock (INPUT_RGMII_RXC_AVB) with DDR timing and the specified min and max input delays.

The source clock delay (DCD) is the path from the clock to the launch flip-flop. Since your "launch flip-flop" is the "model of the device" and you said it was clocked on the system synchronous clock (without any delay), the source clock delay is 0.

The destination clock delay (SCD) is the delay from the primary clock to the capture flip-flop. In the case of your system, this is the path through clock IBUF any clock distribution resources (BUFG, BUFR, MMCM), the clock network (global or regional) before ending at the capture flip-flop.

This leads to the clock skew as being the DCD - SCD = DCD-0, which in your case is (presumably) 2.866-0. This is correct. The input path of an FPGA usually does have a significant clock skew - this is just another way of saying that capture path inside the FPGA is a "race" between the input clock propagating to the capture flip-flop and the input data propagating to the same capture flip-flop.

Avrum

View solution in original post

5 Replies
Highlighted
430 Views
Registered: ‎01-22-2015

@shaikon 

Your constraints indicate that a register outside the FPGA is sending data to a register (within IDDR) that is inside the FPGA.  Both registers are clocked by a clock entering the FPGA on port, INPUT_RGMII_RXC_AVB.

To understand clock path skew, we can similarly analyze the following register-to-register transfer that occurs inside the FPGA, with clock, clk_out3_clkgen, clocking both registers.
clock_path_for_skew.jpg

Vivado gives the following path report:

clock_path_skew.jpg

When you click on the “Clock Path Skew” number in the report, then you get a yellow popup box with a formula for calculating clock path skew = DCD – SCD + CPR

SCD = b – a = time it takes for clock to reach cnt1_reg[1]/C

DCD = d – c = time it takes for clock to reach CE4_reg/C

CPR = e = clock pessimism removal = skew reduction because destination clock and source clock sometimes travel on a common path (see page 229 of UG906(v2019.2)).

Cheers,
Mark

Tags (1)
Highlighted
Voyager
Voyager
402 Views
Registered: ‎04-12-2012

Thanks Mark,

Your example of internal FPGA flip-flops sets the perfect ground for my follow-up question.

I can perfectly understand what clock skew means in the sense of synchronous logic design - it merely expresses the imbalance of clock distribution (what distinguishes an ideal clock tree from a real clock tree). I also understand how Vivado can calculate it when we're dealing with an internal path between 2 FFs in your example - in this case Vivado is the "owner" of the path and knows everything about it.

What I don't understand is how Vivado calculates the "clock skew" when the sending register is outside of the FPGA - the only knowledge it has is:

1.The time it takes INPUT_RGMII_RXC_AVB to arrive to the MMCM (because again - Vivado is the "owner" of this path).

2.The data to clock relationship (from the constraints).

I don't understand how these two are combined to calculate the "clock skew" between an external and internal register.

0 Kudos
Highlighted
Guide
Guide
365 Views
Registered: ‎01-23-2009

[EDIT: This is for a description of an output interface, not an input interface - see later for the correct information for an input interface]

The source clock delay (SCD) is the delay from the primary clock to the launch flip-flop. In the case of your system, this is the path through clock IBUF any clock distribution resources (BUFG, BUFR, MMCM), the clock network (global or regional) before ending at the launch flip-flop.

The data path delay (DPD) is from your launch flip-flop to the "end of the static timing path), which is normally a capture flip-flop, but in your case is "the output port" - really, the model of the device that is just outside the output port. This "model of the device" is specified by the set_output_delay - you tell it that it is a device, clocked on the system synchronous clock (INPUT_RGMII_RXC_AVB) with DDR timing and the specified setup and hold.

The destination clock delay (DCD) is the path from the clock to the capture flip-flop. Since your "capture flip-flop" is the "model of the device" and you said it was clocked on the system synchronous clock (without any delay), the destination clock delay is 0.

This leads to the clock skew as being the DCD - SCD = 0-DCD, which in your case usually a large negative skew. This is correct. The output path of an FPGA usually does have a significant clock skew - this is just another way of saying that the delay through the FPGA includes the SCD + DPD.

Avrum

0 Kudos
Highlighted
Voyager
Voyager
352 Views
Registered: ‎04-12-2012

This "model of the device" is specified by the set_output_delay - you tell it that it is a device, clocked on the system synchronous clock (INPUT_RGMII_RXC_AVB) with DDR timing and the specified setup and hold.

I assume you meant "set_input_delay" ?

 

The output path of an FPGA usually does have a significant clock skew

Here also I don't understand what "output" you're referring to ?

This is an input interface...

Tags (2)
0 Kudos
Highlighted
Guide
Guide
334 Views
Registered: ‎01-23-2009

Sorry - I thought this was an output interface, not an input interface. The argument is the same, but reversed;

The data path delay (DPD) is from your "start of the timing path" to the capture flip-flop. In an input interface the "start of the timing path" is the input port - really, the model of the device that is just outside (before) the data input port. This "model of the device" is specified by the set_input_delay - you tell it that the tools that the source is a device, clocked on the system synchronous clock (INPUT_RGMII_RXC_AVB) with DDR timing and the specified min and max input delays.

The source clock delay (DCD) is the path from the clock to the launch flip-flop. Since your "launch flip-flop" is the "model of the device" and you said it was clocked on the system synchronous clock (without any delay), the source clock delay is 0.

The destination clock delay (SCD) is the delay from the primary clock to the capture flip-flop. In the case of your system, this is the path through clock IBUF any clock distribution resources (BUFG, BUFR, MMCM), the clock network (global or regional) before ending at the capture flip-flop.

This leads to the clock skew as being the DCD - SCD = DCD-0, which in your case is (presumably) 2.866-0. This is correct. The input path of an FPGA usually does have a significant clock skew - this is just another way of saying that capture path inside the FPGA is a "race" between the input clock propagating to the capture flip-flop and the input data propagating to the same capture flip-flop.

Avrum

View solution in original post