cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
daniel.cogan
Explorer
Explorer
8,128 Views
Registered: ‎07-30-2013

Another ADC interface to iserdes timing issue

I am using the iserdes2 to interface with a 14 bit ADC at about 210 Mhz.  There are additional iserdes2s and state machine used for deserializer / frame alignment.  In addition, the idelay2 was implemented for flexibility in case we increase the interface frequency later on.

 

For several months this has been working fine and am getting data without having to adjust the tap delays of the idelay2 blocks.  Now, as the design has grown larger, and I suppose routing has become more of an issue, I am having to adjust the tap delay values in order to get data properly.  The problem is that this tap value varies from image to image. 

 

We considered having a HW or even SW approach to "scan" through all values to find a window and then pick the center of the window as a work around.  However, the more fundamental question is why is this happening?  My understanding is that the timing up to the iserdes2 should be fixed.  Can the clocks to the iserdes2 be affected by high routing?  Is there a way to see this in the timing reports?  Just trying to get a handle on how to proceed.  I'd like to find some way to "lock" the tap value so it doesn't change as images are rebuilt.

0 Kudos
7 Replies
avrumw
Expert
Expert
8,102 Views
Registered: ‎01-23-2009

You need to give much more data...

  - what is your clocking structure

  - what are your constraints

  - what are the timing numbers from the ADC datasheet

  - what I/O standards are you using

  - what device and speedgrade are you using

  - how are you doing your framing

 

In theory, a properly designed clocking and I/O structure with the ISERDES should be immune to any other changes in the design; the timing should not change from route to route. So either

  - something is odd about your clocking or I/O or

  - you are seeing something else

 

It is vaguely possible that as the design gets more complex, the FPGA generates more heat, and that heat is affecting the interface (since all timing in an FPGA is sensitive to process, voltage and temperature), but this would merely be a symptom of your problem, not the cause.

 

Avrum

0 Kudos
daniel.cogan
Explorer
Explorer
8,094 Views
Registered: ‎07-30-2013

Avrum,

Thanks for your post.  The questions alone are helpful.

 

The design is implemented on an Artix 7 -2 part.

 

The bit clock, frame clock, and data bits are all LVDS and all come from the ADC.

 

The bit clock comes into a IBUFDS then passes through a IDELAYE2, then through a BUFIO before clocking the ISERDES2.  In parallel to the BUFIO, it passes through a regional clock buffer in order to divide down by half the number of bits of the output data (data is DDR).

 

The frame clock comes through a IBUFDS, IDELAY2, and into the ISDERDES2.  The frame clock comes into the serdes as data.  This serdes is clocked by the bit clock, and is also given the divided down bit clock.

 

The data simiilarly comes in through a IBUFDS, IDELAYE2, and then into a serdes.

 

Separately a state machine compares the output of the framing serdes to a training patternWhen it doesn't compare, it forces a bit slip back to the framing serdes.  When it does compare, framing is done.  The data serdes is given the same bit slip so that when framing is done, the data should be in sync with the frame, which is in sync with what was sent.  Theoretically once framed it should stay framed, but the state machine always runs in case it ever gets out of sync.

 

The data is registered by the divided down bit clock, and then heads directly into a FIFO.

 

I don't *think* I need timing numbers from the ADC.  Since the data and clocks are sent together, my understanding is that if there were idealy no delays on any lines, the bit clock is already timed correctly in relation to the data.

 

Contraint-wise, I used something I found elsewhere so is probably what needs improvement.  I converted some constraints I found for ISE into something usable by Vivado:

 

------

set_input_delay -clock [get_clocks adc_dat_clk_n] -max 0.500 [get_ports {adc_data_p}]

set_input_delay -clock [get_clocks adc_dat_clk_p] -max 0.500 [get_ports {adc_data_p}]


set_input_delay -clock [get_clocks adc_dat_clk_n] -clock_fall -max -add_delay 0.500 [get_ports {adc_data_p}]

set_input_delay -clock [get_clocks adc_dat_clk_p] -clock_fall -max -add_delay 0.500 [get_ports {adc_data_p}]

 

set_input_delay -clock [get_clocks adc_dat_clk_n] -min 0.000 [get_ports {adc_data_p}]

set_input_delay -clock [get_clocks adc_dat_clk_p] -min 0.000 [get_ports {adc_data_p}]

set_input_delay -clock [get_clocks adc_dat_clk_n] -clock_fall -min -add_delay 0.000 [get_ports {adc_data_p}]

set_input_delay -clock [get_clocks adc_dat_clk_p] -clock_fall -min -add_delay 0.000 [get_ports {adc_data_p}]

 

set_multicycle_path -hold -rise_from [get_clocks {adc_dat_clk_p adc_dat_clk_n}] -through [get_ports {adc_data_p}] -rise_to [get_clocks {adc_dat_clk_p adc_dat_clk_n}] 1

 

set_multicycle_path -hold -fall_from [get_clocks {adc_dat_clk_p adc_dat_clk_n}] -through [get_ports {adc_data_p}] -fall_to [get_clocks {adc_dat_clk_p adc_dat_clk_n}] 1

-------

 

As I copied these here, assuming they are even correct for data, I wonder if I need something similar for the frame clock since frame clock is treated as data.

 

I've also read about forcing the first register to be in the IOB.  But was also told by someone it wouldn't help by much in this case.  I've also had the suggestion of using an area constraint for the logic interfacing with the serdes.

 

We've done overnight testing on the data sent (known data from a counter in the ADC) and found that once the delay tap value was set correctly, the data would be mostly correct overnight.  For some reason every five minutes or so there would be a bad data but I'm not concerned with that now.  But the question remains why the correct tap value will change from build to build.

 

Any suggestions on the constraints?  or anythings else?

