Best way to transfer ADCHS samples to fpga at 20Msps.

[lpcware]

Content originally posted in LPCWare by matys4877 on Tue Oct 27 10:15:09 MST 2015
I consider circuit made of LPC4370 and fpga. The uc would be measuring one analog signal at 20Msps and then transferring samples to the fpga. I need continuous stream of samples for the fpga. The fpga will analyze the data and send back results to uC. For receiving results I will use simple SPI interface because there won't be a lot of data to transfer.
I'm planning to set a DMA to ADCHS for continuously stream the data to fpga at 20Msps by one of the following interfaces.

- SPIFI 4 bit bus
- SGPIO 8/12 bit bus
- ECM 12 bit

Best solution is to transfer 12 bit at the same time. Is it possible to configure SGPIO or ECM to send ADC results at required sample rate? Is it possible to configure it to send also CLK signal to clock bus data? Maybe there is another solution to stream that data?

Best regards
Mateusz

[vicentegomez]

Hi

12 bit data is troublesome, since it can't be only handled by hardware, some software is involved, and the risk is the high sample rate (20MSPS).

SGPIO has parallel mode but only up to 8 bit, so for 12 bit, you must program 2 parallel groups, one for 8 bit, the other for the remaining 4 bit, and use another SGPIO pin to output sampling clock. A good news is up to 8 SGPIO shift registers (slices) can be concatenated to form a longer shift chain, so the data processing/transfer rate is 20M / 32 = 625kHz. Also note that you need uint16_t to store one sample, so data rate is 40MB/s.

Another risk is GPDMA performance, GPDMA typically needs 16 clocks to transfer one data unit, so it could be bottleneck.

A possible approach is to use Cortex-M0 core to handle all the SGPIO driver and data transfer, and use pooling mode instead of IRQ mode (polling for shift complete flag). I think this may applicable because there is an LPC4300 based toy named as "pixy", which uses Cortex-M0 + SGPIO to read camera data (1280x800) and doing computer vision on M4, the data rate is at least 1280*800*2*30= 60MB/s. But it does not involve bit-field operation, so there could be risk.

Regards

Vicente Gomez

[mateuszspychala]

Hello. We have to use lpc4370fet100. It has only 8bit data bus in ECM, but i need 12 bit bus.

Is it possible to configure SGPIO, HSADC and GPDMA to emulate 12 bit 20Mhz ADC for FPGA? Is it possible to make it fully hardware solution, so CPU won't be waste time copying that date from peripherial to peripherial?

What we need is very simple.

12 bit data bus and 1 clk signal. Data and clk signal is generated, by LPC uc. On rising edge of CLK signal data bus is updated with next sample of ADC and on falling edge of CLK signal FPGA reads that sample. We need to transfer samples from HSADC at 20MSPs continously.

Is it possible to configure this peripherials to work without control of CPU?

Regards,

Mateusz

[lpcware]

Content originally posted in LPCWare by matys4877 on Wed Oct 28 09:33:30 MST 2015
Thank you for your help. I think that ECM would be optimal and easy to implement solution.

Regards,
Mateusz

[lpcware]

Content originally posted in LPCWare by bavarian on Wed Oct 28 06:33:57 MST 2015
Hello, thanks for considering the LPC4370 for this application.

SPIFI: tough data rate over a 4-bit interface, but not impossible. 20Msamples with 16 bits * 1/4 = 80Msamples with 4 bits. The SPIFI works on 102MHz, so there would be some MHz left. But of course you would need to know how to handle this qSPI interface on FPGA side.

ECM: you would need to specify a 16-bit bus, the interface can work on 120MHz, so there is quite some room for the overhead of a SDRAM interface overhead, using SRAM interface would even be better.

SGPIO:  you can specify a 12-bit bus, speed is not a problem here, but of course the job to fill the pipe needs to be done. That's for sure more complex than juts using the memory mapped interface(s).

For simplicity reasons I would go for the EMC static memory interface. It provides also the highest performance, at least if you are just writing from the MCU to the FPGA.

Regards,
NXP Support Team.