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: 
Adventurer
Adventurer
3,018 Views
Registered: ‎05-26-2015

Constraining ISERDES

Jump to solution

Hi I am using ISERDESE block to capture DDR data. I am bit confused regarding timing constraint for this design.

 

FPGA DDR input clock is 400Mhz. ISERDESE CLK driven by BUFIO, CLKDIV driven by BUFR(divide by 8). Output of ISERDESE is a 8-bit parallel data and stored in a 8-bit register clocked by CLKDIV. This register output is compared against 0xAA and output port data_valid is asserted whenever comparison succeeds.

 

What are the proper constraint to be used for the above design?

 

Untitled.png

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
4,111 Views
Registered: ‎01-23-2009

Re: Constraining ISERDES

Jump to solution

It is't 0.625. MIPI setup/hold timings are as follows.

Setup time = 0.15*UI = 0.1875, Similarly hold time = 0.15*UI = 0.1875

 

You are reading this wrong. The setup is documented as 1/2UI +/- Tskew, Where Tskew is 0.15UI. Therefore both your setup and hold time are 0.5UI -0.15UI, or 0.35UI. At 800Mbps, this is 438ps.

 

This is what I meant when I said:

 

Furthermore the timing you quote is impossible. At 800Mbps, each bit is 1.25ns long. Your timing is claiming that it is valid 0.625ns before the clock to 0.625ns after the clock. This means that your data transitions instantaneously and with absolutely no variation over process temperature and voltage. Both of these are simply impossible. Even the best real device won't be able to do better than +/-100ps of variation in the data timing, which costs you an additional 200ps of margin on the analysis above. Again, the window is just too small for this device at this speed grade.

 

Instead of the 100ps I guessed, the datasheet says 0.15UI which is 187.5ps, costing you a total window size of 375ps.

 

I think with these modified timings, we can capture the data safely without IDELAY.

 

This is in no way "better" than what you assumed before (which was 625ps). This window is even smaller. As I said before, this interface cannot be captured statically. At this size (875ps), this cannot even be captured statically by the fastest FPGA at the fastest speedgrade.

 

As a result, constraints are meaningless - all they will do is confirm that this interface is impossible to get to meet timing.

 

You will need to do dynamic calibration in order to get data from this interface.

 

Avrum

0 Kudos
6 Replies
Highlighted
Historian
Historian
2,982 Views
Registered: ‎01-23-2009

Re: Constraining ISERDES

Jump to solution

So first - you say your input is 400MHz DDR, which means 800Mb/s. In this configuration, the ISERDES should be set for 8:1 deserialization in DDR mode, but the BUFR must be set for divide by 4 (not 8); the CLKDIV side should be running at 8 bits wide at 100MHz.

 

Second, this may be too fast. At 800Mbps (400MHz DDR), each bit lasts 1.25ns. This is pretty small; depending on the device and speed-grade this may be too fast to capture statically; for example this is too fast for an Artix-7 in a -1 speed grade.

 

Third, even if the data eye is wide enough, your current design has no mechanism for adjusting the clock/data phase relationship. In this configuration, the device will need a defined setup and hold time for the data, which is in a specific place. This is window is not necessarily centered around the clock edge - in fact it is actually completely after the edge. Unless your source provides the data at exactly the right time, you will not be sampling the data in the correct place. Normally, you correct the clock/data phase relationship in this configuration using an IDELAY - either on clock or data or both (although one on data only seems to give the best solution).

 

Then, finally, you can look at how to constrain it. As always, constraints are defined by the device driving the FPGA - you have given us no information on what that is, so we can't help you define the constraints. They are also significantly different if the sending device is edge aligned or center aligned.

 

Take a look at these posts on writing constraints for a Source Synchronous DDR Edge Aligned Interface an on writing constraints for a Source Synchronous DDR Center Aligned Interface.

 

Avrum

0 Kudos
Adventurer
Adventurer
2,962 Views
Registered: ‎05-26-2015

Re: Constraining ISERDES

Jump to solution

@avrumw, Thanks for the reply. 

 