0 Kudos
avrumw
Expert
Expert
8,077 Views
Registered: ‎01-23-2009

Daniel,

 

Your clocking and I/O structure look correct. The only question I have is about your BUFR - you say it "divides down" the clock, but you seem to say that the data is coming in 210MHz DDR - are you using the SERDES in 2:1 or 4:1 mode? Are you processing your internal with 2 bits at 210MHz or 4 bits with 105MHz? (Either will work...)

 

The place where you might have a problem is the timing of the interface. The ADC puts out data and clock  with a specific relationship. It may do this as a clock centered interface (where the clock is in the middle of the data eye), or an edge aligned interface (where the clock changes at the same time as the data), or really anything else. Based on your discription, I am going to assume the former.

 

Even if it is centered there is no guaranteee that

a) the window is actually wide enough to be captured statically and

b) even if it is, it is in the right place for the FPGA to capture it

 

This must be done by careful timing analysis of the interface. You must start with the timing of the ADC, which will specify the timing of the data eye (the clock/data relationship) at the output of the ADC. This will then be affected by your board; any mismatch in trace length will change the relationship, and (particularly at high speeds) you may even need to do analog simulations to see how the transmission lines on the board affect the signal integrity of your clock and data.

 

Once the signals arrive at the FPGA, they will have a particular clock/data relationship. There is nothing that says that clock centered is the "best" (or even a good) timing for the FPGA. In fact, the BUFIO/ISERDES capture clocking is characterized by the FPGA datasheet Tpscs/Tphcs (DS181 v1.17 table 47) as -0.38/1.46. This means that the ideal capture window at the FPGA starts 0.38ns after the rising edge of the clock and ends at 1.46ns after the rising edge of the clock. An clock centered interface will violate this unless the window is almost 3ns wide (and since your bit time is 2.3ns, you will clearly violate this).

 

So, you need to work with the IDELAYs to get this interface right. Putting both your clock and data through IDELAYs is the right thing to do, but the values you should use need to be determined by careful analysis and through static timing analysis.

 

To do static timing analysis, your constraints must exactly match the characteristics of the data coming to your FPGA. The constraints you used say that the window at the FPGA is 1ns wide and centered around the clock. Are we sure this is true? Your bit period is 2.3ns - how much of this window is left once you get to the FPGA?

 

According to the FPGA datasheet, you cannot statically capture a 1ns window - you need a minimum of 1.08ns. The tools actually report a worse timing requirement (I have a webcase open for that). If this is really representative of your interface (the data window is only 1ns), then you cannot statically determine the IDELAY values; they will have to be dynamically calibrated to give a robust interface. Trying to set them statically will result in interface that are unreliable - they will work at some process/voltage/temperature conditions, but not others. This could account for the variation you are seeing in the lab.

 

Avrum

0 Kudos
avrumw
Expert
Expert
8,076 Views
Registered: ‎01-23-2009

(Also the constraints are not correct - the set_multicycle_path commands aren't correct). Its a good try (and I am wondering where you got them from?), but they aren't right. Particularly for a clock centered DDR interface, the constraints are a bit of a nightmare...

 

Avrum

0 Kudos
trenz-al
Scholar
Scholar
8,063 Views
Registered: ‎11-09-2013

Hi

 

very common advice

 

 

1) REMOVE all constraints except the constraint for the main bit clock

 

2) do not use ANY IDELELAY on and data or frame lanes

 

3) use fixed delay on bit/data clock or implement DCLK aligner similar to XAPP524

 

thiis is the best way

 

if you do the above then ALL bit clocks use FIIXED delay dedicated routing, hence additional constrtaints are not needed or meaningful as timing is guaranteed by fixed routing 

 

 

0 Kudos
avrumw
Expert
Expert
8,053 Views
Registered: ‎01-23-2009

do not use ANY IDELELAY on and data or frame lanes

 

Actually, it is recommended that you instantiate IDELAYs on both the data and the clock, but set one or the other (preferably the data) to 0 tap delay.

 

One of the reasons that source synchronous interfaces can be designed to work at high speeds is that the clock and data paths are balanced throughout; the transmitter generates the clock and data in a balanced way, uses the same kind of output buffer for each, they generally use the same trace length on the board, and the same input buffer on the receiver. This is very desirable since this minimizes the variability of the interface across process, voltage and temperature. While the delays of each of the components can change over PVT, since they are balanced, the clock and data path will change almost identically, and hence the data eye will remain more or less constant over PVT.

 

However, inside the FPGA, the routing path from IBUF -> ISERDES is different than the routing from IBUF -> IDELAY -> ISERDES (even though they are all in the IOB), so inserting the IDELAY only on one path (clock or data), introduces some imbalance in the two paths. This imbalance is uncompensated, and hence ends up closing your data eye. However, using IBUF -> IDELAY -> ISERDES on both paths only has a delay difference based on the tap delays of the ISERDESes, which is PVT compensated and controllable.

 

Finally, it is always preferrable to introduce delay on the clock path and not the data path; set the tap delay on the data to 0 and push the clock forward until it finds a data window. This is prefereable to the other way around since the IDELAY introduces some pattern dependent jitter to signals. This is specified as tIDELAYPAT_JIT, which is +/-5ps/tap (for most devices). This jitter (again) closes the data eye and reduces the margin on your interface. However, it is pattern dependent, so only shows up if you have different patterns going through the IDELAY. Since a clock has only one pattern (0101010101), it is not affected by the tIDELAYPAT_JIT.

 

Avrum

trenz-al
Scholar
Scholar
8,041 Views
Registered: ‎11-09-2013

YES and no

 

IF you use the DCLK alignment as in XAPP24 you should not use IDELAY on the FRAME and DATA signals.

0 Kudos