Eclypse Z-7 ADC1410

[summer]

 https://reference.digilentinc.com/reference/programmable-logic/eclypse-z7/low_level_zmod_adc_dac  I'm trying to run ADC in PL by referencing the project here.

 This is my design. Using Digilent's Analog 2 Discovery, I send sine waves, square waves over Waveforms Platforms, and observe over ILA. 

 But I can't analyze the data. "dADC_Data" is 14 bit DDR parallel data bus exported by ADC containing Channel1 and Channel 2 multiplexed samples.  Could you explain why "sCh2Out" data 16 bits? 

sCh2CouplingConfig's value is '0'. That's mean DC Coupling. I should observe unsigned data. But when ı sent the data as DC, I observe 65464... I think it is signed value. How can I decide if data value's signed or unsigned?

[summer]

the last 2 bits were unimportant, solved thanks

[zygot]

5 hours ago, summer said:

That's mean DC Coupling. I should observe unsigned data.

Nope.... Read the datasheet for the ADC to see how the output data is formatted. Ok, for the ADC ZMOD the question as to how you should interpret the output data is a bit more complicated... but the place to start is with the datasheet for the AD9648.

These kinds of questions belong in the FPGA section of the forum.

Edited November 11, 2020 by zygot

[zygot]

To emphasize the importance of ADC users knowing how to interpret ADC output I'll add that constraining an input signal to half of the ADC range, say by halving the signal input amplitude and introducing a 50% offset so that you only get positive output values from a signed ADC, you are turning your 13-bit plus sign ADC into a 12-bit plus sign converter; you just aren't using 50% of the ADC range. In other words you are losing the msb, not the lsb. If you have to throw away bits, you want to toss the lsbs.

The Digilent ADC and DAC Zmods are nicely designed SYZYGY pods, but before you can use them effectively you need to trace through the entire signal chain, starting with the converter, though the analog conditioning front end, through the software drivers to know what's going on. Otherwise, you are in for some bad surprises.

[snak]

Hello,

I am trying to implement the similar design. But I coudnt Debug the ADC_DATA. I get the timing failure. Do I need to modify the constraint file?

I am using the eclypse-z7/low_level_zmod_adc_dac demo project as reference.

Thank you.

[zygot]

On 11/17/2020 at 10:59 AM, naks said:

Do I need to modify the constraint file?

You definitely need to use the Eclypse-Z7 and ZMOD timing constraints. You shouldn't get failing timing paths for the Digilent demos.

[snak]

On 11/23/2020 at 3:49 PM, zygot said:

You shouldn't get failing timing paths for the Digilent demos.

There was timing failure when ILA is used. The issue got solved . There are no timing failures now.

[tsarquis]

Hello @summer.

On 11/11/2020 at 9:03 AM, summer said:

the last 2 bits were unimportant, solved thanks

Did you confirm that? I'm starting to think the same but yet I couldn't find any official word about that.
In my (short) experience, those two LSB are always down except when I put some analog out-of-the-range input value. 
 

[zygot]

If you populate a signed 16-bit std_logic_vector with a signed 14-bit ADC value the low two lsbs will be zero and unimportant. If you scale the ADC word to calibrate the span then those lsbs are no longer 'unimportant'. If you sample at 100 MHz but really are only interested in a 6.25 MHz bandwidth then you can decimate those 100 MHz 14-bit samples and get 16-bit samples at a 6.25 Mhz rate. The assumption that a 14-bit ADC is providing 14-bits of dynamic range is not a good one... so regardless of your system design those lsbs are something to understand, especially if you are processing the sample data. That, as they say, is an exercise for the student. There's a lot going on with analog to digital conversion. It's not a trivial subject for either practical implementation or theoretical musing.

[edit] As to what, exactly the low n-lsbs of any particular ADC code output represents is a matter worthy of inquiry by all students ( i.e. users ) of such circuitry or components. Indeed, for some applications replacing a few of them with random data for improved performance has been a tried and true technique for a long long time.

Edited July 1, 2021 by zygot