Latency of DE0-nano ADC - Page 1
Forum section: electronics / general

author: zigunov
author_rank: Contributor
timestamp: April 14, 2025, 02:49:51 am
content: Hi, everyone,This may not be really an FPGA question but I figured since I'm using a FPGA dev board it would be appropriate.I am trying to use a DE0-nano for an application (I'm a beginner) and I was checking its ADC latency. I built a Verilog that; in summary, reads the ADC value and echoes the binary code in another digital pin. The setup is running the ADC I2C with a 2.3MHz clock and is based off this code:https://github.com/stffrdhrn/adc_interfaceMy hope is that this could eventually be used for a closed-loop real time controller.I was able to make the Verilog code work and output sensible values, but I'm a little concerned about the latency. I attached a picture of a scope measurement; in Channel 1 I have the square wave going from the value where the ADC reads 0 (it's about -0.25 V) to an arbitrary value (about 1.8V). As you can see in channel 2, the FPGA piped output reads zero for a really long time, approximately 732us as measured by the scope cursors. Zooming in that region, the jitter seems to be about 25us, which would be equivalent to approximately 3 samples.It was so much delay that I had to lower the frequency of the wave all the way down to 60Hz to even see the delay!I know this is not really the FPGA's fault, but I'm rather impressed by the amount of latency. Is that normal for ADCs? The DE0-nano uses the ADC128S022 and I can't seem to find anything related to latency figures in their datasheet, or even latency as a performance parameter. Is there something I'm doing potentially incorrectly?Thanks!

author: zigunov
author_rank: Contributor
timestamp: April 14, 2025, 04:21:33 am
content: I gave it some more thought and it really couldn't be the ADC chip. How could you introduce a latency without memory? So it must be the FPGA. Further probing at the data output of the ADC shows that the delay is consistent with one sample.So, how could the FPGA introduce this delay?

author: hamster_nz
author_rank: Super Contributor
timestamp: April 15, 2025, 11:14:58 pm
content: The key will be in understanding this paragraph from the datasheet, along with figure 3:During the first 3 cycles of SCLK, the ADC is in the track mode, acquiring the input voltage. For the next 13SCLK cycles the conversion is accomplished and the data is clocked out. SCLK falling edges 1 through 4 clockout leading zeros while falling edges 5 through 16 clock out the conversion result, MSB first. If there is more thanone conversion in a frame (continuous conversion mode), the ADC will re-enter the track mode on the fallingedge of SCLK after the N*16th rising edge of SCLK and re-enter the hold/convert mode on the N*16+4th fallingedge of SCLK. "N" is an integer value.It seems to me that the only way this can be is if the interface pauses after sending out the zeros,before it clocking out the data bits.The latency in the ADC should be Tconvert (SCLK 13 clock cycles).

author: zigunov
author_rank: Contributor
timestamp: April 16, 2025, 12:23:41 pm
content: Thank you for looking into it. I think there's some huge delay being introduced in that Verilog in the github. I re-built a barebones Verilog to make a state machine that just streams the 16 bits for each communication window and there's no delay now. I think there's something to do with the author of that code trying to work with multiple ADC channels that makes it loop around like that.I'm still checking whether the data makes any sense. My scope is a little on the old side and counting bits is not particularly fun...

author: hamster_nz
author_rank: Super Contributor
timestamp: April 17, 2025, 01:36:30 am
content: I'm not going to say that those $10 AliExpress 24MHz logic analyzers are great for debugging this sort of stuff.I may think it, but I am not going to say it out loud.

author: whollender
author_rank: Regular Contributor
timestamp: April 18, 2025, 07:27:01 pm
content: Quote from: hamster_nz on April 15, 2025, 11:14:58 pmThere shouldn't be any 'pause' in the output of the ADC. It's a successive approximation ADC, so it does one bit of the approximation every SCLK cycle, and is outputting each bit as it measures it.If you look a little deeper in the github repository you linked, the author is using a divided clock of 2.3MHz/64 to update the data, and then looking at the max value of 512 samples (see the max.v file) at that rate before updating the output. That is the reason for the latency you're seeing.If you have any microcontrollers lying around, it shouldn't be too hard to hook them up to decode the SPI data you're seeing. 2.3MHz isn't particularly fast, so even just watching the data in software with something like a teensy or faster arduino should work.Good luck!