sorry i wasnt clear enough about this, i'm so naive in this thing... i dont even know how to program in FPGA
i wish there is MCU to do this kind of thing, but at GSps multibus rate, FPGA seems inevitable. i was looking at
https://www.digikey.my/product-detail/en/texas-instruments/ADC081000CIYB-NOPB/ADC081000CIYB-NOPB-ND/1302378 ADC so the data interface is 16 bits LVDS (i'll need to study more on this, your advice will always be more than welcomed), so its effectively 800MSps @ 16 bits X 4 ADC.
If you want some good clearance with only a single 32bit port, you will have to use the Intel Arria 10, which can run DDR4 at 1.2Ghz, or 2.4 gigawords/sec, or, DDR3 at 1.066Ghz.
That is multi-thousand $$ affair, Xilinx UltraScale/US+ can do that too (DDR4 up to 1333 MHz IIRC).
this one of the main concern, i dont want to be left with $500 useless part that cant do the job just as good as wall decoration in frame. now i got few names to start with.
I've got a design that does that with DACs. 8x AD9736 connected to an Arria V FPGA. Those are 14 bit DACs operating at 1 GS/s. They are kind of old school and use a parallel LVDS interface, so that is 120 LVDS pairs on the FPGA. You can do the same with ADCs, and up to 1-2 GS/s there are still available with LVDS. Faster chips typically use JESD204b, which requires an FPGA with lots of 10G+ transceivers.
We only use SRAM. DDR memory has plenty of bandwidth, but to have both DDR memory interface *and* 120 LVDS transmitters would require a much larger FPGA.
The big gotcha with DRAM is the refresh. You don't want the ADC to stall out because of a memory refresh. That means you either have to have a big SRAM buffer or find a way to avoid hitting the refresh. The way to make that work is application dependent.
hey! i didnt know there is 14 bits ADC @ > 1GSps that is half the price of the 8 bits ADC081000 ADC. thanks! i maybe consider AD9736 in the design plan (that is lingering in the mind) but BGA footprint is no fun for hobbiest one-off project.
to be more specific, there are 4 "paths" for the design (maybe 5 or 6 paths @ 1GSps depending on part used), lets just take one, the other 3-5 will just duplicates. an ADC (8 - 14 bits @ 500 - 800MHz data clock) -> FPGA -> RAM. the total RAM is about 50 - 100MBytes. so its 12.5 - 25MB per RAM (4 paths) or 8 - 16MB per RAM (6 paths). all of this 100MB must be filled at effective rate of 6GSps (total 4x ADC), and then later there will be blind time (no data capture) where another MCU, or the same FPGA will process this data, FFT to be exact, before sending it to PC (USB) or screen for human viewing. anyway i think if i go RAM -> CPU path for FFT processing, this is the easiest part (so i also need a RAM that can be clocked a lot slower to interfacce to MCU), but if i go FFT in FPGA route, this may open another can of worm for a discussion, short FFT up to 1024 pts is common, but MBytes length of FFT is another thing...
https://www.ll.mit.edu/HPEC/agendas/proc04/powerpoints/Posters/Poster%20B/dillon_posters.ppt let alone staggered clock to get 6GSps from 4 x 1.5GSps ADC parts.
so the total FPGA pins required is 4 (ADC) X 16 x 2 (LVDS) = 128 pins, thats for input only (ADC), i guess for RAM requires the same pins amount, so total 256 pins, excluding other pins for comm/command/synch etc... man!
this discussion has lead me to few app notes... google "lvds to fpga" (for my reference later)...
https://www.altera.com/en_US/pdfs/literature/an/an479.pdfhttps://www.xilinx.com/support/documentation/application_notes/xapp1071_V6_ADC_DAC_LVDS.pdfbut not quite ADC->FPGA->RAM thing. anyway this is good when we have somebodies helping shoulder to shoulder, thanks guys.