[sillyquiet]

Regarding the interesting bit (to me) in there about the advantages of FPGAs over an SBC like the Pi (speed)- does anybody know of any blogs or projects where an FPGA's speed helped in a hobby project where software running on an SBC wasn't fast enough? I can imagine a few, mostly real-time projects involving expensive computations (image or pattern recognition maybe?), but I would love to see some concrete examples.

[PragmaticPulp]

Basically anything with significant real-time requirements or high bandwidth requires an external FPGA or microcontroller.

Embedded Linux is great, but if you’re trying to do something like read from a high-speed ADC then the only way to do it is with an FPGA. The FPGA reads from the ADC at precise intervals and buffers the data. The embedded Linux system can then periodically read the buffer with all of the jitter and latencies that come with using Linux.

Virtually every Linux-based software defined radio, oscilloscope, and logic analyzer work on this architecture. For lower speeds you can get away with a microcontroller running bare metal code to do the buffering, but the high speed stuff enters the domain of FPGAs.

[coryrc]

> read from a high-speed ADC

You just have the peripheral DMA and flag/interrupt when done. If you need an "immediate" reaction you use a DSP. There are only so many useful calculations you can do with a single input stream and DSP can handle them.

[andai]

Noob question, in this instance would a realtime OS or a unikernel also solve the problem?

[tyingq]

It's better, but still not the same level of timing guarantees. I suppose, left to right, you would have something like:

SBC/Linux -> SBC/Real-time OS -> General Purpose MCU -> Specialized MCU (Parallax Propeller, for example) -> FPGA/CPLD/DSP

With perhaps some additions to the diagram to account for bit-banging vs actual drivers, speeds where some portion of the left side just isn't fast enough to even kind-of work, slow clock MCUs vs fast clock MCUs, etc.

[sbierwagen]

There are also some some hybrid SOCs, like TI's Sitara chips that the Beagleboard is built around, that have a ARM core for linux, then a couple MCU cores for doing fast-ish realtime stuff. (TI's FAQ says a four instruction busyloop that just toggles a pin can run at about 50MHz on a PRU)

[emteycz]

The problem is, machine code is not the lowest level, there is also processor microcode. Machine code doesn't give you a hard real-time guarantee, the execution is still too approximate. FPGA enables you to work on/below the microcode level.

[FredFS456]

RF/radio is one solid application. Can't really do the signal processing fast enough on an SBC.

[carlsonmark]

Not just the signal processing on the received data, but if you want to transmit something, you will probably be using one or more DDS channels to do so. Those may be in the FPGA, or external chips. Either way, if you are mixing the outputs of the DDS, being off by a single clock cycle can cause your transmitted data to be complete garbage.

With an FPGA and external DDS chips, this is difficult to do just because of mismatches in PCB trace lengths and/or small temperature fluctuations. With a microcontroller, it is nearly impossible to do even when using DMA because of memory bus contention.

[sillyquiet]

Ohh good one. mmRadar projects I guess will fall into this category too.

[undersuit]

There's a growing community using an Altera Cyclone SBC to create faithful recreations of retro gaming machines. Software emulation by the similar sized Raspberry Pi limits you, and the MiSTer is much more compact than a desktop computer that does have the power for accurate software emulation.

https://www.retrorgb.com/mister.html

[tyingq]

Driving LED matrix displays is a good example, since they require good adherance to timing on the output signal. Especially at high refresh rates. There's lots of hobby projects that get away with just using the CPU, but you're throwing a lot of horsepower at something a cheap CPLD could handle fine. There's also solutions like using the "PRU" in a Beaglebone to drive the display...the PRU is basically a microcontroller that can share memory with the CPU, but can work in a more real-time fashion.

So it's not always raw speed, per se, but anything that's sensitive to timing. Linux on a PI can be busy doing something else and miss a critical time to have output (or read) something. An FPGA based solution is working with known loop/io/etc times that don't change.

[marktangotango]

That's interesting, looks like the PRU is built into the AM3358 SOC, is that correct?

[tyingq]

Yes, I believe it's in all (most?) of the products within the "Sitara" line, or at least AM33XX models.

Lowrisc.org also has a similar plan for what they call "minion cores" in their RISCV based product, whenever that happens. Some NXP processors also have something called an "eTPU" that seems similar.

[al2o3cr]

This is a commercial product so it's not _quite_ what you asked for, but the production volume is pretty low (100s) and the implementation is literally an FPGA dev board mounted to the back of the interface panel.

https://intellijel.com/shop/eurorack/cylonix-rainmaker/

In this module, the FPGA's ability to do LOTS of computations in parallel is used to produce 16 taps of pitch-shiftable delay along with a 64-tap comb filter.

[IshKebab]

I think you won't find many because an FPGA that is as fast at computation as a Raspberry Pi will be thousands of pounds. The real advantage is latency and low-level control.

[tyingq]

There are cases where an FPGA is used to make a faster CPU. Old CPUs, of course, but it's still a pretty active niche. There are soft cores for Z80s, 6502, and other old CPUs that run circles around the real hardware.

[coryrc]

Only useful if a microcontroller peripheral doesn't already exist for the thing you want to do and you have some sub-millisecond latency requirements. If a calculation can be vectorized a CPU or GPU is really fast.

At normal speeds, an image can take 10-15 ms to clock out of the sensor. At that point, there's little reason not to run your image processing on a $3 CPU rather than $$$ FPGA because what's another < 30ms at that point and what would need a reaction that quick anyway?