Single Board Computer (SBC) suggestion for interfacing with DMA

Question

I am taking over a project where a Spartan 6 FPGA provides the interface between an ADC and a DDR2 memory chip. The FPGA takes 16-bit data out of the ADC and stores it into the RAM at a rate of 28MHz.

I have the option of making the DDR2 controller multi-ported so that a processor can access the DDR2 memory and begin analyzing it. Ideally I would like to find a COTS single board computer ( SBC ) for under $150 that has Direct Memory Access ( DMA ) available for an off board connection to the memory. The SBC would eventually run some type of Linux distribution so it would have to be more powerful than a standard micro controller.

This is kind of stepping out on a limb for me, since I have previously developed using PIC's or Xilinx Microblaze where I designed the entire board. I'd like to move up to running Ubuntu on an established board, which is why I took this project on.

Just hoping I can get some suggestions and let me know if there are any details I am not clear on or if I should be posting in a different forum. Thanks!

Answer 1

Your numbers suggest a bandwidth of roughly 53.4 MB/s (MegaBytes!). This makes me wonder about the requirements for the rest of the system given that you want to add the overhead of a heavy Linux OS like Ubuntu on top. For what it's worth, there are some SBC Linux boards that offer DMA to a memory card reader to achieve somewhere in the neighborhood of 6 MB/s - this figure probably does not take protocol overhead in to account so the actual data throughput is probably less. Your calculation however, is all raw data, which adds even more to the challenge.

I'm curious to know what kind of application requires that high of a sampling rate - I can imagine something like high frequency radio transceivers need something this fast (or faster) but I won't speculate as to what you're using this for - high speed data acquisition (if this is even really considered high-speed) is not within my knowledge.

Given the bandwidth requirement, what I would do is start with a computer peripheral bus that is capable of moving that kind of data.

• PCI: 133 MB/s
• PCIe (1-lane, gen1): 250 MB/s
• If you're willing to decrease your sampling rate, USB 2.0: 480 Mbit/s (effective throughput up to 35 MB/s)

These figures may or may not include protocol overhead, so keep in mind that your calculated required bandwidth is already pure data and may require much more than 53.4 MB/s considering protocol overhead.

For now I'm going to forget the requirement of an SBC and suggest a full blown PC. After choosing the right bus, now you have the pleasure of implementing your own peripheral card to plug in to a typical PC capable of running Ubuntu. You'll have to write a linux driver for your custom PCI/PCIe/USB device too. I'm hoping someone replies with a nice SBC that exposes a memory bus with DMA instead... the above solutions will surely be a challenge.

By the way, what was already processing the data after the FPGA in the first place? Was it not good/flexible enough?

Answer 2

I think you've painted yourself into a corner here. There are Linux-capable boards for less than $150, but none that I know of bring a memory bus out to an external connector. There are boards that do have such connectors, but they're much more than $150.

The closest thing I can think of would be a "Blackfin Stamp" board. The Analog Devices "Blackfin" family of DSPs can run ucLinux, and have, among other things, a high-speed PPI (parallel peripheral interface) that can handle video data. But I'm not sure if these boards are still generally available.

But normally for this type of application, you'd have the FPGA and processor integrated on the same board. Several manufacturers make boards like this, such as Technologic Systems.

Answer 3

Thanks for the advice regarding the different peripheral bus options. I re-read my original post and I realized I left out a critical piece of information. My apologies. The ADC is pulling data from an image sensor at 28MHz and an image is being taken about once every 30 seconds. Meaning once data is stored, it can be transferred out at a slower rate. My original hope was to connect the RAM bus to the SBC so that I wouldn't have to re-copy the data to the SBC, but this is looking like it might not be possible with a cheaper board.

If this is the case, I think a DMA interface is not the best way to go.

If you only need to pull the contents of the DRAM every 30 seconds, you have a LOT more flexibility.

I think the cheapest, easiest way to go would just be to slap a Raspberry Pi in there. Tie it into the FPGA through a SPI interface (there is a hardware SPI connection brought out in the GPIO of the PI), and with a clock rate of a few megahertz, you should have plenty of time to read out your image data.

---

Now, assuming you're building the FPGA interface in-house, and don't mind making some modifications, I would suggest re-designing the FPGA board with a Xilinx Zynq microprocessor.

The Zynq 7000 family incorporates an extensible processing platform into devices to address high-end embedded-system applications, such as video surveillance, automotive-driver assistance, next-generation wireless, and factory automation. Zync-7000 FPGAs integrate a complete ARM Cortex-A9 MPCore-processor-based 28 nm system. The Zynq architecture differs from previous marriages of programmable logic and embedded processors by moving from an FPGA-centric platform to a processor-centric model.For software developers, Zynq FPGAs appear the same as a standard, fully featured ARM processor-based system-on-chip (SOC) that boots immediately at power-up and can run a variety of operating systems independently of the programmable logic.

Basically, you use the FPGA fabric to read-out your image sensor, and then make it available to the CPU over a local DMA channel. All in the same IC.

There is a dev-kit you could do testing with called the ZedBoard.