FPGA application examples

[daqq]

Hi guys,

I'll be doing a presentation on FPGAs to a few hobbyists - the theme being mostly what they are, how can the be applied and how freakin' cool they are. I'm trying to come up with a few specific examples that robotics enthusiasts (though not all of them necessarily professionals) can relate to. In particular examples where an FPGA is shown to be the better (or only reasonable) choice. I'm trying to find applications in three* classes: low range FPGAs (some place you'd stick a Spartan 7 like device, or lower), mid range (some place you'd stick an Artix/Kintex) and the really really high range (top of the line UltraScale+ sort of thing).

I will mention the cloud and supercomputer things, but mostly as a side note.

So far I've got:

Low:
Multichannel analyzer - a fast 100Msps ADC was hooked up to a small FPGA that analyzed the signal and provided a peak height histogram. Just add a photomultiplier+scintillator and you have a gamma ray spectrometer.
Brains on a multislope ADC
Motor controller

Mid:
Serial port server - a SoC (Zynq) was used for a device that was pretty much a box full of serial lines (32 max IIRC) hooked up to an Ethernet connection. The ARM did the Linuxing and the networking, the USARTs were done on the fabric.
Test equipment - seen everywhere, scopes, logic analyzers, signal digitizers, chewing high speed data, doing triggering, acquisition etc.
Software defined radios
Ultrasound machines
High end audio DACs

High:
Supercomputer accelerator cards, HPC, networking
Real time large scale image analysis

I've had a few more, but removed them, as explaining where the FPGA/CPLD came into play would take a lot of time. I'll be scouring the Xilinx Xcell magazine for some additional applications as well.

Any suggestions are welcome!

Thanks,

David

[tunk]

I don't know anything abouts FPGAs, but this may be an example:
https://www.eevblog.com/forum/testgear/hantek-2c422c722d422d72/

[Mr. Scram]

Video is an obvious candidate. Those Tivo boxes tend to come with FPGAs so decoders and standards can be updated without changing the hardware.

[james_s]

I used to work at a company that made DVRs. Ours had a FPGA in them but it had nothing to do with the decoding, it was used as a crossbar switch to route video and audio between the tuners, recorder, local and remote TVs. I've never seen inside a TiVo but I'd guess it uses a similar arrangement.


As far as examples of what they can be used for, recreating retro hardware is what interests me. Keep in mind this is just a hobby for me, I have no formal HDL training so don't expect flawless code but it does work.

https://github.com/james10952001

[notadave]

Historically the most important high end application has been:
Emulation
That is validating new large-scale integration IC designs before "tape out".

[TomS_]

Those Tivo boxes tend to come with FPGAs so decoders and standards can be updated without changing the hardware.

I would put my money on them doing their decoding etc in software. Video standards dont tend to change often enough, and low cost mass produced consumer devices wouldnt exactly be the kind of devices that might be considered a long term investment warranting full upgradability. By the time the next major standard worthy of replacing your kit comes along, people will just buy new boxes.

Quick google, TiVo Bolt (seems to be the latest gen) looks to be more or less a single chip solution using a BCM7449, which looks basically like an SoC for set top boxes.

[legacy]

FPGAs can *potentially* also be used for emulating old-computers, like Amigas and even SGIs.
However, FPGAs cannot compete, in terms of effort and performances, to software emulation, especially when this one is made on JIT (Dynamic Re-compilation).

[amspire]

A relatively simple application that is a perfect example of a FPGA application is a logic analyser like the old, but still very useful Logicport 32 bit analyser.

https://www.eevblog.com/forum/reviews/intronix-logicport-34-channel-logic-analyzer-teardown/

It can capture 2000 samples directly at 500MHz, but more interesting is it can capture potentially for an unlimited time at 200MHz.

It only has room for about 2000 32 bit samples (probably pretty good for 2006), but what it does is it only stores the samples that include a change to one of the bits, and it records the time of those changes. So it can keep running for hours if necessary at 200MHz until there have been 2000 state changes following the trigger pattern. For many purposes, recording 2000 state changes is enough.

