Comments
One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are forcing down our throats.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
By MisterTea 2025-12-2315:05 This is exactly it.
The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.
Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.
I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.
I'm all for your endeavor, but didn't see a device support list on your front page. Clicked the first of 2 links in your sidebar (docs) and got a 404. I'm not saying it's telling that your issues page works when your docs page doesn't, but it's not the foot I would have put forward.
Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
> it's just me and a professor of previously mentioned course who are actively involved in the project
Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.
I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.
## Irrelevant Complaining
Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.
I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
By woah_okay 2025-12-2412:44 have u looked at the teroshdl extension?
Modern large productivity software (including IDE) are often "fragile".
Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.
Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.
Sometimes the IDE itself has random bugs.
A lot of time is spent workarounding IDE issues
By mikepurvis 2025-12-235:012 reply 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.
By thijson 2025-12-2316:41 Compiling RTL to run on an FPGA is way more complicated than compiling code to run on a CPU. Typically it has to meet timing, which requires detailed knowledge of logic placement. I'm not saying that's impossible, just that it's more complicated.
By SV_BubbleTime 2025-12-2315:341 reply > shouldn’t
Is doing so much heavy lifting here, I need to ask; how much FPGA configuration you have done before?
By mikepurvis 2025-12-2316:10 Very little, just student projects in undergrad.
So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.
By random3 2025-12-236:43 I just remembered I have a Xilinx I bought over a decade ago lying around somewhere. I don't remember ever plugging it in, but I do both the excitement of getting it and trying to figure out the toolchain and getting confused.
I agree but I think that writing yet another IDE extension is not going to solve the problems. An IDE will bring you one step further away from the actual hardware, and makes it more difficult to solve unexpected problems. Also, not everybody likes IDEs, some just prefer Vim and the commandline. An IDE is not the magical solution here.
Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.
By malmeloo 2025-12-2315:46 I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
Have you seen the YoWASP toolchain for VSCode [1]? It sounds pretty similar.
By malmeloo 2025-12-241:08 Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
By misnome 2025-12-2316:46 Oh christ, absolutely this. We spent some time evaluating FPGA for our purposes and ended up GPU instead (algorithms we running can be adapted to strength of either).
The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.
Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!
We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.
By exmadscientist 2025-12-231:037 reply FPGAs need their "Arduino moment". There have been so, so, so many projects where I've wanted just a little bit of moderately-complicated glue logic. Something pretty easy to dash off in VHDL or whatever. But the damn things require so much support infrastructure: they're complicated to put down on boards, they're complicated to load bitstreams in to, they're complicated to build those bitstreams for, and they're complicated to manage the software projects for.
As soon as they reach the point where it's as easy to put down an FPGA as it is an old STM32 or whatever, they'll get a lot more interesting.
It's already happened, people just haven't realized. iCE40-UP5K costs a few bucks, needs minimal support circuitry, and is supported by FOSS toolchains (yosys). Fun packages like the pico-ice bring it all the way down to the entry-level arduino crowd. It just doesn't have the marketing mindshare.
By ithkuil 2025-12-237:55 A few times over the past decade I wanted to start with a side project where I design and develop a CPU.
I bought a relatively cheap artic 7 board with 33kLUT and whatnot which I know people have used to implement risc-v implementations on.
But then I always lost my patience on the tooling.
For a side projects these days I need something comfortable. Something that that I can easily switch my context to without having to juggle VMs and installing unfriendly tools and use horrible IDEs
By nrhrjrjrjtntbt 2025-12-2310:16 Funny enough it is available on an UPDuino board: https://tinyvision.ai/pages/the-upduino
> FPGAs need their "Arduino moment".
This is exactly it. Why hasn't some expert group produced a very simple open design board with a simple Arduino-like IDE for FPGAs? Make it easy to access and use, get it into the hands of makers/hobbyists and watch the apps/ecosystem explode.
As an example, one could provide soft-cores for 8051/RISC-V etc. right out of the box with a menu of peripherals to mix and match. Provide a simple language library wrapper say over SystemVerilog (or whatever the community settles on) just like Arduino did (with C++) that makes it "easy" to program the FPGA.
For apps, one good example would be putting TinyML (or any other ML/LLM models) on a FPGA. This would take advantage of the current technology wave to make this project a success.
PS: Folks might find the book FPGAs for Software Programmers by Dirk Koch et al. (https://link.springer.com/book/10.1007/978-3-319-26408-0) useful.
The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
Loading them is a matter of plugging in a JTAG cable and typing “make program”.
I don’t know what you mean with the “manage SW projects for”?
By exmadscientist 2025-12-231:473 reply > you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose.
Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts.
Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing horsepower. And sometimes you need the certainty of hardware timing, which you get on a gate array and don't get any time there's a processor involved. Or, often, what I actually need is just a little bit of weird logic that's asynchronous, but too hard to do with the remnants of 74-series or 4000-series logic that are still available.
> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)
It is not complicated for people who have spent a long time learning and who have past designs they can copy from. (I have a few of those myself.) It is nasty to explain to a new person and very nasty to explain well enough to reproduce in the future without me around.
> Loading them is a matter of plugging in a JTAG cable and typing “make program”.
Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is possible. It is still a giant headache, and quite a bit worse than just dealing with an MCU.
> I don’t know what you mean with the “manage SW projects for”?
Two words: Xilinx ISE.
By exmadscientist 2025-12-232:102 reply > often, what I actually need is just a little bit of weird logic that's asynchronous
As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been wonderful if I could spend a little bit of money, buy a programmable thing in a 24-pin package, put it down, figure out some way to get the bitstream in (this is never pleasant in medium-volume manufacturing, so it's not like we're going to solve it now), and get my gate function that is literally one line of HDL. One. Line.
As it was, a 21-input OR gate is so much work in 74-series logic that I abandoned that whole thing and we did the bigger-picture job in a different, worse, way.
By summa_tech 2025-12-2312:121 reply Would a SLG46880 work for you? It has 28 GPIOs, enough LUTs to make a 21-input OR gate, runs off 2.3-5.5V (two VCCIO partitions, but you can tie them together). It costs like a buck in 5k quantities - they used to be much cheaper when you bought them directly from Silego, but now that they've been acquired the price has been _improved_.
By exmadscientist 2025-12-2710:51 The Silego stuff has been really attractive at high volume. This is what I think about when some of the other posters in this thread sniff at my cost expectations: this stuff can get real cheap if you have volume behind it.
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.
The device that you were looking was not an FPGA but a GAL22V10L.
By exmadscientist 2025-12-232:531 reply No, it wasn't. Those are mostly available in PLCC and DIP packages and even if you can get the SOIC/TSSOP versions they still cost $1.20 each at 10k volume. That's flat-out unacceptable for 99% of the things I do. The entire rest of the board I was talking about was $4.60. Processor included. $1.20 is not going to fly.
“Reduces use case and requirements to something impossibly niche and low volume then yells at the clouds.”
Anyway, just tie the output of 21 emitter followers together, add a resistor and - tadaaa - 21 input OR!
By exmadscientist 2025-12-234:30 Hey, that was my problem from last week. And, yes, I agree with you -- it was best solved another way.
But please don't complain when I give concrete examples of things I'd like to do but couldn't. (And please do recognize that there was a lot more context to the mess than just "I need an OR gate", but no one cares about the real gory details.)
By mitthrowaway2 2025-12-237:04 If only someone could make a single part that is very versatile, so that it could get production economies of scale while solving all the thousands of different random problems various people might have, whether they need a 21-input OR or something else. Like an array of gates, but field-programmable!
(That's a pretty steep price target even for a small FPGA though. With 16 pins maybe, but with 25?)
> sometimes … sometimes … sometimes …
And sometimes you need support for multiple IO standards.
I don’t understand what point you’re trying to get across.
But if all you need is LVCMOS33, why do you not use a MAX10 FPGA with built-in voltage regulator? Or a similar FPGA device from GoWin that is positioned as a MAX10 alternative? What is wrong with those?
> JTAG
On our production line, we use JTAG to program the FPGA? We literally used the same “make program” command for development and production. That was for production volumes considerably larger than 100k.
> ISE
ISE was end of life’d when I started using FPGAs professionally. That was in 2012. The only reason it still exists is because some hold-outs are still using Spartan 6.
By exmadscientist 2025-12-233:053 reply > I don’t understand what point you’re trying to get across.
My point is twofold:
1. There are many niches. Your main needs are not the same as my main needs. And my needs are poorly met by existing products, so I want to see something better. (And I do buy chips.)
2. All of this is way, way harder than it needs to be. It could be easy, but it isn't. Everything is possible right now. But I wasn't random when I used the dreaded A-word ("Arduino"). Arduino is a kind of horrible product that did not make anything possible and did not really invent anything. It did not make anything really hard suddenly become easy. Hard things before Arduino were still hard after Arduino. It "just" made some things that used to be medium-hard pains-in-the-butt actually really quick and easy (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!).
It turns out that is very valuable.
And is what I would like to see happen with FPGAs: make them easy to drop in instead of pains in the butt. All pieces for this exist, nothing is new tech, no major revolutions need to happen. "Just" ease of use.
By PunchyHamster 2025-12-235:511 reply > It did not make anything really hard suddenly become easy.
It did. Onboarding people onto embedded programmer.
You just ran it, wrote few lines and you had working blinky. Write some more and you have useful toy. You could even technically make products with it but going from this to C++ was easier coz you already know what you could do, just needed to go thru pain of switching the toolchain once you're already invested.
Compare that to "you need to setup compiler, toolchain, SDK, figure out how to program the resulting binary, map the registers to your devboard pins etc."
By exmadscientist 2025-12-2710:52 Ah, but that's only medium hard on my difficulty scale ;)
By 15155 2025-12-233:19 > make them easy to drop in instead of pains in the butt
How much easier does it need to be than putting down a single 1mm^2 LDO and a QFN IC? Is this really that difficult?
By ErroneousBosh 2025-12-239:58 > (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!)
Doesn't really matter if it does break; just use gcc and a Makefile like you would for any other firmware.
You probably want to replace the Arduino libraries with your own ones eventually anyway, because there's so much cruft in there that you're never going to use.
> and quite a bit worse than just dealing with an MCU.
Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming..
These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before, either.
By exmadscientist 2025-12-232:562 reply It's mostly the whole "two binaries" problem.
Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?
Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive?
Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that....
You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't. I am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.
Embed the bitstream into your MCU firmware binary, bitbang the 50-100KB bitstream into SRAM via JTAG from your MCU in all of 10ms. This is <100 lines of Rust.
By exmadscientist 2025-12-234:27 Yes, it's solvable. But my whole argument is that the entire experience is death by a thousand cuts. I'm not seeing how "it's possible in 100 lines of Rust" (a language most people don't even use for embedded work) is really countering my argument.
By tverbeure 2025-12-233:21 I honestly start to wonder how in the world we survived flashing 3 different binaries, for years (bitstream, 2 MCUs), without ever getting a complaint from the production floor.
I should check my spam folder.
Sounds like a PLD might suit your usecase? Simpler than an FPGA, programmed like an EEPROM, perfect for glue logic.
By javawizard 2025-12-231:462 reply 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.
By tverbeure 2025-12-237:21 I don’t see how CPLDs solve anything?
You write RTL for them just like you do for FPGAs, you need to configure them as well. The only major benefit is that they don’t have a delay between power up and logic active? But that’s not something that would make a difference for most people.
CPLDs are also a dying breed and being replaced with FPGAs that have parallel on-board flash to allow fast configuration after power up. (e.g. MAX10)
By bee_rider 2025-12-235:36 I don’t know anything about this (other than doing mediocre in some undergrad Verilog classes one million years ago). Wikipedia seems to call FPGAs a type of PLD. Of course, everybody has heard of FPGAs; is it right to think they’ve sort of branched off, become their own thing, and eclipsed their superset?
By exmadscientist 2025-12-231:40 "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.
By fennecbutt 2025-12-233:151 reply It's basically because they're so locked down, hard to get docs, stupid toolchains and ides like others have mentioned.
It's like fpga companies don't want people using them, much like others like the pixart sensor I wanted to use: NDA because some parasite dipshit executive or manager thinks that register layouts are extremely sensitive information.
I've had dozens of uses for an fpga...but every single time I just can't be bothered. Why, when they make it a pain in the ass on purpose.
By 15155 2025-12-233:21 None of these things are true for the new, cheap Chinese contenders.
> they're complicated to put down on boards
https://gowinsemi.com/en/product/detail/46/
- Requires just 1V2 + 3V3
- Available in QFN
- Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence
By exmadscientist 2025-12-232:591 reply > Contact Sales
> Request Sample
> Please login to download the document.
I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!
This is your job, and it really shouldn't feel difficult. This is really not tedious: the minimum board design for these chips literally consists of just power, JTAG pins, and a clock (if the internal oscillator isn't good enough.)
The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for <$1-2 in China. Efinix are available from DigiKey, with some SKUs under <$10.
All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)
By mschuster91 2025-12-237:431 reply > All of the Gowin documentation is available on their site with a free, approval-less email login
The problem is trust. I'm hesitant to hand out my e-mail anywhere because far too often I have been hounded by salespeople as a result, not to mention data breaches or bombardment of newsletters.
So just use Google to obtain the documentation? Or a fake email? The PDFs are pretty easily obtainable by title:
https://www.google.com/search?q=gowin+user+guide+filetype%3A...
https://www.google.com/search?q=gowin+primitives+filetype%3A...
By mschuster91 2025-12-2312:481 reply If I really need something I'll go that route, yes. But for something that is just on a "cool, that might be interesting" it's too much effort.
By exmadscientist 2025-12-2710:45 Exactly!
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.
By pclmulqdq 2025-12-232:27 The Altera Max 10 devices are also relatively simple to support (flash on the chip, few power rails, etc.)
By PunchyHamster 2025-12-235:37 They can't, by nature of the proprietary bitstream. Arduino was only built thanks to ability to do whatever they wanted with open source compilers
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.
By gnull 2025-12-236:18 > VHDL and Verilog are used because they are excellent languages to describe hardware.
Maybe they were in the 80. In 2025, language design has moved ahead quite a lot, you can't be saying that seriously.
Have a look at how clash-lang does it. It uses functional paradigm, which is much more suitable for circuits than pseudo-pricedural style of verilog. You can also parameterize modules by modules, not just by bitness. Take a functional programmer, hive him clash and he'll have no problems doing things in parallel.
Back when I was a systems programmer, I tried learning system verilog. Had zero conceptual difficulty, but I just couldn't justify to myself why I should spend my time on something so outdated and badly designed. Hardware designers at my company at the time were on the other hand ok with verilog because they haven't seen any programming languages other than C and Python, and had no expectations.
VHDL is ok, Verilog is a sin.
The issue isn't the languages, it's the horrible tooling around them. I'm not going to install a multi GB proprietary IDE that needs a GUI for everything and doesn't operate with any of my existing tools. An IDE that costs money, even though I already bought the hardware. Or requires an NDA. F** that.
I want to be able to do `cargo add risc-v` if I need a small cpu IP, and not sacrifice a goat.
Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.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
By kevin_thibedeau 2025-12-232:29 VHDL was designed for specification. Verilog is the one with the warts from its simulator heritage.
By oscillonoscope 2025-12-235:45 Language really isn't the difficulty. That's why there's a thousand alt-HDLs that have been used for little more than blinking LEDs.
By blackguardx 2025-12-230:482 reply 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.
By Cadwhisker 2025-12-231:17 # Here's the general flow for Vivado TCL projects that takes you from source code to a bit-file with no interaction. Read UG835 for details.
create_project -in_memory -part ${PART}
set_property target_language VHDL [ current_project ]
read_vhdl "my_hdl_file.vhd"
synth_design -top my_hdl_top_module_name -part ${PART}
opt_design
place_design
route_design
check_timing -file my_timing.txt
report_utilization -file my_util.txt
write_checkpoint my_routed_design.dcp
write_bitstream my_bitfile.bit
By exmadscientist 2025-12-231:053 reply 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.
By blackguardx 2025-12-231:53 I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.
By imtringued 2025-12-2311:251 reply I haven't learned Verilog, only VHDL and even that with the explicit <register>_ff <= <register_nxt> pattern when I need flips flops and I never felt like there is anything difficult about VHDL
Is the North American insistence on teaching Verilog what's setting up students for failure since Verilog looks a bit more like a sequential programming language at first glance?
By blackguardx 2025-12-2321:02 VHDL is based on Ada, so it also inherits from sequential programming models.
There is a trend among programmers to assume that everything supported by the syntax can be done. This is not even true in C++, but it's something people think. If you are writing synthesizable SystemVerilog, only a small subset of the language used in a particular set of ways works. You have to resist the urge to get too clever (in some ways, but in other ways you can get extremely clever with it).
By d_tr 2025-12-234:37 I thought that if you have some idea about how hardware works, it is kind of more or less obvious whether something is synthesizable or not.
Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…
This is how most FPGA users interact with vivado/quartus these days.
By halfdanwhitshrt 2025-12-2313:40 Any good guides you'd recommend to get started? Also does this workflow work with the cheap Chinese FPGAs available on aliexpress (tang nano, etc)? I always wanted to try out FPGAs again and I prefer to work from command line when possible.
By makestuff 2025-12-231:17 Yeah I agree it is a lack of understanding on how to use the tools. The main issue I ran into in my undergrad FPGA class as a CS student was a lack of understanding on how to use the IDE. We jumped right into trying to get something running on the board instead of taking time to get everything set up. IMO it would have been way easier if my class used an IDE that was as simple as Arduino instead of everyone trying to run a virtual machine on their macbooks to run Quartus Prime.
By checker659 2025-12-235:563 reply > software developers generally aren't very good at doing things in parallel
If only hardware people would stop stereotyping. Also, do you guys not use use formal tools (BMC etc) now? Who do you think wrote those tools? Heck all the EDA stuff was designed by software people.
I just can't with the gatekeeping.
(Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on reddit and elsewhere. It's damn frustrating to say the least. Also, the worst thing is all the hardware folks only know C so they think all programming is imperative. VDHL is Ada for crying out loud.)
By mgilroy 2025-12-2321:40 I was very specific in using the word generally. I taught a mixture of computer science and electronic engineering students. About three to four times more electronic students were competent for every computer science student over the years I taught.
It's not a case of just stating computer scientist weren't capable of doing it. They struggled with the parallelism and struggled with the optimisations and placements when you had to make physical connections on chips.
I'm well aware it's mostly going to be computer scientists writing the tools we use.
For those that want FPGAs to take off like the Arduino platform, I agree. I'd love it. However, it isn't the tooling that's holding it back. The reality is it is that cheaper, faster and easier solutions already exist. Why would you use an FPGA?
And their cited example was students. I think students would struggle at something new until they 'get it'. Would a software developer who does FPGA development professionally struggle more than, say, a hardware engineer?
By lesuorac 2025-12-2316:37 Sure but most of software development is about running single-core workflows on top of a parallel environment so the experience of a SWE is very heavily single-threaded.
The ever so popular JS is explicitly singlely threaded.
The default way of programming is with code on individual lines and when you run a debugger you step from one line to the next. This is not how code actually runs within a pipelined CPU though.
> EDA stuff was designed by software people.
No - EDA software is built by hardware experts moonlighting as software engineers, which is partly why it is so obtuse.
By checker659 2025-12-244:56 I said "was", not "is". Also, I know how that's working out. Working with Vivado makes me want to barf.
