UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer subpixel
Observer
12,177 Views
Registered: ‎12-28-2010

IO Timing constraints for source synchronous interface

Hello, I need help with timing constrains for RGMII source-synchronous interface. I would like to understand this problematic in generall, I read many posts and documents from different FPGA vendors on the web (it seems to me that Xilinx documentation regarding this problematic is not so rich in content when compare to others). I think, there are typo errors and inconsistencies between different documents on the web. It takes me several days and I am still not sure how to constrain my design correctly (set_input_delay, set_output_delay and may be set_multicycle_path).

 

Our board is based on Artix7 and PHY chip KSZ9021. Parameters of phy chip is following: TskewT is +-500ps; TskewR is from 1ns to 2.6ns. Clock cycle duration is from 7.2 to 8.8ns. PHY chip is able add skew between data and clock for both, RX and TX direction up to combined skew 1.8ns (delay CLK and speed up DATA). Our board traces between FPGA and PHY chip is matched in length for each direction. So I set PHY chip to add 1.8ns skew between clock and data (maximum delay of clk and maximum speed up for data) in each direction to have near to center aligned clocks. So TX data on the output of FPGA can be edge aligned (same clocks can be used for clocking data through ODDR and same clock can be out through second ODDR) and after PHY adds skew internally, the data will be near to center aligned. For receiving direction, RX data on the input ports of FPGA and input clock is near to center aligned.

 

RX direction:

125MHz RX_CLK comes through input pin to the IBUFG, output from buffer RX_CLKG goes to the IDDR which is capturing RX_DATA from input pin.

 

TX direction:

RX_CLKG signal is used to clocking ODDR instances to output TX data from the fpga. Same clock signal is used to create TX clock on the FPGA output pin through ODDR too (TX data and clocks are edge aligned at FPGA output)

 

Now, question is - how to use set_input_delay, set_output_delay and set_multicycle_path to see if design meet timing requirements. After that, I can play with skew settings at the PHY chip and do some iterations.. It will be very helpfull if someone can show me, how to proceed step by step through this, not only final numbers..

 

Thanks

Tags (3)
0 Kudos
5 Replies
Highlighted
Guide avrumw
Guide
12,175 Views
Registered: ‎01-23-2009

Re: IO Timing constraints for source synchronous interface

I have covered these in other forum posts.

 

See these threads for edge aligned and center aligned source synchronous DDR interfaces.

 

Avrum

Tags (3)
0 Kudos
Observer subpixel
Observer
11,976 Views
Registered: ‎12-28-2010

Re: IO Timing constraints for source synchronous interface

Thanks avrumw for all your very informative posts! I read referenced posts again very carefully, but I still have some doubts. From TskewR=1ns to 2.6ns I derived Ts = 1ns and Th=1.4ns. From my drawing I see data windows: WIN -1 [-5, -2.6]; WIN 0 [-1, 1.4]. So, set_input_delay will be -2.6 for –min, and -1 for -max. This will result in failed HOLD (example path slack -0.747ns) and met SETUP (example path slack 1.433ns) without any skew inserted by the PHY. Please see paths timing analysis screenshots (set_multicycle_path and set_false_path based on referenced posts is used too).

 

FPGA required window is at [0.38, 1.76] same as in referenced post. That means that I need delay data or speed up clocks from PHY, based only on the calculations. Needed data delay is 0.87 ns to have overlapped windows centered.

 

I have several questions:

 

1) If I add required skew in my PHY chip internally (no matter if I speed up clock or slow down data, or combine it), how should I tell this in my constrains file? Can I only change set_input_delay min and max numbers with needed offset: min=-2.6+0.87=-1.73 and max=-1+0.87=-0.13? If I do this, the worst hold slack is 0.123ns and setup slack 0.563ns.

 

2) Can you please give me some hint how to deal with set_output_delay too?

 

RX_HoldPath_noBUFR_noPHYskew.png

 

RX_SetupPath_noBUFR_noPHYskew.png

 

Thanks for your time

0 Kudos
Guide avrumw
Guide
11,951 Views
Registered: ‎01-23-2009

