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
471 Views
Registered: ‎06-08-2017

Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

This is a combination hardware and FPGA programming (possibly timing) question.

 

I've got a circuit board with 4 ADC chips (LTC 2194) wired to a Kintex-7 FPGA. All the ADCs share the same clock and SPI wires. Three of the ADCs have all wires connected to IO in bank 12. The fourth ADC has some IO connected to bank 12, and some to bank 14.

 

I've gotten the 3 bank-12 ADCs to work reliably, but I have never seen the 4th ADC work properly. I've made new circuitboards, and replaced the 4th ADC on already made boards and seen the same problem, so I do not think I am blowing up the ADC with crappy soldering practices. Or if I am, I'm being awfully consistent about it....

 

I am deserializing the fast serial data using ISERDESE2 and IDELAYE2. One of the inputs to the FPGA from the ADC is a frame. There are 8 bits transfered to the FPGA per clock cycle so I am doing 1:8 deserialization. The deserialized frame should look like 11110000 (or a shifted version of that sequence). Instead I get sequences of seemingly random bits changing on the order of the clock frequency.

 

Is this sort of problem familiar to anyone? Am I maybe doing something stupid with my clocking? The clocks I use for the deserializers come from a MMCME2 to BUFGs then to the ISERDESE2s.

 

I don't believe there is damage to the FPGA IOs that I am using for that ADC, but I also don't have an easy way to verfy if they are working properly, so I can't rule that out as a possibility. But, as I said it seems more likely I have some design flaw.

 

Thank you for any assistance you can give.

0 Kudos
1 Solution

Accepted Solutions
Adventurer
Adventurer
72 Views
Registered: ‎06-08-2017

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

I know this thread is a bit old now. Just wanted to provide an update if anyone read this later.

My issue was related to termination of the LVDS clock signal coming from the FPGA to the ADCs.

The output LVDS signal needs 100 ohm termination between the positive and negative clock lines. Originally, I did not have any termination, and that problem ADC output complete garbage. With the termination close to the problem ADC, it works most of the time, but with occasional glitches.  With the termination near the ADC farthest from the origin of the clock, all ADCs work at full speed with no glitches.

My guess at what is going on is that there is less signal reflection with the termination farther away from the output from the FPGA.

I know this isn't a full blown technical explanation of the problem, just thought I'd share in case anyone had a similar hardware issue and wanted to blame it on the FPGA software.

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

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution
Hi
Have you looked at XAPP585? It is for 7:1 but it could help you.
Can you clarify something for me?
In the second bank is the frame clock going to its own MMCM?
I think perhaps if you have a second bank the clock is not deskewed if the MMCM and its incoming clock is in a different region... In the Xapp it says that for multiple interfaces across multiple banks with a common frame clock you can only get 625Mbps SDR.
Is this SDR or DDR?
How fast are you going?

As an exercise could you take the frame clock on the 4th ADC route it to its own MMCM and clock the 4th ADC this MMCM. If this works we know its not an issue with the board or signal integrity?
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Historian
Historian
437 Views
Registered: ‎01-23-2009

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

The deserialized frame should look like 11110000 (or a shifted version of that sequence). Instead I get sequences of seemingly random bits changing on the order of the clock frequency

 

So, to be clear, you are sampling the frame clock using an ISERDES which is clocked using the MMCM which is driven from the bit clock from the ADC (a picture would be good), which is coming in on a clock capable pin. I presume the CLKDIV of the ISERDES is also being driven from the same MMCM with a /4 (DDR) or /8 (SDR) clock, also driven by a BUFG.

 

If so, this all sounds like a "correct" clocking structure. It is not the fastest one, but since at least one of the data channels is not in the same bank as the bit clock, you can't use the BUFIO/BUFR combination (which is faster).

 

You didn't tell us what the bitrate of the ADC is - at higher bitrates this clocking scheme may be too slow. You also don't tell us anything about your constraints or how the IDELAYs are set... All this will determine if the interface timing allows for proper data capture.

 

But - even if the capture timing is off, the sampling of the frame clock should always have (more or less) two transitions per 8 samples. It is possible to see things like 11111000 or 11100000 or frame shifted versions of that (rather than the expected 11110000), and the pattern should be more or less constant (or slowly changing or maybe alternating between two patterns that differ by one bit) but not "seemingly random bits changing on the order of the clock frequency" (I am not sure exactly what you mean by this - maybe you can give us examples).

 

If you are really getting different values on every sample and the values don't conform things that look like a sampled clock, then the problem is likely not timing related - it is something else. You don't tell us what I/O standard you are using - if it is differential, is the termination correct? If it is referenced (like SSTL/HSTL) is the VREF correct? Is the bank VCCO correct? Are the PACKAGE_PIN properties correct? These would be more likely the kinds of things that would cause "gross" errors...

 

Avrum

0 Kudos
Adventurer
Adventurer
416 Views
Registered: ‎06-08-2017

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

@klumsde

 

I have looked at XAPP585. I'll read through again to see if there's things I missed.

 

No, the frame clock is not going to its own MMCM. I don't use the frame clock for desierialization in either bank. 

 

Data is sampled at 100 MHz. Data is sent serially to the FPGA at 800 MHz. I was originally sampling at SDR, but was getting a pulse width timing violation. The ADCs have worked reliably with SDR and the PW violation. I am now switching to DDR with a 400 MHz clock to avoid the violation.

 

