cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
quark21
Visitor
Visitor
641 Views
Registered: ‎02-23-2021

High-speed ADC interface

Hello all!

I'm currently fumbling through my first post college FPGA design. I've been tasked with implementing a high-speed ADC interface. The ADC in question is the ADC3444. This is a 4-channel 14-bit ADC, and transmits its data and bit clock on LVDS pairs. I am using it in 2-wire mode, with the least significant 7-bits of a sample transmitted on one pair, and the most significant 7-bits transmitted on another. In general, this is a source-synchronous center-aligned interface. My goal is to run at the highest possible sampling rate of 125 MSPS. This results in a bit clock of 437.5 MHz. Since my data eyes are around 700 ps, it's my understanding that static timing analysis is not possible for such an interface, so I will need to implement a form of dynamic phase alignment, to restore the phase relationship between the clock and the data. 

I currently have basic deserialization design working in simulation, but I've yet to tackle the dynamic phase alignment. I'm working with an UltraScale+ device. In summary, I'm using ISERDESE3's to deserialize to an 8-bit word, then I'm passing this to a gearbox to create a 7-bit word. I do this for both the most significant and least significant portions of the 14-bit sample, and i simply stitch the two together to create the final 14-bit sample. I am aligning the data with the frame clock within the gearbox. I look for either 0000000, or 1111111 to align the data, as two 14-bit samples occur in 1 period of the frame clock. 

I'm using an MMCM to generate all necessary clocks. This includes a clock for the 8-bit domain, one for the 7-bit domain, and the bit clock for the ISERDESE3s. Everything is working wonderfully in simulation. Please see a rough-block diagram of my design below (sorry for the roughness!).

I have a few questions before I begin tacking the dynamic phase alignment. Please would you kind and intelligent folks help me out

1) Can I use the fine-phase shift capability of the MMCM to dynamically align the bit clock for my interface? (I''m under the impression that IDELAYE3s should not be used for clocks)

2) Referring to my first question, in XAPP1315, IDELAYE3s are being used to delay clocks for dynamic alignment. I thought this was inadvisable ?

3) I'm converting the differential signals from my ADC to single ended using IBUFDS, yet I've seen in many designs such as XAPP1315 that the signals remain differential (using an IBUFDS_DIFF_OUT). With each signal of the pair routed to independent ISERDES called master and slave. Why is this done? Why not just use a single ISERDES as I have done?

4) As I mentioned, I'm using an MMCM to produce 3 clocks. The high-speed 437.5 MHz bit clock (CLK), a slower clock for the 7-bit domain (CLK/3.5 = 125 MHz), and CLKDIV which is CLK/4. Is it wise to produce all three of these clocks with an MMCM? What about using a BUFGCE_DIV for generating my CLK/4?

Thank you so much for any words of wisdom!

adc_interface.jpg
0 Kudos
5 Replies
drjohnsmith
Teacher
Teacher
616 Views
Registered: ‎07-09-2009

Would this help

https://www.xilinx.com/support/documentation/application_notes/xapp524-serial-lvds-adc-interface.pdf

for interest, 

   this is the Ti eval board for this part I think

https://www.ti.com/tool/TSW1400EVM

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
avrumw
Guide
Guide
610 Views
Registered: ‎01-23-2009

So, first...

Yes, the IDELAY should not be used for a clock on UltraScale/UltraScale+/Versal. The original XAPP dates back to the 7 series, which used a different technology for the IDELAY which was safe (even preferred) for delaying clocks (which leads you to wonder why this XAPP specifically says that it is valid for UltraScale/UltraScale+).

