FPGAs Need a New Future(allaboutcircuits.com) |
FPGAs Need a New Future(allaboutcircuits.com) |
No mention of that Brazilian company that was set to manufacture them to undercut the market?
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.
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.
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.
I think that’s the clearest explanation of FPGAs I’ve ever seen.
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.
My Ryzen agrees — the fans just spun up like it’s hitting 10,000 rpm.
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.
That relies on "FPGAs everywhere", which is much further out than "GPUs everywhere".
I'm not sure where the state of the art is on this, but given the way that codecs work - bitstream splitting into tiles, each of which is numerically heavy but can be handled separately - how is development of hybrid codecs, where the GPU does the heavy lifting using its general purpose cores rather than fixed function decoder pipeline?
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?
In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.
Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.
I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
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
Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.
Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!
We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.
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.
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.
"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.
Or how to use an LLM properly.
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?
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.
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!
Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice especially it seems like a no brainer but they don’t understand the appeal of open source still.
For me, that means higher capacity and advanced blocks such as SERDES, high-speed DRAM interfaces etc.
The bottleneck in using these kind of FPGAs has rarely been the tools, it’s the amount of time it takes to write and verify correct RTL. That’s not an FPGA specific problem, it applies to ASIC just the same.
I don’t see how GoWin and other alternative brands would be better placed to solve that problem.
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.
All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.
HDL isn't getting any easier, though, and that's where most of the complexity is.
My feeling is that hardware companies do better when they ship the software needed to utilize their hardware for free. (You need a little margin in the hardware price to cover the software development). However, the FPGA companies haven't figured this out. They try to make way too much software and charge exhorbitant fees for it, somehow thinking that their hardware is useless without that. In fact, their hardware is useless because I can't put anything on it without a 1-to-20 hour compile time. That makes it impossible to use it as an accelerator. I can compile OpenCL for my GPU in a few milliseconds; that's what we need for the FPGA. Even thirty seconds would be easily tolerable -- there's many a game that still requires 15 seconds to load a level and compile its shaders.
FPGAs could be much more useful than they are at present. They've artificially limited themselves to ASIC prototyping alone.
So Intel bought an FPGA company -- nobody knows why. AMD got scared and did the same thing with no clue what to do with it. They've both let them rot. Intel did start incorporating it into its compiler targets, but it was only half-baked. Now they've wisely divested themselves of the company, but it should have never happened. They should have just focused on selling the hardware at a small margin whilst opening up the data to use it.
You are presuming an existing tile IP - if you're already in possession of such an IP then the place and route is already coarse grained. There are lots of papers on this.
> (like the GPU does)
What exactly does the GPU do? Yes there are tiles but it's up to you to now tile your workload. You understand this is the exact same problem you're bemoaning re place and route - you need to figure out how to shuffle individual bits efficiently through an existing fabric (roughly it's the same thing as routing 32 wires at a time).
> we need for this to happen is for the companies making the FPGAs to open up the board layout file spec
What exactly is this going to do for you if you're placing tiles? Also you can already recover this by exhaustively enumerating all a->b paths (yes people really do this).
To anyone else that thinks they just absolutely are certain of the silver bullet for digital design: download a copy of Vivado and report back what you discover!
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.
The real argument for open source toolchains is much narrower in scope and implying its requirement for fixing a nonexistent tool problem is absurd
The vendor tools are still a barrier to the high-end FPGA's hardened IP
Unlikely this will ever happen but one can always dream.
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.
Contrarily if you're doing something that doesn't map that well to tensor cores you have a problem: every generation a larger portion of the die is devoted to low/mixed precision mma operations. Maybe FGPAs can find a niche that is underserved by current GPUs, but I doubt it. Writing a cuda/hip/kokkos kernel is just soo much cheaper and accessible than vhdl it's not even funny.
AMD needs to invest in that: Let me write a small FPGA kernel in line in a python script, compile it instantly and let me pipe numpy arrays into that (similar to cupy rawkernels). If that workflow works and let's me iterate fast, I could be convinced to get deeper into it.
The three SKUs between Xilinx and Altera that had HBM are no longer manufactured because Samsung Aquabolt was discontinued.
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.
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.
Secondly the integration with consumer devices and OS is almost non-ecistant - it should really be simpler to interact with ala GPU/Network chip and have more mainboards with lowcost integrated FPGAs even if they are only a couple of hundred of logic cells.
[1]https://github.com/chipsalliance/chisel/blob/main/README.md
I've never really thought of any interesting projects to do with it. Anyone know of anything?
It feels the use cases are dwindling and eaten by ASICs and uC
They see themselves as CAD software companies. The chip is just a copy-protection dongle.
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.
We just need the toolchains to be opened up.
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!
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).
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
Yes, that's certainly a big misconception. Maybe not the one the author meant to call out, but... yes, a big misconception indeed.
I bought a relatively cheap artic 7 board with 33kLUT and whatnot which I know people have used to implement risc-v implementations on.
But then I always lost my patience on the tooling.
For a side projects these days I need something comfortable. Something that that I can easily switch my context to without having to juggle VMs and installing unfriendly tools and use horrible IDEs
This is exactly it. Why hasn't some expert group produced a very simple open design board with a simple Arduino-like IDE for FPGAs? Make it easy to access and use, get it into the hands of makers/hobbyists and watch the apps/ecosystem explode.
As an example, one could provide soft-cores for 8051/RISC-V etc. right out of the box with a menu of peripherals to mix and match. Provide a simple language library wrapper say over SystemVerilog (or whatever the community settles on) just like Arduino did (with C++) that makes it "easy" to program the FPGA.
For apps, one good example would be putting TinyML (or any other ML/LLM models) on a FPGA. This would take advantage of the current technology wave to make this project a success.
PS: Folks might find the book FPGAs for Software Programmers by Dirk Koch et al. (https://link.springer.com/book/10.1007/978-3-319-26408-0) useful.
Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
Loading them is a matter of plugging in a JTAG cable and typing “make program”.
I don’t know what you mean with the “manage SW projects for”?
Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts.
Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing horsepower. And sometimes you need the certainty of hardware timing, which you get on a gate array and don't get any time there's a processor involved. Or, often, what I actually need is just a little bit of weird logic that's asynchronous, but too hard to do with the remnants of 74-series or 4000-series logic that are still available.
> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
It is not complicated for people who have spent a long time learning and who have past designs they can copy from. (I have a few of those myself.) It is nasty to explain to a new person and very nasty to explain well enough to reproduce in the future without me around.
> Loading them is a matter of plugging in a JTAG cable and typing “make program”.
Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is possible. It is still a giant headache, and quite a bit worse than just dealing with an MCU.
> I don’t know what you mean with the “manage SW projects for”?
Two words: Xilinx ISE.
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.
But, really, no one cares what's inside the box. CPLD or FPGA, they're all about the same. The available PLDs are still not really acceptable. There's a bunch of 5V dinosaurs that the manufacturers would obviously love to axe, and a few tiny little micro-BGA things where you've got to be buying 100k to even submit a documentation bug report. Not much for stuff in the middle.
It's like fpga companies don't want people using them, much like others like the pixart sensor I wanted to use: NDA because some parasite dipshit executive or manager thinks that register layouts are extremely sensitive information.
I've had dozens of uses for an fpga...but every single time I just can't be bothered. Why, when they make it a pain in the ass on purpose.
https://gowinsemi.com/en/product/detail/46/
- Requires just 1V2 + 3V3
- Available in QFN
- Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence
> Request Sample
> Please login to download the document.
I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!
Maybe they were in the 80. In 2025, language design has moved ahead quite a lot, you can't be saying that seriously.
Have a look at how clash-lang does it. It uses functional paradigm, which is much more suitable for circuits than pseudo-pricedural style of verilog. You can also parameterize modules by modules, not just by bitness. Take a functional programmer, hive him clash and he'll have no problems doing things in parallel.
Back when I was a systems programmer, I tried learning system verilog. Had zero conceptual difficulty, but I just couldn't justify to myself why I should spend my time on something so outdated and badly designed. Hardware designers at my company at the time were on the other hand ok with verilog because they haven't seen any programming languages other than C and Python, and had no expectations.
The issue isn't the languages, it's the horrible tooling around them. I'm not going to install a multi GB proprietary IDE that needs a GUI for everything and doesn't operate with any of my existing tools. An IDE that costs money, even though I already bought the hardware. Or requires an NDA. F** that.
I want to be able to do `cargo add risc-v` if I need a small cpu IP, and not sacrifice a goat.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
module add :
int#(FROM:-8, TO: 8) a,
int#(FROM: 2, TO: 20) b ->
int c {
c = a+b
}
It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler
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.
If only hardware people would stop stereotyping. Also, do you guys not use use formal tools (BMC etc) now? Who do you think wrote those tools? Heck all the EDA stuff was designed by software people.
I just can't with the gatekeeping.
(Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on reddit and elsewhere. It's damn frustrating to say the least. Also, the worst thing is all the hardware folks only know C so they think all programming is imperative. VDHL is Ada for crying out loud.)
It's not a case of just stating computer scientist weren't capable of doing it. They struggled with the parallelism and struggled with the optimisations and placements when you had to make physical connections on chips.
I'm well aware it's mostly going to be computer scientists writing the tools we use.
For those that want FPGAs to take off like the Arduino platform, I agree. I'd love it. However, it isn't the tooling that's holding it back. The reality is it is that cheaper, faster and easier solutions already exist. Why would you use an FPGA?
No - EDA software is built by hardware experts moonlighting as software engineers, which is partly why it is so obtuse.
The Versal AI Edge line is very power efficient compared to trying to achieve the same number of FLOPs using a Ryzen based CPU.
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.
You write RTL for them just like you do for FPGAs, you need to configure them as well. The only major benefit is that they don’t have a delay between power up and logic active? But that’s not something that would make a difference for most people.
CPLDs are also a dying breed and being replaced with FPGAs that have parallel on-board flash to allow fast configuration after power up. (e.g. MAX10)
The ever so popular JS is explicitly singlely threaded.
The default way of programming is with code on individual lines and when you run a debugger you step from one line to the next. This is not how code actually runs within a pipelined CPU though.
Is doing so much heavy lifting here, I need to ask; how much FPGA configuration you have done before?
So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.
Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.
I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.
## Irrelevant Complaining
Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for <$1-2 in China. Efinix are available from DigiKey, with some SKUs under <$10.
All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)
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.
https://www.google.com/search?q=gowin+user+guide+filetype%3A...
https://www.google.com/search?q=gowin+primitives+filetype%3A...
create_project -in_memory -part ${PART}
set_property target_language VHDL [ current_project ]
read_vhdl "my_hdl_file.vhd"
synth_design -top my_hdl_top_module_name -part ${PART}
opt_design
place_design
route_design
check_timing -file my_timing.txt
report_utilization -file my_util.txt
write_checkpoint my_routed_design.dcp
write_bitstream my_bitfile.bit
So if you learn VHDL first, you'll be on a solid footing.
Is the North American insistence on teaching Verilog what's setting up students for failure since Verilog looks a bit more like a sequential programming language at first glance?
If I need it I will go do the thing and jump through the hoop.
If I am exploring, hell no.
And, next week, if that thing I was exploring turns out to be useful, congratulations, you just sold 100,000 chips.
As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been wonderful if I could spend a little bit of money, buy a programmable thing in a 24-pin package, put it down, figure out some way to get the bitstream in (this is never pleasant in medium-volume manufacturing, so it's not like we're going to solve it now), and get my gate function that is literally one line of HDL. One. Line.
As it was, a 21-input OR gate is so much work in 74-series logic that I abandoned that whole thing and we did the bigger-picture job in a different, worse, way.
It was not a fit for this use case (on this product I am literally counting tenths of pennies, so, no go), and I dread dealing with Renesas in any form, but it's the right fit for something.
And sometimes you need support for multiple IO standards.
I don’t understand what point you’re trying to get across.
But if all you need is LVCMOS33, why do you not use a MAX10 FPGA with built-in voltage regulator? Or a similar FPGA device from GoWin that is positioned as a MAX10 alternative? What is wrong with those?
> JTAG
On our production line, we use JTAG to program the FPGA? We literally used the same “make program” command for development and production. That was for production volumes considerably larger than 100k.
> ISE
ISE was end of life’d when I started using FPGAs professionally. That was in 2012. The only reason it still exists is because some hold-outs are still using Spartan 6.
My point is twofold:
1. There are many niches. Your main needs are not the same as my main needs. And my needs are poorly met by existing products, so I want to see something better. (And I do buy chips.)
2. All of this is way, way harder than it needs to be. It could be easy, but it isn't. Everything is possible right now. But I wasn't random when I used the dreaded A-word ("Arduino"). Arduino is a kind of horrible product that did not make anything possible and did not really invent anything. It did not make anything really hard suddenly become easy. Hard things before Arduino were still hard after Arduino. It "just" made some things that used to be medium-hard pains-in-the-butt actually really quick and easy (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!).
It turns out that is very valuable.
And is what I would like to see happen with FPGAs: make them easy to drop in instead of pains in the butt. All pieces for this exist, nothing is new tech, no major revolutions need to happen. "Just" ease of use.
It did. Onboarding people onto embedded programmer.
You just ran it, wrote few lines and you had working blinky. Write some more and you have useful toy. You could even technically make products with it but going from this to C++ was easier coz you already know what you could do, just needed to go thru pain of switching the toolchain once you're already invested.
Compare that to "you need to setup compiler, toolchain, SDK, figure out how to program the resulting binary, map the registers to your devboard pins etc."
How much easier does it need to be than putting down a single 1mm^2 LDO and a QFN IC? Is this really that difficult?
Doesn't really matter if it does break; just use gcc and a Makefile like you would for any other firmware.
You probably want to replace the Arduino libraries with your own ones eventually anyway, because there's so much cruft in there that you're never going to use.
Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming..
These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before, either.
Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?
Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive?
Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that....
You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't. I am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.
I should check my spam folder.
Anyway, just tie the output of 21 emitter followers together, add a resistor and - tadaaa - 21 input OR!
But please don't complain when I give concrete examples of things I'd like to do but couldn't. (And please do recognize that there was a lot more context to the mess than just "I need an OR gate", but no one cares about the real gory details.)
(That's a pretty steep price target even for a small FPGA though. With 16 pins maybe, but with 25?)