The interesting thing is it has comprehensive triggering as well as performing the compression. It is able to do all of this at 200MHz for 32 bits of data with a clock that is either 200 or 400MHz  by passing the data down a synchronous pipeline.

The cyclone chip easily has enough logic to pass the input down 64 or more synchronous stages while it is doing the trigger pattern detection logic, and implementing the compression. The 32 bits can move down this pipeline at 200MHz and all the triggering logic and compression logic can be done with zero effect on the sampling speed. This is one of the abilities of FPGA's that cannot be duplicated by a CPU.


I think the thing limiting sampling speed with this 2006-era FPGA is that the maximum speed you can run a 64 bit counter on this chip is 208MHz.

Richard

[voltsandjolts]

Before I turned on my Logicport 32 I took it apart!
Cyclone FPGA + FTDI, thats it.
Its a shame it hasn't been updated because the software works well, wouldn't take much to drop in a newer FPGA and FTDI.

[rstofer]

FPGAs can *potentially* also be used for emulating old-computers, like Amigas and even SGIs.
However, as being discussed here, FPGAs cannot compete, in terms of effort and performances, to software emulation, especially when this one is made on JIT (Dynamic Re-compilation).

No potentially about it!  I built an FPGA emulation of an IBM1130 computer system and all of the peripherals (CPU, Line Printer, Card Reader, Typewriter, Keyboard and Disk) and it runs the factory OS and compilers unchanged.  I have used it for practical projects using Fortran including plotting to a LaserJet (versus the old drum plotter).

PDP11/70s running on FPGAs are all over the place.  Many are running 2.11BSD Unix unchanged.  AVRs and PICs have been done - check OpenCores.org.

I would have to think pretty hard about whether FPGAs can compete with a software emulation.  FPGAs are fast, if you have the money, and can do in one cycle what an emulation may do in several instructions, each taking one or more cycles.  As to effort, true, FPGA coding, at the bleeding edge, is quite difficult.  Running down in the 50-100 MHz range, it's pretty straightforward.  My 1130 runs at 50 MHz while the factory machine ran at 400 kHz and i can do a little cleanup (or porting) and get mine to 100 MHz.  I made no effort to keep my implementation 'cycle accurate' as I could easily throw more hardware into the mix to speed things up a bit.  With one of the Artix 7 chips, I could probably get to 100 MHz quite easily.  Someday...

FPGAs are the coolest toy on the planet!  You can pretty much build whatever you want as long as it is primarily in the digital domain.  Some FPGAs are incorporating ADCs (and DACs?) so a bit of analog is thrown in.

In terms of robotics, I might use an FPGA for a vision processor but I certainly would not use it to replace a uC running the motors and servos.  The entire mechanical system can run off one or more uCs and it would be far easier than creating specialized hardware.  Unless there is a reason a uC is inadequate.  There are some awesome uCs so I just don't see when an FPGA plays in this arena unless it's "just because".

[rstofer]

Or you can grab the T80 core from OpenCores, add in copies of the original PacMan ROMs and, with very little effort, you have a REAL hardware implementation of the classic games.  There are many others - check Google.

https://www.fpgaarcade.com/

And, yes, I have a very clean implementation of PacMan.  Galaga is another possibility.

https://www.fpgaarcade.com/kbtopic/games/

Of course, MAME does a nice job and there are thousands of jobs.  And, yes, I have a full size arcade cabinet with MAME.  I built mine with a period accurate CRT but it looks a lot like this one:

https://shop.xgaming.com/products/x-arcade-machine-cabinet-with-250-arcade-classics

FPGAs are quite useful for arcade games.

[SiliconWizard]

FPGAs can *potentially* also be used for emulating old-computers, like Amigas and even SGIs.
However, as being discussed here, FPGAs cannot compete, in terms of effort and performances, to software emulation, especially when this one is made on JIT (Dynamic Re-compilation).

I would have to think pretty hard about whether FPGAs can compete with a software emulation.

Well, I think it would really depend on a number of factors. First, whether the processor(s) core you're targetting already exists in RTL (or conversely in software), or if you have to design it yourself from scratch. So, that's about development time.

Then it would depend on part cost. The required FPGA may cost a lot more than the CPU you could run a software emulation on. Or not.