Second, this interface looks like it might be pretty close to ideal for using native mode I/O on UltraScale/UltraScale+. With native mode I/O (with Built-In Self Calibration - BISC), the I/O stuff uses the PLL to automatically center the clock in the data eye. With a symmetrical data eye this will "guarantee" accurate capture. The disadvantage of native mode is:

  • The clocks must come in on the *BC pins (DBC and QBC) and not the GC pins (which feed the BUFGs)
    • If your board is already designed it may be too late to consider this
  • There is no way to do static timing of interfaces using native mode - you need to rely on the datasheet, which specifies that you only need tiny setup/hold windows (tSAMP_NATIVE_BISC) which is between 60 and 110ps depending on speed grade - much smaller than the 420ps/470ps your device is guaranteeing

This removes all the complexity of designing your own dynamic phase adjust - it is built-in to the native mode sampling.

But on to your questions:

1) Can I use the fine-phase shift capability of the MMCM to dynamically align the bit clock for my interface? (I''m under the impression that IDELAYE3s should not be used for clocks)

Yes - the dynamic phase shift of the MMCM can be used for this.

2) Referring to my first question, in XAPP1315, IDELAYE3s are being used to delay clocks for dynamic alignment. I thought this was inadvisable ?

 See above

3) I'm converting the differential signals from my ADC to single ended using IBUFDS, yet I've seen in many designs such as XAPP1315 that the signals remain differential (using an IBUFDS_DIFF_OUT). With each signal of the pair routed to independent ISERDES called master and slave. Why is this done? Why not just use a single ISERDES as I have done?

This is the basis of some of the XAPP dynamic phase adjust schemes. It samples the incoming signals independently with two different IDELAY setups with the two IDELAYs set exactly 90 degrees apart. The idea is that if one of them (lets say the slave) is sampling in the "worst" possible place, then the other one (the master) is sampling at the "best" possible place. So on any data transition you look at the two samples - if they are the same, then the "worst" sample is too late and the adjustment moves the sample point earlier. If they are opposite then the "worst" one is to early, so it moves it later. With this done dynamically, the "best" sample point stays near the middle of the data window.

With an LVDS signal you are using two IOBs. The IBUFDS uses the I/O structure from both. But each one has an IDELAY and an ISERDES. So by using the LVDS_DIFF_OUT, you can have the result of the LVDS comparison sent to both IDELAY/ISERDES (knowing that the N side will be inverted) - this gives you the connectivity you need for the above sampling.

But, again, if you use the native mode BISC, none of this is necessary.

4) As I mentioned, I'm using an MMCM to produce 3 clocks. The high-speed 437.5 MHz bit clock (CLK), a slower clock for the 7-bit domain (CLK/3.5 = 125 MHz), and CLKDIV which is CLK/4. Is it wise to produce all three of these clocks with an MMCM? What about using a BUFGCE_DIV for generating my CLK/4?

Either is fine, but you get a bit better skew using the BUFGCE_DIV. Make sure that all clock nets are in the same CLOCK_DELAY_GROUP.

Avrum

 

avrumw
Guide
Guide
468 Views
Registered: ‎01-23-2009

Just a quick follow up. I only later realized that the CLK and CLK/4 are used for the CLK and CLKDIV of an ISERDES. In UltraScale/UltraScale+ the skew requirement between these two clocks is SUPER tight - you must use the BUFGCE/BUFGCE_DIV combination to make this work. Take a look at this answer record (although it seems to state that the problem is only on the OSERDES, not the ISERDES, but that you should use the same topology anyway).

Avrum

quark21
Visitor
Visitor
394 Views
Registered: ‎02-23-2021

avrumw,

Thank you very much for your thorough and thoughtful responses It's most appreciated. I had certainly considered the use of native mode, using the BISC and RX_BITSLICE primitive, but we need the interface to support lower sampling rates, too, and it seems native mode has a minimum bit rate of 800 Mbps.

I do have a few follow up questions:

1) In order to satisfy the skew requirement between CLK and CLKDIV, I will generate CLKDIV using the BUFGCE/BUFGCE_DIV combination as you suggested. However, I also have a third clock domain for (CLK/3.5) used within my gearbox. Am I likely to run into trouble using the MMCM to generate this clock? Obviously it needs to be in phase with CLKDIV. I understand that I should place CLK, CLKDIV, and CLK/3.5 in the same clock group.

