6 ms·

FPGAs Need a New Future

235 points by thawawaycold 9mo ago

checker659 9mo ago
Cost is also such a big issue.
- fleventynine 9mo ago
  There are some reasonably affordable models like https://www.lcsc.com/product-detail/C5272996.html https://www.lcsc.com/product-detail/C5272996.html that are powerful enough for many tasks.
jauntywundrkind 9mo ago
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!
omneity 9mo ago
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.
- 15155 9mo ago
  > 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.
- rfv6723 9mo ago
  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.
  - KeplerBoy 9mo ago
    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.
    - imtringued 9mo ago
      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.
rcxdude 9mo ago
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.
anondawg55 9mo ago
No. FPGAs already have a future. You just don't know about it yet.
mgilroy 9mo ago
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.
- j-pb 9mo ago
  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.
  - blackguardx 9mo ago
    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.
    - exmadscientist 9mo ago
      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.
nospice 9mo ago
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.
- tyami94 9mo ago
  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.
  - ThrowawayR2 9mo ago
    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.
    - checker659 9mo ago
exmadscientist 9mo ago
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.
- timthorn 9mo ago
  Sounds like a PLD might suit your usecase? Simpler than an FPGA, programmed like an EEPROM, perfect for glue logic.
  - exmadscientist 9mo ago
    "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.
  - javawizard 9mo ago
    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.
Cadwhisker 9mo ago
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.
- tverbeure 9mo ago
  > 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?
  - Cadwhisker 9mo ago
    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.
    - fooblaster 9mo ago
      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.
malmeloo 9mo ago
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 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.
- delifue 9mo ago
  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
  - mikepurvis 9mo ago
    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.
    - SV_BubbleTime 9mo ago
ursAxZA 9mo ago
If Jim Keller says it, I’ll believe it. My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.
octoberfranklin 9mo ago
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.
- poslathian 9mo ago
  Pushing 20 years in industry and this is the best take I’ve heard
jhide 9mo ago
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
- amirhirsch 9mo ago
  I did write this 20 years ago https://fpgacomputing.blogspot.com/2006/05/methods-for-reconfigurable-computing.html https://fpgacomputing.blogspot.com/2006/05/methods-for-recon... The vendor tools are still a barrier to the high-end FPGA's hardened IP
phendrenad2 9mo ago
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".
- lvoudour 9mo ago
  You forget network infrastructure, high frequency trading, ASIC prototyping and emulation. These are not hobbyist or government markets
  - phendrenad2 9mo ago
    True but they behave exactly like government markets ("no price is too high") so I don't quite understand why the comment.
rzerowan 9mo ago
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 https://github.com/chipsalliance/chisel/blob/main/README.md
CamperBob2 9mo ago
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.
- oscillonoscope 9mo ago
  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
mastax 9mo ago
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.
- 15155 9mo ago
  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.
- bsder 9mo ago
  > 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.
  - hmry 9mo ago
    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.
    - bsder 9mo ago
      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.
xgstation 9mo ago
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?
- 15155 9mo ago
  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.
- tverbeure 9mo ago
  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.
  - imtringued 9mo ago
    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.
dsab 9mo ago
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.
Peteragain 9mo ago
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.
- Ericson2314 9mo ago
  https://clash-lang.org/ 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.
Ericson2314 9mo ago
This is a very correct article. FPGAs should indeed be really easy to use!
mikewarot 9mo ago
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.
- pjc50 9mo ago
  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.
marcosscriven 9mo ago
> 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.
juliangmp 9mo ago
> 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.
jonesjohnson 9mo ago
I'm surprised, no one mentioned https://f4pga.org/ https://f4pga.org/ yet.
pavel-novikau 9mo ago
[dead]
lefra 9mo ago
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).
- fluorinerocket 9mo ago
  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
mgaunard 9mo ago
There are a number of alternatives to VDHL and Verilog, many of which lower to Verilog, for example MyHDL.
ImPleadThe5th 9mo ago
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?
- kown7 9mo ago
  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
- ab71e5 9mo ago
  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?
- pythonguython 9mo ago
  Anything RF
Traster 9mo ago
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.
brador 9mo ago
No mention of video game emulation on FPGA? No mention of that Brazilian company that was set to manufacture them to undercut the market?
BrannonKing 9mo ago
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.
- mertleee 9mo ago
  [dead]
- almostgotcaught 9mo ago
  > 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!
