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.<p>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.<p>We decided to build a VSCode extension that wraps these open source tools (<a href="https://edacation.github.io" rel="nofollow">https://edacation.github.io</a> 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.<p>There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
I'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.
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.
Modern large productivity software (including IDE) are often "fragile".<p>Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.<p>Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.<p>Sometimes the IDE itself has random bugs.<p>A lot of time is spent workarounding IDE issues
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 <i>build</i> those bitstreams for, and they're complicated to manage the software projects for.<p>As soon as they reach the point where it's as easy to put down an FPGA as it is an old STM32 or whatever, they'll get a lot more interesting.
The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.<p>Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)<p>Loading them is a matter of plugging in a JTAG cable and typing “make program”.<p>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.<p>Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would <i>love</i> to have the option to drop all of the power rail complexity in a simplified series of parts.<p>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.<p>> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)<p>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.<p>> Loading them is a matter of plugging in a JTAG cable and typing “make program”.<p>Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is <i>possible</i>. It is still a giant headache, and quite a bit worse than just dealing with an MCU.<p>> I don’t know what you mean with the “manage SW projects for”?<p>Two words: Xilinx ISE.
> often, what I actually need is just a little bit of weird logic that's asynchronous<p>As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been <i>wonderful</i> 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 <i>one line of HDL</i>. One. Line.<p>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.
> and quite a bit worse than just dealing with an MCU.<p>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..<p>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.<p>Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?<p>Oh look, the factory screwed up and isn't flashing the PLD <i>this</i> week! Does the board survive?<p>Oh look, the factory... wait, what <i>is</i> the factory doing and why are they putting <i>that</i> sticker on <i>that</i>....<p>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 <i>bend over backwards</i> 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.
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.<p>I should check my spam folder.
> sometimes … sometimes … sometimes …<p>And sometimes you need support for multiple IO standards.<p>I don’t understand what point you’re trying to get across.<p>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?<p>> JTAG<p>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.<p>> ISE<p>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.<p>My point is twofold:<p>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.)<p>2. All of this is way, way harder than it needs to be. It <i>could</i> be easy, but it isn't. Everything is <i>possible</i> 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!).<p>It turns out that is very valuable.<p>And is what I would like to see happen with FPGAs: make them <i>easy</i> 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.<p>It did. Onboarding people onto embedded programmer.<p>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.<p>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<p>How much easier does it need to be than putting down a single 1mm^2 LDO and a QFN IC? Is this really <i>that</i> difficult?
It's already happened, people just haven't realized. iCE40-UP5K costs a few bucks, needs minimal support circuitry, and is supported by FOSS toolchains (yosys). Fun packages like the pico-ice bring it all the way down to the entry-level arduino crowd. It just doesn't have the marketing mindshare.
They can't, by nature of the proprietary bitstream. Arduino was only built thanks to ability to do whatever they wanted with open source compilers
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.<p>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.<p>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.)<p>Anyway. CPLDs are neat.
I don’t see how CPLDs solve anything?<p>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.<p>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.<p>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.
> they're complicated to put down on boards<p><a href="https://gowinsemi.com/en/product/detail/46/" rel="nofollow">https://gowinsemi.com/en/product/detail/46/</a><p>- Requires just 1V2 + 3V3<p>- Available in QFN<p>- Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence<p><a href="https://www.efinixinc.com/products-trion.html" rel="nofollow">https://www.efinixinc.com/products-trion.html</a>
The Altera Max 10 devices are also relatively simple to support (flash on the chip, few power rails, etc.)
> Contact Sales<p>> Request Sample<p>> Please login to download the document.<p>I mean, yeah. My argument isn't that anything is <i>impossible</i>. My argument is that all of this is <i>harder than it needs to be</i> 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.)<p>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.<p>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<p>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.
It's basically because they're so locked down, hard to get docs, stupid toolchains and ides like others have mentioned.<p>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.<p>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.
> FPGAs need their "Arduino moment".<p>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.<p>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.<p>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.<p>PS: Folks might find the book <i>FPGAs for Software Programmers by Dirk Koch et al.</i> (<a href="https://link.springer.com/book/10.1007/978-3-319-26408-0" rel="nofollow">https://link.springer.com/book/10.1007/978-3-319-26408-0</a>) useful.
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.<p>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.<p>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.<p>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.<p>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.<p>Maybe they were in the 80. In 2025, language design has moved ahead quite a lot, you can't be saying that seriously.<p>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.<p>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.<p>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.<p>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.<p>I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.<p>Simple things look pretty much like C:<p><pre><code> module add :
int#(FROM:-8, TO: 8) a,
int#(FROM: 2, TO: 20) b ->
int c {
c = a+b
}
</code></pre>
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.<p>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 => <a href="https://github.com/pc2/sus-compiler" rel="nofollow">https://github.com/pc2/sus-compiler</a>
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...<p>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.<p>create_project -in_memory -part ${PART}<p>set_property target_language VHDL [ current_project ]<p>read_vhdl "my_hdl_file.vhd"<p>synth_design -top my_hdl_top_module_name -part ${PART}<p>opt_design<p>place_design<p>route_design<p>check_timing -file my_timing.txt<p>report_utilization -file my_util.txt<p>write_checkpoint my_routed_design.dcp<p>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.<p>So if you learn VHDL first, you'll be on a solid footing.
I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.
There is a trend among programmers to assume that everything supported by the syntax can be done. This is not even true in C++, but it's something people think. If you are writing synthesizable SystemVerilog, only a small subset of the language used in a particular set of ways works. You have to resist the urge to get too clever (in some ways, but in other ways you can get extremely clever with it).
Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…
> software developers generally aren't very good at doing things in parallel<p>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.<p>I just can't with the gatekeeping.<p>(Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on reddit and elsewhere. It's damn frustrating to say the least. Also, the worst thing is all the hardware folks only know C so they think all programming is imperative. VDHL is Ada for crying out loud.)
Yeah I agree it is a lack of understanding on how to use the tools. The main issue I ran into in my undergrad FPGA class as a CS student was a lack of understanding on how to use the IDE. We jumped right into trying to get something running on the board instead of taking time to get everything set up. IMO it would have been way easier if my class used an IDE that was as simple as Arduino instead of everyone trying to run a virtual machine on their macbooks to run Quartus Prime.
An FPGA is like a spreadsheet for bits that can recalculate at hundreds of millions of times per second.<p>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.
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.<p>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” ?<p>For me, that means higher capacity and advanced blocks such as SERDES, high-speed DRAM interfaces etc.<p>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.<p>I don’t see how GoWin and other alternative brands would be better placed to solve that problem.
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.)<p>HDL isn't getting any easier, though, and that's where most of the complexity is.
> My prediction is one of the Chinese FPGA makers will embrace open source<p>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.<p>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.
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.
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.<p>"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.<p>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.<p>My daily Vivado experience involves typing "make", then waiting for the result and analysing from there (if necessary). It takes experience to set up a hardware project like this, but once you get there it's compatible with standard version control, CI tools, regression tests and the other nice things you expect form a modern development environment.
> My daily Vivado experience involves typing "make", …<p>Exactly my experience with Quartus as well.<p>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.<p>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>"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.</i><p>Or how to use an LLM properly.
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.
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.<p>Unlikely this will ever happen but one can always dream.
On the software front as mentioned VHDL and Verilog are showing their age with their design as well as ther tooling ecosystem.Attempts such as CHISEL[1] (written in Scala)also havent gotten much traction - seeing also the language choice - would have btter have been in something more accesible like kotlin/ocaml.<p>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.<p>[1]<a href="https://github.com/chipsalliance/chisel/blob/main/README.md" rel="nofollow">https://github.com/chipsalliance/chisel/blob/main/README.md</a>
This is a very correct article. FPGAs should indeed be really easy to use!
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.<p>The real argument for open source toolchains is much narrower in scope and implying its requirement for fixing a nonexistent tool problem is absurd
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 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?
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.<p>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.<p>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.<p>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.
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.<p>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.)<p>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.
It seems to me that there are exactly 3 buyers for FPGAs: Government contractors (who spend millions all at once), retro gamers (small market), and electronics hobbyists (another small market). It's no wonder every company has orientated itself towards the first one. I look to China to accidentally make chips that are an order of magnitude better "just because they can".
Making FPGA's actually available (without encumbering stacks) would be so great. Companies IMO do better when they stop operating from within their moat & this would be such the amazing use case to lend support for that hypothesis.<p>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.<p>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 problem is that FPGA companies don't see themselves as chip companies.<p>They see themselves as CAD software companies. The chip is just a copy-protection dongle.
No. FPGAs already have a future. You just don't know about it yet.
Cost is also such a big issue.
<i>Here’s the first big misconception: HDL is hardware. It isn’t. HDL is software and should be managed like software.</i><p>Yes, that's certainly a big misconception. Maybe not the one the author meant to call out, but... yes, a big misconception indeed.
To folks who wax lyrical about FPGAs: <i>why</i> do they need a future?<p>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?<p>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.<p>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 only be a game changer if you don’t care about a 40x area cost, massive lower clock speeds and off the chart increase in power consumption.<p>AV1 is a complex codec. You need a large FPGA (hundreds of square mm2) to run it. When implemented as custom silicon, it’s just a handful of mm2.<p>If you can’t afford AV1 as custom silicon, you’re much better off doing it in SW.
But <i>why</i> 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).<p>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?
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.
If Jim Keller says it, I’ll believe it.<p>My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.