The Harsh Truth about FPGAs (You Should Avoid Them)
video description
Date: 2025-09-28
Related videos
Comments and reviews: 20
RGD2k
SPI is much easier on an FPGA than I2C. Many sensors are available in both kinds: so if you know you prefer FPGA's, just pick SPI and avoid I2C.
FPGA's can implement either an SPI controller or peripheral in just a couple lines of verilog - it's really convenient.
They also like to do arbitrarily long bit strings. FPGA's are all about the arbitrarily long bit vectors, and slicing/recombining arrays of such signals is very easy in the language, and also 'easy' on the compiler too.
Microcontrollers, OTOH are all about bytes.
Also, FPGA's do kind of have 'instructions', in the form of built-in hardware blocks. They're called 'primitives' in the manual, you just instantiate them like any other 'module' but they come in a pre-defined library for the particular kind of FPGA you have.
Things like PLL blocks let you take your whatever MHz crystal input and make what frequency you actually want out of it, making them much more flexible than first appears. You can easily have mulitple different clock domains: protip: best to synchronise with one system clock, and have that drive everything else in your circuitry.
Crossing clock domains is best done with generic fifo and or handshaking blocks intended for crossing clock domains. Oh, that's another thing unique to FPGA's: There exists both 'closed source' and 'open source' IP libraries. These are generic functions you can put into pretty much any FPGA (for the open source ones at least.
A lot of the 'closed source' IP blocks are heavily controlled: you can't have them. Their compilation source files are even encrypted so you can't read them yourself, only the approved proprietary compilers will work with them, and only if you have a current license (they 'phone home'.
The true FOSS toolchains are actually so good that it's well worth simply restricting your choice of FPGA to what they support: as they are relatively tiny, small (can run on a RasPi) and fast (can compile and upload to an FPGA within seconds: Most proprietary toolchains will take minutes to nearly an hour, for some older chips.
The FOSS FPGA tools also don't force you to use yet another eclipse-clone IDE like the cheapo proprietary tools do, instead, they will integrate and work properly with plain old GNU make. Something some of the proprietary tools are quite bad at, especially the older ones.
FPGA: Best connected to a fast SoC like a RasPi. Also best used with state machines at very low level: Fixed-function pipelines for processing at best, but for raw compute, you may likely be better off integrating a modern SoC and doing your compute there instead.
Oh, BTW: only a very few FPGA's with FOSS support have support for talking PCIe. So in theory, you could attach one of the documented (AMD) old gpu's and have your FPGA send jobs out for it to compute for it. Which would be a great way to have a lot of DSP compute handy, perhaps for digital control, in a very low-latency way, all whilst avoiding running an OS.
Have fun!
reply
SPI is much easier on an FPGA than I2C. Many sensors are available in both kinds: so if you know you prefer FPGA's, just pick SPI and avoid I2C.
FPGA's can implement either an SPI controller or peripheral in just a couple lines of verilog - it's really convenient.
They also like to do arbitrarily long bit strings. FPGA's are all about the arbitrarily long bit vectors, and slicing/recombining arrays of such signals is very easy in the language, and also 'easy' on the compiler too.
Microcontrollers, OTOH are all about bytes.
Also, FPGA's do kind of have 'instructions', in the form of built-in hardware blocks. They're called 'primitives' in the manual, you just instantiate them like any other 'module' but they come in a pre-defined library for the particular kind of FPGA you have.
Things like PLL blocks let you take your whatever MHz crystal input and make what frequency you actually want out of it, making them much more flexible than first appears. You can easily have mulitple different clock domains: protip: best to synchronise with one system clock, and have that drive everything else in your circuitry.
Crossing clock domains is best done with generic fifo and or handshaking blocks intended for crossing clock domains. Oh, that's another thing unique to FPGA's: There exists both 'closed source' and 'open source' IP libraries. These are generic functions you can put into pretty much any FPGA (for the open source ones at least.
A lot of the 'closed source' IP blocks are heavily controlled: you can't have them. Their compilation source files are even encrypted so you can't read them yourself, only the approved proprietary compilers will work with them, and only if you have a current license (they 'phone home'.
The true FOSS toolchains are actually so good that it's well worth simply restricting your choice of FPGA to what they support: as they are relatively tiny, small (can run on a RasPi) and fast (can compile and upload to an FPGA within seconds: Most proprietary toolchains will take minutes to nearly an hour, for some older chips.
The FOSS FPGA tools also don't force you to use yet another eclipse-clone IDE like the cheapo proprietary tools do, instead, they will integrate and work properly with plain old GNU make. Something some of the proprietary tools are quite bad at, especially the older ones.
FPGA: Best connected to a fast SoC like a RasPi. Also best used with state machines at very low level: Fixed-function pipelines for processing at best, but for raw compute, you may likely be better off integrating a modern SoC and doing your compute there instead.
Oh, BTW: only a very few FPGA's with FOSS support have support for talking PCIe. So in theory, you could attach one of the documented (AMD) old gpu's and have your FPGA send jobs out for it to compute for it. Which would be a great way to have a lot of DSP compute handy, perhaps for digital control, in a very low-latency way, all whilst avoiding running an OS.
Have fun!
reply
Cynthia_Cantrell
My peak FPGA involvement was about 30 years go, but I believe this video sells FPGA short, and although comparing them to a microcontroller or cpu might be easy or convenient, that's not where their strength lies. It's about using the right tool for the job.
CPUs are great for hardware that has lots of branching, and have time to do things relatively slowly. FPGAs are great when you don't have a lot of decisions to make, but you need to do everything quickly - like on every single clock cycle. A CPU or micro typically has 1 ALU. But what if you need 32 of them running in parrallel Then you want an FPGA.
Back then, I worked for a telecom test equipment company - SONET, DS3, DS1, T1, Ethernet, ATM, etc. We used FPGAs to sync up to the framing of those signals, pull out the relevant data, process it, can check for errors at multiple levels of the comms stack simultaneously. Of course, we generated the payload, framing, error insert, and line coding for the transmit side as well. Standard CPUs of the time simply did not have anywhere near enough bandwidth to do all of that.
RISC processors started coming out then, and if they were supported by custom external hardware (like an FPGA, dual-ported RAM, high-speed FIFOs, etc) could be used if designed VERY carefully, to handle important subsets of the functions.
As a test equipment company, one of the hugh advantages of an FPGA was how much discrete logic we could pack into a single chip compared to standard TTL devices. The space, power, and weight savings were CRUCIAL for keeping the test equipment portable. Although back in the '90s FPGAs couldn't run nearly as fast as discrete logic - especially ECL - their size grew pretty quickly, and we could convert the serial data into parallel (outside the FPGA) and had enough flip-flops in the FPGA to do the logic we needed at a workable clock speed.
My group was constantly hitting the speed limits of FPGAs at the time. I had to figure out that the standard design methods their documentation promoted, while good for standard designs, did not apply to our cases. I required me to carefully examine the device architecture and use its resources in the most effective way possible. For example, for the speeds we ran at, any logic decision that couldn't fit entirely within 1 logic block / LUT had to be pipe-lined, otherwise you'd never be able to route it to meet timing requirements. I also hand-placed (but NOT hand-routed) many critical circuits, having figured out that if I had placed critical flip-flops and tri-state buffers next to the right long lines, the router could figure out the proper way to connect the signals.
So I will reiterate, that it's about using the right tool for the job. For some jobs you can use a circular saw or a jig saw, but chances are, your results will be far better if you pick the one best suited for that project.
reply
My peak FPGA involvement was about 30 years go, but I believe this video sells FPGA short, and although comparing them to a microcontroller or cpu might be easy or convenient, that's not where their strength lies. It's about using the right tool for the job.
CPUs are great for hardware that has lots of branching, and have time to do things relatively slowly. FPGAs are great when you don't have a lot of decisions to make, but you need to do everything quickly - like on every single clock cycle. A CPU or micro typically has 1 ALU. But what if you need 32 of them running in parrallel Then you want an FPGA.
Back then, I worked for a telecom test equipment company - SONET, DS3, DS1, T1, Ethernet, ATM, etc. We used FPGAs to sync up to the framing of those signals, pull out the relevant data, process it, can check for errors at multiple levels of the comms stack simultaneously. Of course, we generated the payload, framing, error insert, and line coding for the transmit side as well. Standard CPUs of the time simply did not have anywhere near enough bandwidth to do all of that.
RISC processors started coming out then, and if they were supported by custom external hardware (like an FPGA, dual-ported RAM, high-speed FIFOs, etc) could be used if designed VERY carefully, to handle important subsets of the functions.
As a test equipment company, one of the hugh advantages of an FPGA was how much discrete logic we could pack into a single chip compared to standard TTL devices. The space, power, and weight savings were CRUCIAL for keeping the test equipment portable. Although back in the '90s FPGAs couldn't run nearly as fast as discrete logic - especially ECL - their size grew pretty quickly, and we could convert the serial data into parallel (outside the FPGA) and had enough flip-flops in the FPGA to do the logic we needed at a workable clock speed.
My group was constantly hitting the speed limits of FPGAs at the time. I had to figure out that the standard design methods their documentation promoted, while good for standard designs, did not apply to our cases. I required me to carefully examine the device architecture and use its resources in the most effective way possible. For example, for the speeds we ran at, any logic decision that couldn't fit entirely within 1 logic block / LUT had to be pipe-lined, otherwise you'd never be able to route it to meet timing requirements. I also hand-placed (but NOT hand-routed) many critical circuits, having figured out that if I had placed critical flip-flops and tri-state buffers next to the right long lines, the router could figure out the proper way to connect the signals.
So I will reiterate, that it's about using the right tool for the job. For some jobs you can use a circular saw or a jig saw, but chances are, your results will be far better if you pick the one best suited for that project.
reply
thorjohnson5237
If the FPGA is large enough, you can synthesize a CPU with some peripherals.
Getting I2C I/O is gonna be fiddly (but your core library might have a module for that since I2C is everywhere, but you can rig up a LED and a phototransistor and drive those fast enough to make your own LIDAR with the FPGA. If you want an amazing one (at an amazing price) with amazing IO. There's a Red Pitaya that has both a very nice FPGA and a decent micro under the hood. and an ecosystem with measurements and projects -- including that LIDAR I was mentioning -- using actual lasers and measuring the time it takes for the pulses to go and come back (and the phase to keep everything very nice.
Think of FPGA's as universal hardware chip (so you're making a JK flip flop or whatever -- and you can make a CPU if you really need one. and micros as It's a PC, so it runs the software you want, but. the micro is the speed and that's what it is; if you want low-power, expect kinda slow until you start playing fpga-like-games (see also BlueGeckos and other bits that let you handle IO without waking the computer up.
FPGA - Brutally fast, but very brutal. You wire it from the ground up (but at least you do that in code instead of in Eagle.
uC - A computer with hardware-friendly I/O (for some values of friendly PCIE, LVDS, and HDMI are. doofy here, but simple FPGA.
If you want a compromise, look for uC's with reflex or AFE or other things that let you play games with IO without having to wake up the computer. Usually more limited in scope, but. makes it easy to turn the cpu on when somebody steps on the strain gauge
SBC - More computer, less hardware friendly. Go control a stepper driver with a RasPi and find that the Linux really really fights your realtimeness (sure, declare that Python real-time. Watch as your VNC traffic causes the steppers to miss because of inertia.
Computer - Bigger, farther away from hardware. But at least you can use SFP, HDMI, and NVMe easily enough (if you have the drivers. You wanna have IO Go get a USB LabJack. Or one of these FPGA or uC boards and talk to it over USB. 2. 4 GHz can get pretty real-time. unless there's something more real bugging your processor(s.
Does anybody do anything with those weird DSP's any more Goofy gray-coded PC's (see ADSP SHARC) and other real nonsense that made signal processing easy, but abstract computing. daft.
reply
If the FPGA is large enough, you can synthesize a CPU with some peripherals.
Getting I2C I/O is gonna be fiddly (but your core library might have a module for that since I2C is everywhere, but you can rig up a LED and a phototransistor and drive those fast enough to make your own LIDAR with the FPGA. If you want an amazing one (at an amazing price) with amazing IO. There's a Red Pitaya that has both a very nice FPGA and a decent micro under the hood. and an ecosystem with measurements and projects -- including that LIDAR I was mentioning -- using actual lasers and measuring the time it takes for the pulses to go and come back (and the phase to keep everything very nice.
Think of FPGA's as universal hardware chip (so you're making a JK flip flop or whatever -- and you can make a CPU if you really need one. and micros as It's a PC, so it runs the software you want, but. the micro is the speed and that's what it is; if you want low-power, expect kinda slow until you start playing fpga-like-games (see also BlueGeckos and other bits that let you handle IO without waking the computer up.
FPGA - Brutally fast, but very brutal. You wire it from the ground up (but at least you do that in code instead of in Eagle.
uC - A computer with hardware-friendly I/O (for some values of friendly PCIE, LVDS, and HDMI are. doofy here, but simple FPGA.
If you want a compromise, look for uC's with reflex or AFE or other things that let you play games with IO without having to wake up the computer. Usually more limited in scope, but. makes it easy to turn the cpu on when somebody steps on the strain gauge
SBC - More computer, less hardware friendly. Go control a stepper driver with a RasPi and find that the Linux really really fights your realtimeness (sure, declare that Python real-time. Watch as your VNC traffic causes the steppers to miss because of inertia.
Computer - Bigger, farther away from hardware. But at least you can use SFP, HDMI, and NVMe easily enough (if you have the drivers. You wanna have IO Go get a USB LabJack. Or one of these FPGA or uC boards and talk to it over USB. 2. 4 GHz can get pretty real-time. unless there's something more real bugging your processor(s.
Does anybody do anything with those weird DSP's any more Goofy gray-coded PC's (see ADSP SHARC) and other real nonsense that made signal processing easy, but abstract computing. daft.
reply
AdamDavisEE
People think microcontrollers are easy because of projects like Arduino, similar to people thinking linux is easy due to Raspberry PI. Prior to those two you rarely had convenient libraries for the sensors, or even the on-chip peripherals, and C compilers were often not included so you had you buy them - meaning a lot of hobbyists worked in assembly. One of the biggest changes that helped vault microcontrollers to the hobbyist level was on chip flash that didn't require a UV eeprom eraser to erase the chip, and low voltage programming methods with simple printerport or serial port adaptors and free programs to allow programming the chips repeatedly and easily. The cost to play with them dropped significantly. The PIC16C84 (eventually renamed 16f84) was a watershed microcontroller.
I fully expect the same thing to happen with FPGAs - we may still need to use HDL or Verilog, but the tools being free for smaller designs provides an opportunity. If people spend time decreasing the difficulty of development by making tools that make it easier, and making the blocks that can be dropped into a design to implement simple state machines, peripherals, etc, along with the video tutorials then we might see an explosion of FPGA based projects. If the arduino IDE become FPGA aware and capable it would accelerate this process significantly. Sadly Arduino has moved into the profit extraction mode so I don't see anything like this coming from them anytime soon.
What's needed then are projects that really shine using an FPGA, and are more difficult or less performant on a microcontroller. Using FPGAs with built in CPUs, though, or making the arduino equivalent that has both FPGA and CPU on one hobbyist development board should suddenly become the defacto solution for everything.
The gowin fpgas are getting cheap enough to do impressive work at hobbyist levels. Throw some tools and tutorials in there and watch interest and usage explode.
reply
People think microcontrollers are easy because of projects like Arduino, similar to people thinking linux is easy due to Raspberry PI. Prior to those two you rarely had convenient libraries for the sensors, or even the on-chip peripherals, and C compilers were often not included so you had you buy them - meaning a lot of hobbyists worked in assembly. One of the biggest changes that helped vault microcontrollers to the hobbyist level was on chip flash that didn't require a UV eeprom eraser to erase the chip, and low voltage programming methods with simple printerport or serial port adaptors and free programs to allow programming the chips repeatedly and easily. The cost to play with them dropped significantly. The PIC16C84 (eventually renamed 16f84) was a watershed microcontroller.
I fully expect the same thing to happen with FPGAs - we may still need to use HDL or Verilog, but the tools being free for smaller designs provides an opportunity. If people spend time decreasing the difficulty of development by making tools that make it easier, and making the blocks that can be dropped into a design to implement simple state machines, peripherals, etc, along with the video tutorials then we might see an explosion of FPGA based projects. If the arduino IDE become FPGA aware and capable it would accelerate this process significantly. Sadly Arduino has moved into the profit extraction mode so I don't see anything like this coming from them anytime soon.
What's needed then are projects that really shine using an FPGA, and are more difficult or less performant on a microcontroller. Using FPGAs with built in CPUs, though, or making the arduino equivalent that has both FPGA and CPU on one hobbyist development board should suddenly become the defacto solution for everything.
The gowin fpgas are getting cheap enough to do impressive work at hobbyist levels. Throw some tools and tutorials in there and watch interest and usage explode.
reply
junkerzn7312
FPGA work is tough when things get complex. The hardware description language implementations and poor optimization models are terrible verses what is available for high level (general cpu) programming languages. I often get stuck trying to do things, particularly hierarchical access to elements and structural encapsulation to reduce complexity in the input/output parameterization that a particular IDE's compiler either just can't deal with, or winds up spending 30 minutes trying to optimize something that I don't want it to optimize for my development cycle.
What's crazy is that even the vendors loose control over their own hardware compilers. where the companies wind up losing the expertise required to make fixes and additions to the batch processes that compiler the HDLs into FPGA programming bit streams. It is literally that bad.
And then we get into timing and propagation constraints. things go south quickly when there's a ton of combinatorial logic inbetween registered stages that result in huge clock optimization problems. Things go south even more quickly when you depart from clock-edge-driven logic. Level-driven buffers to deal with stage-to-stage flows with overlapped clocks and relaxed timing constraints just isn't something an FPGA can do well. or at all really.
It really makes me angry, to be honest. I use a microcontroller whenever possible, but there are just some things that a microcontroller can't do. FPGA design would be a whole lot easier if the tools were actually kept up to date and modernized instead of being a dozen separate little batch programs written across the last 30 years some of which the companies owning the I. P. no longer have the expertise to work on.
-Matt
reply
FPGA work is tough when things get complex. The hardware description language implementations and poor optimization models are terrible verses what is available for high level (general cpu) programming languages. I often get stuck trying to do things, particularly hierarchical access to elements and structural encapsulation to reduce complexity in the input/output parameterization that a particular IDE's compiler either just can't deal with, or winds up spending 30 minutes trying to optimize something that I don't want it to optimize for my development cycle.
What's crazy is that even the vendors loose control over their own hardware compilers. where the companies wind up losing the expertise required to make fixes and additions to the batch processes that compiler the HDLs into FPGA programming bit streams. It is literally that bad.
And then we get into timing and propagation constraints. things go south quickly when there's a ton of combinatorial logic inbetween registered stages that result in huge clock optimization problems. Things go south even more quickly when you depart from clock-edge-driven logic. Level-driven buffers to deal with stage-to-stage flows with overlapped clocks and relaxed timing constraints just isn't something an FPGA can do well. or at all really.
It really makes me angry, to be honest. I use a microcontroller whenever possible, but there are just some things that a microcontroller can't do. FPGA design would be a whole lot easier if the tools were actually kept up to date and modernized instead of being a dozen separate little batch programs written across the last 30 years some of which the companies owning the I. P. no longer have the expertise to work on.
-Matt
reply
RGD2k
So far as 'FPGA has nothing in the middle': You need to get swapforth and port it onto your FPGA.
Particularly the j4a cpu. That thing can host a whole almost-complete ANS Forth interpreter/compiler, and still run at incredibly low latencies.
It's a really good way to 'talk' to a live, running system, so you can easily talk it into doing 'bit bang' interfaces to oddball chips, without having to 'stop and recompile'.
It make a fantastic way to learn about how to talk to new chips, and is a great 'middle' between high level but clumsy arduino and writing a state-machine in verilog to do the same job.
Plus you can then do the latter, and hook it into your j4a swapforth image's 'IO' space, letting you then 'offload' such jobs into the unused parts of the FPGA.
This makes it to where it's very easy to end up with a custom j4a swapforth core that has four separate SPI busses talking to half a dozen chips, all at different rates, whilst you independently talk to the swapforth interpreter over serial from your PC, using it to set controls and read indicators.
The nicest thing about swapforth, is you can easily read the CPU verilog and understand how it works. It just takes the typically interpreted virtual machine of a typical FORTH implementation, and implements it in a single-cycle state machine, with a couple of cool optimizations. And all in about a hundred lines of pretty amazingly clear verilog!
There's your 'middle'.
reply
So far as 'FPGA has nothing in the middle': You need to get swapforth and port it onto your FPGA.
Particularly the j4a cpu. That thing can host a whole almost-complete ANS Forth interpreter/compiler, and still run at incredibly low latencies.
It's a really good way to 'talk' to a live, running system, so you can easily talk it into doing 'bit bang' interfaces to oddball chips, without having to 'stop and recompile'.
It make a fantastic way to learn about how to talk to new chips, and is a great 'middle' between high level but clumsy arduino and writing a state-machine in verilog to do the same job.
Plus you can then do the latter, and hook it into your j4a swapforth image's 'IO' space, letting you then 'offload' such jobs into the unused parts of the FPGA.
This makes it to where it's very easy to end up with a custom j4a swapforth core that has four separate SPI busses talking to half a dozen chips, all at different rates, whilst you independently talk to the swapforth interpreter over serial from your PC, using it to set controls and read indicators.
The nicest thing about swapforth, is you can easily read the CPU verilog and understand how it works. It just takes the typically interpreted virtual machine of a typical FORTH implementation, and implements it in a single-cycle state machine, with a couple of cool optimizations. And all in about a hundred lines of pretty amazingly clear verilog!
There's your 'middle'.
reply
ErazerPT
It's obviously a need thing. As in do you need all that power. If the answer is yes, then no other option, if it's no, then maybe a MCU or a SoC is a better option. I'm putting the finishing touches on a (virtual) expansion device for the ZX Spectrum over a point i wanted to make. The platform (conveniently) already has a standard way to do bytestream PIO to the bus at a lightning fast 4KB/s give or take. Sounds tiny until you remember that loading from tape was 1500baud/s. And given how lacking in power the Z80 is, there are LOTS of things you can speed up by offloading the work to an external device. Or capabilities you can add, like extra (fake) RAM, storage, etc. If it was to be translated to real iron, you'd probably just plot a ESP32 or similar with a CPLD as a bridge to the bus or something and everything past that would be software. Want to add more capabilities Just add more code. More expansion hardware Add more code and hook up the devices to the ESP32 I2C, SPI, UART, WIFI, BT, whatever. Easy peasy, little stress.
Now, an FPGA would be able to do proper DMA thus lot faster, but would it be as simple/fast to add new stuff Would any C/Python/C#/whatever developer be able to drop in and start fixing things and adding more things Not really.
As with most things in life, use the right tool for the job. Sometimes it's an FPGA, sometimes it's not. And it starts with knowing what the job is and what the requirements are.
reply
It's obviously a need thing. As in do you need all that power. If the answer is yes, then no other option, if it's no, then maybe a MCU or a SoC is a better option. I'm putting the finishing touches on a (virtual) expansion device for the ZX Spectrum over a point i wanted to make. The platform (conveniently) already has a standard way to do bytestream PIO to the bus at a lightning fast 4KB/s give or take. Sounds tiny until you remember that loading from tape was 1500baud/s. And given how lacking in power the Z80 is, there are LOTS of things you can speed up by offloading the work to an external device. Or capabilities you can add, like extra (fake) RAM, storage, etc. If it was to be translated to real iron, you'd probably just plot a ESP32 or similar with a CPLD as a bridge to the bus or something and everything past that would be software. Want to add more capabilities Just add more code. More expansion hardware Add more code and hook up the devices to the ESP32 I2C, SPI, UART, WIFI, BT, whatever. Easy peasy, little stress.
Now, an FPGA would be able to do proper DMA thus lot faster, but would it be as simple/fast to add new stuff Would any C/Python/C#/whatever developer be able to drop in and start fixing things and adding more things Not really.
As with most things in life, use the right tool for the job. Sometimes it's an FPGA, sometimes it's not. And it starts with knowing what the job is and what the requirements are.
reply
pennyandrews3292
I don't know much about FPGAs as a general thing, but I do know that they are really good for simulating various older 8-bit and 16-bit computers that aren't produced anymore. They seem to be able to get very low latency and accurate timing without the kind of pitfalls you run into trying to emulate another computer on a normal CPU, issues that force you to try and work around all kinds of things that introduce latency to try and get the most accurate emulation possible with decent performance. Basically, you don't have to sacrifice latency and precise timing to get better performance with an FPGA, and that's where it is really good. This is probably a naive way of thinking about it, but I always just saw an FPGA as a blank, erasable CPU-like thing that can be programmed to act like almost any other computer system within certain limitations, so would be good for something like prototyping a new CPU architecture or recreating hardware that no longer exists. In other words, I wouldn't think it would be of use to someone who just likes playing around with Arduino, it would be of use to someone who wants to design a very simple CPU but doesn't have access to their own fab, and buying an FPGA that can kind of be programmed is cheaper than convincing a microprocessor fab to create something according to your specifications. Can anyone who knows more tell me if I am in the right ballpark or not as to what these are for
reply
I don't know much about FPGAs as a general thing, but I do know that they are really good for simulating various older 8-bit and 16-bit computers that aren't produced anymore. They seem to be able to get very low latency and accurate timing without the kind of pitfalls you run into trying to emulate another computer on a normal CPU, issues that force you to try and work around all kinds of things that introduce latency to try and get the most accurate emulation possible with decent performance. Basically, you don't have to sacrifice latency and precise timing to get better performance with an FPGA, and that's where it is really good. This is probably a naive way of thinking about it, but I always just saw an FPGA as a blank, erasable CPU-like thing that can be programmed to act like almost any other computer system within certain limitations, so would be good for something like prototyping a new CPU architecture or recreating hardware that no longer exists. In other words, I wouldn't think it would be of use to someone who just likes playing around with Arduino, it would be of use to someone who wants to design a very simple CPU but doesn't have access to their own fab, and buying an FPGA that can kind of be programmed is cheaper than convincing a microprocessor fab to create something according to your specifications. Can anyone who knows more tell me if I am in the right ballpark or not as to what these are for
reply
alphus89
FPGA Engineer here, with 15yrs of experience.
1- USe IP core or open source HDL code if you want commonly used functions like I2C, UART, SDI.
2- After years of FPGA experience, you will get a massive library of IP blocks ready to use. Make sure to define them with parameters in the header, so you can tune them for your application.
3- Any HDL code/blok should be tested/validated via simulation. Many free simulation tools are free, and even sometimes included into the IDE. => Learn to do do testbench is crtitical, and help to debug and make your code functionnal even before compiling it.
4- Your verilog code without debouncer hurted me, haha. Simple debouncing algo like majority is sufficient. Make sure to put as much code a posiible into a process to make it sequential, it fits better, compile better, and more easy to check/debug for the timing analysis when you will start to reach high frequency clock.
FPGAs are awesome once masterized, and much much more powerfull than CPU, GPU and MCU. Main limitation is DSP that is basically only on Fixed-point and integer numbers, and it can takes monthes to get a working bitstream, as it is not as fast as developing with MCU/CPU.
reply
FPGA Engineer here, with 15yrs of experience.
1- USe IP core or open source HDL code if you want commonly used functions like I2C, UART, SDI.
2- After years of FPGA experience, you will get a massive library of IP blocks ready to use. Make sure to define them with parameters in the header, so you can tune them for your application.
3- Any HDL code/blok should be tested/validated via simulation. Many free simulation tools are free, and even sometimes included into the IDE. => Learn to do do testbench is crtitical, and help to debug and make your code functionnal even before compiling it.
4- Your verilog code without debouncer hurted me, haha. Simple debouncing algo like majority is sufficient. Make sure to put as much code a posiible into a process to make it sequential, it fits better, compile better, and more easy to check/debug for the timing analysis when you will start to reach high frequency clock.
FPGAs are awesome once masterized, and much much more powerfull than CPU, GPU and MCU. Main limitation is DSP that is basically only on Fixed-point and integer numbers, and it can takes monthes to get a working bitstream, as it is not as fast as developing with MCU/CPU.
reply
rolfdieterklein
yes indeed FPGA development is always hard but also fun. I work with FPGAs a long time also as space eengineer. For our space project (MOVEII and MOVEIIB - LRT Munich) with FPGA for SDR in transceivers I developed, I used Xilinx Artix 5 FPGAs with a MRAM (magnetic storage more reliable in space than flash, at that time we used altium for schemtci pcb and FPGA which had a manufacturer independant workflow and a SOftcore cpu WHICH WE USED for the I2C parts on board to initalize and readout. The SDR part is handled by the pure logic part and both comminicate through ports internally, and via SPI through the Cubesat Bus we used ad the edges. This hybrid aproach was really great, nowday also embeddec cpus in hardware could be used, but all is also power tradeoff. The parts we used word for the whole lifetime (7 years for MOVEII and 5 years for MOVEII2b) until there deorbit time. We did a 1-3 hrs auto reset and reload of the Firmware and FPGA code to prevent hangups. The communication windows is always around 15 min in VHF and UHF and SBAND for the two different trasnceivers, Code could be uploaded to the satellite also if wanted.
reply
yes indeed FPGA development is always hard but also fun. I work with FPGAs a long time also as space eengineer. For our space project (MOVEII and MOVEIIB - LRT Munich) with FPGA for SDR in transceivers I developed, I used Xilinx Artix 5 FPGAs with a MRAM (magnetic storage more reliable in space than flash, at that time we used altium for schemtci pcb and FPGA which had a manufacturer independant workflow and a SOftcore cpu WHICH WE USED for the I2C parts on board to initalize and readout. The SDR part is handled by the pure logic part and both comminicate through ports internally, and via SPI through the Cubesat Bus we used ad the edges. This hybrid aproach was really great, nowday also embeddec cpus in hardware could be used, but all is also power tradeoff. The parts we used word for the whole lifetime (7 years for MOVEII and 5 years for MOVEII2b) until there deorbit time. We did a 1-3 hrs auto reset and reload of the Firmware and FPGA code to prevent hangups. The communication windows is always around 15 min in VHF and UHF and SBAND for the two different trasnceivers, Code could be uploaded to the satellite also if wanted.
reply
nwrkbiz
You cannot compare FPGAs to micro controllers; they are used for completely different purposes. Also important, you do not program a FPGA, you describe hardware.
FPGA = build and use your own hardware.
uC = pre-built and ready to use hardware with many general-purpose functions
FPGAs are used for your very custom hardware (like a subsystem/peripheral within your microcontroller, also microcontrollers and all their peripherals are mostly also designed in HDLs and the bitstream is then used by a fab to build the ASIC. The use-case you came up with to compare uCs to FPGAs was a bit like comparing apples and pears there.
If your FPGA is big enough, you can make it even run your very custom CPU. The FPGA systems I know are mostly used for highly specialized signal processing tasks or hardware codecs.
FPGAs are sometimes also used to prototype things like I2C peripherals etc, they are really there to build custom hardware, while a microcontroller is a ready to use pre-built hardware.
But your video showed pretty neatly, that in most cases for normal automation projects there is no need for FPGAs.
reply
You cannot compare FPGAs to micro controllers; they are used for completely different purposes. Also important, you do not program a FPGA, you describe hardware.
FPGA = build and use your own hardware.
uC = pre-built and ready to use hardware with many general-purpose functions
FPGAs are used for your very custom hardware (like a subsystem/peripheral within your microcontroller, also microcontrollers and all their peripherals are mostly also designed in HDLs and the bitstream is then used by a fab to build the ASIC. The use-case you came up with to compare uCs to FPGAs was a bit like comparing apples and pears there.
If your FPGA is big enough, you can make it even run your very custom CPU. The FPGA systems I know are mostly used for highly specialized signal processing tasks or hardware codecs.
FPGAs are sometimes also used to prototype things like I2C peripherals etc, they are really there to build custom hardware, while a microcontroller is a ready to use pre-built hardware.
But your video showed pretty neatly, that in most cases for normal automation projects there is no need for FPGAs.
reply
maurvir3197
I've been working with FPGA's for 24 years, and this is largely spot-on - they are different tools with unique benefits. Microprocessors are great when you don't care about timing accuracy or you just need to move data around. FPGA's are for when you need precise timing or need to implement a non-standard protocol. Most of what I do involves adapting between custom protocols and a PC.
That said, there are FPGAs with integrated SoC CPUs that can do both. Alternately, you can implement a CPU model in an FPGA, allowing your code to interact directly with your digital logic design. It really comes down to whether you need that flexibility. A good example of the latter would be a custom digital synthesizer I did once that integrated a small 8-bit supervisory CPU model with a custom FM synthesis core. The CPU model programmed the NCO and filter parameters while the oscillator code ran at full-speed.
However, the learning curve is steep and the pitfalls wide, as working with an HDL is more akin to schematic capture than software. It's a different way of thinking about problems and modeling solutions.
reply
I've been working with FPGA's for 24 years, and this is largely spot-on - they are different tools with unique benefits. Microprocessors are great when you don't care about timing accuracy or you just need to move data around. FPGA's are for when you need precise timing or need to implement a non-standard protocol. Most of what I do involves adapting between custom protocols and a PC.
That said, there are FPGAs with integrated SoC CPUs that can do both. Alternately, you can implement a CPU model in an FPGA, allowing your code to interact directly with your digital logic design. It really comes down to whether you need that flexibility. A good example of the latter would be a custom digital synthesizer I did once that integrated a small 8-bit supervisory CPU model with a custom FM synthesis core. The CPU model programmed the NCO and filter parameters while the oscillator code ran at full-speed.
However, the learning curve is steep and the pitfalls wide, as working with an HDL is more akin to schematic capture than software. It's a different way of thinking about problems and modeling solutions.
reply
TatharNuar
6: 58 FPGAs aren't always faster! They're great at doing the same thing lots of times on a stream of data in a pipelined fashion, but really bad at mimicking sequential code. In an extreme example, if you need to create a CPU in your chosen HDL to run code in your chosen ISA, the FPGA will be just as limited by its clock as a microcontroller would be, except missing some potential clock cycle savings from the microcontroller being implemented as an ASIC.
The benefit of an FPGA comes from its massive parallelism, so something like Conway's Game of Life would be extremely fast on an FPGA relative to a microcontroller or single core CPU. It should also be on the easier end of FPGA projects (much easier than implementing I2C or VGA, at least) because the underlying logic is so simple.
Also definitely look for an I2C module online, since that's a pretty common solo project for entry level engineers. Once you have a known good module for a particular interface you want to use, it'll work in every future project you make.
reply
6: 58 FPGAs aren't always faster! They're great at doing the same thing lots of times on a stream of data in a pipelined fashion, but really bad at mimicking sequential code. In an extreme example, if you need to create a CPU in your chosen HDL to run code in your chosen ISA, the FPGA will be just as limited by its clock as a microcontroller would be, except missing some potential clock cycle savings from the microcontroller being implemented as an ASIC.
The benefit of an FPGA comes from its massive parallelism, so something like Conway's Game of Life would be extremely fast on an FPGA relative to a microcontroller or single core CPU. It should also be on the easier end of FPGA projects (much easier than implementing I2C or VGA, at least) because the underlying logic is so simple.
Also definitely look for an I2C module online, since that's a pretty common solo project for entry level engineers. Once you have a known good module for a particular interface you want to use, it'll work in every future project you make.
reply
JeffSmith03
Thank you this helps me understand people's thinking, what they don't understand. You never mentioned that no computer you have was made of anything different than the FPGA. That is a computer, just not structured yet. This brings us to the real problem, that manufacturers stopped making the chips of the computers I loved. Solution: remake the same functions in FPGA so that all of our work, billions of dollars worth, isn't just wasted because misleading jerks found they can make more money by throwing out value already done. So yes, if you want HDMI to still work after they throw it away, definitely make your FPGA design for that too. Everything will be thrown out sooner than you think just so they can keep taking more money. In my observation it just makes money worthless (call it inflation but getting more extreme because nobody understands that only value is valuable, not money.
reply
Thank you this helps me understand people's thinking, what they don't understand. You never mentioned that no computer you have was made of anything different than the FPGA. That is a computer, just not structured yet. This brings us to the real problem, that manufacturers stopped making the chips of the computers I loved. Solution: remake the same functions in FPGA so that all of our work, billions of dollars worth, isn't just wasted because misleading jerks found they can make more money by throwing out value already done. So yes, if you want HDMI to still work after they throw it away, definitely make your FPGA design for that too. Everything will be thrown out sooner than you think just so they can keep taking more money. In my observation it just makes money worthless (call it inflation but getting more extreme because nobody understands that only value is valuable, not money.
reply
justinolbrantz403
There are really only a few reasons to use an FPGA (partially summarizing the video):
1. Getting maximum processing power per $ is worth more than dev time/expense
2. You need ultra-low latency that can't be achieved with a uC
3. You need processing power with the lowest possible energy consumption (this may or may not apply depending on the application's suitability to FPGA)
4. As glue logic connecting chips with non-standard interfaces at bandwidths that can't be achieved with bitbanging (e. g. in my case intercepting the custom digital audio signal sent from an audio synth chip to its specialized DAC and converting it to a standard format for the uC to use)
5. You want the practice with FPGAs (I really should be doing more of this, as my FPGA experience is still limited)
If none of these applies, use a uC, CPU, or GPU as appropriate to the application.
reply
There are really only a few reasons to use an FPGA (partially summarizing the video):
1. Getting maximum processing power per $ is worth more than dev time/expense
2. You need ultra-low latency that can't be achieved with a uC
3. You need processing power with the lowest possible energy consumption (this may or may not apply depending on the application's suitability to FPGA)
4. As glue logic connecting chips with non-standard interfaces at bandwidths that can't be achieved with bitbanging (e. g. in my case intercepting the custom digital audio signal sent from an audio synth chip to its specialized DAC and converting it to a standard format for the uC to use)
5. You want the practice with FPGAs (I really should be doing more of this, as my FPGA experience is still limited)
If none of these applies, use a uC, CPU, or GPU as appropriate to the application.
reply
Mrjcowman
You shouldn't be shocked AI didn't have a good answer for you here. It still makes mistakes on many straightforward, common-sense prompts since it doesn't have an underlying model for understanding what it's being asked.
The only reason it's remotely functional for software is because it was made by software engineers and given access to billions and billions of lines of code to train on. A lot of its training comes from places like Stack Overflow where people ask for code snippets to solve common problems. There's a lot less info readily available for solving equivalent problems in HDL, so a tougher implementation like I2C is a lot of blind guesswork from the AI.
Thank you for these videos on FPGAs! I think they're very interesting and I would love to come back to your videos as a resource/inspiration when I inevitably get one to fiddle with.
reply
You shouldn't be shocked AI didn't have a good answer for you here. It still makes mistakes on many straightforward, common-sense prompts since it doesn't have an underlying model for understanding what it's being asked.
The only reason it's remotely functional for software is because it was made by software engineers and given access to billions and billions of lines of code to train on. A lot of its training comes from places like Stack Overflow where people ask for code snippets to solve common problems. There's a lot less info readily available for solving equivalent problems in HDL, so a tougher implementation like I2C is a lot of blind guesswork from the AI.
Thank you for these videos on FPGAs! I think they're very interesting and I would love to come back to your videos as a resource/inspiration when I inevitably get one to fiddle with.
reply
bears7777777
I made a 64x128 LED Matrix display driver using an FPGA for one of my digital logic labs. I spent 30 minutes trying to explain how it worked to the lab instructor because she was trying to say it didn't meet the requirements. In reality, it was just so complicated that she couldn't wrap her head around how the Verilog code worked. It was a scrolling display with a potentiometer for the speed. There was a built in microcontroller that communicated via UART to the FPGA for the AD conversion. You could also upload bitmaps to it using a program I wrote that sent the data via a serial terminal to the microcontroller and then to the FPGA. It controlled individual LED brightness using PWM (8-bit resolution, so it updated the display around 15k times/sec for 60fps (IIRC. That project really showed me the potential of FPGA's.
reply
I made a 64x128 LED Matrix display driver using an FPGA for one of my digital logic labs. I spent 30 minutes trying to explain how it worked to the lab instructor because she was trying to say it didn't meet the requirements. In reality, it was just so complicated that she couldn't wrap her head around how the Verilog code worked. It was a scrolling display with a potentiometer for the speed. There was a built in microcontroller that communicated via UART to the FPGA for the AD conversion. You could also upload bitmaps to it using a program I wrote that sent the data via a serial terminal to the microcontroller and then to the FPGA. It controlled individual LED brightness using PWM (8-bit resolution, so it updated the display around 15k times/sec for 60fps (IIRC. That project really showed me the potential of FPGA's.
reply
KrotowX
Awesome explanation. The difference between microcontroller and FPGA is exactly that. You can use microcontroller to program device algoritms, but still must add surrounding peripherals as hardware blocks. FPGA in general will allow you to build whole microcontroller together with surrounding peripherals inside the same FPGA chip. Less surrounding hardware and works faster. But development and debugging will be hard and really hard. FPGA itself is more expensive though together with surrounding peripherals going away it somewhat equalize with MCU circuit BOM cost. Particularly that is why FPGAs aren't so much used as ATtiny based door openers and other simpler MCU based hardware, but signal processing is full of them. Also circuits with MCU as main supervisor and FPGA as signal processor are pretty widespread.
reply
Awesome explanation. The difference between microcontroller and FPGA is exactly that. You can use microcontroller to program device algoritms, but still must add surrounding peripherals as hardware blocks. FPGA in general will allow you to build whole microcontroller together with surrounding peripherals inside the same FPGA chip. Less surrounding hardware and works faster. But development and debugging will be hard and really hard. FPGA itself is more expensive though together with surrounding peripherals going away it somewhat equalize with MCU circuit BOM cost. Particularly that is why FPGAs aren't so much used as ATtiny based door openers and other simpler MCU based hardware, but signal processing is full of them. Also circuits with MCU as main supervisor and FPGA as signal processor are pretty widespread.
reply
BangkokBubonaglia
No serious FPGA engineer designs peripherals from scratch. They simply use IP cores, either public domain or purchased. They work very similar to libraries in programming. So you just find an i2c IP core that works for you, and include it. It isn't that there is no middle ground to level up your knowledge, simply that you have to know more about how to use the tools, and you have a lot more variety. A micro controller gives you only a single option for an i2c peripheral. An FPGA gives you hundreds to choose from. A CPU is like ordering food in Europe. An FPGA is like ordering food in America. except without being forced to tip. You can even include a microcontroller IP core in your FPGA if you so desire. Although not much is going to fit in a 9K.
reply
No serious FPGA engineer designs peripherals from scratch. They simply use IP cores, either public domain or purchased. They work very similar to libraries in programming. So you just find an i2c IP core that works for you, and include it. It isn't that there is no middle ground to level up your knowledge, simply that you have to know more about how to use the tools, and you have a lot more variety. A micro controller gives you only a single option for an i2c peripheral. An FPGA gives you hundreds to choose from. A CPU is like ordering food in Europe. An FPGA is like ordering food in America. except without being forced to tip. You can even include a microcontroller IP core in your FPGA if you so desire. Although not much is going to fit in a 9K.
reply
eliasalvarez1181
I’m an electronics engineering student in my final year. FPGAs click once you realize HDL isn’t code in the usual sense. It looks like software but describes hardware, and thinking like a programmer will hold you back from using what makes FPGAs powerful compared to microcontrollers.
State machines are key. They’re just a formal way to express logic: define the states, specify what happens in each based on inputs and the current state. Simple idea, huge payoff.
At school we even built a MIPS processor in VHDL to run alongside our own hardware. You probably never will do that in industry, but it showed how you can mix approaches and get the best of both worlds without making everything maximally efficient the hard way.
reply
I’m an electronics engineering student in my final year. FPGAs click once you realize HDL isn’t code in the usual sense. It looks like software but describes hardware, and thinking like a programmer will hold you back from using what makes FPGAs powerful compared to microcontrollers.
State machines are key. They’re just a formal way to express logic: define the states, specify what happens in each based on inputs and the current state. Simple idea, huge payoff.
At school we even built a MIPS processor in VHDL to run alongside our own hardware. You probably never will do that in industry, but it showed how you can mix approaches and get the best of both worlds without making everything maximally efficient the hard way.
reply
Add a review, comment
Other channel videos