The IO that the frame goes to is not a clock pin. Is it still possible to send this signal to an MMCM to try your test? I'll see if I can test this.

 

 

@avrumw

ADC_clocking-min.jpg

Here's a sketch of the clocking scheme. I included the clocking regions. There is a 100 MHz oscillator that comes in on bank 34, clock region X1Y1 using an IBUFG to a BUFG. The signal out of the BUFG is the input to and MMCM in clock region X1Y0, and those clocks go to BUFGs then over to the deserializers.

 

The clock for all ADCs originates from a bank 12 pin. Data and frame for ADC0-2 all go to bank 12, clock region X0Y0. Frame for ADC3 (the one that hasn't worked) also goes to bank 12, but the data lines are connected to bank 14, clocking region X0Y2. So frame for that chip is actually in the same bank as all the other working ADC inputs, but the data lines are not....

 

All ADC clock, frame, and data lines are LVDS. I use the LVDS_25 standard for the IBUFDS and OBUFDS for frame, data, and clock. Both banks 12 and 14 are powered by 2.5V. For IBUFDS I have .DIFF_TERM("TRUE"). For OBUFDS this AR seems to indicate that enternal termination is not required. I do not have external termination on the output (clock).

 

And an example sequence of the deserialized frame might be: 11111011, 10111111, 00111011, 11111110, .....

 

I don't have Input/output constraints, and I've set the IDELAYs by manually changing them, finding the edges of the data eye, and using a centered value for the delay.

0 Kudos
Historian
Historian
372 Views
Registered: ‎01-23-2009

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

Here's a sketch of the clocking scheme.

 

This is not great... There are two problems...

 

First, the clock for an ADC shouldn't come from the FPGA. The quality of the clock to an ADC directly affects the quality of the ADC sampling - any jitter on the input clock causes error in the sampling. The clock coming from an FPGA inherently has more jitter than one coming from a good quality oscillator; the clock in the FPGA is traveling through a noisy digital environment and picking up jitter along the way.

 

Second, if you are going to send a clock out of an FPGA, you should always use an ODDR for the clock forwarding - drive the internal clock to the C pin of the ODDR and drive the D0 to 1 and the D1 to 0. Going directly from the clock buffer means that at some point, the clock needs to leave the dedicated clock network and go through general fabric routing to get to the OBUF. This route is route dependent (so can change from implementation run to run) and makes it more susceptible to jitter.

 

But more importantly, the ADCs provide a digital clock out (DCO) for a reason - the timing correlation between the DCO and the data output is far better than between the clock in and the DCO. It is highly recommended (and in many cases required) to capture the data from the ADC with the DCO and not with the input clock.

 

Putting these two together (sourcing the clock from the FPGA and not using the DCO) is pretty much a lethal combination. The clock being driven out of the FPGA is only loosely related to the internal clock of the FPGA. If generated properly, it is delayed by the delay of the ODDR and the OBUF (if not using the ODDR then the delay of the general fabric routing and the OBUF, which is worse). This delay is large (generally well more than the bit period of the clock) and highly process/voltage/temperature dependent. Since the output data is being generated by this clock, and then captured by the internal clock the sum of the uncertainties involved is WAY too large to perform static capture...

 

That being said, none of this explains your frame clock problem. Even with absolutely no correlation in phase between the ADC data (and frame clcok) and the internal clock, what you get back should still look roughly like a clock - so you need to find the source of that... But even with that, this interface will not work statically. You will need to use dynamic calibration...

 

That being said, assuming this is running at 400MHz DDR (the maximum rate of the ADC), even if this interface were designed correctly (using the DCO and with all DCOs in the same bank as their respective data) a bit period of 1.25ns would have still required dynamic calibration - but you need to deal with less than 0.5ns of variation in your dynamic calibration scheme (a bit period of 1.75ns is enough for static capture), whereas with this clocking scheme, the variation is several bit periods wide, making the dynamic capture much trickier (it could even be outside the range possible with the IDELAY).

 

Avrum

0 Kudos
Adventurer
Adventurer
310 Views
Registered: ‎06-08-2017

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

@avrumw

Thank you for the detailed explanation. I will fix these design issues on the next iteration of my board.

I currently just set delays for each data line manually using the IDELAYE2 primitive. I guess this is what you mean by static capture. As I've mentioned this has worked well so far for the first 3 chips... but I guess there's not guarantee that it will work properly in future implementations.

I'll need to do some searching to understand static and dynamic data capture....

I'll post again if I get to the bottom of the third ADCs issues.

Thanks again. 

0 Kudos
Adventurer
Adventurer
73 Views
Registered: ‎06-08-2017

Re: Serial data from ADC not deserialized properly, using IO in 2 adjacent banks

Jump to solution

I know this thread is a bit old now. Just wanted to provide an update if anyone read this later.

My issue was related to termination of the LVDS clock signal coming from the FPGA to the ADCs.

The output LVDS signal needs 100 ohm termination between the positive and negative clock lines. Originally, I did not have any termination, and that problem ADC output complete garbage. With the termination close to the problem ADC, it works most of the time, but with occasional glitches.  With the termination near the ADC farthest from the origin of the clock, all ADCs work at full speed with no glitches.

My guess at what is going on is that there is less signal reflection with the termination farther away from the output from the FPGA.

I know this isn't a full blown technical explanation of the problem, just thought I'd share in case anyone had a similar hardware issue and wanted to blame it on the FPGA software.

0 Kudos