zerofor_conduct 9mo ago
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.
thijson 9mo ago
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.
strfry 9mo ago
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?
bgnn 9mo ago
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!

235 points by thawawaycold 9mo ago

checker659 9mo ago

Cost is also such a big issue.

fleventynine 9mo ago
There are some reasonably affordable models like https://www.lcsc.com/product-detail/C5272996.html https://www.lcsc.com/product-detail/C5272996.html that are powerful enough for many tasks.

jauntywundrkind 9mo ago

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!

omneity 9mo ago

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.

15155 9mo ago
> 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.
rfv6723 9mo ago
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.
- KeplerBoy 9mo ago
  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.
  - imtringued 9mo ago
    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.

rcxdude 9mo ago

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.

anondawg55 9mo ago

No. FPGAs already have a future. You just don't know about it yet.

mgilroy 9mo ago

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.

j-pb 9mo ago
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.
- blackguardx 9mo ago
  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.
  - exmadscientist 9mo ago
    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.

nospice 9mo ago

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.

tyami94 9mo ago
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.
- ThrowawayR2 9mo ago
  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.
  - checker659 9mo ago

exmadscientist 9mo ago

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.

timthorn 9mo ago
Sounds like a PLD might suit your usecase? Simpler than an FPGA, programmed like an EEPROM, perfect for glue logic.
- exmadscientist 9mo ago
  "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.
- javawizard 9mo ago
  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.

Cadwhisker 9mo ago

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.

tverbeure 9mo ago
> 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?
- Cadwhisker 9mo ago
  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.
  - fooblaster 9mo ago
    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.

malmeloo 9mo ago

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 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.

delifue 9mo ago
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
- mikepurvis 9mo ago
  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.
  - SV_BubbleTime 9mo ago

ursAxZA 9mo ago

If Jim Keller says it, I’ll believe it. My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.

octoberfranklin 9mo ago

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.

poslathian 9mo ago
Pushing 20 years in industry and this is the best take I’ve heard

jhide 9mo ago

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

amirhirsch 9mo ago
I did write this 20 years ago https://fpgacomputing.blogspot.com/2006/05/methods-for-reconfigurable-computing.html https://fpgacomputing.blogspot.com/2006/05/methods-for-recon... The vendor tools are still a barrier to the high-end FPGA's hardened IP

phendrenad2 9mo ago

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".

lvoudour 9mo ago
You forget network infrastructure, high frequency trading, ASIC prototyping and emulation. These are not hobbyist or government markets
- phendrenad2 9mo ago
  True but they behave exactly like government markets ("no price is too high") so I don't quite understand why the comment.

rzerowan 9mo ago

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 https://github.com/chipsalliance/chisel/blob/main/README.md

CamperBob2 9mo ago

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.

oscillonoscope 9mo ago
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

mastax 9mo ago

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.

15155 9mo ago
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.
bsder 9mo ago
> 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.
- hmry 9mo ago
  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.
  - bsder 9mo ago
    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.

xgstation 9mo ago

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?

15155 9mo ago
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.
tverbeure 9mo ago
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.
- imtringued 9mo ago
  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.

dsab 9mo ago

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.

Peteragain 9mo ago

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.

Ericson2314 9mo ago
https://clash-lang.org/ 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.

Ericson2314 9mo ago

This is a very correct article. FPGAs should indeed be really easy to use!

mikewarot 9mo ago

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.

pjc50 9mo ago
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.

marcosscriven 9mo ago

> 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.

juliangmp 9mo ago

> 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.

jonesjohnson 9mo ago

I'm surprised, no one mentioned https://f4pga.org/ https://f4pga.org/ yet.

pavel-novikau 9mo ago

[dead]

lefra 9mo ago

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).

fluorinerocket 9mo ago
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

mgaunard 9mo ago

There are a number of alternatives to VDHL and Verilog, many of which lower to Verilog, for example MyHDL.

ImPleadThe5th 9mo ago

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?

kown7 9mo ago
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
ab71e5 9mo ago
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?
pythonguython 9mo ago
Anything RF

Traster 9mo ago

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.

brador 9mo ago

No mention of video game emulation on FPGA? No mention of that Brazilian company that was set to manufacture them to undercut the market?

BrannonKing 9mo ago

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.

mertleee 9mo ago
[dead]
almostgotcaught 9mo ago
> 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!

zerofor_conduct 9mo ago

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.

thijson 9mo ago

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.

strfry 9mo ago

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?

bgnn 9mo ago

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!