So first - you say your input is 400MHz DDR, which means 800Mb/s. In this configuration, the ISERDES should be set for 8:1 deserialization in DDR mode, but the BUFR must be set for divide by 4 (not 8); the CLKDIV side should be running at 8 bits wide at 100MHz.

 

Yes, you are correct. It's a typo.

 

you have given us no information on what that is, so we can't help you define the constraints. They are also significantly different if the sending device is edge aligned or center aligned.

 

The source is an Image sensor with sourcing center aligned data as shown below. I am using Artix-7(Speed grade-1) FPGA. As data is center aligned, I am not using IDELAY to adjust the clock.

 

Untitled.png

 

 

Take a look at these posts on writing constraints for a Source Synchronous DDR Edge Aligned Interface an on writing constraints for a Source Synchronous DDR Center Aligned Interface.

 

I have gone through the above posts. They are very much helpful and informative. I have a doubt related to your post Source Synchronous DDR Center Aligned Interface.

 

This is not necessarily an obvious choice. If we look (say) at BUFR clocking (which is what is specified here), the required setup/hold of the FPGA (measured at the pins of the FPGA) is Tpscs/Tphcs (you can find this in the appropriate device datasheet), but for all 7 series devices, Tpscs is slightly negative, and Tphcs is fairly large (A7 in -1 speedgrade is -0.38/1.70; this means that the required setup/hold window of the FPGA will occur after the edge of the clock; the data must be valid from t=0.38 to t=1.70.

 

So, if we were to capture window 0 with the rising edge of clock at t=0, we would need to delay the data so that the window we do have [-1.3,1.1] overlaps the required window of [0.38.1.70]. We would do this with IDELAYs with a handful of taps of delay. This is consistent with the interface defined by the IP core, which has IDELAY only on the data

 

 

What is the significance of Tpscs/Tphcs of BUFR. How are these figures related to the data to be captured? For A7 in -1 these figures are -0.38/1.70.

In the above paragaph, you stated that the data must be valid from t=0.38 to t=1.70. As there is a minus sign for setup time, is it not to be valid from -0.38 to 1.70 instead of  0.38 to 1.70, which still overlaps the required window of -1.3 to 1.1 ??

 

0 Kudos
Historian
Historian
2,939 Views
Registered: ‎01-23-2009

Re: Constraining ISERDES

Jump to solution

What is the significance of Tpscs/Tphcs of BUFR.

 

First, these are (sort of) guidelines only - (apparently) the final timing can only be ascertained by Vivado (and Vivado does not conform to these "specifications"), but...

 

These are documented in the datasheet as the "Input Setup and Hold Time Relative to a Forwarded Clock Input Pin Using BUFIO for SSTL15 Standard." These are "pin to pin" timing numbers. So, these are the effective setup and hold time requirements measured between the clock pin of an FPGA and the data pin of an FPGA, when the clock comes in through a clock capable I/O, goes directly to a BUFIO and from there to the clock input of an IOB flip-flop, which is used (directly) to capture the data from the data pin.

 

The datasheet gives setup and hold times for a number of other "common" clock capture mechanisms

  - Tpsfd/Tphfd: When the clock goes from the clock capable pin to a BUFG to the IOB flip-flop (which will automatically select the "zero hold" mode of the IOB

  - Tpsmmcmcc/Tphmmcmcc: When the clock goes from the clock capable pin to an MMCM with BUFG feedback and a BUFG is used to clock the IOB flip-flop

  - Tpspllcc/Tphpllcc: Same as above but with a PLL instead of an MMCM

 

 

In the above paragaph, you stated that the data must be valid from t=0.38 to t=1.70. As there is a minus sign for setup time, is it not to be valid from -0.38 to 1.70 instead of  0.38 to 1.70,

 

 

 

Setup times are the time data must be start being valid before the clock edge. If the required setup time is -0.38, then it must be become valid -0.38ns before the clock edge, hence 0.38ns after the clock edge.

 

Hold times are the time data must remain valid after the clock edge. If the hold time is 1.70ns, then it must remain valid until 1.70ns after the clock edge.

 

Therefore the required window is from 0.38ns after to 1.70ns after.

 

 

 

which still overlaps the required window of -1.3 to 1.1 ??

 

So the FPGA requires that the data be valid from 0.38 to 1.70, but the device is only providing data from -1.3ns to 1.1ns. So the data will become invalid as early as 1.1ns after the clock, but the FPGA requires it to remain valid until at least 1.7ns after the clock. So the required window is not completely inside the valid window - it must be for a design to work.

 

Note that the required data window is not centered around the clock edge - the required window is completely after the clock edge. So your perfectly centered 0.625ns before to 0.625ns after is not in the right place, the data goes away at 0.625ns after the clock, but is required to stay valid until 1.70ns.

 

Furthermore, even if you could add "perfect" delay to the data, you would need to delay the data by at least 1.70ns - 0.625ns = 1.075ns. This would mean that your data window that started 0.625ns before the clock edge would now start -0.625+1.075=0.45ns. For the BUFIO (or BUFR) clocking to work, it must start at 0.38ns, but yours only starts at 0.45ns. So it fails.

 

And this is best case. Using the IDELAY increases the width of the required window, this calculation doesn't have a derating for jitter or duty cycle or mismatches in the board layout. Finally, the actual timing from Vivado is slightly worse than Tpscs/Tphcs. So all told, this window is simply too small.

 

Furthermore the timing you quote is impossible. At 800Mbps, each bit is 1.25ns long. Your timing is claiming that it is valid 0.625ns before the clock to 0.625ns after the clock. This means that your data transitions instantaneously and with absolutely no variation over process temperature and voltage. Both of these are simply impossible. Even the best real device won't be able to do better than +/-100ps of variation in the data timing, which costs you an additional 200ps of margin on the analysis above. Again, the window is just too small for this device at this speed grade.

 

So since this can't be done statically, you will need to use some kind of dynamic calibration.

 

Avrum

0 Kudos
Adventurer
Adventurer
2,923 Views
Registered: ‎05-26-2015

Re: Constraining ISERDES

Jump to solution

@avrumw

Thanks for the reply. I completely understand your explaination about BUFR timings.
Sorry, I haven't understood MIPI setup/hold timings correctly. It is't 0.625. MIPI
setup/hold timings are as follows.

Setup time = 0.15*UI = 0.1875, Similarly hold time = 0.15*UI = 0.1875

 

Screenshot.png

I think with these modified timings, we can capture the data safely without IDELAY.

As per your previous post, I will define 4 windows for this design

  - Window -1: Centered around the falling edge before the first rising edge (at t=-1.25)

     - starts at t=-1.4375, ends at t=-1.0625

  - Window 0: Centered around the first rising edge (at t=0.0)

     - starts at t=-0.1875, ends at t=0.1875

  - Window 1: Centered around the first falling edge (at t=1.25)

     - starts at t=1.0625, ends at t=1.4375

  - Window 2: Centered around the second rising edge (at t=2.5)

     - starts at t=2.3125, ends at t=2.6875

So for the above, there are really two choices

  1) Capture each window with the clock edge around which it is centered

      - capture window 0 with the rising edge of the clock at t=0.0

      - capture window 1 with the falling edge of clock at t=1.25

  2) Capture each window with the next edge

      - capture window 0 with the falling edge of clock at t=1.25

      - capture window 1 with the rising edge of clock at t=2.5

