Guesstimate request - ADC->FPGA->STM32F4->Ethernet->Master - Page 1
Forum section: electronics / projects

author: daqq
author_rank: Super Contributor
timestamp: March 20, 2015, 11:31:07 am
content: Hi guys,I would like to ask you for a guess whether this is feasible or not:Assuming a measurement device:A 100MSps ADC feeds a Xilinx FPGA with raw data. The FPGA prechews this data (filtering, decimation, simple stuff) resulting in about 2 MB/sec max. The ADC also does some trigger like stuff - the stream is not continuous most of the time. The FPGA would send some simple handshaking signals to the STM.The FPGA is the data source for an STM32F4 device. This is a dedicated device, its responsibilities would be:Converting the FPGA input to a UDP (or TCP?) output. It would then send these packets through a dedicated Ethernet into a master device (a PC).Receiving simple command packets (set trigger level to X and such) and sending these to the FPGA through a low speed channel (SPI probably).The master device is a PC.My questions are:Is the STM32F4 line up to the task?What would be the best way to connect the STM32F4 device to the FPGA?While this might seem the ideal thing to use a ZYNQ in, we are limited to using non-BGA devices and also, there's the problem of ZYNQ requiring more housekeeping just to keep enable its existence.Thank you,David

author: Jeroen3
author_rank: Super Contributor
timestamp: March 20, 2015, 11:49:09 am
content: You can hook up the external bus of the STM to the FPGA using it as external addressable peripheral.

author: 6thimage
author_rank: Regular Contributor
timestamp: March 20, 2015, 12:20:26 pm
content: I don't have any experience of using the STM32F4 for ethernet (although, with it running at 168/180 MHz, I would be very surprised if it couldn't manage 2 MB/s). I would use SPI to connect the FPGA and microcontroller together as it would allow the DMA controller to be used. You could always use the external RAM interface, but for 2 MB/s SPI is more than capable.My real question is why are you using ethernet and the STM32F4 in the first place. If your end goal is to get the data onto a computer, why don't you use USB?FTDI's FT232H can manage 8 MB/s and is fairly easy to interface with as an async fifo. The FT2232H is a bigger device that is used in a lot of development boards for both programming the FPGA and for FPGA<->USB communications. So could you save yourself a lot of effort by using USB rather than ethernet?

author: scatha
author_rank: Regular Contributor
timestamp: March 20, 2015, 12:30:40 pm
content: If you have sufficient resources on the FPGA a softcore might be an option - for example the Ettus USRP N210 uses a (relatively) puny ZPU softcore on a Spartan 3 to handle management/data streaming and yet comes close to being able to saturate a gigabit Ethernet link.

author: daqq
author_rank: Super Contributor
timestamp: March 20, 2015, 12:56:50 pm
content: Hi,QuoteI'll look into that option, thanks! But it seems to invite extra requirements for the FPGA, and I already need a CPU there (outside of the FPGA) for some miscellany stuff. While it probably COULD be jammed into the FPGA, it would just complicate things I think.QuoteI'd love to really, but: distance, drivers and integration into existing software/infrastructure require the use of Ethernet.

author: Jeroen3
author_rank: Super Contributor
timestamp: March 20, 2015, 02:02:26 pm
content: Using UDP broadcast works fine if ethernet is the medium of choice for interfacing a bunch of sensors to a dedicated control PC. Just hook up a switch and you can attach a large number of sensors. This is done with some industrial camera's. This even works on auto-ip self-configured NICs.If you want to use it on existing networks a control TCP socket and a data UDP socket might be a better option.

author: daqq
author_rank: Super Contributor
timestamp: March 20, 2015, 02:05:35 pm
content: Jeroen3: Thanks - it'll be completely dedicated to two of these devices, and a master PC, with a switch in the middle.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 20, 2015, 02:07:22 pm
content: Hi,I have transferred such raw ADC data over Ethernet with FPGA only (+ Ethernet MAC/PHY chip) - I didn't feel I would like to add a CPU. I also did some basic data processing on FPGA.Some of the work was done at a university by a coworker and me in 2010-2011, and as it is open-sourced under GNU LGPL, you can get it here:http://www.tkt.cs.tut.fi/research/nocbench/download.html, specificallyhttp://www.tkt.cs.tut.fi/research/nocbench/data/trace_monitor_release_package_10_2011.zip(Disclaimer: I don't have time to provide much support, so I just hope you'll find these helpful as-is.)The zip has a nicely working UDP/IP implementation in VHDL. It's kind of usability oriented, the interface is not too complex and it doesn't require much configuration. There also is a controller for DM9000A 100M Ethernet MAC/PHY IC, which, however, is not a sane choice today - you are better off getting a gigabit ethernet MAC from Opencores, or doing you own (last time I checked, Opencores didn't have any usable HW oriented ethernet MAC implementation) and then just use a gigabit ethernet PHY chip.Using a CPU as a middleman in a data pouring application, only for the integrated Ethernet MAC in the CPU, is IMO not sane -- ethernet MAC is extremely simple to implement on FPGA, even if you need to Do It Yourself! If there are any control needs where a CPU is best suited, then a softcore on the FPGA makes a lot more sense. In my cases, the control side has always been simple enough so that VHDL state machines were easier than using a CPU.In addition to the university project described in the URL above, my personal project was a film scanner with a 2Kx1 line CCD, 14-bit 25Msps ADC with CCD timing generation and basic image processing on FPGA (+ LED & motor control). The reason DM9000A ethernet MAC/PHY was used in these projects is that Terasic Altera DE2 development board uses that; even though the chip is CPU-oriented.

author: langwadt
author_rank: Super Contributor
timestamp: March 20, 2015, 02:50:58 pm
content: Quote from: daqq on March 20, 2015, 11:31:07 amYou could just get a zynq module like the microzed, then you don't have to mess with bga and you have a workingsystem out of the box. I don't see it requiring more in terms of house keeping, it runs linux out of the box

author: daqq
author_rank: Super Contributor
timestamp: March 23, 2015, 06:00:08 am
content: Hi guys,Thanks for the info so far.QuoteI meant that it's rather tricky to design a system with a functioning ARM9 processor - adding DDR RAM and stuff isn't trivial. But you are right, I could use a module. I'll look into those, but I'd rather design the system my self.Siwastaja: Thank you, very nice project. I'll look into it. The main reason why we'd rather not implement more than necessary inside of the FPGA is that we have limited experience with FPGAs, and we'd like to use a small FPGA (Spartan 6, one of the lowest ones, in TQFP package). I'm not sure the Ethernet controller would even fit inside.Thanks guys!David

author: Siwastaja
author_rank: Super Contributor
timestamp: March 26, 2015, 01:44:40 am
content: Quote from: daqq on March 23, 2015, 06:00:08 amI'm quite sure that the mentioned UDP/IP implementation plus any somewhat sane MAC implementation (MAC being even simpler than UDP/IP) will fit even in the smallest FPGA chips. I don't remember the exact numbers and I have worked with Altera products, but I think UDP/IP + a MAC would require about 2500 Altera Logic Elements or about half of the smallest Altera FPGA available.Limited experience is a good reason, however, and it may be easiest to use a CPU with necessary DMA capabilities that can handle direct data transfer from the ADC to the memory area used as ethernet TX fifo.