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.
The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.
Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.
I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.
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.
Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
> it's just me and a professor of previously mentioned course who are actively involved in the project
Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.
I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.
## Irrelevant Complaining
Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.
I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
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.
Compiling RTL to run on an FPGA is way more complicated than compiling code to run on a CPU. Typically it has to meet timing, which requires detailed knowledge of logic placement. I'm not saying that's impossible, just that it's more complicated.
So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.
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 agree but I think that writing yet another IDE extension is not going to solve the problems. An IDE will bring you one step further away from the actual hardware, and makes it more difficult to solve unexpected problems. Also, not everybody likes IDEs, some just prefer Vim and the commandline. An IDE is not the magical solution here.
Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.
I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
Oh christ, absolutely this. We spent some time evaluating FPGA for our purposes and ended up GPU instead (algorithms we running can be adapted to strength of either).
The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.
Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!
We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.
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.
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.
A few times over the past decade I wanted to start with a side project where I design and develop a CPU.
I bought a relatively cheap artic 7 board with 33kLUT and whatnot which I know people have used to implement risc-v implementations on.
But then I always lost my patience on the tooling.
For a side projects these days I need something comfortable. Something that that I can easily switch my context to without having to juggle VMs and installing unfriendly tools and use horrible IDEs
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.
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.)
If only someone could make a single part that is very versatile, so that it could get production economies of scale while solving all the thousands of different random problems various people might have, whether they need a 21-input OR or something else. Like an array of gates, but field-programmable!
(That's a pretty steep price target even for a small FPGA though. With 16 pins maybe, but with 25?)
Would a SLG46880 work for you? It has 28 GPIOs, enough LUTs to make a 21-input OR gate, runs off 2.3-5.5V (two VCCIO partitions, but you can tie them together). It costs like a buck in 5k quantities - they used to be much cheaper when you bought them directly from Silego, but now that they've been acquired the price has been _improved_.
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."
> (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!)
Doesn't really matter if it does break; just use gcc and a Makefile like you would for any other firmware.
You probably want to replace the Arduino libraries with your own ones eventually anyway, because there's so much cruft in there that you're never going to use.
> 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.
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.)
You write RTL for them just like you do for FPGAs, you need to configure them as well. The only major benefit is that they don’t have a delay between power up and logic active? But that’s not something that would make a difference for most people.
CPLDs are also a dying breed and being replaced with FPGAs that have parallel on-board flash to allow fast configuration after power up. (e.g. MAX10)
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.
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.)
> All of the Gowin documentation is available on their site with a free, approval-less email login
The problem is trust. I'm hesitant to hand out my e-mail anywhere because far too often I have been hounded by salespeople as a result, not to mention data breaches or bombardment of newsletters.
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 haven't learned Verilog, only VHDL and even that with the explicit <register>_ff <= <register_nxt> pattern when I need flips flops and I never felt like there is anything difficult about VHDL
Is the North American insistence on teaching Verilog what's setting up students for failure since Verilog looks a bit more like a sequential programming language at first glance?
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.
Any good guides you'd recommend to get started? Also does this workflow work with the cheap Chinese FPGAs available on aliexpress (tang nano, etc)? I always wanted to try out FPGAs again and I prefer to work from command line when possible.
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.
> 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.)
I was very specific in using the word generally. I taught a mixture of computer science and electronic engineering students. About three to four times more electronic students were competent for every computer science student over the years I taught.
It's not a case of just stating computer scientist weren't capable of doing it. They struggled with the parallelism and struggled with the optimisations and placements when you had to make physical connections on chips.
I'm well aware it's mostly going to be computer scientists writing the tools we use.
For those that want FPGAs to take off like the Arduino platform, I agree. I'd love it. However, it isn't the tooling that's holding it back. The reality is it is that cheaper, faster and easier solutions already exist. Why would you use an FPGA?
And their cited example was students. I think students would struggle at something new until they 'get it'. Would a software developer who does FPGA development professionally struggle more than, say, a hardware engineer?
Sure but most of software development is about running single-core workflows on top of a parallel environment so the experience of a SWE is very heavily single-threaded.
The ever so popular JS is explicitly singlely threaded.
The default way of programming is with code on individual lines and when you run a debugger you step from one line to the next. This is not how code actually runs within a pipelined CPU though.
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.
But Vivado doesn't get the job done. The intended workflow is to click around in the GUI until it (hopefully) synthesizes something. The state is then recorded in some proprietary project file that cannot be version controlled or shared with other developers. The workaround is to generate some unholy mess of tcl scripts that automate the clicking, such that one can start from scratch for each synthesis. The scripting mess breaks with each minor release of Vivado, so you need to either never update, or have a separate (~100 GB) Vivado installation for every single project. And if your chip is more than a home-gamer ZYNQ, you hopefully like paying subscription fees for the experience.
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.
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.
For me, that means higher capacity and advanced blocks such as SERDES, high-speed DRAM interfaces etc.
The bottleneck in using these kind of FPGAs has rarely been the tools, it’s the amount of time it takes to write and verify correct RTL. That’s not an FPGA specific problem, it applies to ASIC just the same.
I don’t see how GoWin and other alternative brands would be better placed to solve that problem.
> 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.
> 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.
All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.
Support is stuck at the old levels--none of the GW5 series are implemented. This is just like how the Lattice support is similarly stuck at the ice40/ECP5 level which is almost a decade old.
Gowin seemingly doesn't even sell the chips to individuals. Either set up an LLC so you can request samples from a destributor, or desolder one from a sipeed dev kit.
I could order MOQ (minimum order quantity) of anywhere from 100-500 depending upon range. I didn't need to be an LLC, but it sure helps to actually know the lingo and understand how to deal with distributors and FAEs (field application engineers).
One thing you absolutely have to remember is that when it comes to distributors and FAEs is that as an individual you are wasting their time. Talking to anyone other than you is more profitable. Nevertheless, most won't ignore you (sales is their job, after all) but you very definitely have to make their lives as easy as possible and understand that you get their time after they have serviced everybody more profitable.
Tariffs made everything miserable because the FAEs and salespeople were up to their earballs dealing with the daily price swings of customers with actual volumes.
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.
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!
The whole place-and-route thing is completely wrong for using FPGAs as accelerators. We don't need an optimal layout, we need a tiled layout (like the GPU does). All that we need for this to happen is for the companies making the FPGAs to open up the board layout file spec. They don't need to even make/ship any software at all. Just ship the dang file that says where the resources & timings are and some instructions on how to toggle the LUT config.
My feeling is that hardware companies do better when they ship the software needed to utilize their hardware for free. (You need a little margin in the hardware price to cover the software development). However, the FPGA companies haven't figured this out. They try to make way too much software and charge exhorbitant fees for it, somehow thinking that their hardware is useless without that. In fact, their hardware is useless because I can't put anything on it without a 1-to-20 hour compile time. That makes it impossible to use it as an accelerator. I can compile OpenCL for my GPU in a few milliseconds; that's what we need for the FPGA. Even thirty seconds would be easily tolerable -- there's many a game that still requires 15 seconds to load a level and compile its shaders.
FPGAs could be much more useful than they are at present. They've artificially limited themselves to ASIC prototyping alone.
So Intel bought an FPGA company -- nobody knows why. AMD got scared and did the same thing with no clue what to do with it. They've both let them rot. Intel did start incorporating it into its compiler targets, but it was only half-baked. Now they've wisely divested themselves of the company, but it should have never happened. They should have just focused on selling the hardware at a small margin whilst opening up the data to use it.
You are presuming an existing tile IP - if you're already in possession of such an IP then the place and route is already coarse grained. There are lots of papers on this.
> (like the GPU does)
What exactly does the GPU do? Yes there are tiles but it's up to you to now tile your workload. You understand this is the exact same problem you're bemoaning re place and route - you need to figure out how to shuffle individual bits efficiently through an existing fabric (roughly it's the same thing as routing 32 wires at a time).
> we need for this to happen is for the companies making the FPGAs to open up the board layout file spec
What exactly is this going to do for you if you're placing tiles? Also you can already recover this by exhaustively enumerating all a->b paths (yes people really do this).
To anyone else that thinks they just absolutely are certain of the silver bullet for digital design: download a copy of Vivado and report back what you discover!
I was quite surprised the direction this article took. I wasn't expecting reheated whinging about the toolchain.
FPGAs do need a new future. They need a future where someone tapes out an FPGA! Xilinx produced Ultrascale+ over a decade ago and haven't done anything interesting since. Their Versal devices went off a tangent into SoCs, NOCs, AI engines - you know what they didn't do? Build a decent FPGA.
Altera did something ambitious back in 2014 when they proposed the hyper-register design, totally failed to execute on it and have been treading water because of the Intel cluster**. They're now an independent company but literally don't have anyone who knows how to tape out a chip.
I'm less familiar with the Lattice stuff, but since their most advanced product is still 16nm finfet I suspect they aren't doing anything newer than Xilinx or Altera.
We need a company that builds an FPGA. It doesn't matter what tooling you have because the fundamental performance gap between a custom FPGA solution and a CPU or GPU based solution is entirely eaten up by the fact the newest FPGA you can buy is a decade old and inexplicably still tens of thousands of dollars.
If FPGA technology had progressed at the same rate NVidia or Apple had pushed forward CPU/GPU performance, thered be some amazing opportunities to accelerate AI (on the path to then creating ASICs). But they haven't, so all the scaling laws have worked against them and the places they have a performance benefit have shrunk massively.
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
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.
Yes, if you're doing what everyone else is doing you can just use tensor cores and libraries which optimize for that.
Contrarily if you're doing something that doesn't map that well to tensor cores you have a problem: every generation a larger portion of the die is devoted to low/mixed precision mma operations. Maybe FGPAs can find a niche that is underserved by current GPUs, but I doubt it. Writing a cuda/hip/kokkos kernel is just soo much cheaper and accessible than vhdl it's not even funny.
AMD needs to invest in that: Let me write a small FPGA kernel in line in a python script, compile it instantly and let me pipe numpy arrays into that (similar to cupy rawkernels). If that workflow works and let's me iterate fast, I could be convinced to get deeper into it.
The primary niche of FPGAs is low latency, determinism and low power consumption. Basically what if you needed an MCU, or many MCUs but the ones in the market don't have enough processing power?
The Versal AI Edge line is very power efficient compared to trying to achieve the same number of FLOPs using a Ryzen based CPU.
An FPGA is like a spreadsheet for bits that can recalculate at hundreds of millions of times per second.
It's a declarative programming system, and there's a massive impedance match when you try to write source code for it in text. I suspect that something closer to flow charts, would be much easier to grok. Verilog is about as good at match as you are likely to get, if you stick with the source code approach to designing with them.
Very good metaphor. I'm going to use that in the future. It even has rows and columns.
Except the spreadsheet is a really accessible technology that's been cloned, while the critical problem with FPGA is the proprietary tooling. This is the same reason that NVIDIA made a gazillion dollars by turning GPUs into general purpose compute: a proper API, CUDA.
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.
I had the misfortune of working with the Xilinx Vivado environment, it's a fucking garbage, the software is straight out of the 90s, everything is glued together with shell scripts and the TCL scripting language, the IDE throws thousands of warnings and errors while building a sample project, the documentation is missing or spread over 150 PDFs, if the manufacturer of your evaluation board prepared an example for the previous version of Vivado, you must have two installations, which is probably about 2 * 100GB, if you want to keep anything under version control, you have to use some external tools, it's all absurd.
I knew someone who created a mandelbrot set viewer that would display over an VGA port, you had a game controller to move around and zoom into it. Something like that?
> I once hoped things would improve when Xilinx launched the Zynq line, combining a processor with FPGA fabric. Instead, the accompanying tools were so unusable that they made things worse, pushing developers even further away.
I once tried to use Xilinx' Vitis (2025) to make a small-ish piece of software running on such a Zynq chip. After wrestling with it* for like 5 weeks, me and my colleagues decided to ditch the entire Xilinx suite entirely and just pick a compiler and make a bare-metal binary with it. The FPGA part is done by a separate team of course, so us traditional software devs can stick with decent tools.
We actually opted for a Rust toolchain and I'm extremely glad we did this, despite the additional time it took.
I don't know how my FPGA colleagues work with the proprietary toolchains and not go insane.
*The IDE is effectively a wrapper with a custom python API around cmake and gcc. It's not very well written cmake and I also don't know how they configure the linker that it does the weird things it does.
Programming languages were originally designed by mathematicians based on a Turing machine. A modern language for FPGAs is a challenge for theoretical computer science, but we should keep computer literate researchers away from it. This is a call out to hard core maths heads to think about how we should think about parallelism and what FPGA hardware can do.
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.
I don't get the VHDL or Verilog hate. Digital IC design engineers have no problem with them. True, most of the industry moved to SystemVerilog, mainly for simulation and verification reasons.
It's the weirdnesses of FPGAs though. You aren't really designing a gate level circuit at the end. I'm not sure Verilog or VHDL are to blame here. Maybe they aren't fit for purpose to begin with. I hate the toolchains too. They got worse (sluggish, more paid IPs etc) in the last 15 years. IC design tools cost A LOT more (like 2-3 orders of magnitude more) comparatively but they just work at least!
Neat, but we've been in the same situation for a while. A couple years back, I wrote a tutorial for using an open source stack with the Nandland Go FPGA board: a simple Lattice board. This was because the FPGA book I bought from No Starch required Windows (shock and horror). This was 2023. Now we're coming up into 2026?
I don't understand why the fpga chip vendors don't sell direct to customers. You typically have to go through a distributor, and that entails quite a bit of markup. It doesn't lend itself to the hobby market like raspberry pi for example.
I program FPGAs professionally (Xilinx Zynq, VHDL). I agree that the tool's GUI is atrocious, the actual way to use it is to write everything in TCL scripts, and invoke the tools through a Makefile. I only open the GUI to look at timing issues or ask it for code templates.
I disagree with "HDL is software" though. It's not, it's even in the name: "hardware description language". Yes it's a text file with what looks a lot like regular code in it. However what's being decribed is how to connect boxes of logic together, and how to compute the output of the boxes from their inputs. There's no implicit program counter that's advancing from one line to the next.
It is (theoretically) possible to write these kind of things with a lot of abstraction, but every time you try that by using more advanced language features, you hit some bugs in the tool's implementation of the language. If you're lucky it'll tell you where you're doing undupported stuff. Often it'll crash. Sometimes it'll sythesize hardware that doesn't conform with the language spec.
Finally, FPGAs are simple only when you're looking at a bird's eye view (just like CPUs are simple when you're looking at a diagram with a few boxes saying "ALU", "Cache", "Registers"). The actual datasheets are thousands of pages long.
FPGAs are still useful though, their use case is "I need custom hardware and I don't have the volume to build an ASIC". For example, my application is a custom signal processing pipeline that's handling about 3.5 Gbit/s of streaming raw data. On a $40 chip.
I think my main point is that yes, the tooling is a pain to use, with heaps of bugs and bad language support. However a HDL is conceptually different from a software language and I'm not sure you can hide away the complexities of designing hardware behind "modern" language features.
For those suggesting diagram-based languages, go program something in LabView, you'll quickly understand why that's a bad idea (works for trivial designs, anything complex is an opaque mess of boxes and lines, unsearchable, and impossible to integrate with version control).
LabVIEW FPGA was amazing, I did all kinds of things with it on the compactRIO controller FPGA
You can write very neat and tidy code with dataflow diagram languages. I did it professionally for years, and there were many others who did as well.
Same thing as any other language, you have to come up ways to organize the code into functions and classes that make sense. Vomiting everything into the top level diagram is the same as 10000 line of code while(1)
You could always tell the exact level of proficiency someone had with LabVIEW immediately when opening the diagram.
The dataflow model maps very well to FPGAs IMO, it's a shame it never became widespread. There was much potential there
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
completely agree, it's a miserable environment for software developers. The Xilinx environment was a 1 GB download, EACH TIME they issued an update. I actually met with someone from higher up to give them some feedback, but they were clearly not interested in the slightest in making any changes.
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.
My rule of thumb is a 40x silicon area ratio between FPGA and ASIC, a clock speed that is around 5x lower. And a lot more power consumption.
If you have an application that can be done on a CPU, with lots of sequences dependencies (such as video compression/decompression), an FPGA doesn’t stand a chance compared to adding dedicated silicon area.
That’s even more so if you’d embed an FPGA on a CPU die. Intel tried it and you got a power hungry jack of all trades, master of none that nobody knew what to do with.
Xilinx MPSOC and RFSOC are successful, but their CPUs are comparatively lower performance and used as application specific orchestrators and never as a generic CPU that run traditional desktop or server software.
I have yet to see the "FPGA is less power efficient" thing to be true. People are always comparing the same circuit in an FPGA Vs an ASIC but this is a nonsensical comparison because of three reasons:
FPGAs have hard wired blocks like DSPs which do not have any power disadvantages vs "ASIC" (only advantages actually)
the likelihood that there is an ASIC that happens to implement your particular design is very low
and off the shelf ASICs like GPUs and CPUs have significant amounts of overhead for each operation. This is especially evident with CPUs. They perform a small number of operations per cycle, but they have to pay the entire fixed energy cost of caches, registers, instruction decoding, etc per cycle. This is way way worse than programmable logic if you're mostly using the DSP and the block RAM slices.
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".
> An FPGA, by contrast, defines data pathways specifying how signals change on each clock tick based on internal states and external inputs. In essence, we describe global per-clock-cycle behavior rather than an individual act of data manipulation per step.
I think that’s the clearest explanation of FPGAs I’ve ever seen.
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.
> It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm
That relies on "FPGAs everywhere", which is much further out than "GPUs everywhere".
I'm not sure where the state of the art is on this, but given the way that codecs work - bitstream splitting into tiles, each of which is numerically heavy but can be handled separately - how is development of hybrid codecs, where the GPU does the heavy lifting using its general purpose cores rather than fixed function decoder pipeline?
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.
This is exactly it.
The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.
Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.
I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.
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.
Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
> it's just me and a professor of previously mentioned course who are actively involved in the project
Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.
I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.
## Irrelevant Complaining
Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.
I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
have u looked at the teroshdl extension?
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.
Compiling RTL to run on an FPGA is way more complicated than compiling code to run on a CPU. Typically it has to meet timing, which requires detailed knowledge of logic placement. I'm not saying that's impossible, just that it's more complicated.
> shouldn’t
Is doing so much heavy lifting here, I need to ask; how much FPGA configuration you have done before?
Very little, just student projects in undergrad.
So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.
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 agree but I think that writing yet another IDE extension is not going to solve the problems. An IDE will bring you one step further away from the actual hardware, and makes it more difficult to solve unexpected problems. Also, not everybody likes IDEs, some just prefer Vim and the commandline. An IDE is not the magical solution here.
Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.
I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
Have you seen the YoWASP toolchain for VSCode [1]? It sounds pretty similar.
[1] https://github.com/YoWASP/vscode
Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
Oh christ, absolutely this. We spent some time evaluating FPGA for our purposes and ended up GPU instead (algorithms we running can be adapted to strength of either).
The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.
Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!
We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.
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.
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.
A few times over the past decade I wanted to start with a side project where I design and develop a CPU.
I bought a relatively cheap artic 7 board with 33kLUT and whatnot which I know people have used to implement risc-v implementations on.
But then I always lost my patience on the tooling.
For a side projects these days I need something comfortable. Something that that I can easily switch my context to without having to juggle VMs and installing unfriendly tools and use horrible IDEs
Funny enough it is available on an UPDuino board: https://tinyvision.ai/pages/the-upduino
> 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.
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.)
If only someone could make a single part that is very versatile, so that it could get production economies of scale while solving all the thousands of different random problems various people might have, whether they need a 21-input OR or something else. Like an array of gates, but field-programmable!
(That's a pretty steep price target even for a small FPGA though. With 16 pins maybe, but with 25?)
Would a SLG46880 work for you? It has 28 GPIOs, enough LUTs to make a 21-input OR gate, runs off 2.3-5.5V (two VCCIO partitions, but you can tie them together). It costs like a buck in 5k quantities - they used to be much cheaper when you bought them directly from Silego, but now that they've been acquired the price has been _improved_.
https://www.renesas.com/en/products/slg46880
> 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?
> (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!)
Doesn't really matter if it does break; just use gcc and a Makefile like you would for any other firmware.
You probably want to replace the Arduino libraries with your own ones eventually anyway, because there's so much cruft in there that you're never going to use.
> 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.
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 see how CPLDs solve anything?
You write RTL for them just like you do for FPGAs, you need to configure them as well. The only major benefit is that they don’t have a delay between power up and logic active? But that’s not something that would make a difference for most people.
CPLDs are also a dying breed and being replaced with FPGAs that have parallel on-board flash to allow fast configuration after power up. (e.g. MAX10)
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.
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
> 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.)
> All of the Gowin documentation is available on their site with a free, approval-less email login
The problem is trust. I'm hesitant to hand out my e-mail anywhere because far too often I have been hounded by salespeople as a result, not to mention data breaches or bombardment of newsletters.
So just use Google to obtain the documentation? Or a fake email? The PDFs are pretty easily obtainable by title:
https://www.google.com/search?q=gowin+user+guide+filetype%3A...
https://www.google.com/search?q=gowin+primitives+filetype%3A...
https://www.google.com/search?q=gowin+gw1n+filetype%3Apdf
If I really need something I'll go that route, yes. But for something that is just on a "cool, that might be interesting" it's too much effort.
The Altera Max 10 devices are also relatively simple to support (flash on the chip, few power rails, etc.)
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 haven't learned Verilog, only VHDL and even that with the explicit <register>_ff <= <register_nxt> pattern when I need flips flops and I never felt like there is anything difficult about VHDL
Is the North American insistence on teaching Verilog what's setting up students for failure since Verilog looks a bit more like a sequential programming language at first glance?
VHDL is based on Ada, so it also inherits from sequential programming models.
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.
Any good guides you'd recommend to get started? Also does this workflow work with the cheap Chinese FPGAs available on aliexpress (tang nano, etc)? I always wanted to try out FPGAs again and I prefer to work from command line when possible.
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.
> 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.)
I was very specific in using the word generally. I taught a mixture of computer science and electronic engineering students. About three to four times more electronic students were competent for every computer science student over the years I taught.
It's not a case of just stating computer scientist weren't capable of doing it. They struggled with the parallelism and struggled with the optimisations and placements when you had to make physical connections on chips.
I'm well aware it's mostly going to be computer scientists writing the tools we use.
For those that want FPGAs to take off like the Arduino platform, I agree. I'd love it. However, it isn't the tooling that's holding it back. The reality is it is that cheaper, faster and easier solutions already exist. Why would you use an FPGA?
And their cited example was students. I think students would struggle at something new until they 'get it'. Would a software developer who does FPGA development professionally struggle more than, say, a hardware engineer?
Sure but most of software development is about running single-core workflows on top of a parallel environment so the experience of a SWE is very heavily single-threaded.
The ever so popular JS is explicitly singlely threaded.
The default way of programming is with code on individual lines and when you run a debugger you step from one line to the next. This is not how code actually runs within a pipelined CPU though.
> EDA stuff was designed by software people.
No - EDA software is built by hardware experts moonlighting as software engineers, which is partly why it is so obtuse.
I said "was", not "is". Also, I know how that's working out. Working with Vivado makes me want to barf.
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.
But Vivado doesn't get the job done. The intended workflow is to click around in the GUI until it (hopefully) synthesizes something. The state is then recorded in some proprietary project file that cannot be version controlled or shared with other developers. The workaround is to generate some unholy mess of tcl scripts that automate the clicking, such that one can start from scratch for each synthesis. The scripting mess breaks with each minor release of Vivado, so you need to either never update, or have a separate (~100 GB) Vivado installation for every single project. And if your chip is more than a home-gamer ZYNQ, you hopefully like paying subscription fees for the experience.
"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.
> 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.
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.
Define “upmarket” ?
For me, that means higher capacity and advanced blocks such as SERDES, high-speed DRAM interfaces etc.
The bottleneck in using these kind of FPGAs has rarely been the tools, it’s the amount of time it takes to write and verify correct RTL. That’s not an FPGA specific problem, it applies to ASIC just the same.
I don’t see how GoWin and other alternative brands would be better placed to solve that problem.
> 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.
> 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.
All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.
Support is stuck at the old levels--none of the GW5 series are implemented. This is just like how the Lattice support is similarly stuck at the ice40/ECP5 level which is almost a decade old.
Gowin seemingly doesn't even sell the chips to individuals. Either set up an LLC so you can request samples from a destributor, or desolder one from a sipeed dev kit.
I could order MOQ (minimum order quantity) of anywhere from 100-500 depending upon range. I didn't need to be an LLC, but it sure helps to actually know the lingo and understand how to deal with distributors and FAEs (field application engineers).
One thing you absolutely have to remember is that when it comes to distributors and FAEs is that as an individual you are wasting their time. Talking to anyone other than you is more profitable. Nevertheless, most won't ignore you (sales is their job, after all) but you very definitely have to make their lives as easy as possible and understand that you get their time after they have serviced everybody more profitable.
Tariffs made everything miserable because the FAEs and salespeople were up to their earballs dealing with the daily price swings of customers with actual volumes.
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.
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!
The whole place-and-route thing is completely wrong for using FPGAs as accelerators. We don't need an optimal layout, we need a tiled layout (like the GPU does). All that we need for this to happen is for the companies making the FPGAs to open up the board layout file spec. They don't need to even make/ship any software at all. Just ship the dang file that says where the resources & timings are and some instructions on how to toggle the LUT config.
My feeling is that hardware companies do better when they ship the software needed to utilize their hardware for free. (You need a little margin in the hardware price to cover the software development). However, the FPGA companies haven't figured this out. They try to make way too much software and charge exhorbitant fees for it, somehow thinking that their hardware is useless without that. In fact, their hardware is useless because I can't put anything on it without a 1-to-20 hour compile time. That makes it impossible to use it as an accelerator. I can compile OpenCL for my GPU in a few milliseconds; that's what we need for the FPGA. Even thirty seconds would be easily tolerable -- there's many a game that still requires 15 seconds to load a level and compile its shaders.
FPGAs could be much more useful than they are at present. They've artificially limited themselves to ASIC prototyping alone.
So Intel bought an FPGA company -- nobody knows why. AMD got scared and did the same thing with no clue what to do with it. They've both let them rot. Intel did start incorporating it into its compiler targets, but it was only half-baked. Now they've wisely divested themselves of the company, but it should have never happened. They should have just focused on selling the hardware at a small margin whilst opening up the data to use it.
> we need a tiled layout
You are presuming an existing tile IP - if you're already in possession of such an IP then the place and route is already coarse grained. There are lots of papers on this.
> (like the GPU does)
What exactly does the GPU do? Yes there are tiles but it's up to you to now tile your workload. You understand this is the exact same problem you're bemoaning re place and route - you need to figure out how to shuffle individual bits efficiently through an existing fabric (roughly it's the same thing as routing 32 wires at a time).
> we need for this to happen is for the companies making the FPGAs to open up the board layout file spec
What exactly is this going to do for you if you're placing tiles? Also you can already recover this by exhaustively enumerating all a->b paths (yes people really do this).
To anyone else that thinks they just absolutely are certain of the silver bullet for digital design: download a copy of Vivado and report back what you discover!
[dead]
I was quite surprised the direction this article took. I wasn't expecting reheated whinging about the toolchain.
FPGAs do need a new future. They need a future where someone tapes out an FPGA! Xilinx produced Ultrascale+ over a decade ago and haven't done anything interesting since. Their Versal devices went off a tangent into SoCs, NOCs, AI engines - you know what they didn't do? Build a decent FPGA.
Altera did something ambitious back in 2014 when they proposed the hyper-register design, totally failed to execute on it and have been treading water because of the Intel cluster**. They're now an independent company but literally don't have anyone who knows how to tape out a chip.
I'm less familiar with the Lattice stuff, but since their most advanced product is still 16nm finfet I suspect they aren't doing anything newer than Xilinx or Altera.
We need a company that builds an FPGA. It doesn't matter what tooling you have because the fundamental performance gap between a custom FPGA solution and a CPU or GPU based solution is entirely eaten up by the fact the newest FPGA you can buy is a decade old and inexplicably still tens of thousands of dollars.
If FPGA technology had progressed at the same rate NVidia or Apple had pushed forward CPU/GPU performance, thered be some amazing opportunities to accelerate AI (on the path to then creating ASICs). But they haven't, so all the scaling laws have worked against them and the places they have a performance benefit have shrunk massively.
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
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.
FPGA for AI only makes sense when machine learning had diverse model architectures.
After Transformer took over AI, FPGA for AI is totally dead now. Because Transformer is all about math matrix calculation, ASIC is the solution.
Modern Datacenter GPU is nearly AISC now.
Yes, if you're doing what everyone else is doing you can just use tensor cores and libraries which optimize for that.
Contrarily if you're doing something that doesn't map that well to tensor cores you have a problem: every generation a larger portion of the die is devoted to low/mixed precision mma operations. Maybe FGPAs can find a niche that is underserved by current GPUs, but I doubt it. Writing a cuda/hip/kokkos kernel is just soo much cheaper and accessible than vhdl it's not even funny.
AMD needs to invest in that: Let me write a small FPGA kernel in line in a python script, compile it instantly and let me pipe numpy arrays into that (similar to cupy rawkernels). If that workflow works and let's me iterate fast, I could be convinced to get deeper into it.
The primary niche of FPGAs is low latency, determinism and low power consumption. Basically what if you needed an MCU, or many MCUs but the ones in the market don't have enough processing power?
The Versal AI Edge line is very power efficient compared to trying to achieve the same number of FLOPs using a Ryzen based CPU.
> 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.
An FPGA is like a spreadsheet for bits that can recalculate at hundreds of millions of times per second.
It's a declarative programming system, and there's a massive impedance match when you try to write source code for it in text. I suspect that something closer to flow charts, would be much easier to grok. Verilog is about as good at match as you are likely to get, if you stick with the source code approach to designing with them.
Very good metaphor. I'm going to use that in the future. It even has rows and columns.
Except the spreadsheet is a really accessible technology that's been cloned, while the critical problem with FPGA is the proprietary tooling. This is the same reason that NVIDIA made a gazillion dollars by turning GPUs into general purpose compute: a proper API, CUDA.
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
I had the misfortune of working with the Xilinx Vivado environment, it's a fucking garbage, the software is straight out of the 90s, everything is glued together with shell scripts and the TCL scripting language, the IDE throws thousands of warnings and errors while building a sample project, the documentation is missing or spread over 150 PDFs, if the manufacturer of your evaluation board prepared an example for the previous version of Vivado, you must have two installations, which is probably about 2 * 100GB, if you want to keep anything under version control, you have to use some external tools, it's all absurd.
I have an old FPGA sitting around at home and I'm relatively comfortable with VHDL.
I've never really thought of any interesting projects to do with it. Anyone know of anything?
That was my point as well: what can't you do with a uC or RPi?
It feels the use cases are dwindling and eaten by ASICs and uC
I knew someone who created a mandelbrot set viewer that would display over an VGA port, you had a game controller to move around and zoom into it. Something like that?
Anything RF
> I once hoped things would improve when Xilinx launched the Zynq line, combining a processor with FPGA fabric. Instead, the accompanying tools were so unusable that they made things worse, pushing developers even further away.
I once tried to use Xilinx' Vitis (2025) to make a small-ish piece of software running on such a Zynq chip. After wrestling with it* for like 5 weeks, me and my colleagues decided to ditch the entire Xilinx suite entirely and just pick a compiler and make a bare-metal binary with it. The FPGA part is done by a separate team of course, so us traditional software devs can stick with decent tools. We actually opted for a Rust toolchain and I'm extremely glad we did this, despite the additional time it took.
I don't know how my FPGA colleagues work with the proprietary toolchains and not go insane.
*The IDE is effectively a wrapper with a custom python API around cmake and gcc. It's not very well written cmake and I also don't know how they configure the linker that it does the weird things it does.
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.
Pushing 20 years in industry and this is the best take I’ve heard
Programming languages were originally designed by mathematicians based on a Turing machine. A modern language for FPGAs is a challenge for theoretical computer science, but we should keep computer literate researchers away from it. This is a call out to hard core maths heads to think about how we should think about parallelism and what FPGA hardware can do.
https://clash-lang.org/ we've already done the research! Circuits are just functional programming (the vast majority of the time).
We just need the toolchains to be opened up.
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.
I don't get the VHDL or Verilog hate. Digital IC design engineers have no problem with them. True, most of the industry moved to SystemVerilog, mainly for simulation and verification reasons.
It's the weirdnesses of FPGAs though. You aren't really designing a gate level circuit at the end. I'm not sure Verilog or VHDL are to blame here. Maybe they aren't fit for purpose to begin with. I hate the toolchains too. They got worse (sluggish, more paid IPs etc) in the last 15 years. IC design tools cost A LOT more (like 2-3 orders of magnitude more) comparatively but they just work at least!
Neat, but we've been in the same situation for a while. A couple years back, I wrote a tutorial for using an open source stack with the Nandland Go FPGA board: a simple Lattice board. This was because the FPGA book I bought from No Starch required Windows (shock and horror). This was 2023. Now we're coming up into 2026?
I don't understand why the fpga chip vendors don't sell direct to customers. You typically have to go through a distributor, and that entails quite a bit of markup. It doesn't lend itself to the hobby market like raspberry pi for example.
There are a number of alternatives to VDHL and Verilog, many of which lower to Verilog, for example MyHDL.
I program FPGAs professionally (Xilinx Zynq, VHDL). I agree that the tool's GUI is atrocious, the actual way to use it is to write everything in TCL scripts, and invoke the tools through a Makefile. I only open the GUI to look at timing issues or ask it for code templates.
I disagree with "HDL is software" though. It's not, it's even in the name: "hardware description language". Yes it's a text file with what looks a lot like regular code in it. However what's being decribed is how to connect boxes of logic together, and how to compute the output of the boxes from their inputs. There's no implicit program counter that's advancing from one line to the next.
It is (theoretically) possible to write these kind of things with a lot of abstraction, but every time you try that by using more advanced language features, you hit some bugs in the tool's implementation of the language. If you're lucky it'll tell you where you're doing undupported stuff. Often it'll crash. Sometimes it'll sythesize hardware that doesn't conform with the language spec.
Finally, FPGAs are simple only when you're looking at a bird's eye view (just like CPUs are simple when you're looking at a diagram with a few boxes saying "ALU", "Cache", "Registers"). The actual datasheets are thousands of pages long.
FPGAs are still useful though, their use case is "I need custom hardware and I don't have the volume to build an ASIC". For example, my application is a custom signal processing pipeline that's handling about 3.5 Gbit/s of streaming raw data. On a $40 chip.
I think my main point is that yes, the tooling is a pain to use, with heaps of bugs and bad language support. However a HDL is conceptually different from a software language and I'm not sure you can hide away the complexities of designing hardware behind "modern" language features.
For those suggesting diagram-based languages, go program something in LabView, you'll quickly understand why that's a bad idea (works for trivial designs, anything complex is an opaque mess of boxes and lines, unsearchable, and impossible to integrate with version control).
LabVIEW FPGA was amazing, I did all kinds of things with it on the compactRIO controller FPGA
You can write very neat and tidy code with dataflow diagram languages. I did it professionally for years, and there were many others who did as well.
Same thing as any other language, you have to come up ways to organize the code into functions and classes that make sense. Vomiting everything into the top level diagram is the same as 10000 line of code while(1)
You could always tell the exact level of proficiency someone had with LabVIEW immediately when opening the diagram.
The dataflow model maps very well to FPGAs IMO, it's a shame it never became widespread. There was much potential there
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
No. FPGAs already have a future. You just don't know about it yet.
I'm surprised, no one mentioned https://f4pga.org/ yet.
completely agree, it's a miserable environment for software developers. The Xilinx environment was a 1 GB download, EACH TIME they issued an update. I actually met with someone from higher up to give them some feedback, but they were clearly not interested in the slightest in making any changes.
No mention of video game emulation on FPGA?
No mention of that Brazilian company that was set to manufacture them to undercut the market?
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.
My rule of thumb is a 40x silicon area ratio between FPGA and ASIC, a clock speed that is around 5x lower. And a lot more power consumption.
If you have an application that can be done on a CPU, with lots of sequences dependencies (such as video compression/decompression), an FPGA doesn’t stand a chance compared to adding dedicated silicon area.
That’s even more so if you’d embed an FPGA on a CPU die. Intel tried it and you got a power hungry jack of all trades, master of none that nobody knew what to do with.
Xilinx MPSOC and RFSOC are successful, but their CPUs are comparatively lower performance and used as application specific orchestrators and never as a generic CPU that run traditional desktop or server software.
I have yet to see the "FPGA is less power efficient" thing to be true. People are always comparing the same circuit in an FPGA Vs an ASIC but this is a nonsensical comparison because of three reasons:
FPGAs have hard wired blocks like DSPs which do not have any power disadvantages vs "ASIC" (only advantages actually)
the likelihood that there is an ASIC that happens to implement your particular design is very low
and off the shelf ASICs like GPUs and CPUs have significant amounts of overhead for each operation. This is especially evident with CPUs. They perform a small number of operations per cycle, but they have to pay the entire fixed energy cost of caches, registers, instruction decoding, etc per cycle. This is way way worse than programmable logic if you're mostly using the DSP and the block RAM slices.
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".
You forget network infrastructure, high frequency trading, ASIC prototyping and emulation. These are not hobbyist or government markets
True but they behave exactly like government markets ("no price is too high") so I don't quite understand why the comment.
> An FPGA, by contrast, defines data pathways specifying how signals change on each clock tick based on internal states and external inputs. In essence, we describe global per-clock-cycle behavior rather than an individual act of data manipulation per step.
I think that’s the clearest explanation of FPGAs I’ve ever seen.
This is a very correct article. FPGAs should indeed be really easy to use!
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.
> It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm
That relies on "FPGAs everywhere", which is much further out than "GPUs everywhere".
I'm not sure where the state of the art is on this, but given the way that codecs work - bitstream splitting into tiles, each of which is numerically heavy but can be handled separately - how is development of hybrid codecs, where the GPU does the heavy lifting using its general purpose cores rather than fixed function decoder pipeline?
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.
You definitely don't want an FPGA if those are your concerns.
...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.
[dead]
If Jim Keller says it, I’ll believe it.
My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.