2) My strategy for dynamically aligning CLK with the data will be based upon the technique describes in XAPP524 (I understand this is a 7 series document). I plan to sample the inserted CLK (using an ISERDESE3) using a delayed version of CLK, with the delay/phase shift provided by the MMCM as opposed to IDELAY as used in XAPP524. I would then adjust the phase of CLK until the output of the ISERDESE3 becomes metastable, indicating I'm sampling when CLK is transitioning. Is this a viable strategy with this particular architecture? Is it a better strategy to align the data as opposed to aligning CLK?

Kind regards

0 Kudos
avrumw
Guide
Guide
370 Views
Registered: ‎01-23-2009

1) In order to satisfy the skew requirement between CLK and CLKDIV, I will generate CLKDIV using the BUFGCE/BUFGCE_DIV combination as you suggested. However, I also have a third clock domain for (CLK/3.5) used within my gearbox. Am I likely to run into trouble using the MMCM to generate this clock? Obviously it needs to be in phase with CLKDIV. I understand that I should place CLK, CLKDIV, and CLK/3.5 in the same clock group.

Use one MMCM. Generate CLK and CLK/3.5 from two outputs of the MMCM (say CLK from CLKOUT0 and CLK/3.5 from CLKOUT2 - I will come back to CLKOUT1 later!). Have CLKOUT0 drive two buffers, a BUFGCE (for CLK) and a BUFGCE_DIV dividing by 4 for CLK/4. Have CLKOUT2 drive a BUFGCE for CLK/3.5. Put the nets driven by the outputs of the three clock buffers in the same CLOCK_DELAY_GROUP. This will keep everything in phase.

However, be careful with the statement that CLK/3.5 is in phase with CLK/4. The ratios between these will result in requirements of 1.14ns; this is going to be very tight for bringing data across the boundaries. While the skew between these domains will be minimized, they will be significant - crossing between these domains in is not necessarily easy...

2) My strategy for dynamically aligning CLK with the data will be based upon the technique describes in XAPP524 (I understand this is a 7 series document). I plan to sample the inserted CLK (using an ISERDESE3) using a delayed version of CLK, with the delay/phase shift provided by the MMCM as opposed to IDELAY as used in XAPP524. I would then adjust the phase of CLK until the output of the ISERDESE3 becomes metastable, indicating I'm sampling when CLK is transitioning. Is this a viable strategy with this particular architecture?

Yes, it should be. But I have had trouble with this in the past. What you want is

  • CLKOUT0 - frequency of CLK, phase of PH, where PH is the dynamically adjusted phase (using the dynamic fine phase shifter)
    • This is used to generate CLK and CLKDIV for the ISERDES sampling data
  • CLKOUT1 - frequency of CLK, phase of PH+90, where PH is the dynamically adjusted phase
    • This is used to generate CLK and CLKDIV for the ISERDES sampling the forwarded clock
  • CLKOUT2 - frequency of CLK/3.5, phase of PH

The problem is getting CLKOUT0 and CLKOUT1 to both be using the dynamic fine phase shift, but be 90 degrees apart. From the architecture of the MMCM this should be possible since you have both the coarse phase shifter (in increments of tVCO/8) and the fine phase shifter. You should be able to use both, but getting the tools to understand what you want to do isn't easy. 

One thing to investigate is to put the fine phase shift on the feedback clock - you won't be able to do this through the clocking wizard (at least I don't think you can). This has the effect of shifting all the output clocks together. Then you can program all the output clocks as static phase shift (including the 90 degree shift you need for CLKOUT1) and do the dynamic adjustment on the feedback clock. The only thing to realize is that this is backwards - increasing the delay on the feedback clock makes all the other clocks arrive earlier.

Is it a better strategy to align the data as opposed to aligning CLK?

Probably not, but I don't claim to be an expert on dynamic capture - I try and avoid it whenever I can!

Avrum