Electronic – Interfacing ADC Output with SDRAM


I am working on a design for a high-speed data acquisition device for a 10-bit ADC signal at 80 Msps. So far, it looks like most MCU boards are too slow to be able to route and store data and keep up with the high sampling rate. The latest board that I've been looking at is the Teensy 4.1 with a CPU frequency of 600 MHz (can go higher with overclocking, up to ~1 GHz with cooling). What I am wondering is if I can circumvent this issue by interfacing the ADC output directly with the I/O pins on a memory IC or SDRAM chip. In this scenario, I would use the Teensy 4.1 to drive the clock signals and logic signals for both the ADC and SDRAM.

In order to read the data from the SDRAM, I would use a multiplexer to re-route the I/O pins on the SDRAM to the Teensy 4.1, which can process the data and write it to external memory via SDIO. The multiplexer would only be used to switch the signals after my measurement is complete.

I've included a schematic below for what I am trying to describe above. Is this something that can physically be done?

enter image description here

Best Answer

In principle, this looks like of especially older acquisition devices worked.

Practically, you're still facing a few core problems with your SDRAM:

  1. It's non-trivial to work with SDRAM; you must make sure that for the duration of your acquisition, you can count up addresses at 80 MHz, as well as that the SDRAM is able to accept new data every clock. Usually, that's not the case, with finite burst sizes, and with refresh cycles that need to be inserted. SRAM might be easier to deal with
  2. Your Teensy still has to generate 80 million addresses a second, far as I can tell, or if you can program the SDRAM into accepting bursts of length larger than a word, a factor of that.

Honestly, this sounds a lot like you want SRAM in this application, not SDRAM, and the clock speed sounds like Pseudo-SRAM would do.

You'd also want to find an easy way to implement your mux, and while you're at it, solve the address generation timing problem, as well as reliable clock generation.

Honestly, this all sounds like a small FPGA in the middle would do much better:

      10b       2×8b data
ADC ==//==>FPGA====//====>PSRAM
           ||   x b addr  ^ ^
           \\======//====// |
           |      clk       |

Implementing an address counter in an FPGA is pretty straight forward, and having that FPGA allows you to handle, delay, scale, encode your ADC data on the fly.

For reading from a host MCU, an SPI interface would be pretty straightforward to have in the same FPGA, allowing you to keep the PCB complexity at bay.

Which FPGA? Don't know, it doesn't have to be large, and if you use one of the lower-pin-count PSRAMs (I've never worked with them, but I find Infineon HyperRAM quite interesting), you don't need more than maybe 32 IO pads; a medium-sized Lattice ICE40 might do (and there's an open source toolchain to produce FPGA images, which is a big plus in terms of vendor freedom).

Addition: Oh, scratch the HyperRAM. I've miscalculated: you need to sustain a 800 Mbps write rate. The interface of that device class will not do that.