ADS5463 Timing

Thanks for the reply!

Let me comment on the answers given, as they did not fully address the questions in a couple of the cases:

1.)  Our 1st choice in latching the output data is to use the DRY output signal of the ADC.
    [A]: DRY can be used as a data capture clock and it needs a delay to set a good setup/hold time between DRY and data.

DH:  Unfortunately, the DRY signal alone cannot be used (without PLL multiplication) to latch the output data, because (according to the spec sheet) the DRY signal will exhibit an alternately rising or falling edge during the latch time of the output data, rather than an always-rising edge for each output data period.  This is because the DRY signal is 1/2 the input clock rate.  So, this is why we intend to use the DRY signal to generate a 2X PLL multiplied signal in our FPGA, which then can be used to latch the incoming ADC data into our FPGA.  Do you know of any simpler/more robust method to latch the ADC data at our FPGA input?  Did TI intend the DRY signal to be used somehow directly to latch the output data, possibly with some sort of rising/falling edge circuit based on an XOR or other?

2.)  The spec sheet shows a Tskew = -350pS to +650pS, labeled the "DATA to DRY skew".
    [A]: Yes.

3.)  Is this a combined min/max range of delay and skew between any individual DATA output and DRY, or is it the range of delay between the entire DATA bus together and the DRY signal?

    [A]: It is delay and skew which is cased by misalignment of 12 bits during the data transition.

DH:  So to be sure I understand this correctly, the answer to the above question is yes, the DATA to DRY skew consists of the delay from any individual DATA output signal and the DRY output signal, and this by definition includes skew across the 12 bits of the DATA output signals, correct?

4.)  The CLK to DRY delay is 950pS to 1600pS across process/temperature/time, so that any individual device could exhibit any delay within that range, independent of another device, when multiple devices are used?

    [A]: Yes.

5.)  The CLK to DATA delay is 750pS to 2100pS, and does this include max DATA bus skew?  Also, is this across process/temperature/time, so that any individual device could exhibit any delay within that range, independent of another device, when multiple devices are used?

    [A]: Yes, it includes bus skew.

DH:  Per the question above, does this delay also include the effect of process/temperature/time, so that any individual device could exhibit any delay within that range, independent of another device, when multiple devices are used?

6.)  What is the DATA bus max skew alone (i.e. from any one DATA bus LVDS output pair to any other DATA bus LVDS output pair)?
[A]: It should be counted this way, bus skew plus clock propagation delay is t_data (CLK to DATA). But when you use the number in the data sheet it may give you a number with error because the spec has added some margin estimated. Why do you need this number? 

DH:  The reason to ask this question is that it has a direct and important effect on the input latch design for our FPGA.  For instance, if the skew portion of the DATA to DRY delay is very small (say 100pS), and the rest of the timing is strictly propagation delay (i.e. appx -350pS to +650pS), then it could simplify how we do our latching, because we can potentially use a single clock with adjustable delay to latch the 12bit bus of signals.  If on the other hand the propagation delay is small and the skew across the DATA output pins is very large (i.e. appx -350pS to +650pS), it will potentially make the latching more difficult, because we now have a relatively large 1nS range over which we will need to latch each individual DATA output pin pair.

So as in the question above, do you have a specification for the DATA output skew only (i.e. not including the CLK or DRY to DATA delay)?  As noted here, this would help us greatly in terms of our design.  If the specification for this is not available, then we will have to make the worst case assumption that the entire range of -350pS to +650pS can manifest as DATA output skew for the DATA to DRY delay, and design accordingly.

Please let me know on the above questions as soon as possible.  Thanks for your help!

-J

Hi Hui,

Thanks for the excellent information.  Do we have an estimate of data bus max skew alone? 

-Jon

Hi Qin,

Thanks for your great help.  We have some additional quesitons.

1.  What portion of the CLK to DATA delay specification is skew and what is delay?

2.  How is the CLK to DATA delay spec related to the DATA to DRY delay spec?  In other words, if the performance of the CLK to DATA delay is at the minimum 750ps, will we see a corresponding DATA to DRY delay of approximately -350ps?  Likewise, if the CLK to DATA delay is at the maximum of 2100ps, will we see a DATA to DRY delay of approx. +650ps?


We are still working on the best method to support latching of the data from the ADCs as they are captured at our FPGA, which is complicated by the fact that we have to capture the data from multiple ADCs.  We may also consider the  RF version of the ADC device, as it has considerably improved timing as compared to the standard device.

-Jon

Let's look at some numbers for the ADS54rf63 at 550 MHz, using the DRDY signalas clock in to a virtex 6 using its DDR input registers.

