cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
10,617 Views
Registered: ‎03-11-2016

IDDR fails hold on p edge and setup on n edge

Hi,

 

I'm working on data reception from an external ADC with multiple LVDS synced to a single DDR clock. The data eye is center aligned with guarenteed +/-500ps skew between data and clock. Without IDELAYE2 element I could run the system up to 210MHz, any faster it will fail. Right now I would like to run it up to 300MHz thus I implemented the data delay constraint using the constrait wizard using source synchronization. Immediately the timing failed with positive edge hold slack around -1.7ns for all IDDRs. 

 

Thus I improved the design by adding a fixed value IDELAYE2 between the IBUFDS and IDDR, this improve the holding slack but still fails the timing. If I increase the delay tap to satisfy the holding time on positive edge, the setup time on negative edge will fail. In fact, I found the timing slack on the negative edge (~ -740ps) is always shorter than the setup on the rising edge (~ + 300ps). There's always 400ps insufficiency between the 2 sampling window, like the duty cycle is no longer 50%.

 

I wonder why the propagation delay in the inputs is not symetric for rising and falling edge? And is there anyway to improve/cirvument this problem.

0 Kudos
4 Replies
Highlighted
Contributor
Contributor
9,485 Views
Registered: ‎03-11-2016

No one after a month?

 

I've included a timing report for all the setup/hold on both edges

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,419 Views
Registered: ‎05-07-2015

HI @fshenmi

 

>>I wonder why the propagation delay in the inputs is not symetric for rising and falling edge?


I think you are comapring prop delay values between hold and setup analysis. They differ  as the prop delay values for setup and hold analysis are  taken from different process(slow/fast) to account for the worstcase scenario.

Consider IBUFDS prop delay in the reports you shared:
An hold analysis is happening at slow process corner: IBUFDS prop delay : 0.936/0.960 (min/max),
As setup analysis is happening at fast corner : IBUFDS prp delay : 0.388/0443 (min /max)

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
Guide
Guide
9,293 Views
Registered: ‎01-23-2009

First, lets go back to your ADC device - you describe it as "center aligned with a +/-500 ps skew between clock and data" - this doesn't really make sense. Center aligned interfaces are not usually described with clock/data skew; that is usually done for edge aligned interfaces. Center aligned interfaces usually give guaranteed setup and holds provided at the device...

 

So, first, lets see the actual datasheet description of the device to see if your constraints are correct.

 

210MHz DDR is a bit period (or unit interval - UI) of 2.38ns. If you have +/-500ps of clock data skew (assuming this is edge aligned), then you lose 1ns from each data eye, leaving you with 1.38ns. This is pretty small. Some devices in the faster speed grades and with the right clocking scheme may be able to capture a data eye this small, but others won't.

 

From your timing reports, it looks like you are using a Zynq-7010 in a -1 speed grade. It looks like you are using BUFIO clocking (which is the fastest). But even with this, the device needs more than 1.38ns under ideal conditions; the datasheet (DS187 v1.17 table 82) show Tpscs/Tphcs=-0.38/1.86, for a required window of 1.48ns. This is just a starting point:

  - this is for HSTL15 I/O standard, LVDS will likely be faster

  - this assumes no IDELAY in the clock or data path - adding one will increase the size of the window

  - this doesn't include any jitter - your real system will have some

  - the timing in the datasheet is an estimate only; the real timing comes from the tool

 

And the tool is telling you you can't make this work...

 

So, we need to make sure your constraints are correct, and if they are, then the tools are basically telling you that you cannot statically capture this interface with this device - this is an Artix-7 based Zynq device in the slowest speed grade - it's abilities are going to be less than (say) a Kintex-7 (or Kintex-7 based Zynq) or Virtex-7 device in a faster speed grade.

 

If this device cannot be captured statically, then you will need to use dynamic calibration to capture this interface...

 

Avrum

Highlighted
Contributor
Contributor
9,176 Views
Registered: ‎03-11-2016

Hi avrumw,

 

Thank you for your answer. First I made mistake when initiated this question in the first place, that I only looked at the timing summary window not the full report for setup/hold for both edge. One of the hold slack was hidden. It turn out it's what nagabhar had mentioned that hold slack is more negative than setup slack for both clock edge. Thus I could revert to another thread you had posted in this forum.

 

Secondly, I apologize for confusion regarding using the word "skew". The datasheet did specify the guarenteed setup and hold time as:

Minimum time between data change and clock rising edge

Minimum time between clock rising edge and data change

Minimum time between data change and clock falling edge

Minimum time between clock falling edge and data change

 

All the above 4 values are 500ps and I constrain the data accordingly using the constraint wizard with source synchronization and center aligned. As such, I understood that data might not be possible to capture statically. Now I tried dynamic calibration with similar implementation in XAPP585 with a bit of variation. I'll briefly describe in the following.

 

Data pair -> IBUFDS_DIFF_OUT -> p_out -> IDELAY_master -> IDDR -> downstream sync detect and logic

                                      |_______ -> n_out -> IDELAY_slave (2 tap offset) -> IDDR -> check master set for deskew

 

With the above scheme, I successfully capture the data with dynamic calibration at 300MHz. The increment of delay tap reveal the bit eye to be roughly (9+2) taps wide. 

 

However, I run into another problem by instantiating 4 of the above module. (I have 4 ADC banks, each with 7 data pairs sync to 1 clock). The bit eye is completely closed except for the first bit in the first instance. Do you want me to continoue here or start another thread elsewhere?

 

Thank you!

0 Kudos