ADS5485EMV interfacing to Spartan 3E FPGA

Hi Raul,

Generally you dont need to make any special arrangement once you have connected LVDS signals to FPGA in hardware.

The fact that you are getting only noise data suggests that either ADC is not sampling the data correctly (on the clock edge) or your control signlas are not being assigned correctly. Are you sure that it is not a signal integrity issue, which may also result in noisy output?

What is the clock source you are using? Is your clock clean? Have you observed the sampled data waveforms on ADC pins on oscilloscope?

Regards,

Sid

Raul,

i'd also like to say that if you are meeting setup and hold time in getting the data latched into the FPGA from the data converter, then if you see 'noise' data after that point then it is likely an issue with bit assignment.  It is easy with Dual Data Rate data to get the odd and even bits swapped after the input latching, so that then your samples from the ADC turn in to bits 14-15-12-13-10-11-8-9-6-7-4-5-2-3-0-1 instead of 15-14-13-12-11-10-9-8-7-6-5-4-3-2-1-0.  

The ADS5485 does not have the option to outptu test patterns instead of sample data, like some of our other devices do.  But if you can enter a *very* slow sine wave for the analog input then you can look for patterns in the captured sample data that might give a clue to where the bits are getting messed up.  If you cannot get a very very slow sine wave through your input circuit to the ADC, then you can still get a very slow sine wave out of the ADC by inputing a sine wave that is very close in frequency to the sample clock.  In other words, if the sample clock is 200MHz, and if you input a sine wave to the ADC that is 200.001MHz, then the output samples would look like a 1 KHz signal and the arithmetic value of the output samples would be ramping very slowly.   Then you can look for things like swapped bit positions.

If the timing into the FPGA is bad, then the data will be bad even before you can get to look at it.  Keep in mind that the DRY signal is *synchronous* to the data transitions, so that the DRY signal must be delayed in the FPGA before the rising and falling edges of the DRY signal can be used to latch the data.  I have included a sketch of how our TSW1200 catches the data from the ADS5485 in a Virtex 4 FPGA.  Xilinx provides a cell called the IDDR that is used to latch in DDR data using the rising and falling edges of the DDR clock.  They also provide a cell called the IDELAY that lets you delay the data or the clock as needed to make the setup/hold timing into the FPGA work.

Finally, if you have any issue with over-filling the FIFO buffer, then you may get gaps in the captured data that will mess up what you expect to see for a captured waveform.

Regards,

Richard P.

Hi Richard, 

In the next image i show how implementing my control for the ADC. The control uses the IDDR2 component to get even and odd data in the low and high transition of the DRY signal.  The LVDS for the clock and the data is often for IBUFGDS and IBUFDS. The atributes for this components is this:

DIFF_TERM => TRUE,

IBUF_DELAY_VALUE => "0",

IOSTANDARD => "LVDS_25"

i use the IBUF_DELAY_VALUE to delay data and clock signals, but i not see better results.

I looked at some of the documentation for the Spartan 3 IDDR2 cell.  Your drawing looks like it should work, but only if you can be sure that the timing into the IDDR2 cell is met, which is that there is proper setup and hold time for the data around the clock edges. 

One thing your code does not mention is the attributes that must be set for the IDDR2 cell.  It looks like the default case is for the E_DATA and the O_DATA to come out *not* aligned to the same clock edge.  You will need for the odd data and even data to be aligned to the same clock edge if you are to then load the data into a FIFO.    This attribute is called DDR_ALIGNMENT

The Xiling design tools will be able to tell you if the setup and hold timing into the IDDR2 cell is met if you enter timing constaints to tell the tools what the timing of the clock and data out of the ADS5485 looks like.  You would find the results in the timign report following the Static Timing Analysis portion after place and route.  What we do to make sure we meet timing into the TSW1200 Virtex 4 is that we will set the IDELAY to our best estimate of what it needs to be to meet timing, then check the timing report for errors.  If there are setup and hold timing errors (called negative slack) then we look at the magnitude and direction of the timing error to determine how much we must change the setting of the IDELAY elemetns.  And then we rerun to tools to verify the timing.  The hardest part of this job is figuring out how to properly describe the ADS5485 timing in the constraint file.  We run our contraints for the fastest LVDS DDR bus device to work with the TSW1200 which is the ADS5463.  A portion of our constraint file to describe the DDR timing follows:

NET "DDRClk_p_pin" TNM_NET = ClkDDRp;

TIMESPEC TS_ClkDDRp = PERIOD "ClkDDRp" 3.87 ns HIGH 50%;

INST D*_p_pin TNM = DATA_IN;

TIMEGRP FF_RISING = RISING ClkDDRp EXCEPT PADS;

TIMEGRP FF_FALLING = FALLING ClkDDRp EXCEPT PADS;

TIMEGRP DATA_IN OFFSET = IN -0.35 ns VALID 1.3 ns BEFORE DDRClk_p_pin TIMEGRP FF_RISING; # ADS5463

TIMEGRP DATA_IN OFFSET = IN -2.35 ns VALID 1.3 ns BEFORE DDRClk_p_pin TIMEGRP FF_FALLING; # ADS5463

Regards,

Richard P.