The data out of ADS5463 sometimes is not OK

User,

Are you terminating all of the data lines and DRY at the FPGA with 100 Ohms? What frequency is this interface running at?

When setting the time relationship between DRY and DATA at the receiving device, it is generally

recommended that setup time be maximized, but this partially depends on the setup and hold times of the device

receiving the digital data (like an FPGA, Field Programmable Gate Array). Since DRY and DATA are coincident,

it will likely be necessary to delay either DRY or DATA such that setup time is maximized.

Regards,

Jim

hi,

As Jim pointed out, the LVDS dual-data-rate clock for the sample bus (signal DRY) must be delayed in your FPGA to get the proper setup and hold timing for the data bits into the FPGA.   The timing of the data and DRY as they leave the ADC is such that the clock edges are aligned up with the data bit transitions, and so the clock signal must be delayed by 90 degrees in the FPGA.   In the Xilinx you are using (I think that is what the part number points to), you could use a PLL to delay the DRY or you could use the IDELAY cells to add delay to either the DRY signal or the 12 data signals.   In our old TSW1200 capture card (now obsolete and replaced by the TSW1400) we used the IDELAY cells as that was easy to use and all the LVDS inputs had IDELAY cells there to be used.  Please see attached for a sketch of how we implemented the interface between the ADS5463 and a Virtex4 back then.  

looking at your data, the 'good' output seems to me mostly values 0,1,2,3 or 4.  I take it this is with no signal present at the input to the ADC - what we would call Idle Channel noise.   Is that correct?     And mostly it is the two lsb's that are toggling somewhat randomly.   That looks to be normal, although there could be different amounts of offset to the ADC output that varies from device to device.  I different offset voltage could cause your idle channel noise to be on the other side of mid-scale and look like negative samples, or to be crossing back and forth across midscale making all 12 bits toggle.

  But the 'bad' data also seems to have two bits that are toggling randomly, in bit positions D7 and D8 out of the 12bit pattern.   These look like they could be your lsb's toggling, although I don't know what could have happened in the code to sometimes have the data show up in a different position.   Maybe this would happen with an ISERDES cell, but not using an IDDR cell to latch the data. 

I would check your timing of the data to clock as Jim suggests, as I don't know what else would do that to your data.

Regards,

Richard P.

I using the internal 100 Ohms in the FPGA.

ADC work frequency is 400MHz, so the data interface is 200MHz DDR;

 

I use a DCM to delay DRY 90 degree to clock the IDDR  primitive.

 

 

1)I am using VIRTEX7 FPGA, and I use DCM to delay DRY 90 degree, then use the delayed clock to capture the data.
2)Yes, Now the ADC is in IDLE state;

1）I use the 100 Ohms resistance in the FPGA to terminate the DRY and DATA signal.
2）The ADC clock frequency is 400MHz, and the data interface is 200MHz DDR;
3) I use a DCM to delay the DRY clock 90 degree to capture the IDDR data;

Hi,

then the only other thing I would look into is whether the input buffering of the clock before the DCM is significantly different that the input buffering delay of the data such that the true clock timing could be 90 degrees plus the difference in clock delay vs data delay.    In that sketch of how I implemented the interface in the Virtex4, I used the IDELAY cell to add delay to the clock, but when the final settings for the IDELAY were determined I needed very little IDELAY at all.  It turns out that the buffer for the clock input was so much longer than the delay for the data input that most of the necessary clock delay was already there.   

You would need to work with your Xilinx representative about the timing constraints for the clock and data into your design and the DCM to see what is needed to meet timing into your design.

Regards,

Richard P.