truni

Using FPGA - Am I right to do so?

17 posts in this topic

Hi All

I am currently running through the beaglebone tutorials online as well as completing the Derek Molloy "exploring beaglebone" book.

I want to create a project over the next year or so which will have the following requirements:

1. Connectivity to a PC, via wifi and Ethernet/USB

2. Possible lcd panel integration (tbc)

3. Expansion (maybe more than one real time "peripheral" connected into "slots" on the main pcb

4. Real time data acquisition

My thoughts are to use the beaglebone as the "hub", where the data from the real time units are sent. The beaglebone would take advantage of its linux os to provide high level user interface programming and connection to the outside world.

The FPGA would be used to sample the input signals (probably via adcs), perform some signal processing and pass the "computed results" over to the main "hub"

Am I thinking correctly here? Would the fpga be a good solution to the real time "sampling" and signal processing?

As an example, imagine wanting to sample an adc at 500ks/s (50hz waveform) and transfer the rms value to the main PC every 20ms.... So the transfer rate to the main hub would be low whilst he fpga handled the heave maths...

Am I on the right track? If so I will continue on this route of research :-)

And of course... Buy a Papilio!

Thanks!!

Share this post


Link to post
Share on other sites

While I'm a huge fan of FPGAs, what you want to do might be an excellent fit for the BeagleBone's Programmable Real-time Unit (PRU) Sub-System (PRUSS).  In addition to its ARM Cortex-A8 BeagleBone's SoC has two 200 MHz RISC processors for real-time I/O and signal conditioning.

 

Here's a good starting point: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui

Share this post


Link to post
Share on other sites

Hi john

 

Thanks for the response

 

Yes I have considered the PRUs, but I thought this would limit be with regards to expansion.

 

If I can install expansion slots on the main PCB which all run on one bus of some description, then this will help with expand ability. What do you think?

 

I could run an SPI bus or something similar, or I2C... I have not crunched the numbers yet but as the raw samples won't be on the bus (only computed results at max 1ms intervals) then I think even an I2C bus will be fine..

 

Interested to hear your comments..

 

Thanks!

Share this post


Link to post
Share on other sites

My friend built a power monitor using a cheap AVR microcontroller with the internal ADC sampling the AC line and producing a graph of the current waveform. It also calculates the RMS value in real time and that's a ATMEGA88 running at 8MHz.

 

You could use a FPGA, but that's sort of like using a sledge hammer to drive a small nail to hang a picture.

Share this post


Link to post
Share on other sites

Hi James

 

You want to see the walls in my house, smashed to bits;)

 

That is true, but I want to ramp up the sample rate for maximum bandwidth....

Share this post


Link to post
Share on other sites

Hello Truni,

 

Here is my take on this, use the FPGA if you need to capture high speed signals or you want a platform that you can always overcome limitations with. FPGA's are flexible enough to solve any type of problem, but it is going to be more difficult to do with an FPGA. If you can find an easier solution with another platform that solves all of your problems then I would go with that option. 

 

Now, having potentially pointed you to another platform for this project you are working on, which is the right thing to do, let me make the case for learning about FPGAs too. I think everyone in this forum can attest to the amazing feeling of satisfaction you get when you build a circuit on your computer that comes to life on an FPGA board and does something you couldn't do any other way. In short, it is very worthwhile to learn FPGA technology because at some point it is going to enable you to do something you can not do with any other platform...

 

Jack.

Share this post


Link to post
Share on other sites

Hi Jack

 

I appreciate the response, thank you for the advice.

 

I will continue on my quest to master linux (which 4 weeks ago I knew very little about)

 

I will make sure I know what is possible with the PRU's before I do anything else.

 

I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs, I am worried that I will run out of processing power with the beaglebone PRU's... But that is a naive assumption as I do not know enough about them....

 

More reading and learning about the limitations of the beaglebone before committing.

 

Out of interest, how would you interface the FPGA to the beaglebone?

 

I2C? SPI? Direct memory?

 

Sorry for the stupid questions...

Share this post


Link to post
Share on other sites

"Out of interest, how would you interface the FPGA to the beaglebone?"

Preferrably SPI.

"I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs"

Why not ? your sampling rate is quite small. I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless.

 

Analog muxers are cheaper than ADCs.

 

You can use the FPGA to control all this and present all ADC data on SPI bus (either master or slave) to main CPU in case you are worried. You can also do RMS computations on FPGA (as well as other goodies).

 

Alvie

Share this post


Link to post
Share on other sites
Out of interest, how would you interface the FPGA to the beaglebone?

 

I2C? SPI? Direct memory?

 

For talking to a Papilio I agree with Alvie that SPI is the way to go.  While I suppose it's bad manners to mention other FPGA boards here, you might want to check out the ValentF(x) LOGI-Bone, which is a Spartan-6 LX9 FPGA board that plugs directly into a BeagleBone.  This gives you the option of treating the FPGA as a 16-bit wide memory using BeagleBone's General-Purpose Memory Controller (GPMC).  You also have SPI and I2C.  LOGI-Bone is a nice solution provided you don't have to separate the boards too often since it's a pain to pry those connectors apart.   

Share this post


Link to post
Share on other sites