Re: IO Timing constraints for source synchronous interface

First, I can't follow the first part of your post - I don't know what TskewR is, and how that ends up as being Ts=1 and Th=1.4. But assuming that is the case, then your constraints are correct.

 

1) If I add required skew in my PHY chip internally (no matter if I speed up clock or slow down data, or combine it), how should I tell this in my constrains file? Can I only change set_input_delay min and max numbers with needed offset: min=-2.6+0.87=-1.73 and max=-1+0.87=-0.13? If I do this, the worst hold slack is 0.123ns and setup slack 0.563ns.

 

Yes, but two things.

 

The [0.38, 1.76] is an estimate only. Really you should be basing your adjustment off of what the tools are telling you, which is that you have 1.433ns of slack on the setup and a -0.747 violation on the hold. So, if you did delay the data, you would want to do so by 0.747 + (1.433 - 0.747)/2 = 1.09ns. This will center your margins so that you get 0.343ns of slack on both setup and hold.

 

Second - how are you going to make the adjustment in your PHY? If the PHY does have adjustable delays, then, yes - add 1.09ns of delay to your data (or -1.09ns of delay to your clock) and change the constraints so that you add 1.09ns to both the -min and -max numbers. This makes sense since you are adding this delay outside the FPGA - the constraints are the way that you tell the tool about all the stuff outside the FPGA...

 

However, I have never seen a PHY that allows you this kind of programmable delay. Generally this delay is done by using the IDELAY inside the FPGA - that's what it's there for. Using the IDELAY you can add a programmable number of taps of delay to the path. Each tap is calibrated based on a refernce clock provided to it (usually 200MHz), so that each tap is around 78ps (there is some variation tap-to-tap, but not across PVT - the tools know the actual tap delays).

 

So generally what you do is you insert an IDELAY between the IBUF and the IDDR. The addition of this cell will change your timing, so start with the #taps set to 0, and re-do the static timing analysis. Use the resulting slacks as above to determine what the ideal delay is, and then divide that by 78ps to determine the number of taps.

 

Then change the IDELAYs #taps (this can actually be done on the opened design simply by changing the properties of the IDELAY and re-do timing. If the setup and hold margins are not balanced to within 78/2ps, then adjust the taps accordingly. Once you have done this, this will be the timing (and margin) of your FPGA across PVT; put these tap values in your .XDC file and you are done.

 

(I will try and cover the outputs later - it would help if you gave me the timing of your PHY as an example).

 

Avrum

Tags (3)
0 Kudos
Observer subpixel
Observer
11,945 Views
Registered: ‎12-28-2010

Re: IO Timing constraints for source synchronous interface

Probably, I did big mistake regarding my PHY (KSZ9021) timing. There is noted PCB board delay in the specification. And TskewR (data to clock output skew at Receiver) numbers is based on this required additional PCB trace delay (on the clock signals). Now I think, that I need to count with TskewT (data to clock input skew at Transmitter) which is +-500ps, when my PCB traces is same length (data and clock). Yes this PHY have optional internal skew settings by the use of internal registers. I will be back after several hours and I will recalculate my timing to post it here..

0 Kudos
Observer subpixel
Observer
11,908 Views
Registered: ‎12-28-2010

Re: IO Timing constraints for source synchronous interface

Regarding RX direction (FPGA receive, set_input_delay): from new drawing for TskewT=+-500ps (edge aligned interface). I get data win -1 at [-3.5,-0.5] and 0 at [0.5,3.5]. Needed speedup data (or delay clk) is about 0.7ns (internally in the PHY). It will gives me set_input_delay min -1.2 and max -0.2. For this constrains timing analysis ends with about 1.7ns slacks for Hold and for Setup too. OK, input delay is done, I hope it is correct now.

 

I am not sure about TX direction (FPGA transmit) timing now. May be it is sufficient to output data pretty well edge aligned with the clock (by the use of ODDR for data signals and for clock signal with ODDR too) and do the center aligning internally in the phy (by the use of maximum clk delay 1.8ns). In this case, how should I set set_output_delay constraints?

0 Kudos