To define window 0 with respect to the clock at t=0.0, we know

   - the edge that starts this window can be anywhere from t=--1.0625 to t=-0.1875

      - the end of window -1 to the start of window 0

So the constraints are

create_clock -name clk_hs_rxp -period 2.5 [get_ports clk_hs_rxp]
create_clock -name virt_clk -period 2.5

set_input_delay -clock virt_clk -0.1875 -max [get_ports data_hs_rxp]
set_input_delay -clock virt_clk -1.0625 -min [get_ports data_hs_rxp]
set_input_delay -clock virt_clk -0.1875 -max [get_ports data_hs_rxp] -clock_fall -add_delay
set_input_delay -clock virt_clk -1.0625 -min [get_ports data_hs_rxp] -clock_fall -add_delay

set_multicycle_path 0 -from [get_clocks virt_clk] -to [get_clocks clk_hs_rxp]
set_false_path -setup -rise_from [get_clocks virt_clk] -fall_to [get_clocks clk_hs_rxp]; # diable a)
set_false_path -setup -fall_from [get_clocks virt_clk] -rise_to [get_clocks clk_hs_rxp]; # diable b)

set_multicycle_path -1 -hold -from [get_clocks virt_clk] -to [get_clocks clk_hs_rxp]
set_false_path -hold -rise_from [get_clocks virt_clk] -rise_to [get_clocks clk_hs_rxp];
set_false_path -hold -fall_from [get_clocks virt_clk] -fall_to [get_clocks clk_hs_rxp];