@johnbeethem: heh, just tell me if you want a wider bus (quad-spi, 8-bit spi). :)

Just make it synchronous. Is GPMC synchronous ?

Asynchronous [parallel] buses are long dead. It's faster and more reliable to use SPI on let's say 80Mhz with a quad-bus (yielding 40MBit/s) than using plain asynch stuff.

i2C is so slow no one uses it unless a shared bus is required (cause CAN is still encumbered by Bosch's patents).

Share this post


Link to post
Share on other sites

"Out of interest, how would you interface the FPGA to the beaglebone?"

Preferrably SPI.

"I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs"

Why not ? your sampling rate is quite small. I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless.

 

Analog muxers are cheaper than ADCs.

 

You can use the FPGA to control all this and present all ADC data on SPI bus (either master or slave) to main CPU in case you are worried. You can also do RMS computations on FPGA (as well as other goodies).

 

Alvie

Thanks for the advice, I may end up sampling at 1MHz per channel, do you consider that low frequency?

The data will then be transferred at around 1kHz (max data transfer of around 100 bytes or so per transfer)

As you can imagine, at this stage of my learning curve I have millions of questions and lots of research to make.

Good job I have an understanding wife!!!

For this project there aren't any serious cost saving requirements so I figured I would use sledgehammers ;-)

Thanks for all advice...

Share this post


Link to post
Share on other sites

For talking to a Papilio I agree with Alvie that SPI is the way to go.  While I suppose it's bad manners to mention other FPGA boards here, you might want to check out the ValentF(x) LOGI-Bone, which is a Spartan-6 LX9 FPGA board that plugs directly into a BeagleBone.  This gives you the option of treating the FPGA as a 16-bit wide memory using BeagleBone's General-Purpose Memory Controller (GPMC).  You also have SPI and I2C.  LOGI-Bone is a nice solution provided you don't have to separate the boards too often since it's a pain to pry those connectors apart.

Hi John

I have considered the Logibone but heard that you guys on this forum are more help and friendly ;-)

I have certainly found that to be the case here :-)

The GPMC is something I will certainly look into!

Thanks!

Share this post


Link to post
Share on other sites

Just make it synchronous. Is GPMC synchronous ?

Asynchronous [parallel] buses are long dead. It's faster and more reliable to use SPI on let's say 80Mhz with a quad-bus (yielding 40MB/s) than using plain asynch stuff.

GPMC can probably be used synchronously, but I suspect most people use it to talk to async devices such as SRAM and NOR Flash.  If async buses are dead, I guess it was a bad idea to put asynchronous SRAM on Papilio DUO, eh?  :)

 

Seriously, an async parallel bus is still a good way to talk to lots of peripherals and has the advantage that you don't need a device driver -- you can just use mmap().  This can be an important feature for a Linux newbie who doesn't want to become a device driver guru.  The Spartan-6 LX9 has lots of dual-port RAM, so an effective way to do data acquisition is to store inbound data to one side of a dual-port RAM and have the other side talk to the CPU.

 

"Long dead" reminds me of an early unix "man" page for assembly language.  IIRC, the page read "Assembly language is dead.  Necrophilia will be punished."  Funny, you don't see that page any more if you enter "man as" ;)

Share this post


Link to post
Share on other sites

I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless.

 

 

And I happen to work on a system that samples up to 1024 analog signals each 16-bit at 30 kHz sampling rate using up to 16 ADCs, each with a 64 ch mux :)  All done with an Spartan6 LX16 and streaming the data out using a TMDS link (i.e. like HDMI but just clock and data) at 78.6 MB/s. using regular HDMI connectors and cables.  For something like this you definitely need an FPGA.

 

Here is a picture of a 640 ch system. FPGA board to the right with micro-HDMI connector for power and data, 5 ADC boards in the middle, each with 2 ADCs (i.e. 128 ch each), and LVDS terminator board to the left.  The ADCs are connected to the FPGA using SPI with LVDS signaling (CS, CLK, MOSI, 16x MISO).

 

640ch.jpg

Share this post


Link to post
Share on other sites

For more info see:

https://www.llnl.gov/news/nih-taps-lab-develop-sophisticated-electrode-array-system-monitor-brain-activity

 

The NIH project is a collaboration between LLNL's Neural Technology Group; the laboratory of Loren Frank at University of California, San Francisco (UCSF); Intan Technology; and SpikeGadgets.

 

Housed at the Center for Bioengineering, the Neural Technology Group will work with UCSF researchers to design and build electrode arrays that can record hundreds to thousands of brain cells simultaneously. Their goal is to develop 1,000-plus channel arrays that can eventually be expanded to 10,000 channels.

 

These arrays will use new microchips designed at Intan and will send data to a system developed at SpikeGadgets. UCSF will coordinate these efforts and test the technologies. The arrays will penetrate multiple regions of the brain without interfering with normal functions during the experiments, allowing for detailed studies of brain circuits that underlie behavior.

 

"This collaboration combines the engineering talent of LLNL with UCSF's expertise in neural recording and modulation systems, and the design and programming skills of Intan and SpikeGadgets," Frank said. "The result will be a system that will help us understand how different brain areas communicate and carry out complex mental functions."

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now