Clock delay in Virtex device 1.3-2.7 nS best case/worst case

Data out uncertainty 0.4 nS

Total uncertainty 1.8 nS which is the data rate; therefore it cannot be done.

Robert,

  I don't have Virtex timing spec and not so sure how you configure the data and DRY lines in Virtex, so I am limited to provide information you need. But I am thinking if both data and DRY go through the same path they will face the same delay variation and it should not impact  the capture window in the spec. If the clock delay variation caused by Virtex is 1.4ns uncontrollable, then you are right, it can't keep valid data capture window in the spec. In this case I would like to suggest to get help from Virtex to make sure the DRY delay variation in Virtex is controlled. Just for your reference, we have many users using FPGA to capture ADS54RF63.  I hope this helps.

Regards,

Hui  

Hi,

Not sure if I should crreate a new topic for this but I'd like to tag a question onto this post related to the tDRY and tDATA specs in the ADS5463 data sheet. In the data sheet for the device tSKEW is defined as tDATA - tDRY. The min tDATA for the ADS5463 is 750ps and the min tDRY is 950ps, however tSKEW is given as -250 ps. I may be misunderstanding the equation here but shouldn't tSKEW be 750ps - 950ps = -200 ps? Similarly the max values seem to be incorrect.

Any clarification on this would be much appreciated.

Hi,

Nominally the DRY and the data outptus transition together, after some propagation delay from the sample clock.  That is why the typical tSKEW is zero, meaning the data and DRY transitions are coinicident. 

But there are things that cause variations in that propagation through the device from the sample clock to the DRY output, and additional factors that can cause variations in the output of the data bits, and these things are not all correlated.  So you won't see the min value of tDRY at the same time as the min value of tDATA.  The things that lead to tDRY and tDATA variation are things tha affect propagation time through a buffer.  The things that affect tSKEW min to max include matching issues that might be worst at different conditions than when propagation delay are worst.

Looking at the min to max variation in tDRY shows a window of 650ps that the DRY edge will be in relative to the sample clock.   tDATA shows a much larger min to max window of 1350ps for the placement of the data transitions, as *some* of the variance in DRY placement carry over to the DATA placement, plus additional skews of the data relative to the DRY. 

You may notice in the tSKEW for the ADS5463 column that there is more skew in the max direction than in the min direction.  Early silicon for this device had a speed path in the correction logic that caused the most significant bits to output later, which was made worse with increasing temperature.  We had to put wider min to max specs on the tSKEW than we wanted to because of the speed path.  For the ADS54RF63 that speed path was fixed so that it didn't limit tSKEW, so the tSKEW for that device is tighter, and correlates better to the tDRY and tDATA.  (And production silicon for the ADS5463 also fixes that speed path and the device will now be better than the data sheet suggests, but we can't revise the datasheet to have better numbers for the ADS5463 because there is still the older silicon out there someplace.)

Regards,

Richard P.

Hi,

I am using Virtex 6 ML605 board to latch the digital output data coming from ADS54RF63EVM. It would be really helpful if I could get in touch with fellow users with respect to this issue. I am facing quite a lot of fundamental issues with respect to this implementation.

Any minor help would be of utmost importance for my work.

My email id for contact is : badaboss@gmail.com.

Expecting a positive reply and Thanking you in advance,

Basil M.

Hi,

I believe I posted this sketch of a Xilinx implementation elsewhere, but just for completeness please see attached.  This is how the interface was implemented for the ADS54RF63 EVM into the TSW1200 capture card which uses a Xilinx Virtex 4 FPGA.

Also the ADS54RF63 EVM works with the TSW1400 capture card which uses an Altera FPGA, and it works with the TSW1405 capture card which uses a Lattice FPGA.  For the latter, Lattice has put the ADC Interface portion of the FPGA design into a 'black box' that you can get from the Lattice website and use in your design if using a Lattice.

The Xilinx implementation used the Xilinx IDELAY cells to delay clock or data to close timing tor meeting the setup adn hold time into the PFGA.  The Altera and Lattice implementations used a PLL to shift the clock 90 degrees to deal with the source-synchronous nature of the interface and meet timing into the FPGAs.

If anyone else with experience implementing these interfaces wants to join in, feel free.  But there are at least some 'existence proofs' for using this EVM with each of the major FPGA vendors in the form of the TI capture cards.

Regards,

Richard P.

Hi Richard,

 Thanks for replying again. Yes, you had posted this sketch on a different post too. I am trying to use this implementation for my interfacing. At the same time, I would also like to get the VHDL source code used in the TSW1200 capture cards, as it has a Xilinx FPGA in it. My mail id is badaboss@gmail.com.

Thanks,

Basil.