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: 
Highlighted
Adventurer
Adventurer
258 Views
Registered: ‎10-12-2018

DDR Input Timing Constraints

Hello to all,

I try to read a sensor with several LVDS data lines in DDR using ISERDESE and IODELAY on Kintex 7.

The sensor needs a master clock (MCLK) of 100MHz for working and it is generated by ODDR. The sensor outputs data through several LVDS data lines, and these lines are synced to their corresponding LVDS 400MHz DDR output clock (800Mbps). The output clocks have different phase and they are generated by different PLLs on the sensor board using the MCLK. Moreover, it should be indicated that the output clock edges are in the middle of the data eye, and I use ISERDES and IODELAY to deserialize the input data. Because of the short eye of the data, I use phase detection to move the sampling point. All in all, the whole design works most of the time fine but sometimes there are some issues in deserialization that I guess are related to the timing constraints.   

My question is about the constraints that I should define in the XDC file. Currently, the only constraints that I defined for that are about the sensor output clocks as:

create_clock -period 2.500 -name A_CLKP -waveform {0.000 1.250} [get_ports A_CLKP]
create_clock -period 2.500 -name B_CLKP -waveform {0.100 1.350} [get_ports B_CLKP]
create_clock -period 2.500 -name C_CLKP -waveform {0.200 1.450} [get_ports C_CLKP]
create_clock -period 2.500 -name D_CLKP -waveform {0.300 1.550} [get_ports D_CLKP]
create_clock -period 2.500 -name E_CLKP -waveform {0.400 1.650} [get_ports E_CLKP]
create_clock -period 2.500 -name F_CLKP -waveform {0.500 1.750} [get_ports F_CLKP]

Did I define the constraints right? Is my occationally problem related to them?

 

Thank you very much in advance.

Amir  

 

0 Kudos
6 Replies
Moderator
Moderator
231 Views
Registered: ‎04-18-2011

Re: DDR Input Timing Constraints

An interface running at this data rate will never close timing statically. 

As you have done the interface must be dynamic. 

If you can say more about the failures you see we can try to understand what is going on. In the failing case can you tell if the problem is with alignment of the sample clock to the data or if the problem is word alignment?

Have you been careful to delay match the clock and data lines?

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
183 Views
Registered: ‎10-12-2018

Re: DDR Input Timing Constraints

Hi @klumsde 

Thank you for your reply.

"If you can say more about the failures you see we can try to understand what is going on. In the failing case can you tell if the problem is with alignment of the sample clock to the data or if the problem is word alignment?"

As I said, the data are transferred through several LVDS lines synced with their corresponding LVDS DDR clock, and most of the time, the transmission is working properly except some rare times. It does not mean all the LVDSs are erroneous during the error cases but only one or maximally two lines. The problem is the alignment of the sample clock synced with the data, and I think it comes from the clock jitter. Interestingly, two different bitstreams of the same design can have different behavior in terms of number error cases.

"Have you been careful to delay match the clock and data lines?"

The tap number of data lines IDELAYSs are almost all around the middle of the eye that means the data and clock are edges aligned at the corresponding ISERDES.  

Thank you.

Amir 

 

0 Kudos
Moderator
Moderator
132 Views
Registered: ‎04-18-2011

Re: DDR Input Timing Constraints

So are you saying that in the failing case that the tap delay is still around the middle of the eye?

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
108 Views
Registered: ‎10-12-2018

Re: DDR Input Timing Constraints

Hi @klumsde 

Yes, the tap delay is around the center of the eye in failing cases. As well for the fine cases. 

As I said, it is rare but still, I have it. 

0 Kudos
Moderator
Moderator
98 Views
Registered: ‎04-18-2011

Re: DDR Input Timing Constraints

So, if the tap delay is good and the eye looks wide (I guess you do a kind of sweep to find the line between stable and unstable data so you know the centre tap but also max and min taps, is that the case?) then it is not clock jitter. If the eye is not wide then I would suspect jitter. 

Let's say the data eye is open, then can you tell if the data is shifted?

Are you sure that your word alignment logic is properly bit slipping the data and acheiving alignment across all channel?

I would encourage this check, what can sometimes happen is that the SERDES comes out of reset and you get a 2 bit shift in DDR mode. 

Double check the deassertion of reset is synchronous to the CLKDIV domain. 

 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
52 Views
Registered: ‎10-12-2018

Re: DDR Input Timing Constraints

Hi Keith,

 

"So, if the tap delay is good and the eye looks wide (I guess you do a kind of sweep to find the line between stable and unstable data so you know the centre tap but also max and min taps, is that the case?) then it is not clock jitter. If the eye is not wide then I would suspect jitter"

The maximum number of taps is 22, but the data is valid from 4 to 17. And of course, it varies a little from one LVDS to another one. 

 

"Let's say the data eye is open, then can you tell if the data is shifted?

I was also suspicious about that, and so I logged the maximum and minimum values of the taps for all LVDSs separately. The results say that the minimum and maximum taps are completely within the radius of 2 for all LVDSs.  

 

"Are you sure that your word alignment logic is properly bit slipping the data and acheiving alignment across all channel?

I would encourage this check, what can sometimes happen is that the SERDES comes out of reset and you get a 2 bit shift in DDR mode. "

My sensor is an image sensor and is generating a training pattern before sending the main data for every line, and I am using this data for word alignment.

Interestingly, ONLY for the first line of the first frame, the data needs bit-slipping, and once the word is aligned, there is not any rotation.  

 

"Double check the deassertion of reset is synchronous to the CLKDIV domain."

Actually, I have extended the code from XAPP1017 which by default the reset is synced to the BUFR (CLKDIV) output clock. 

 

Regards,

Amir

0 Kudos