Newbie project - DSO with high speed ADC, FPGA, DDR2 (3) and MCU

[Altera_Forum]

Hi everyone, 

  I have been working with AVRs and C/C++ for quite a few years and everything looked pretty much straightforward as i used CodeVisionAVR and did not have to dig in the manual of every uC i worked with. Recently i started a project (http://www.youtube.com/watch?v=73ygbq9wq_m) with a STM32F4 discovery board aiming to build a DSO with high speed ADC 16bits (100-250Msps) and a few (tenths) megabytes of memory to store the captured values. As i finally concluded, after googling a lot and asking for help in chat rooms, the most obvious solution was to use an ADC, connect it to a FPGA, connect a RAM chip to the FPGA and optionally also connect a uC such as the STM32F4 to the FPGA or just use Nios II as uC (depending on the CPU power needs of the app). In order to get to know a little bit about FPGAs, i bought a DE0-nano which was perfect for my case as it carries an ADC, a Cyclone IV, 32Mbytes of SDRAM and some sensors, leds, buttons etc. I was able to play a little bit with the leds and buttons based on a Nios II configuration but that was pretty much all i did. So, as i am not experienced at all with FPGAs and don't have a clue about coding in Verilog / VHDL or even thinking in terms of parallel processing, i would like to ask for your suggestions as far as my project is concerned.  My thinking is that an ADC 16bit 250MSps connected to a FPGA and a DDR2 or 3 will do the trick. The thing is that i have no idea where to start from. I know that a FPGA does have a huge advantages package that includes interfacing different types of levels such as LVDS (ADC), TTL/CMOS (uC) and memory chips at the same time which is fantastic. However, even though i used the Quarus 13 software not for writing my own HDL but using the MegaWizard, i have no clue which IPs to use and how in order to interconnect the ADC, DDR mem and probably an ARM uC such as a STM32F4. As far as i know the speed of 250Msps plays a huge role of whether selecting a Cyclone FPGA or a faster one. There will also be issues with the timing of the memory while capturing at 250Msps and so on. As i read, simulation must be done before proceeding with anything but of course after writing the HDL that will bring all these parts together.  - The ADC will be dual at 16bits 250Msps. The output of the ADC will be LVDS parallel (not serial). That would propably be the important key when considering which FPGA to use. Which do you think suits this project? - I was thinking about using a memory chip close to 64Mbytes so that i can always run the ADC at max rate and still be able to show on my LCD low frequency signals by compressing time axis as well as doing other things that only very expensive DSOs do. Is there a memory like that when it comes to DDR2/3? - Will a Nios II CPU be able to process fast enough the data from the memory? Not the whole 64Mbytes. For example, the RMS value of a signal would require (assumption) 10K samples to be calculated with a decent accuracy. Would such a CPU be able to draw fast enough on a 800x480 16bit TFT LCD via DMA? - What should i be reading right now? Verilog?    I know that specific answers require specific questions but the point where i am right now is anything but guess-safe.  Thanks for reading.   Any suggestions are welcome.  Manos

[Altera_Forum]

Hi Manos: 

 I would look at the SoCKit from Terasic for a project like this versus the DE0. It has dual Arm Cortex A9 cores running upto 800 MHz, plus a HSMC connector for attaching the ADCs.  Terasic doesn't have a HSMC adc board running at 250 Msps, but they do have some 14 bit adc boards running 150 Msps. If you have a specific ADC you are looking at, see if they have a dev board that attaches to an HSMC connector. I know many of the ADC vendors either have it already or they have a HSMC to their board adapters already.  Can you do this with Nios? Yes, but it will not run as fast as the ARM. Can you draw everything fast enough? Not at 250 Msps. But at some reduced rate yes.  The SOCKit gives you 2GB of DDR 3 to play with. So you can do a lot with it. Start playing with QSYS. Most likely you will have to write at least some of the hardware yourself to get it all to play nice...  The ADC to memory interface is what probably will not be there for you. You should be able to use QSYS to get the basic system up and running, and add on all the basic IP cores required for the SOC portion. But you will have to write the ADC interface, and make it compatible with the standard DMA controller. Writing samples at 250 Msps is not trivial, so it will take some work.  Pete

[Altera_Forum]

Hi Pete, 

  Thanks so much for your time to answer to my post. The way i see it is that using a Nios II configured FPGA is an all-in-one solution because this will save some money and time as well design effort integrating an additional ARM uC. You told me that a Nios processor would not write fast enough to the memory to keep up with the 250Msps expectations of mine. In fact, i do not expect the cpu to perform anywhere near that. What i was thinking was implementing, in the FPGA, a direct ADC to Memory controller with near-full and/or full flags so that in some way the capturing will stop on even a custom level of the memory completeness. After that, the Nios cpu will process the data by having access to the memory via another CPU to RAM controller. In this way the cpu will not have to strungle or bother with the capturing process. After the Nios cpu processes data captured and updates the LCD with the new data cycle, it will trigger a new capture by accessing the first FPGA controller (ADC to Memory). Talking about LCD update, i was thinking that i want to keep a high rate of display update, regarding the waveform, over 15-20 FPS mostly at high frequency content as measuring 50Hz with a 20FPS rate is not possible by nature. That is why i purchased a RA8875 based LCD (http://www.buydisplay.com/default/5-800x480-tft-lcd-module-touch-display-w-controller-i2c-serial-spi.html) that has amazing (supposingly) specs like drawing lines and other shapes just by passing the coordinates of your choice to it and it then uses no cpu to draw the line as well as doing other stuff with no cpu overhead.  Please see the attached block diagram and kindly comment on whether my thinking is anywhere near a doable implementation inside the FPGA.  Awaiting your comments.  Regards Manos

[Altera_Forum]

Hi Manos: 

 The Cyclone V series has the SE, SX and ST flavors that have dual ARM A9 hard cores already built in. So you get a higher performance CPU already in the FPGA, with out using any additional fabric. (It also has hard memory controllers, and PCI controllers depending on the exact device)..  For a performance SOC design, this is the way to go, because you get the performance of a A9 with no LE requirements. This allows you to use all of your LE's for your non CPU pieces.  At 250 Msps, in Cyclone III/IV, you will probably be fighting timing issues.. That's pushing the performance of these families.   I currently have a design running in Cyclone II at 102.4 Msps (barely). We just recently moved to Cyclone V. There was a push to move to 204.8 Msps, but we advised against it even in Cyclone V. There requirements didn't merit the 200+ Msps, and it was just additional pain, for no appreciable gain.  They had multiple display requirements, as will as a high update rate requirement, We ended up going with a IMX6 + Cyclone V E family combination. The SE family wasn't out at the time, so it wasn't a contender, but even if it was, we probably would have still gone with the IMX6, because of the 3 displays.  Everything is always a trade off. I haven't worked with your particular touch panel, but in general your block diagram will work. The questions comes in will it be enough. The CPU still has to read every sample and send it to the LCD, if you can write the LCD frame buffer directly from hardware, that will give you much better performance. But it will also be much more difficult to implement.  Regards,  Pete

[Altera_Forum]

Hi Pete, 

  Thank you for your response. It was really helpfull to hear a pro's opinion regarding my case. I will probably go with the integraded ARM FPGA. However i have still got to overcome a ton of various obstacles mostly caused by inexperience and lack of FPGA knowledge.  Thanks again. Manos