After running timing analysis with above constraints. I have following doubts.
Q1: Did I miss any constraints?

Q2: Why is the tool not reporting setup analysis for - capture window 0 with the rising edge of the clock at t=0.0, it's only reporting for - capture window 1 with the falling edge of clock at t=1.25. You can see from the below screen shot that only one path is reported under setup analysis.

 

Screenshot-1.png

Q3: I am bit confused about hold analysis for DDR interfaces. I know that usually hold analysis is done for the same edge(active edge). Is this still true for DDR interface. But based on above false_path constraints from rise to rise & false to false, it is evident that the hold for DDR interface is done for rise to fall & fall to rise. Am I correct? How is the hold analysis done for DDR interface and what are the edges to be considered? By the way timing is failing for Hold.

 

Screenshot-2.png

0 Kudos
Historian
Historian
4,112 Views
Registered: ‎01-23-2009

Re: Constraining ISERDES

Jump to solution

It is't 0.625. MIPI setup/hold timings are as follows.

Setup time = 0.15*UI = 0.1875, Similarly hold time = 0.15*UI = 0.1875

 

You are reading this wrong. The setup is documented as 1/2UI +/- Tskew, Where Tskew is 0.15UI. Therefore both your setup and hold time are 0.5UI -0.15UI, or 0.35UI. At 800Mbps, this is 438ps.

 

This is what I meant when I said:

 

Furthermore the timing you quote is impossible. At 800Mbps, each bit is 1.25ns long. Your timing is claiming that it is valid 0.625ns before the clock to 0.625ns after the clock. This means that your data transitions instantaneously and with absolutely no variation over process temperature and voltage. Both of these are simply impossible. Even the best real device won't be able to do better than +/-100ps of variation in the data timing, which costs you an additional 200ps of margin on the analysis above. Again, the window is just too small for this device at this speed grade.

 

Instead of the 100ps I guessed, the datasheet says 0.15UI which is 187.5ps, costing you a total window size of 375ps.

 

I think with these modified timings, we can capture the data safely without IDELAY.

 

This is in no way "better" than what you assumed before (which was 625ps). This window is even smaller. As I said before, this interface cannot be captured statically. At this size (875ps), this cannot even be captured statically by the fastest FPGA at the fastest speedgrade.

 

As a result, constraints are meaningless - all they will do is confirm that this interface is impossible to get to meet timing.

 

You will need to do dynamic calibration in order to get data from this interface.

 

Avrum

0 Kudos
Participant jesperjustesen
Participant
693 Views
Registered: ‎01-19-2016

Re: Constraining ISERDES

Jump to solution

This might help all the unenlightened people like my self :)

"Setup times are the time data must be start being valid before the clock edge. If the required setup time is -0.38, then it must be become valid -0.38ns before the clock edge, hence 0.38ns after the clock edge."

I was reading this line 20 times trying to understand how -0.38 all of a sudden becomes 0.38ns.

Then i realised that setup time is defined as the amount of time the data must be stable before the active edge of the clock!
...before... is the key here.

So if the clock edge is at t = 0
setup time of  0.38ns is  0.38ns before the clock edge aka t = -0.38n
setup time of -0.38ns is -0.38ns before the clock edge aka t =  0.38n