One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are forcing down our throats.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
I just remembered I have a Xilinx I bought over a decade ago lying around somewhere. I don't remember ever plugging it in, but I do both the excitement of getting it and trying to figure out the toolchain and getting confused.
I'm all for your endeavor, but didn't see a device support list on your front page. Clicked the first of 2 links in your sidebar (docs) and got a 404. I'm not saying it's telling that your issues page works when your docs page doesn't, but it's not the foot I would have put forward.
Modern large productivity software (including IDE) are often "fragile".
Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.
Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.
The issue with the software team using an FPGA is that software developers generally aren't very good at doing things in parallel. They generally do a poor job in implementing hardware. I previously taught undergraduates VHDL, the software students generally struggles with the dealing with things running in parallel.
VHDL and Verilog are used because they are excellent languages to describe hardware. The tools don't really hold anyone back. Lack of training or understanding might.
Consistently the issue with FPGA development for many years was that by the time you could get your hands on the latest devices, general purpose CPUs were good enough. The reality is that if you are going to build a custom piece of hardware then you are going to have to write the driver's and code yourself. It's achievable, however, it requires more skill than pure software programming.
Again, thanks to low power an slow cost arm processors a class of problems previously handled by FPGAs have been picked up by cheap but fast processors.
The reality is that for major markets custom hardware tends to win as you can make it smaller, faster and cheaper. The probability is someone will have built and tested it on an FPGA first.
> VHDL and Verilog are used because they are excellent languages to describe hardware.
Maybe they were in the 80. In 2025, language design has moved ahead quite a lot, you can't be saying that seriously.
Have a look at how clash-lang does it. It uses functional paradigm, which is much more suitable for circuits than pseudo-pricedural style of verilog. You can also parameterize modules by modules, not just by bitness. Take a functional programmer, hive him clash and he'll have no problems doing things in parallel.
Back when I was a systems programmer, I tried learning system verilog. Had zero conceptual difficulty, but I just couldn't justify to myself why I should spend my time on something so outdated and badly designed. Hardware designers at my company at the time were on the other hand ok with verilog because they haven't seen any programming languages other than C and Python, and had no expectations.
The issue isn't the languages, it's the horrible tooling around them. I'm not going to install a multi GB proprietary IDE that needs a GUI for everything and doesn't operate with any of my existing tools. An IDE that costs money, even though I already bought the hardware. Or requires an NDA. F** that.
I want to be able to do `cargo add risc-v` if I need a small cpu IP, and not sacrifice a goat.
Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
module add :
int#(FROM:-8, TO: 8) a,
int#(FROM: 2, TO: 20) b ->
int c {
c = a+b
}
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.
It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler
You can pretty much do everything in Vivado from the command line as long as you know Tcl...
Also, modern Verilog (AKA Systemverilog) fixes a bunch of the issues you might have had. There isn't much advantage to VHDL these days unless perhaps you are in Europe or work in certain US defense companies.
The main advantage to VHDL is the style of thinking it enforces. If you write your Verilog or SystemVerilog like it's VHDL, everything works great. If you write your VHDL like it's Verilog, you'll get piles of synthesis errors... and many of them will be real problems.
So if you learn VHDL first, you'll be on a solid footing.
I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.
There is a trend among programmers to assume that everything supported by the syntax can be done. This is not even true in C++, but it's something people think. If you are writing synthesizable SystemVerilog, only a small subset of the language used in a particular set of ways works. You have to resist the urge to get too clever (in some ways, but in other ways you can get extremely clever with it).
Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…
I should have said "most _professional_ FPGA users" because I assume many people here who don't know this (including the author of the article) are not.
> software developers generally aren't very good at doing things in parallel
If only hardware people would stop stereotyping. Also, do you guys not use use formal tools (BMC etc) now? Who do you think wrote those tools? Heck all the EDA stuff was designed by software people.
I just can't with the gatekeeping.
(Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on reddit and elsewhere. It's damn frustrating to say the least. Also, the worst thing is all the hardware folks only know C so they think all programming is imperative. VDHL is Ada for crying out loud.)
Yeah I agree it is a lack of understanding on how to use the tools. The main issue I ran into in my undergrad FPGA class as a CS student was a lack of understanding on how to use the IDE. We jumped right into trying to get something running on the board instead of taking time to get everything set up. IMO it would have been way easier if my class used an IDE that was as simple as Arduino instead of everyone trying to run a virtual machine on their macbooks to run Quartus Prime.
FPGAs need their "Arduino moment". There have been so, so, so many projects where I've wanted just a little bit of moderately-complicated glue logic. Something pretty easy to dash off in VHDL or whatever. But the damn things require so much support infrastructure: they're complicated to put down on boards, they're complicated to load bitstreams in to, they're complicated to build those bitstreams for, and they're complicated to manage the software projects for.
As soon as they reach the point where it's as easy to put down an FPGA as it is an old STM32 or whatever, they'll get a lot more interesting.
The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
Loading them is a matter of plugging in a JTAG cable and typing “make program”.
I don’t know what you mean with the “manage SW projects for”?
> you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts.
Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing horsepower. And sometimes you need the certainty of hardware timing, which you get on a gate array and don't get any time there's a processor involved. Or, often, what I actually need is just a little bit of weird logic that's asynchronous, but too hard to do with the remnants of 74-series or 4000-series logic that are still available.
> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
It is not complicated for people who have spent a long time learning and who have past designs they can copy from. (I have a few of those myself.) It is nasty to explain to a new person and very nasty to explain well enough to reproduce in the future without me around.
> Loading them is a matter of plugging in a JTAG cable and typing “make program”.
Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is possible. It is still a giant headache, and quite a bit worse than just dealing with an MCU.
> I don’t know what you mean with the “manage SW projects for”?
> often, what I actually need is just a little bit of weird logic that's asynchronous
As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been wonderful if I could spend a little bit of money, buy a programmable thing in a 24-pin package, put it down, figure out some way to get the bitstream in (this is never pleasant in medium-volume manufacturing, so it's not like we're going to solve it now), and get my gate function that is literally one line of HDL. One. Line.
As it was, a 21-input OR gate is so much work in 74-series logic that I abandoned that whole thing and we did the bigger-picture job in a different, worse, way.
No, it wasn't. Those are mostly available in PLCC and DIP packages and even if you can get the SOIC/TSSOP versions they still cost $1.20 each at 10k volume. That's flat-out unacceptable for 99% of the things I do. The entire rest of the board I was talking about was $4.60. Processor included. $1.20 is not going to fly.
Hey, that was my problem from last week. And, yes, I agree with you -- it was best solved another way.
But please don't complain when I give concrete examples of things I'd like to do but couldn't. (And please do recognize that there was a lot more context to the mess than just "I need an OR gate", but no one cares about the real gory details.)
> and quite a bit worse than just dealing with an MCU.
Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming..
These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before, either.
Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?
Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive?
Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that....
You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't. I am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.
Embed the bitstream into your MCU firmware binary, bitbang the 50-100KB bitstream into SRAM via JTAG from your MCU in all of 10ms. This is <100 lines of Rust.
Yes, it's solvable. But my whole argument is that the entire experience is death by a thousand cuts. I'm not seeing how "it's possible in 100 lines of Rust" (a language most people don't even use for embedded work) is really countering my argument.
I honestly start to wonder how in the world we survived flashing 3 different binaries, for years (bitstream, 2 MCUs), without ever getting a complaint from the production floor.
And sometimes you need support for multiple IO standards.
I don’t understand what point you’re trying to get across.
But if all you need is LVCMOS33, why do you not use a MAX10 FPGA with built-in voltage regulator? Or a similar FPGA device from GoWin that is positioned as a MAX10 alternative? What is wrong with those?
> JTAG
On our production line, we use JTAG to program the FPGA? We literally used the same “make program” command for development and production. That was for production volumes considerably larger than 100k.
> ISE
ISE was end of life’d when I started using FPGAs professionally. That was in 2012. The only reason it still exists is because some hold-outs are still using Spartan 6.
> I don’t understand what point you’re trying to get across.
My point is twofold:
1. There are many niches. Your main needs are not the same as my main needs. And my needs are poorly met by existing products, so I want to see something better. (And I do buy chips.)
2. All of this is way, way harder than it needs to be. It could be easy, but it isn't. Everything is possible right now. But I wasn't random when I used the dreaded A-word ("Arduino"). Arduino is a kind of horrible product that did not make anything possible and did not really invent anything. It did not make anything really hard suddenly become easy. Hard things before Arduino were still hard after Arduino. It "just" made some things that used to be medium-hard pains-in-the-butt actually really quick and easy (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!).
It turns out that is very valuable.
And is what I would like to see happen with FPGAs: make them easy to drop in instead of pains in the butt. All pieces for this exist, nothing is new tech, no major revolutions need to happen. "Just" ease of use.
> It did not make anything really hard suddenly become easy.
It did. Onboarding people onto embedded programmer.
You just ran it, wrote few lines and you had working blinky. Write some more and you have useful toy. You could even technically make products with it but going from this to C++ was easier coz you already know what you could do, just needed to go thru pain of switching the toolchain once you're already invested.
Compare that to "you need to setup compiler, toolchain, SDK, figure out how to program the resulting binary, map the registers to your devboard pins etc."
It's already happened, people just haven't realized. iCE40-UP5K costs a few bucks, needs minimal support circuitry, and is supported by FOSS toolchains (yosys). Fun packages like the pico-ice bring it all the way down to the entry-level arduino crowd. It just doesn't have the marketing mindshare.
I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!
This is your job, and it really shouldn't feel difficult. This is really not tedious: the minimum board design for these chips literally consists of just power, JTAG pins, and a clock (if the internal oscillator isn't good enough.)
The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for <$1-2 in China. Efinix are available from DigiKey, with some SKUs under <$10.
All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)
I wish CPLDs were more well known in the common vernacular.
The industry draws a distinction between CPLDs and FPGAs, and rightly so, but most "Arduino-level" hobbyists think "I want something I can program so that it acts like such-and-such a circuit, I know, I need an FPGA!" when what they probably want is what the professional world would call a CPLD - and the distinction in terminology between the two does more to confuse than to clarify.
I don't know how to fix this; it'd be lovely if the two followed convergent paths, with FPGAs gaining on-board storage and the line between them blurring. Or maybe we need a common term that encompasses both. ("Programmable logic device" is technically that, but no-one knows that.)
I don’t know anything about this (other than doing mediocre in some undergrad Verilog classes one million years ago). Wikipedia seems to call FPGAs a type of PLD. Of course, everybody has heard of FPGAs; is it right to think they’ve sort of branched off, become their own thing, and eclipsed their superset?
"Programmed like an EEPROM" is part of the problem, any system that needs more than one piece of firmware to be wrangled during the assembly/bringup process is asking for pain.
But, really, no one cares what's inside the box. CPLD or FPGA, they're all about the same. The available PLDs are still not really acceptable. There's a bunch of 5V dinosaurs that the manufacturers would obviously love to axe, and a few tiny little micro-BGA things where you've got to be buying 100k to even submit a documentation bug report. Not much for stuff in the middle.
It's basically because they're so locked down, hard to get docs, stupid toolchains and ides like others have mentioned.
It's like fpga companies don't want people using them, much like others like the pixart sensor I wanted to use: NDA because some parasite dipshit executive or manager thinks that register layouts are extremely sensitive information.
I've had dozens of uses for an fpga...but every single time I just can't be bothered. Why, when they make it a pain in the ass on purpose.
This is exactly it. Why hasn't some expert group produced a very simple open design board with a simple Arduino-like IDE for FPGAs? Make it easy to access and use, get it into the hands of makers/hobbyists and watch the apps/ecosystem explode.
As an example, one could provide soft-cores for 8051/RISC-V etc. right out of the box with a menu of peripherals to mix and match. Provide a simple language library wrapper say over SystemVerilog (or whatever the community settles on) just like Arduino did (with C++) that makes it "easy" to program the FPGA.
For apps, one good example would be putting TinyML (or any other ML/LLM models)
on a FPGA. This would take advantage of the current technology wave to make this project a success.
My prediction is one of the Chinese FPGA makers will embrace open source, hire a handful of talented open source contributors, and within a handful of years end up with tooling that is way easier to use for hobbyists, students, and small businesses. They use this as an inroad and slowly move upmarket. Basically the Espressif strategy.
Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice especially it seems like a no brainer but they don’t understand the appeal of open source still.
Gowin and Efinix's tools are extremely spartan compared to Vivado or Quartus: they're pretty much straight HDL to bitstream compilers. There's also a FOSS implementation flow available for the Gowin chips (but I haven't used it.)
HDL isn't getting any easier, though, and that's where most of the complexity is.
> My prediction is one of the Chinese FPGA makers will embrace open source
Sadly, this doesn't seem to be panning out because the Chinese domestic market has perfectly functional Xilinx and Altera clones for a fraction of the price. Consequently, they don't care about anything else.
It irritates me to no end that Gowin won't open their bitstream format because they'd displace a bunch of the low end almost immediately.
This article is a rant about how bad tools are without going into specifics. "VHDL and Verilog are relics", well so is "C" but they all get the job done if you've been shown how to use them properly.
"engineers are stuck using outdated languages inside proprietary IDEs that feel like time capsules from another century.". The article misses that Vivado was developed in the 2010's and released around 2013. It's a huge step-up from ISE if you know how to drive it properly and THIS is the main point that the original author misses. You need to have a different mindset when writing hardware and it's not easy to find training that shows how to do it right.
If you venture into the world of digital logic design without a guide or mentor, then you're going to encounter all the pitfalls and get frustrated.
My daily Vivado experience involves typing "make", then waiting for the result and analysing from there (if necessary). It takes experience to set up a hardware project like this, but once you get there it's compatible with standard version control, CI tools, regression tests and the other nice things you expect form a modern development environment.
I've managed to make nice 'make' flows for Vivado, ISE, Quartus and DC. Libero took a bit more poking, but it's also possible.
The GUI interfaces are what newcomers tend to aim for straight away, but they're not good for any long-term "repeatable" build flows and they're no use for CI. I think this is where a lot of the frustration comes from.
I think my real problem is that xilinx pushes the gui flows heavily. It is extremely annoying to configure the mpsoc fabrics entirely outside of vivado. Same thing for using any of their bundled IP.
Yes, IP usage is awkward and tricky. You can use the GUI to make the initial .xci file or .tcl file, but when you build a project, you need to use the same version of Vivado that the IP core was originally created in. Xilinx have improved that a little with 'write_ip_tcl' and 'write_bd_tcl' now having flags that let you ignore the version (or minor version). I've not had time to try those yet.
If performant FPGAs were more accessible we’d be able to download models directly into custom silicon, locally, and unlock innovation in inference hardware optimizations. The highest grade FPGAs also have HBM memory and are competitive (on paper) to GPUs. To my understanding this would be a rough hobbyist version of what Cerebras and Groq are doing with their LPUs.
Unlikely this will ever happen but one can always dream.
On the software front as mentioned VHDL and Verilog are showing their age with their design as well as ther tooling ecosystem.Attempts such as CHISEL[1] (written in Scala)also havent gotten much traction - seeing also the language choice - would have btter have been in something more accesible like kotlin/ocaml.
Secondly the integration with consumer devices and OS is almost non-ecistant - it should really be simpler to interact with ala GPU/Network chip and have more mainboards with lowcost integrated FPGAs even if they are only a couple of hundred of logic cells.
This article could’ve been written 20 years ago with only minor revisions, and it would’ve been true then. But it’s not now. It is trivial, literally a day of work, to set up a build system and CICD environment using Verilator if you are already proficient with your build system of choice. Learning TCL to script a bitfile generation target using your FPGA vendor’s tools is a few extra days of work. And regarding IDE support, the authors complain about the experience of writing code in the vendor GUI. They should look at one of the numerous fully featured systemverilog LSPs available in e.g. VS Code.
The real argument for open source toolchains is much narrower in scope and implying its requirement for fixing a nonexistent tool problem is absurd
I imagine FPGA could just be part of general CPU that provides user space APIs to program them to accelerate certain work flow, in other words, this sounds like exactly JIT to me. People may program FPGA as they need to, e.g. AV1 encoder/decoder, accelerate some NN layers, or even a JS runtime, am I thinking something too wild for hardware capability or is it just the ecosystem isn't there yet to allow such flexible use cases?
Digital logic design isn't software programming, and today's FPGAs are for most intents and purposes 'single-configuration-at-a-time' devices - you can't realistically time-slice them.
The placement and routing flow of these devices is an NP-Complete problem and is relatively non-deterministic* (the exact same HDL will typically produce identical results, but even slightly different HDL can produce radically different results.)
All of these use cases you've mentioned (AV1 decoders, NN layers, but especially a JS runtime) require phenomenal amounts of physical die area, even on modern processes. CPUs will run circles around the practical die area you can afford to spare - at massively higher clock speeds - for all but the most niche of problems.
FPGA toolchains certainly could do with being pulled out of the gutter but I don't think that alone will lead to much of a renaissance for them. Almost definitionally they're for niches: applications which need something weird in hardware but aren't big enough to demand dedicated silicon, because the flexibility of FPGAs comes at a big cost in die area (read:price), power, and speed.
It seems to me that there are exactly 3 buyers for FPGAs: Government contractors (who spend millions all at once), retro gamers (small market), and electronics hobbyists (another small market). It's no wonder every company has orientated itself towards the first one. I look to China to accidentally make chips that are an order of magnitude better "just because they can".
Making FPGA's actually available (without encumbering stacks) would be so great. Companies IMO do better when they stop operating from within their moat & this would be such the amazing use case to lend support for that hypothesis.
Gowin and Efinix, like Lattice, have some very interesting new FPGAs, that they've innovated hard on, but which still are only so-so available.
Particularly with AI about, having open source stacks really should be a major door opening function. There could be such an OpenROAD type moment for FPGAs!
Its both depending on context. If HDL becomes custom silicon then it needs to be treated like hardware. If you can easily deploy field updates to your device then it's no different than any other firmware
To folks who wax lyrical about FPGAs: why do they need a future?
I agree with another commenter: I think there are parallels to "the bitter lesson" here. There's little reason for specialized solutions when increasingly capable general-purpose platforms are getting faster, cheaper, and more energy efficient with every passing month. Another software engineering analogy is that you almost never need to write in assembly because higher-level languages are pretty amazing. Don't get me wrong, when you need assembly, you need assembly. But I'm not wishing for an assembly programming renaissance, because what would be the point of that?
FPGAs were a niche solution when they first came out, and they're arguably even more niche now. Most people don't need to learn about them and we don't need to make them ubiquitous and cheap.
I can't say I agree with you here, if anything FPGAs and general purpose microprocessors go hand in hand. It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm. Currently this is all handled by fixed function silicon which rapidly becomes obsolete. AV1 support is only just now appearing in mainstream chips after almost 8 years, and soon AV2 will be out and the cycle will repeat.
This is such a severe problem that even now, (20+ year old) H.264 is the only codec that you can safely assume every end-user will be able to play, and H.264 consumes 2x (if not more) bandwidth compared to modern codecs at the same perceived image quality. There are still large subsets of users that cannot play any codecs newer than this without falling back to (heavy and power intensive) software decoding. Being able to simply load a new video codec into hardware would be revolutionary, and that's only one possible use case.
But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder).
Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer would do. Sure, except doing it the "right" way is actually slower, more expensive, and less flexible, so why bother?
...which are playing back video, so they're likely blowing most of their power budget on the display and on radio. I guess my threshold of "amazing" is different. Again, I'm not denying some incremental utility in specialized uses, but most of the time, it just doesn't seem to be worth the pain - especially since nothing about the implementation will be portable or maintainable in the long haul.
In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.
And you think that a downloaded codec on an FPGA would perform anywhere close to custom silicon? Because it won't; configurability comes at a steep cost.
One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are forcing down our throats.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
I just remembered I have a Xilinx I bought over a decade ago lying around somewhere. I don't remember ever plugging it in, but I do both the excitement of getting it and trying to figure out the toolchain and getting confused.
I'm all for your endeavor, but didn't see a device support list on your front page. Clicked the first of 2 links in your sidebar (docs) and got a 404. I'm not saying it's telling that your issues page works when your docs page doesn't, but it's not the foot I would have put forward.
Modern large productivity software (including IDE) are often "fragile".
Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.
Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.
Sometimes the IDE itself has random bugs.
A lot of time is spent workarounding IDE issues
Building for an fpga shouldn’t be any harder than building for cortex mcus, and there are lots of free/oss toolchains and configurations for those.
The issue with the software team using an FPGA is that software developers generally aren't very good at doing things in parallel. They generally do a poor job in implementing hardware. I previously taught undergraduates VHDL, the software students generally struggles with the dealing with things running in parallel.
VHDL and Verilog are used because they are excellent languages to describe hardware. The tools don't really hold anyone back. Lack of training or understanding might.
Consistently the issue with FPGA development for many years was that by the time you could get your hands on the latest devices, general purpose CPUs were good enough. The reality is that if you are going to build a custom piece of hardware then you are going to have to write the driver's and code yourself. It's achievable, however, it requires more skill than pure software programming.
Again, thanks to low power an slow cost arm processors a class of problems previously handled by FPGAs have been picked up by cheap but fast processors.
The reality is that for major markets custom hardware tends to win as you can make it smaller, faster and cheaper. The probability is someone will have built and tested it on an FPGA first.
> VHDL and Verilog are used because they are excellent languages to describe hardware.
Maybe they were in the 80. In 2025, language design has moved ahead quite a lot, you can't be saying that seriously.
Have a look at how clash-lang does it. It uses functional paradigm, which is much more suitable for circuits than pseudo-pricedural style of verilog. You can also parameterize modules by modules, not just by bitness. Take a functional programmer, hive him clash and he'll have no problems doing things in parallel.
Back when I was a systems programmer, I tried learning system verilog. Had zero conceptual difficulty, but I just couldn't justify to myself why I should spend my time on something so outdated and badly designed. Hardware designers at my company at the time were on the other hand ok with verilog because they haven't seen any programming languages other than C and Python, and had no expectations.
VHDL is ok, Verilog is a sin.
The issue isn't the languages, it's the horrible tooling around them. I'm not going to install a multi GB proprietary IDE that needs a GUI for everything and doesn't operate with any of my existing tools. An IDE that costs money, even though I already bought the hardware. Or requires an NDA. F** that.
I want to be able to do `cargo add risc-v` if I need a small cpu IP, and not sacrifice a goat.
Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler
Language really isn't the difficulty. That's why there's a thousand alt-HDLs that have been used for little more than blinking LEDs.
VHDL was designed for specification. Verilog is the one with the warts from its simulator heritage.
You can pretty much do everything in Vivado from the command line as long as you know Tcl...
Also, modern Verilog (AKA Systemverilog) fixes a bunch of the issues you might have had. There isn't much advantage to VHDL these days unless perhaps you are in Europe or work in certain US defense companies.
# Here's the general flow for Vivado TCL projects that takes you from source code to a bit-file with no interaction. Read UG835 for details.
create_project -in_memory -part ${PART}
set_property target_language VHDL [ current_project ]
read_vhdl "my_hdl_file.vhd"
synth_design -top my_hdl_top_module_name -part ${PART}
opt_design
place_design
route_design
check_timing -file my_timing.txt
report_utilization -file my_util.txt
write_checkpoint my_routed_design.dcp
write_bitstream my_bitfile.bit
The main advantage to VHDL is the style of thinking it enforces. If you write your Verilog or SystemVerilog like it's VHDL, everything works great. If you write your VHDL like it's Verilog, you'll get piles of synthesis errors... and many of them will be real problems.
So if you learn VHDL first, you'll be on a solid footing.
I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.
There is a trend among programmers to assume that everything supported by the syntax can be done. This is not even true in C++, but it's something people think. If you are writing synthesizable SystemVerilog, only a small subset of the language used in a particular set of ways works. You have to resist the urge to get too clever (in some ways, but in other ways you can get extremely clever with it).
I thought that if you have some idea about how hardware works, it is kind of more or less obvious whether something is synthesizable or not.
Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…
This is how most FPGA users interact with vivado/quartus these days.
One really wonders when reading some of the comments here…
I should have said "most _professional_ FPGA users" because I assume many people here who don't know this (including the author of the article) are not.
> software developers generally aren't very good at doing things in parallel
If only hardware people would stop stereotyping. Also, do you guys not use use formal tools (BMC etc) now? Who do you think wrote those tools? Heck all the EDA stuff was designed by software people.
I just can't with the gatekeeping.
(Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on reddit and elsewhere. It's damn frustrating to say the least. Also, the worst thing is all the hardware folks only know C so they think all programming is imperative. VDHL is Ada for crying out loud.)
Yeah I agree it is a lack of understanding on how to use the tools. The main issue I ran into in my undergrad FPGA class as a CS student was a lack of understanding on how to use the IDE. We jumped right into trying to get something running on the board instead of taking time to get everything set up. IMO it would have been way easier if my class used an IDE that was as simple as Arduino instead of everyone trying to run a virtual machine on their macbooks to run Quartus Prime.
FPGAs need their "Arduino moment". There have been so, so, so many projects where I've wanted just a little bit of moderately-complicated glue logic. Something pretty easy to dash off in VHDL or whatever. But the damn things require so much support infrastructure: they're complicated to put down on boards, they're complicated to load bitstreams in to, they're complicated to build those bitstreams for, and they're complicated to manage the software projects for.
As soon as they reach the point where it's as easy to put down an FPGA as it is an old STM32 or whatever, they'll get a lot more interesting.
The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
Loading them is a matter of plugging in a JTAG cable and typing “make program”.
I don’t know what you mean with the “manage SW projects for”?
> you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts.
Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing horsepower. And sometimes you need the certainty of hardware timing, which you get on a gate array and don't get any time there's a processor involved. Or, often, what I actually need is just a little bit of weird logic that's asynchronous, but too hard to do with the remnants of 74-series or 4000-series logic that are still available.
> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
It is not complicated for people who have spent a long time learning and who have past designs they can copy from. (I have a few of those myself.) It is nasty to explain to a new person and very nasty to explain well enough to reproduce in the future without me around.
> Loading them is a matter of plugging in a JTAG cable and typing “make program”.
Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is possible. It is still a giant headache, and quite a bit worse than just dealing with an MCU.
> I don’t know what you mean with the “manage SW projects for”?
Two words: Xilinx ISE.
> often, what I actually need is just a little bit of weird logic that's asynchronous
As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been wonderful if I could spend a little bit of money, buy a programmable thing in a 24-pin package, put it down, figure out some way to get the bitstream in (this is never pleasant in medium-volume manufacturing, so it's not like we're going to solve it now), and get my gate function that is literally one line of HDL. One. Line.
As it was, a 21-input OR gate is so much work in 74-series logic that I abandoned that whole thing and we did the bigger-picture job in a different, worse, way.
The device that you were looking was not an FPGA but a GAL22V10L.
No, it wasn't. Those are mostly available in PLCC and DIP packages and even if you can get the SOIC/TSSOP versions they still cost $1.20 each at 10k volume. That's flat-out unacceptable for 99% of the things I do. The entire rest of the board I was talking about was $4.60. Processor included. $1.20 is not going to fly.
“Reduces use case and requirements to something impossibly niche and low volume then yells at the clouds.”
Anyway, just tie the output of 21 emitter followers together, add a resistor and - tadaaa - 21 input OR!
Hey, that was my problem from last week. And, yes, I agree with you -- it was best solved another way.
But please don't complain when I give concrete examples of things I'd like to do but couldn't. (And please do recognize that there was a lot more context to the mess than just "I need an OR gate", but no one cares about the real gory details.)
> and quite a bit worse than just dealing with an MCU.
Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming..
These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before, either.
It's mostly the whole "two binaries" problem.
Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?
Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive?
Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that....
You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't. I am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.
Embed the bitstream into your MCU firmware binary, bitbang the 50-100KB bitstream into SRAM via JTAG from your MCU in all of 10ms. This is <100 lines of Rust.
Yes, it's solvable. But my whole argument is that the entire experience is death by a thousand cuts. I'm not seeing how "it's possible in 100 lines of Rust" (a language most people don't even use for embedded work) is really countering my argument.
I honestly start to wonder how in the world we survived flashing 3 different binaries, for years (bitstream, 2 MCUs), without ever getting a complaint from the production floor.
I should check my spam folder.
> sometimes … sometimes … sometimes …
And sometimes you need support for multiple IO standards.
I don’t understand what point you’re trying to get across.
But if all you need is LVCMOS33, why do you not use a MAX10 FPGA with built-in voltage regulator? Or a similar FPGA device from GoWin that is positioned as a MAX10 alternative? What is wrong with those?
> JTAG
On our production line, we use JTAG to program the FPGA? We literally used the same “make program” command for development and production. That was for production volumes considerably larger than 100k.
> ISE
ISE was end of life’d when I started using FPGAs professionally. That was in 2012. The only reason it still exists is because some hold-outs are still using Spartan 6.
> I don’t understand what point you’re trying to get across.
My point is twofold:
1. There are many niches. Your main needs are not the same as my main needs. And my needs are poorly met by existing products, so I want to see something better. (And I do buy chips.)
2. All of this is way, way harder than it needs to be. It could be easy, but it isn't. Everything is possible right now. But I wasn't random when I used the dreaded A-word ("Arduino"). Arduino is a kind of horrible product that did not make anything possible and did not really invent anything. It did not make anything really hard suddenly become easy. Hard things before Arduino were still hard after Arduino. It "just" made some things that used to be medium-hard pains-in-the-butt actually really quick and easy (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!).
It turns out that is very valuable.
And is what I would like to see happen with FPGAs: make them easy to drop in instead of pains in the butt. All pieces for this exist, nothing is new tech, no major revolutions need to happen. "Just" ease of use.
> It did not make anything really hard suddenly become easy.
It did. Onboarding people onto embedded programmer.
You just ran it, wrote few lines and you had working blinky. Write some more and you have useful toy. You could even technically make products with it but going from this to C++ was easier coz you already know what you could do, just needed to go thru pain of switching the toolchain once you're already invested.
Compare that to "you need to setup compiler, toolchain, SDK, figure out how to program the resulting binary, map the registers to your devboard pins etc."
> make them easy to drop in instead of pains in the butt
How much easier does it need to be than putting down a single 1mm^2 LDO and a QFN IC? Is this really that difficult?
It's already happened, people just haven't realized. iCE40-UP5K costs a few bucks, needs minimal support circuitry, and is supported by FOSS toolchains (yosys). Fun packages like the pico-ice bring it all the way down to the entry-level arduino crowd. It just doesn't have the marketing mindshare.
They can't, by nature of the proprietary bitstream. Arduino was only built thanks to ability to do whatever they wanted with open source compilers
> they're complicated to put down on boards
https://gowinsemi.com/en/product/detail/46/
- Requires just 1V2 + 3V3
- Available in QFN
- Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence
https://www.efinixinc.com/products-trion.html
The Altera Max 10 devices are also relatively simple to support (flash on the chip, few power rails, etc.)
> Contact Sales
> Request Sample
> Please login to download the document.
I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!
This is your job, and it really shouldn't feel difficult. This is really not tedious: the minimum board design for these chips literally consists of just power, JTAG pins, and a clock (if the internal oscillator isn't good enough.)
The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for <$1-2 in China. Efinix are available from DigiKey, with some SKUs under <$10.
All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)
Sounds like a PLD might suit your usecase? Simpler than an FPGA, programmed like an EEPROM, perfect for glue logic.
I wish CPLDs were more well known in the common vernacular.
The industry draws a distinction between CPLDs and FPGAs, and rightly so, but most "Arduino-level" hobbyists think "I want something I can program so that it acts like such-and-such a circuit, I know, I need an FPGA!" when what they probably want is what the professional world would call a CPLD - and the distinction in terminology between the two does more to confuse than to clarify.
I don't know how to fix this; it'd be lovely if the two followed convergent paths, with FPGAs gaining on-board storage and the line between them blurring. Or maybe we need a common term that encompasses both. ("Programmable logic device" is technically that, but no-one knows that.)
Anyway. CPLDs are neat.
I don’t know anything about this (other than doing mediocre in some undergrad Verilog classes one million years ago). Wikipedia seems to call FPGAs a type of PLD. Of course, everybody has heard of FPGAs; is it right to think they’ve sort of branched off, become their own thing, and eclipsed their superset?
"Programmed like an EEPROM" is part of the problem, any system that needs more than one piece of firmware to be wrangled during the assembly/bringup process is asking for pain.
But, really, no one cares what's inside the box. CPLD or FPGA, they're all about the same. The available PLDs are still not really acceptable. There's a bunch of 5V dinosaurs that the manufacturers would obviously love to axe, and a few tiny little micro-BGA things where you've got to be buying 100k to even submit a documentation bug report. Not much for stuff in the middle.
It's basically because they're so locked down, hard to get docs, stupid toolchains and ides like others have mentioned.
It's like fpga companies don't want people using them, much like others like the pixart sensor I wanted to use: NDA because some parasite dipshit executive or manager thinks that register layouts are extremely sensitive information.
I've had dozens of uses for an fpga...but every single time I just can't be bothered. Why, when they make it a pain in the ass on purpose.
None of these things are true for the new, cheap Chinese contenders.
> FPGAs need their "Arduino moment".
This is exactly it. Why hasn't some expert group produced a very simple open design board with a simple Arduino-like IDE for FPGAs? Make it easy to access and use, get it into the hands of makers/hobbyists and watch the apps/ecosystem explode.
As an example, one could provide soft-cores for 8051/RISC-V etc. right out of the box with a menu of peripherals to mix and match. Provide a simple language library wrapper say over SystemVerilog (or whatever the community settles on) just like Arduino did (with C++) that makes it "easy" to program the FPGA.
For apps, one good example would be putting TinyML (or any other ML/LLM models) on a FPGA. This would take advantage of the current technology wave to make this project a success.
PS: Folks might find the book FPGAs for Software Programmers by Dirk Koch et al. (https://link.springer.com/book/10.1007/978-3-319-26408-0) useful.
My prediction is one of the Chinese FPGA makers will embrace open source, hire a handful of talented open source contributors, and within a handful of years end up with tooling that is way easier to use for hobbyists, students, and small businesses. They use this as an inroad and slowly move upmarket. Basically the Espressif strategy.
Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice especially it seems like a no brainer but they don’t understand the appeal of open source still.
Gowin and Efinix's tools are extremely spartan compared to Vivado or Quartus: they're pretty much straight HDL to bitstream compilers. There's also a FOSS implementation flow available for the Gowin chips (but I haven't used it.)
HDL isn't getting any easier, though, and that's where most of the complexity is.
> My prediction is one of the Chinese FPGA makers will embrace open source
Sadly, this doesn't seem to be panning out because the Chinese domestic market has perfectly functional Xilinx and Altera clones for a fraction of the price. Consequently, they don't care about anything else.
It irritates me to no end that Gowin won't open their bitstream format because they'd displace a bunch of the low end almost immediately.
This article is a rant about how bad tools are without going into specifics. "VHDL and Verilog are relics", well so is "C" but they all get the job done if you've been shown how to use them properly.
"engineers are stuck using outdated languages inside proprietary IDEs that feel like time capsules from another century.". The article misses that Vivado was developed in the 2010's and released around 2013. It's a huge step-up from ISE if you know how to drive it properly and THIS is the main point that the original author misses. You need to have a different mindset when writing hardware and it's not easy to find training that shows how to do it right.
If you venture into the world of digital logic design without a guide or mentor, then you're going to encounter all the pitfalls and get frustrated.
My daily Vivado experience involves typing "make", then waiting for the result and analysing from there (if necessary). It takes experience to set up a hardware project like this, but once you get there it's compatible with standard version control, CI tools, regression tests and the other nice things you expect form a modern development environment.
> My daily Vivado experience involves typing "make", …
Exactly my experience with Quartus as well.
One really can’t help but wonder if those who always whine about the IDE/GUI just don’t know any better?
I've managed to make nice 'make' flows for Vivado, ISE, Quartus and DC. Libero took a bit more poking, but it's also possible.
The GUI interfaces are what newcomers tend to aim for straight away, but they're not good for any long-term "repeatable" build flows and they're no use for CI. I think this is where a lot of the frustration comes from.
I think my real problem is that xilinx pushes the gui flows heavily. It is extremely annoying to configure the mpsoc fabrics entirely outside of vivado. Same thing for using any of their bundled IP.
Yes, IP usage is awkward and tricky. You can use the GUI to make the initial .xci file or .tcl file, but when you build a project, you need to use the same version of Vivado that the IP core was originally created in. Xilinx have improved that a little with 'write_ip_tcl' and 'write_bd_tcl' now having flags that let you ignore the version (or minor version). I've not had time to try those yet.
"VHDL and Verilog are relics", well so is "C" but they all get the job done if you've been shown how to use them properly.
Or how to use an LLM properly.
If performant FPGAs were more accessible we’d be able to download models directly into custom silicon, locally, and unlock innovation in inference hardware optimizations. The highest grade FPGAs also have HBM memory and are competitive (on paper) to GPUs. To my understanding this would be a rough hobbyist version of what Cerebras and Groq are doing with their LPUs.
Unlikely this will ever happen but one can always dream.
> highest grade FPGAs also have HBM memory
The three SKUs between Xilinx and Altera that had HBM are no longer manufactured because Samsung Aquabolt was discontinued.
On the software front as mentioned VHDL and Verilog are showing their age with their design as well as ther tooling ecosystem.Attempts such as CHISEL[1] (written in Scala)also havent gotten much traction - seeing also the language choice - would have btter have been in something more accesible like kotlin/ocaml.
Secondly the integration with consumer devices and OS is almost non-ecistant - it should really be simpler to interact with ala GPU/Network chip and have more mainboards with lowcost integrated FPGAs even if they are only a couple of hundred of logic cells.
[1]https://github.com/chipsalliance/chisel/blob/main/README.md
This article could’ve been written 20 years ago with only minor revisions, and it would’ve been true then. But it’s not now. It is trivial, literally a day of work, to set up a build system and CICD environment using Verilator if you are already proficient with your build system of choice. Learning TCL to script a bitfile generation target using your FPGA vendor’s tools is a few extra days of work. And regarding IDE support, the authors complain about the experience of writing code in the vendor GUI. They should look at one of the numerous fully featured systemverilog LSPs available in e.g. VS Code.
The real argument for open source toolchains is much narrower in scope and implying its requirement for fixing a nonexistent tool problem is absurd
I did write this 20 years ago https://fpgacomputing.blogspot.com/2006/05/methods-for-recon...
The vendor tools are still a barrier to the high-end FPGA's hardened IP
I imagine FPGA could just be part of general CPU that provides user space APIs to program them to accelerate certain work flow, in other words, this sounds like exactly JIT to me. People may program FPGA as they need to, e.g. AV1 encoder/decoder, accelerate some NN layers, or even a JS runtime, am I thinking something too wild for hardware capability or is it just the ecosystem isn't there yet to allow such flexible use cases?
Digital logic design isn't software programming, and today's FPGAs are for most intents and purposes 'single-configuration-at-a-time' devices - you can't realistically time-slice them.
The placement and routing flow of these devices is an NP-Complete problem and is relatively non-deterministic* (the exact same HDL will typically produce identical results, but even slightly different HDL can produce radically different results.)
All of these use cases you've mentioned (AV1 decoders, NN layers, but especially a JS runtime) require phenomenal amounts of physical die area, even on modern processes. CPUs will run circles around the practical die area you can afford to spare - at massively higher clock speeds - for all but the most niche of problems.
FPGA toolchains certainly could do with being pulled out of the gutter but I don't think that alone will lead to much of a renaissance for them. Almost definitionally they're for niches: applications which need something weird in hardware but aren't big enough to demand dedicated silicon, because the flexibility of FPGAs comes at a big cost in die area (read:price), power, and speed.
It seems to me that there are exactly 3 buyers for FPGAs: Government contractors (who spend millions all at once), retro gamers (small market), and electronics hobbyists (another small market). It's no wonder every company has orientated itself towards the first one. I look to China to accidentally make chips that are an order of magnitude better "just because they can".
Making FPGA's actually available (without encumbering stacks) would be so great. Companies IMO do better when they stop operating from within their moat & this would be such the amazing use case to lend support for that hypothesis.
Gowin and Efinix, like Lattice, have some very interesting new FPGAs, that they've innovated hard on, but which still are only so-so available.
Particularly with AI about, having open source stacks really should be a major door opening function. There could be such an OpenROAD type moment for FPGAs!
No. FPGAs already have a future. You just don't know about it yet.
The problem is that FPGA companies don't see themselves as chip companies.
They see themselves as CAD software companies. The chip is just a copy-protection dongle.
Here’s the first big misconception: HDL is hardware. It isn’t. HDL is software and should be managed like software.
Yes, that's certainly a big misconception. Maybe not the one the author meant to call out, but... yes, a big misconception indeed.
Its both depending on context. If HDL becomes custom silicon then it needs to be treated like hardware. If you can easily deploy field updates to your device then it's no different than any other firmware
Cost is also such a big issue.
There are some reasonably affordable models like https://www.lcsc.com/product-detail/C5272996.html that are powerful enough for many tasks.
To folks who wax lyrical about FPGAs: why do they need a future?
I agree with another commenter: I think there are parallels to "the bitter lesson" here. There's little reason for specialized solutions when increasingly capable general-purpose platforms are getting faster, cheaper, and more energy efficient with every passing month. Another software engineering analogy is that you almost never need to write in assembly because higher-level languages are pretty amazing. Don't get me wrong, when you need assembly, you need assembly. But I'm not wishing for an assembly programming renaissance, because what would be the point of that?
FPGAs were a niche solution when they first came out, and they're arguably even more niche now. Most people don't need to learn about them and we don't need to make them ubiquitous and cheap.
I can't say I agree with you here, if anything FPGAs and general purpose microprocessors go hand in hand. It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm. Currently this is all handled by fixed function silicon which rapidly becomes obsolete. AV1 support is only just now appearing in mainstream chips after almost 8 years, and soon AV2 will be out and the cycle will repeat.
This is such a severe problem that even now, (20+ year old) H.264 is the only codec that you can safely assume every end-user will be able to play, and H.264 consumes 2x (if not more) bandwidth compared to modern codecs at the same perceived image quality. There are still large subsets of users that cannot play any codecs newer than this without falling back to (heavy and power intensive) software decoding. Being able to simply load a new video codec into hardware would be revolutionary, and that's only one possible use case.
But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder).
Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer would do. Sure, except doing it the "right" way is actually slower, more expensive, and less flexible, so why bother?
Battery powered or thermally constrained devices.
...which are playing back video, so they're likely blowing most of their power budget on the display and on radio. I guess my threshold of "amazing" is different. Again, I'm not denying some incremental utility in specialized uses, but most of the time, it just doesn't seem to be worth the pain - especially since nothing about the implementation will be portable or maintainable in the long haul.
In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.
And you think that a downloaded codec on an FPGA would perform anywhere close to custom silicon? Because it won't; configurability comes at a steep cost.
FPGAs are more like CGRAs these days. With the right DSP units, it could absolutely be competitive with custom silicon.
If Jim Keller says it, I’ll believe it.
My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.