Fast ADC projects

[DrConcern]

Have you been able to acquire your data from the SDRam on the Mx?

I have the same need with my 1064nm Nd-YAG medical laser - such as in this scenario: Ablazione laser di un tumore epatico https://m.youtube.com/watch?v=SrBZmfo39Z4

[tbalon]

The project that was measuring time of flight for the laser used the previous BlackICE board which had SRAM and was way easier (and faster speed) to use than the SDRAM. I'm my ultrasound project the with the MX, I'm using the on-chip dual-ported bram to store ADC sample data.

[DrConcern]

Is it possible to store the ADC data onto the SDRam?

With the icoUSBaseBoard - https://shop.trenz-electronic.de/en/TE0889-02-icoUSBaseboard-FTDI-Interfacebasis-for-icoBoard ”It is also possible to send data from and to the icoBoard from your workstation. The software for this is not yet developed.”

[lawrie]

Is it possible to store the ADC data onto the SDRam?

I have not done anything with ADC devices for a while.

But it may be possible to use one of the SDRAM controllers we now have to do that.

How wide is the ADC data that you want to read (8-bit, 16-bit or 32-bit)? Do you need to read the ADC device continuously? At what speed? How much data at a time?

The SDRAM controller I am using for retro computers does a 16-bit write in 8 cycles with a 64Mhz clock but need some spare groups of 8 cycles to do refreshes. It is probably possible to do writes in fewer cycles.

Using @zipcpu's Wishbone bus SDRAM controller is another possibility. That does 32-bit writes but the number of cycles taken is variable. He says it should be possible to overlap writes and issue them every 2 cycles. You would probably need to do that to keep up with a fast ADC device. I have not tried this.

The other SDRAM controller that I have working is a SpinalHDL SaxonSoc one, but that would probably be difficult to use for this and I don't know how fast it could be made to go. It would probably need a DMA ADC controller.

[DrConcern]

Similar to Luc’s development at http://un0rick.cc/

https://raw.githubusercontent.com/kelu124/un0rick/master/images/128msps.png

Tip: reaching 128msps
Playing with the trigger, it’s possible to interleave two signals and artificially double to acquisition speed, yielding clean images:

Specs (un0v1.1)
FPGA: Lattice iCE40HX4K - TQFP 144 Package
Memory:
8 Mbit SRAM, 10ns, 512 k x 16, equivalent to 65 full lines of 120us at 64Msps or 840 lines of 120us at 10Msps, 8 bits.
8 Mb SPI Flash for FPGA configuration

[DrConcern]

lawrie 19d

Here is a much simpler SDRAM implementation from the Mist/Mister project. It is the Gameboy variant that has a 64Mhz clock and accesses the ram (both reads and writes) in a fixed 8 cycles to simulate 8MHz asynchronous DRAM.

Your implementation would be suitable for such ADC data collection on the MX?

[lawrie]

Your implementation would be suitable for such ADC data collection on the MX?

You might be able to use it at a fairly slow data rate. It can write a 16-bit value in 8 cycles of a 64Mhz clock. But it needs periodic refresh cycles, and the easiest way to do that is to keep the next 8 cycles free after doing a write. That would then write 8-bits every 8 cycles or 8Msps. I don't know if it would work with an 80Mhz clock. If it did that would be 10Msps.

If you want faster than that you will have to do the refreshes in a more intelligent way, perhaps optimise the write path so it takes less than 8 cycles, or overlap the writes. Using SB_IOs in the way that @zipcpu's wishbone SDRAM controller does may also help to support high clock speeds.

You could try it at the lower data rate and then try to optimise it.

I am not a great expert at any of this. I have just tried a few things and got them to work, but not at very fast data rates.

[Folknology]

To maximise the throughput to SDRAM you would probably need to configure a Fifo using the built in Ice40 BRAM (128Kbit) in order to buffer through the memory refresh periods, the Fifo has to be big enough to store the incoming ADC data during that refresh cycle.