Then it would depend on target performance. For cycle-accurate emulation, a pure software emulation may not cut it, or could be pretty hard to write correctly, could involve disabling caches, etc (hindering performance...) whereas it's pretty straightforward with an FPGA.

Then it would depend on requirements for power consumption, if there is any. A pure FPGA solution may draw a lot more power than the software emulation approach. Or not. Really would depend on the complexity of the emulated hardware and the clock frequency...

Then again, the software emulation approach could get you "cheap" access to additional resources (like peripherals, ethernet, USB, whatever...) that could be tough (or costly if you have to buy IPs) to implement on an FPGA.

And probably many other factors.

But one thing is certain, developing a whole system including CPU + peripherals on FPGAs is fun and rewarding.

[coppice]

You listed SDR as a medium scale application. Try looking in a cellular base-station and you'll find the biggest application for large FPGAs is also SDR.

[laugensalm]

Then it would depend on requirements for power consumption, if there is any. A pure FPGA solution may draw a lot more power than the software emulation approach. Or not. Really would depend on the complexity of the emulated hardware and the clock frequency...

Keyword vision processor: I've hacked a MJPEG streaming camera 'SoC' a few years ago which consumes considerably less power than the multi core DSP variant of it. But it took some trickery to power-optimize.
I guess you can find a few more vision applications where you're better off with the FPGA - if you can parallelize and keep the clocks low.
In any case, many high throughput or low latency applications in industrial image processing depend on programmable custom logic, so industrial vision and special cameras is a main supporting pillar.

Another interesting application is the convolutional neural network field, Lattice Semi has demonstrated a few applications on the last Embedded World trade show. Not sure how the power comparison turns out there compared to a DSP implementation. I'd guess in favor of the FPGA.

But one thing is certain, developing a whole system including CPU + peripherals on FPGAs is fun and rewarding.

Actually, when it comes to tricky (time critical, or safety) applications, it can be the perfect solution for debugging down to the peripherals, the fully cycle accurate way. You can also prove that your program works right on another level. For example, many scenarios that could slip a MISRA-C source check turn out to go wrong in the simulation and might produce undefined results in the synthesized logic. Good, if you track this down early in development.

[rstofer]

Then again, the software emulation approach could get you "cheap" access to additional resources (like peripherals, ethernet, USB, whatever...) that could be tough (or costly if you have to buy IPs) to implement on an FPGA.

And probably many other factors.

But one thing is certain, developing a whole system including CPU + peripherals on FPGAs is fun and rewarding.

And software emulation is why 'simh' is so popular.  I have two PiDP11 consoles which are PDP11/70 clones running in simh on Raspberry Pi 3B+ processors.  These systems emulate a bunch of peripherals and the systems can be configured in many different ways.  In addition, the emulation runs a multitude of OSes although mine are running just 2.11BSD Unix.  These systems have a maximum memory configuration which very few real systems had (4 MB) and the emulation is faster than the real hardware.  These machines are FUN!  Especially if you like old-time Fortran and the vi editor.  As it turns out, they also make a half decent web server.

https://obsolescence.wixsite.com/obsolescence/pidp-11

There's something satisfying about a multiuser Unix system with the bare essentials and none of the bloat.

Of course there is also a simh emulation of the IBM1130

http://ibm1130.org/

[Bassman59]

Hi guys,

I'll be doing a presentation on FPGAs to a few hobbyists - the theme being mostly what they are, how can the be applied and how freakin' cool they are. I'm trying to come up with a few specific examples that robotics enthusiasts (though not all of them necessarily professionals) can relate to. In particular examples where an FPGA is shown to be the better (or only reasonable) choice. I'm trying to find applications in three* classes: low range FPGAs (some place you'd stick a Spartan 7 like device, or lower), mid range (some place you'd stick an Artix/Kintex) and the really really high range (top of the line UltraScale+ sort of thing).

One thing not mentioned in the other replies is basically what we do: roll up a shit-ton of logic that used to occupy several VME-style boards into a chip that occupies a square inch of board space. And this is all custom -- application-specific -- stuff that doesn't really fall into any of the categories noted here.

[SiliconWizard]

