cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
2,867 Views
Registered: ‎04-26-2017

Zynq-7020: Design and constraints of LVDS DDR interface spread over multiple clock regions.

Jump to solution

Hi all! I am having problems defining the timing constraints for my ADC interface. I am trying to
follow the XAPP524, without the dynamic clock phase alignment and with some simplifications.

 

My case is "special" in that the data from the ADC is 5 DDR LVDS lanes, of which three are connected
to pins in the X1Y2 region, and 2 in the X1Y1 region. The serialisation factor is 8. The lanes are
frame clock and 2 * (MSB + LSB) (I have a dual 16-bit ADC)

 

The bit clock is output from the ADC , and centred with respect to the data signals. This clock,
DCO is also LVDS and arrives in clock region X1Y2. The bit clock is 80 MHz, i.e. 6.25ns half-period.

 

Because of the multi-region situation, my clocking scheme has this structure, with a BUFMR to
buffer the clock to neighbouring regions:

DCO_P/DCO_N ==> IBUFDS ==> BUFMR ====> BUFIO_X1Y1 ==> CLK on ISERDESE2 in X1Y1
                                  |==> BUFR_X1Y1  ==> CLKDIV on ISERDESE2 in X1Y1
                                  |==> BUFIO_X1Y2 ==> CLK on ISERDESE2 in X1Y2
                                  `==> BUFR_X1Y2  ==> CLKDIV on ISERDESE2 in X1Y2

I instantiated ISERDESE2 elements for each data lane. Then comparing the path delay of the
serial clock path and the data path I added a IDELAYE2 elements in the data path, finding a tap
value that reduces this difference to ~0.1ns in the post-implementation timing reports.

E.g. the data path looks like:
FRAME_P/FRAME_N ==> IBUFDS ==> IDELAYE2 ==> ISERDESE2

 

I implemented a frame alignment state machine, using the BITSLIP operation of the ISERDES
elements to align the parallell output. This uses the output of the ISERDES that is deserialising
the frame clock, and executes BITSLIPs until this output is 0xF0.

I have two problems:


1: Looking at the data with a ILA core, I don't see what I expected. When I start the frame align
   ment, the frame clock parallell data aligns to 0xFO, but the other data lines show unexpected
   values. An example is when I expect a test pattern of 0x04, 0x08 I see for example 0x0480.
   This value is not always the same, after a reset a new value can be shown, but always something
   quite close to the expected value. Also, the data from the two ADC channels are never the same,
   even though they should be. I can power-cycle until I get the correct data in one channel, but
   never both.

2: I get failing timing paths in "Intra-clock" paths. The violations are in the hold slack section
   for Intra-clock paths:

Clock		WNS(ns)		TNS(ns)		TNS Failing Endpoints	TNS Total Endpoints
-------------------------------------------------------------------------------
DCO_P_0		1.108		0.000		0			5

		WHS(ns)		THS(ns)		THS Failing Endpoints	THS Total Endpoints
		-------------------------------------------------------------------
		-0.104		-0.242		3			5
		
		WPWS(ns)	TPWS(ns)	TPWS Failing Endpoints	TPWS Total Endpoints
		------------------------------------------------------------------
		10.345		0.000		0			15

 

This slack, -0.104ns, was more like -5 ns before I added the IDELAYE elements. So the clock took
longer to get to ISERDESE2.clk via BUFMR and BUFIO than the data, as expected. And it should be fine
now, right?

My constraints look like this (they are based on constraints I have found in similar forum posts
here, but I don't fully understand them):

# ADC Data path and clock constraints
create_clock -period 12.500 -name DCO_P_0 -waveform {0.000 6.250} [get_ports DCO_P_0]
set_input_delay -clock [get_clocks DCO_P_0] -min 2.187 [get_ports {FR_P_0 OUT1A_P_0 OUT1B_P_0 OUT2A_P_0 OUT2B_P_0}]
set_input_delay -clock [get_clocks DCO_P_0] -max 4.063 [get_ports {FR_P_0 OUT1A_P_0 OUT1B_P_0 OUT2A_P_0 OUT2B_P_0}]
set_input_delay -clock [get_clocks DCO_P_0] -clock_fall -min -add_delay 2.187 [get_ports {FR_P_0 OUT1A_P_0 OUT1B_P_0 OUT2A_P_0 OUT2B_P_0}]
set_input_delay -clock [get_clocks DCO_P_0] -clock_fall -max -add_delay 4.063 [get_ports {FR_P_0 OUT1A_P_0 OUT1B_P_0 OUT2A_P_0 OUT2B_P_0}]

This is based on the ADC data sheet which specifies that data is valid anywhere from
0.35*6.25ns=2.187ns to 0.65*6.25=4.06 ns before the clock edge.

Question 1: Is this the proper way of constraining the interface? Should I / how can I constrain the
full speed clocks for ISERDESE2 in different clock regions with respect to each other?
And what about skew between the serial data lines?


Question 2: The mentioned frame alignment function only looks at the frame clock, and sends the same
BITSLIP signal to all 5 ISERDESE2 modules. Is this completely wrong? I thought when the
signals are properly aligned on the ISERDES inputs, the required shift would be the same
for all of them. I program the ADC to output a static pattern so I can implement one
state machine for each ISERDESE2 if it is the right thing to do.
Question 3: Could the problem be the ILA? After studying similar cases, I connected the parallell
data lines to a VIO core via 2 sequential flipflops. When debugging with the VIO core
I still see the same behaviour. Because the interface is spread over 2 clock regions,
there is 2 ILA cores. They are clocked from the BUFR output in their respective region.
The dbg_hub component is clocked with a 100 MHz output from the Zynq PS.

Sorry that this post got so long, I feel it was necessary to provide some background data, but maybe I
should have split my question in more pieces. Anyway I have faith in you, forum gurus!

 

Kind regards,
Snorre

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
4,099 Views
Registered: ‎04-18-2011
Hi
It seems like you have 2 issues. Most likely this is not failing because of a hold violation on the input. But we can fix that up so you don't have to worry about it.

The first issue is the word alignment problem after reset.
You should be to ensure a synchronous deassertion of the resets.
Regardless of the bufr design advisory, it is important to always take the iserdes out of reset synchronous to CLKDIV. if there is too skew large a skew on this reset then you can see them come out with a bit shift in the data like this.

Second your problem with the timing is separate. What you need to do is add 2 or 3 more taps to the delay line if possible.as a rule of thumb, If your set up and hold slacks add up to a positive number then a delay on the data will fix the error.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

5 Replies
Highlighted
Mentor
Mentor
2,849 Views
Registered: ‎02-24-2014

you may have to apply a FSM bitslip to all the data channels, not just the clock.    There can be an issue with the reset on the ISERDES, because there are 2 clock domains applied to the element ( CLK and CLKDIV).    See AR#57966      Looking at your schematic,  I don't think this reset problem applies to your design, since you are using BUFR elements to drive the CLKDIV inputs, but the red flag is that you sometimes get different results after a reset, which is a bad sign.    Your approach of debugging with an ILA/VIO core is an excellent approach, since I don't trust post-route timing analysis nearly as much as actual silicon operation.  My advice is to figure out a way to change the clock skew on the CLK and CLKDIV (perhaps with a pair of IDELAY's), and experiment to see if you can get a reproducible result after a reset sequence.  

Don't forget to close a thread when possible by accepting a post as a solution.
Highlighted
Moderator
Moderator
4,100 Views
Registered: ‎04-18-2011
Hi
It seems like you have 2 issues. Most likely this is not failing because of a hold violation on the input. But we can fix that up so you don't have to worry about it.

The first issue is the word alignment problem after reset.
You should be to ensure a synchronous deassertion of the resets.
Regardless of the bufr design advisory, it is important to always take the iserdes out of reset synchronous to CLKDIV. if there is too skew large a skew on this reset then you can see them come out with a bit shift in the data like this.

Second your problem with the timing is separate. What you need to do is add 2 or 3 more taps to the delay line if possible.as a rule of thumb, If your set up and hold slacks add up to a positive number then a delay on the data will fix the error.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Highlighted
Observer
Observer
2,792 Views
Registered: ‎04-26-2017

Thank you for the helpful replies. You both solved a problem each :)

 

Indeed, increasing the tap number a couple of steps on the data delay such that THS > 0 solved the timing errors.

 

I implemented a FSM for each SERDES as per @jmcclusk's recommendation, but unfortunately it didn't immediately solve my problems. The data is not even shifted - it's like a few bits inside each word has swapped places.

 

Then, after trying with/without delay on the data lines (the data made WAY less sense when I bypassed the delay, so it seems I was outside the data valid eye at that point - I guess I don't have as much wiggle room as I thought) I added a IDELAYE2 on the serial clock with a tap value of 1 - desperately hoping that making the paths similar in this way would help.

 

After generating the bitstream, configuring, and launching my software I could enable the test pattern, reset the word alignment logic, and voilà - both channels locked in to the correct words! I did a soft reset of the ADC a couple of times and confirmed that the word alignment features really did their job. I suppose this also shows that I have implemented the VIO/ILA combination in a way that does not mess up the data path.

 

Unfortunately, after a hard (power off - power on) reset, channel 1 was no longer able to align its word. That is, it's not only shifted but somehow garbled.

 

As for the ISERDES reset - it's connected to the peripheral_reset output of a "Processor System Reset" IP instance. I don't really know when this signal is deasserted - apparently 16 cycles after the AXI bus elements, which I believe come out 18 cycles after power-on. However this module is clocked by the AXI Lite clock from the processing system - a 100 MHz clock. 

 

Eventually, I connected the reset line for the ISERDES circuitry to a push button synchronised to CLKDIV from one of the BUFR's - and I am finally able to lock in to the test pattern every time.

 

What about my constraints? Do they look sensible? Is there some constraint I can add to check skew between the clock regions - i.e. if the CLK and DIVCLK in the different regions are reasonably synchronized? 

 

Also, I think I will try to make a reset control circuit, and I will try this approach:

- Hold ISERDES in reset until the IDELAYCTRL's both assert RDY

- Wait a few (3?) CLKDIV cycles -then release ISERDES

- Wait 3 more CLKDIV cycles and restart the bitslip FSMs

(- Implement a way to repeat this process from PS - probably just an EMIO GPIO pin.)

 

Does this make sense?

 

Cheers,

Snorre

0 Kudos
Highlighted
Mentor
Mentor
2,781 Views
Registered: ‎02-24-2014

If you are trying to constrain dedicated paths through the IDELAYE2 into the ISERDES,  using an input delay constraint,  don't bother... all it does is produce a timing report for you (which can be interesting, I'll admit).     On dedicated paths,  setting a constraint won't actually change any timing.    Setting an input delay constraint only makes sense when capturing external data in a fabric FF, where the router actually has some ability to change the timing by picking the route.    your reset procedure seems reasonable..  it's crucial that deassertion of the reset on the ISERDES is synchronous to the clocks (both CLK and CLKDIV).   If you violate the setup/hold requirements on either of the clocks, then failure is generally assured.    If you are feeling paranoid, it wouldn't hurt to bolster your reset logic to implement a validation scheme that verifies the alignment to the external ADC test patterns, and then sets a flag in a register so that the software can be reassured of good calibration on the interface.   This is fairly common on other ADC interfaces I've seen.

Don't forget to close a thread when possible by accepting a post as a solution.
Highlighted
Observer
Observer
2,765 Views
Registered: ‎04-26-2017
Thank you for the clarification about the constraints. Even if it wouldn't affect the routing, it would be of interest to see skew between the clock signals reaching the ISERDESE2 elements in the different clock regions? Would this be under "Inter clock" section in the timing report. I'm getting oddly high numbers here...

The reset strategy worked perfectly it seems so far. I am not looking at CLK in the reset controller, only CLKDIV. But CLKDIV is derived from CLK via the BUFR element, so it should be okay, no?

I implemented a function in software to trigger this reset sequence from PS, and I already have functions to set the test pattern on the ADC, so I am basically using the method you are describing.

Thank you again for helpful insight. I am marking this as solved now, but I have a feeling there will be more posts coming related to this design...

Snorre
0 Kudos