Powering the ADS5282 EVM

Hi,

Yes.  Please consult the User Guide for the EVM, Figure 7.  This shows that the 5V supply from J1 goes to two voltage regulators to make the 3.3V and the 1.8V that the ADC wants to see.  And the normal position of the jumpers JP8 and JP9 is to power the rest of the EVM from these two voltage regulators leaving the power connections J4 and J5 unused.   But if you wanted to power the 3.3V or 1.8V separately, then you could move the jumpers and bring in that 3.3V or 1.8V separately.   The 5V supply is always needed because it powers the USB port for the ADC SPI register writes for configuration.

Regards,

Richard P.

Thanks.

Is there any design example to interface ADS5282 with Altera ?

Thanks.

Hi,

No, we do not have a suitable example of the interface between Altera and the ADS5282.

For Xilinx, the unofficial example interface was the Verilog code that went into the TSW1200.  For Lattice, the Veilog code that went into the TSW1405 is available and Lattice even extracted the interface into a block they put on their website.  But for Altera, our example would be the TSW1400 design.  But the author of the TSW1400 code did *not* include code to make the FPGA find the sample boundary using the frame clock signal.  The TSW1400 had the GUI do a capture of the frame clock, and then in software do a pattern match on the captured frame clock to determine how much to 'jog' the input deserializer, and then do the actual data capture.    So I think this Altera example would not be what you are looking for.

Regards,

Richard P.

HI,

Thanks Richard.

Are you talking about this example ?

http://www.ti.com/lit/ug/slaa545/slaa545.pdf

Even if doesn't find sample boundary, can I still use the same logic explained in Figure 2 on Page 4 of the document mentioned above to making the interfacing part ? May be later using Frame Clock by other means to find the sample boundary ?

-BAS

Hi,

No, that ADC in that example project you pointed to is an ADC with a parallel bus of LVDS data with DDR (dual data rate) clocking.  You can see in that figure you point out that the FPGA is using the Altera ALTDDIO cell to catch the DDR LVDS data.  In the Altera user guide for the ALTDDIO http://www.altera.com/literature/ug/ug_altddio.pdf in figure 3-1 you can see how the ALTDDIO cell works - the data is latched on the falling edge of the clock and also the rising edge of the clock, while the data from the falling edge is re-latched on the rising edge.  Then two bits of data per clock cycle are given to the fabric of the FPGA to process.

Our Altera code for the TSW1400 does not use the ALTDDIO to catch the serialized data from the ADS5282.  It uses a deserializer block, possibly ALTLVDS although I cannot confirm that at the moment.  This deserializer block has a 'bitslip' control input that lets it move the deserialization boundary by one position.  We do not use FPGA hardware to look for the alignment of the frame clock through the deserialization and internally issue the bit slip automatically.  We use software on the PC to do the pattern match and then use commands through the USB conenction to the TSW1400 to issue bit slips.    That is why this code is very flexible for our TSW1400 that has to support many different EVM types, but not directly useful to a customer who is interested in only one specific ADC.

Now - since you ask about the ALTDDIO cell - yes, this cell *could* be used to catch the serial data from the ADS5282 since the bit clock from the ADC is also LVDS dual data rate.  And then the deserialization could be done in the FPGA fabric.  This is exactly what we did in the TSW1405 and the older TSW1200.   The input DDR cells were used to catch the serial data from each channel *and* the frame clock channel in partallel.   The frame clock is captured just as if it were another data channel that happens to have a known data pattern each cycle - 111111000000.  Then logic is used to look for the DDR clock cycle where the frame clock went from 0 to 1 and the logic then knows that that is where the data channels also go from the end of the last sample to the start of the new sample.    This is not how we did it in our Altera design but it is how we did it in our Xilinx and Lattice designs.  Please see attached logic sketch.  The thing to watch for is the speed of the fabric being fast enough to close timing for the deserialization logic and the creation of a 'sample clock' to go with the deserialized samples.  In the Xilinx i just buffered through a delayed version of the frame clock onto a global clock route to be the sample clock to go with the data.  In the Lattice I had to divide down the bit clock by 6 to get a sample clock to go with the data.  In the Altera I don't know which would be best for meeting timing into the fabric.

Regards,

Richard P.

Richard,

Thanks a lot for your explanation.

Is it possible to get the Xilinx version of the code ? I am totally new to this area, code might be helpful to translate the same logic in Altera.

matlab_fft@yahoo.com

I appreciate your help.

Thanks.

Hi,

Sent to the address provided.

Regards,

Richard P.

Thanks a lot.

-Tariq