One thing not mentioned in the other replies is basically what we do: roll up a shit-ton of logic that used to occupy several VME-style boards into a chip that occupies a square inch of board space. And this is all custom -- application-specific -- stuff that doesn't really fall into any of the categories noted here.

Yup.
Maybe it wasn't mentioned because the OP targets hobbyists. Of course that could still interest hobbyists that are into recreating vintage computers for instance...

Generally speaking, with FPGAs you can do many things that once required either gigantic and power-hungry boards, or the design of ASICs, which was extremely expensive, and still is.

[daqq]

Thanks guys for the advice and examples! The vintage computer emulators are a great addition.

The 'compress several square meters of logic boards into a single chip' will be mentioned, but more in terms of how FPGAs came to be. A large board with chips will be shown, then a few of those will disappear, replaced by a single PAL IC. Then more and more chips will be disappearing as the programmable logic devices improve, eventually gobbling up a CPU and being left alone on a large, otherwise empty board.

[mac.6]

Historically the most important high end application has been:
Emulation
That is validating new large-scale integration IC designs before "tape out".

And they are still used for this *looking a the pile of FPGA on my left*

[james_s]

Those Tivo boxes tend to come with FPGAs so decoders and standards can be updated without changing the hardware.

I would put my money on them doing their decoding etc in software. Video standards dont tend to change often enough, and low cost mass produced consumer devices wouldnt exactly be the kind of devices that might be considered a long term investment warranting full upgradability. By the time the next major standard worthy of replacing your kit comes along, people will just buy new boxes.

Quick google, TiVo Bolt (seems to be the latest gen) looks to be more or less a single chip solution using a BCM7449, which looks basically like an SoC for set top boxes.

Almost all DVRs use Broadcom SOCs which have hardware MPG decoding built into them. I don't know offhand how the encoding is handled, that was not a part of the product I was closely involved in.

[switch998]

Those Tivo boxes tend to come with FPGAs so decoders and standards can be updated without changing the hardware.

I would put my money on them doing their decoding etc in software. Video standards dont tend to change often enough, and low cost mass produced consumer devices wouldnt exactly be the kind of devices that might be considered a long term investment warranting full upgradability. By the time the next major standard worthy of replacing your kit comes along, people will just buy new boxes.

Quick google, TiVo Bolt (seems to be the latest gen) looks to be more or less a single chip solution using a BCM7449, which looks basically like an SoC for set top boxes.

Almost all DVRs use Broadcom SOCs which have hardware MPG decoding built into them. I don't know offhand how the encoding is handled, that was not a part of the product I was closely involved in.

I was going to chime in with the same, most consumer grade set top boxes (even most industrial IRDs) use Broadcom SOCs to handle video. However, on the provider side where cost is no issue, it is likely the video is received, processed/ad-spliced/(re)multiplexed and QAM modulated using FPGAs.

[daqq]

Question, aside from ASICs, is there any other kind of IC that can read and do something useful with, say, the data from a 200 MSps ADC?

[rstofer]

Question, aside from ASICs, is there any other kind of IC that can read and do something useful with, say, the data from a 200 MSps ADC?

At such a low datarate, I would expect almost any FPGA to be capable of handing this.  Assuming, of course, that the ADC sends parallel data.  Dual port BlockRAM comes into play here.  Grab the data from the ADC and stuff it into one side of the BlockRAM while processing the data from the other side.

I would try to design my way out of using off-chip DDR memory although it is a possibility.

[SiliconWizard]

Oh yeah. You can definitely handle this on many FPGAs. Lots of low-end (or even mid-end) scopes use FPGAs for that.

As to external DDR.... well, if you need a sizeable amount of sample memory, it's hard to do without it. You can also use fast synchronous SRAM chips instead (and parallel as many as needed...)

[james_s]

Many midrange FPGAs have onboard DDR hardware interfaces that make this even easier. There are also various implementations in HDL, it's common enough that a majority of dev boards I see have some DDR memory on them.

Personally I much prefer SRAM but that's mostly because I'm focused on recreating retro hardware and SRAM is far easier to work with in that context. Hard to beat the price per capacity ratio of DDR though.