I am working with high speed ADC (200/250MSPS) to sample the signals and connect it to stm32f429 microcontroller.
How is it possible to handle such high speed ADC's as it cannot be directly connected to stm32? Can I use DSP or FPGA in between? How should it be done?
Thanks in Advance.
Not only you can use an FPGA but you have to!
The AD9601 is a 200/250 Msps ADC, and the max clock rate of the stm32f429 is apparently 180MHz.
So you have to interface the AD9601 onto an FPGA, preferably a Xilinx one :-) , and perform a downconversion to keep the frequency band of interest.
Then you have to connect your FPGA to the stm32... Which interface? Enough for the bandwidth you want to process?
My biased view is to stay on the FPGA or preferably on the XILINX ZYNQ device (or Zynq Ultrascale+) you would have enough processing performance and actually much more than you can hope. All the programmable logic can be used to do some dataflow processing, and the low sampling rate processing can be done on the embedded processor (dual Cortex-A9 [Zynq] or quad Cortex A-53 [Zynq Ultrascale+]). It will cost more than the stm32, but you have the FPGA and the processor in one device, leading to simplified and lower cost PCB, and you don't have to bother about the connection between the FPGA and the stm32.
You meant using FPGA with an embedded processor and not required to use stm32?
Yes. Zynq parts are processors that have an FPGA part tightly coupled.
These are processors because you can start the Processing System (PS) without having to program the FPGA part aka Programmable Logic (PL)
You can use the PL for interfacing with the external world and/or as accelerators of the PS.
On the Zynq-7000 part There are 4 links on 64 bits that can be run at 150MHz or 250MHz depending on the device. There is also an Accelerator Coherency Port that is directly connected to the L2 cache of the PS.
Zynq Ultrascale+ PS-PL connection is even more performant with links on 128bits and up to 333MHz
Las but not least, you can also have Zynq Ultrascale+ components with integrated very high speed ADC and DAC called Zynq Ultrascale+ RFSoC.
The caracteristcs of the ADC and DAC are well above your needs, and I suppose the price won't fit your wallet!!
Thank you so much.
Truly helped me to get an idea and proceed.
I think the most direct answer to your question is that you could buy the smallest, cheapest FPGA on the market and use it to simply deinterleave (split) your samples to a wider bit-width, at a lower sample rate. Many options may be possible, depending on the available I/O on your microcontroller.
As a simple example, imagine that your ADC produces 11-bit samples at 250 MSps, then the FPGA could pack this into 32-bit blocks, which it would need to output at an average rate of 250M*11/32 = 85.9375 MSps to avoid overflow.
You would use a FIFO in the FPGA to absorb any fluctuations in the rate at which the microcontroller can consume the data.
The problem I see is how to process a stream of samples @ 250Msps using a processor @180MHz.
The FPGA should at least perform a downconversion.
"The problem I see is how to process a stream of samples @ 250Msps using a processor @180MHz."
"The FPGA should at least perform a downconversion."
But no reason to stick to Xilinx parts. ALTERA/Intel parts also have FPGA fabric plus Cortex-A class CPUs inside. Similarly, Microsemi/Microchip has FPGAs with Cortex-M class CPUs inside.
Use what suits your needs best.
But true: raw 250 MSPS can not be processed with a 180 MHz Cortex-M4 class MCU.
I work for Xilinx! And I should have indicated it at the beginning.
That's why I wrote in my first reply:
So you have to interface the AD9601 onto an FPGA, preferably a Xilinx one :-) ,
My biased view is to stay on the FPGA or preferably on the XILINX ZYNQ device (or Zynq Ultrascale+)
And yes, Intel part could be used (Aaaarrrgghhhh your killing me!!!) and other vendor are also suitable.
Well, if you knew which semiconductor vendor I work for... And is none of the ones mentioned here! :(
Hopefully it gives some guidance to Yash5.
A tangent ... I used to work so closely with TI that it felt like I worked there. Weekly even daily dialogs about various projects and efforts. Intel was the enemy. But TI killed their c66x multicore CPU devices, which we were putting into servers on PCIe cards and competing with Nvidia in HPC and deep learning. In doing that TI continues a long tradition of "TI not inside" servers. That worked 10-20 years ago, but for today's product development it means they are not participating / not engaged in deep learning. That's unfortunate as deep learning is directly adjacent to DSP. They were right there in 2012-2015, they had a great chance. Instead they will leave multi $B revenue on the table for ... others, maybe you guys.
So now I advocate for Intel. I like some of what they're doing with Altera, such as server acceleration and FlexRAN. If you can't beat 'em, join 'em :-)
Now that is time to confess, full disclosure:
For long time I worked very close with Analog Devices, mastered their entire line of DSPs (ADSP-21XX, SHARC, Blackfin, TigerSHARC). And I still love them.
That experience brought me to Germany, where for the last 8+ years I've been working at Renesas. Topic is ADAS with the R-Car family of SoCs (look for Renesas V3M abd V3H), focus being Smart Camera. In that arena, your beloved Intel and TI (among others) are the of course also serious contenders.
Really interesting times we are living in!
Yes former DSP guys migrating en masse !
As Mr. Miyagi would say, you guys have "good chance", probably very good. TI can't win those seats because ADAS guys start with servers (everything starts with servers) and decisions are made early on about the embedded platform and how to port, compress the model, plan for CICD, etc. At least that's what I'm seeing with our customers in Dallas and San Jose. Deep learning is relentless in its never-ending requirements for training, augmentation, incorporating new R&D ... Whoever has the smooth path between servers and embedded -- both directions -- is what customers are looking for.
Yes, Some FPGA or IGLOO (CPLD) you have to put.
Max interface speed you may get with ST Microcontroller is with DCMI interface (80 MHz, 8bit) so thats what you connect.
But even at this reduced rate ST processor can not process the data in real time (whatever you might be trying to do, even if throwing packet out on ethernet).
Only option is to go go non-realtime data processing or reduce the sampling rate to the extent you can handle inside FPGA/CPLD
[editing to correct the data rate descripancies]
here is my 2 cent - here, you at least two problems to solve:
a. interface high speed ADC to a low-power ARM.
b. bring the ADC data into a rate which the processor can handle.
This may require an FPGA which performs highspeed data capture and mix, possibly a CIC decimator, like, as in xilinx zynq as described by oliviert.
If you're looking for low-power FPGA, the lowest power FPGA with an ARM core i know is QuickLogic's EOSS3. for you may have to use a ADC which can perform mixing and decimation to get the I/F. The I/F then interface to the stm32 for the 'real' processing through a QuickLogic's EOSS3. Hope the EOSS3 IO pins can handle the I/F rate at the sample width of 10bits. this may not help you as you have to move to ADC with downconvertor such as AD968x or so.