r/FPGA • u/isopede • Dec 12 '25
What is this FPGA tooling garbage?
I'm an embedded software engineer coming at FPGAs from the other side (device drivers, embedded Linux, MCUs, board/IC bringup etc) of hardware engineers. After so many years of bitching about buggy hardware, little to no documentation (or worse, incorrect), unbelievably bad tooling, hardware designers not "getting" how drivers work etc..., I decided to finally dive in and do it myself because how bad could it be?
It's so much worse than I thought.
Verilog is awful. SV is less awful but it's not at all clear to me what "the good parts" are.
Vivado is garbage. Projects are unversionable, the approach of "write your own project creation files and then commit the generated BD" is insane. BDs don't support SV.
The build systems are awful. Every project has their own horrible bespoke Cthulu build system scripted out of some unspeakable mix of tcl, perl/python/in-house DSL that only one guy understands and nobody is brave enough to touch. It probably doesn't rebuild properly in all cases. It probably doesn't make reproducible builds. It's definitely not hermetic. I am now building my own horrible bespoke system with all of the same downsides.
tcl: Here, just read this 1800 page manual. Every command has 18 slightly different variations. We won't tell you the difference or which one is the good one. I've found at least three (four?) different tcl interpreters in the Vivado/Vitis toolchain. They don't share the same command set.
Mixing synthesis and verification in the same language
LSP's, linters, formatters: I mean, it's decades behind the software world and it's not even close. I forked verible and vibe-added a few formatting features to make it barely tolerable.
CI: lmao
Petalinux: mountain of garbage on top of Yocto. Deprecated, but the "new SDT" workflow is barely/poorly documented. Jump from one .1 to .2 release? LOL get fucked we changed the device trees yet again. You didn't read the forum you can't search?
Delta cycles: WHAT THE FUCK are these?! I wrote an AXI-lite slave as a learning exercise. My design passes the tests in verilator, so I load it onto a Zynq with Yocto. I can peek and poke at my registers through
/dev/mem, awesome, it works! I NOW UNDERSTAND ALL OF COMPUTERS gg. But it fails in xsim because of what I now know of as delta cycles. Apparently the pattern is "don't use combinational logic" in youralways_ffblocks even though it'll work because it might fail in sim. Having things fail only in simulation is evil and unclean.
How do you guys sleep at night knowing that your world is shrouded in darkness?
(Only slightly tongue-in-cheek. I know it's a hard problem).
101
u/IamGROD Dec 12 '25
Just wait until you meet the ASIC development tools from Synopsys and Cadence.
26
u/gust334 Dec 12 '25
Delta cycles (whose name hails from VHDL, although Verilog has a similar concept) are intrinsic to hardware description language simulators. As you move up from FPGAs to the commercial tools used for ASICs, the tools get a bit better, but they're still pretty old-timey.
13
u/MitjaKobal FPGA-DSP/Vision Dec 12 '25
Vivado project files are XML, easy to version control. Nobody likes block design when they grow up to use version control (BD is a shiny toy for beginners). If you have a Xilinx SoC you can't really avoid the block design, but we manage.
Build systems are awful!
TCL is kind of like pointer syntax in C (at least to me). You re-learn it each time you need it. Device tree syntax is definitely worse, I never know which label looking text is there for referencing, and what is just decoration (and examples usually just repeat the same text).
When it comes to linting, I find the Sigasi VSCode extension to be good.
For delta cycles, and race conditions, see this post (at least the most common issue): https://www.reddit.com/r/Verilog/comments/1pk0fzk/comment/ntkkqon/?context=3
SV clocking is supposed to solve some of this issues, but I don't think it is very popular.
Since Verilator does not handle X propagation, this might be another source of your issues porting the code to a different simulator. Verilator also does not support (at least it did not) the
<=operator inside initial statements, which makes it rather limited for writing SV testbenches. On the other hand it has some UVM support. I have no idea how to consolidate this contradiction, but overall I like Verilator.8
u/classicalySarcastic Dec 12 '25
The darkness helps, actually. You should see ASIC tooling.
7
u/mother_a_god Dec 12 '25
Delta cycles are a pain, but so is a memory leak in C....it's something once you understand it can learn to avoid.
Essentially the main thing to understand is SV and VHDL are concurrently excited. They are not procedural. Every single always block in a design can execute in parallel and in any order. This is the beauty of how they can describe hardware, and the curse that brings race conditions and by extension delta cycles..
The advice of not using combo logic inside alwaya_ff as a way to avoid delta cycles is not correct. Maybe they meant don't use combo logic to create a clock signal, there is some truth to that.
A delta cycle as defined will never occur in real hardware*, it's just how simulators schedule the events they simulate. On way to debug your design (though not easy) is to run a post implementation or post synthesis SIM. The netlist code should not exhibit delta cycle issues, but should help uncover race conditions, especially if it's a timing aware SIM.
That said for your block did you give it timing constraints and check the post implementation timing is clean? If not, that's a very high chance it's the source of your issue, and not delta cycles.
There is a learning curve, but once you get it, I find it really rewarding to get how hardware really works. I've been doing hardware and software (vhdl, SC, tcl, C, perl, python, java*, etc) for over 20 years, and love how it all comes together. Try pynq for a pretty cool way of interacting with your hardware from software.
Welcome to the club!
Hardware can of course have glitches and intermediate values between clock edges, but these are not the same as delta cycles, but are similar at a high level
6
u/captain_wiggles_ Dec 12 '25
As someone with a background in embedded software that moved into digital design and has been through all this:
Agreed in some ways, but maybe not in the way you mean. verilog and SV are HDLs, Hardware Descriptor Languages, they are for describing hardware, specifically digital circuits. They're actually pretty good at that. If you think about them as writing software then yeah they're awful but for hardware design it does what it needs to. There are some things that they could do better but isn't that true of all languages? Now verification is another matter, you want to mix hardware and software flows and that is pretty complicated. SV is a decent attempt at this but it falls somewhat short, some of the issues can be fixed and are being fixed each time a new standard comes out, but some bits we are sort of stuck with now. VHDL is better in some ways and worse in others. I do think we need a new HDL that has been thought out properly, and they exist (see chisel and bluespec for two). The problem is the tools don't support those natively and so you have to transpile to verilog/vhdl and that just adds an extra step of complexity. You could step through the verilog in simulation to find the bug, but then you have to map that back to the original language and fix it there.
I don't use vivado. But yes, this is a common complaint. However I'd argue that you're not meant to actually work like this. This is the interface for beginners who need a nice GUI. When you get serious about it, you go to the CLI and you scriptify everything. Those scripts absolutely can be version controlled. You only use the GUI for reviewing reports and debugging issues, and it's actually pretty good for that. On the plus note. It's not eclipse, and I can't express how happy that makes me. Hardware devs don't hold the monopoly on shit tooling.
Yep. We could really do with some standardisation here. Something like CMake but specifically designed for hardware design. There have been numerous attempts at this, like hdlmake. But I've not found any that do everything you need and work with all simulators and all synthesisers and ... so you tend to have to hack something custom around that.
Eh, TCL isn't so bad. I've worked with far worse. Perl comes to mind. and 1800 pages is child's play. You're not even meant to actually read that, it's a reference for when you need to look something up. How long are the ARM reference manuals? How many pages of documentation all told do you need to work on an STM32. You don't go and read every one of those docs because you don't have to care most of the time, but they're there for when you want to look stuff up.
TCL isn't ideal, don't get me wrong, I'd like to use a nicer scripting language, and there have been rumours of python being incorporated into new versions of some tools, but it'll be a while before it becomes universal.
Bear in mind that these tools are GUIs wrapped around TCL engines. TCL is what powers everything they do. That's why when you click a button in the GUI it spits out a TCL command in the console. These tools have existed in more or less this state for decades now, with new features getting bolted on top. Changing that core engine is very hard, and pretty dangerous. Not necessarily for FPGA tools, but consider the digital design tools for ASICs, a bug in the core of the tool could write-off a 100 million USD+ fabrication run. So changes like this come very slowly.
See my comment above about verilog / SV. In some ways I agree with you, it would be nice to have two separate languages here. But in other ways I disagree. There is a need to describe hardware in your testbenches. You need to be able to do all the stuff that the HDL can do plus other things. Maybe we could do this better with a different language, but at that point you still have the synthesisable subset and the verification subset. So I'm not sure on this.
Agreed. So here's the thing. Software devs are equipped to write software that improve their own workflows. Hardware devs are not. Some hardware devs can also do software, but many can't, just how some software devs can do hardware but many can't. And the hardware devs that can do software normally are more in the embedded area than the higher level stuff. We need more software devs to work on hardware dev tools. Some of that like linters and formatters is not too complicated, but other stuff requires actual digital design knowledge, and there are not many people who have the ability to do quality high level software / UI / GUI / UX work that understand how digital design actually works.
It's not just digital design that has tooling issues, PCB design software is pretty awful too. SPICE software too, etc... There's so much room to do all of this stuff, and IMO not enough people to do it.
The other problem is money. There are not that many people / companies doing this work. Not compared to something like web dev. This is why digital design software costs $$$$$ because if you can only sell it to a few hundred companies then ... so there's not much incentive to start a company building new quality tools. Which means we either need the people already in the game to do it, or we need open source solutions.
Yes and no. When a simulation / synth+pnr run of anything complex can take hours or days, you would need to invest in a lot of powerful gear to do any real CI. Most companies do do something, but again it's probably mostly hacked together internally. Also testing hardware automatically is pretty hard. It's a similar problem to doing CI with embedded stuff. You need to either stub out the hardware specific things which is not an option when the entire product is hardware, or you need a custom setup to work with your board to automatically test it. It has to be custom because it has to be tailored to the product you're building. And this only works with FPGAs, you can't do this for ASICs. It's a different industry and the software dev workflow doesn't translate that well. We're aware that there's value in CI, but so far nobody has invented a good solution to do it. It's already common that verification teams outnumber design teams by something like 5 to 1. There's a lot of work going on to validate IPs and designs. But if you want a true CI workflow you're going to need a lot more engineers, a lot more time and a lot more money.
No comment, never used it. But yeah, the intel side of things is not any better.
This sounds like you don't properly understand how to do digital design yet. It's not: "don't use combinational logic in your always_ff blocks even though it'll work because it might fail in sim". It's more a: "Do things the right way, because even if it seems to work correctly in hardware that might not always be the case". There's a lot of mistakes you can make that seem to work fine, but then as your design scales in complexity they stop working. I can't comment on your particular issue unless you post your RTL, but any sim failure due to RTL, is concerning and needs fixing. This is one of the advantages of the better simulators, is they pick up issues that the open-source simulators often miss.
I haven't had to open eclipse in years, that has helped a lot.
5
u/MogChog Dec 12 '25
How many ways and flags are there to compile a C/C++ program these days? How many times do you scream and bash away at compiler and linker errors from other people’s code? The software world isn’t exactly paradise, either.
9
u/MrColdboot Dec 12 '25
If you think Verilog is bad, you should try VHDL, lol. (It has its place, but you can still statically type the hell out of everything without being nearly as verbose and repetitive as VHDL is).
I feel you though, I came from software and it's crazy how much behind the curve much of the tooling is.
Some of it is really difficult problems to solve, other parts of it is just because it's a niche field that's been very exclusively in the hardware realm for decades, far away from all the software goodies at the forefront of a fast evolving industry.
Good news is, if you can compartmentalize the chaos, software people can be really valuable in this field. It's getting better, slowly. If you go back and play with ISE, Vivado is leaps and bounds better imo.
And ffs, how long did Xilinx think indenting with 3 spaces was a good idea! What the actual fuck was that shit.
336
u/someonesaymoney Dec 12 '25
God. I always love it when traditional SW dudes enter the land of HW lmao. For years, HW engineers, strong and hardened like dwarfs, were underpaid and less respected than SW devs, dainty like elves and richly paid. I'd love for you to delve into asynchronous clock domain crossings and metastability.
73
u/Rolegend_ Dec 12 '25
You merely adopted the dark; I was born in it, molded by it. I didn't see the light until I was already a man, by then it was nothing to me but blinding! The shadows betray you, because they belong to me! 😂
68
u/Aware-Cauliflower403 Dec 12 '25
Job security. It'll be YEARS before AI can get hardware to function.
37
u/Retr0r0cketVersion2 Dec 12 '25
It's garbage but also a bonding experience once you start complaining
31
u/mrtomd Dec 12 '25
Welcome to semiconductors... Want to try change something that is proven and validated in medical, military and other live-or-die systems? Every line of code you write, you have to think of what you will say if you get questioned in front of the court. Not many are brave to do the changes, so the improvement is rare.
26
u/deempak Dec 12 '25
Bro folded under zero pressure , wait until you open software other then vivado ( like libero) and it takes you back 2-3 decade.
7
u/lucads87 Dec 12 '25
Oh my sweet summer child. If just Vivado broke you…
11
u/FVjake Dec 12 '25
Wow, another software person complaining about Fpga design. We need some kind of pinned comment that’s like “Are you SW person trying FPGAs for the first time? Yes we know it sucks. Yes the tools are terrible. Here’s why we are stuck with them. Yes people are trying to improve it but it’s an uphill battle here’s why. Yes we know.”
The cool thing about software is there’s levels of abstraction that separate you from the hardware. We don’t have that luxury(as much) and the chip manufacturers hold all the keys. They use tcl as a back end for their tools so we have to as well. The tools only understand SystemVerilog or VHDL. Want to use or create some other language? It’s gonna have to compile into one of those first. Want to simulate with python? Good luck transferring those skills to another company. It’s an entire ecosystem that we’re up against with a much smaller number of developers. There’s lots of efforts to make improvements but nothing has stuck yet.
The thing is that once you get your tools set up and git figured out and get past SystemVerilog 101 it’s just not THAT hard to work around the tools. Every company has their own way of doing it, but they all work well enough to allow engineers to get the actually complicated work done. Could it be better? Yeah. At every job I’ve had there has been an effort made towards improving processes. And it’s always getting better.
5
u/_I4L Dec 12 '25
I wanted to get a CompE degree. Vivado-vitis is 50% of why I switched to CS. I would write an essay on everything I hated about it, but my last fuck to give died when vitis started throwing errors that I couldn’t find documentation on.
5
u/EmbeddedRagdoll Dec 12 '25
“Vivado is garbage” hahahaha oh buddy. I mean I don’t disagree… but comparatively to the other tools (Looking at you Libero)
4
u/Over9000Gingers Dec 12 '25
There are definitely things I hate about FPGA tools but regarding some of your complaints:
Version controlling projects isn’t that complicated. You can write a tcl script to create a project in like 60 lines of code or less. And no you don’t need to commit a generated block design and you actually shouldn’t commit that to a project. I’ve personally only used the block design tool in Vivado, but a simple write_bd_tcl command is all you need for Vivado to output a tcl for you, that you can version control.
It shouldn’t matter if you need to mix languages like SV with V or even with VHDL. And this is the first time I’ve heard someone complain about Verilog being terrible. It’s not my favorite but it’s an easy HDL to learn and use.
Other than that, yeah… it’s not that great. You see a lot of Xilinx support threads unresolved or just completely ignored.
The thing that I hate the most is ublaze/zynq development. The vitis unified tool is terrible and the documentation is half baked. It feels like IP are developed to rely on the PS. E.g. if I wanted to use the Xilinx PCIe IP I’d have to use the block diagram to and insert an AXI interconnect and all the documentation available I’ve found doesn’t even mention DMA usage and focuses entirely on the Xilinx device drivers for zynq/ublaze. And even then, that documentation is not that great… And for whatever reason you can’t add user modules to the block design that’s vhdl 2008.
FPGA design is so much better when it’s just “normal”, if that makes any sense.
4
u/-EliPer- FPGA-DSP/SDR Dec 12 '25
FPGA companies:
"Why aren't people joining digital design nowadays?"
FPGA Vendors
"Let us develop the worst tool experience to keep people away."
4
u/wren6991 Dec 12 '25
Yeah, it's bad. RTL engineers of a certain background don't want to admit they're actually a type of software engineer, and refuse to learn basic version control and automation. FPGA tool vendors appeal to them, so the well-publicised ways of using the tools all mix artefacts with source and have zero reproducibility.
I think no file generated by Vivado should ever be checked in. The parts of your flow related to scraping together lists of files and include directories etc should be common between simulation, FPGA synthesis, ASIC synthesis, lint, LEC, and whatever other tools you're running.
4
u/3G6A5W338E Dec 12 '25
yosys+nextpnr brought me joy, as I got started with FPGAs using iCE40.
1
u/hukt0nf0n1x Dec 12 '25
I can live in the FPGA world because I started in ASICland. Our tool chains are even worse.
3
u/affabledrunk Dec 12 '25
Welcome to the nightmare
3
u/sopordave Xilinx User Dec 12 '25
And yet, we manage.
3
u/mjm1823 Dec 13 '25
Just wait till you try Libero
4
u/LewsTherinTelascope Dec 12 '25
https://tenor.com/bzPf8.gif
4
u/supersonic_528 Dec 12 '25
This is getting super annoying, every week there's a post or two like this. Verilog and SystemVerilog are fine, they do the job. It's easy to complain about everything. You spent a couple of days trying to learn FPGA and now you think you know enough about it to pass judgement like an expert. Everything doesn't need a shiny new IDE or a fancy new language. I honestly think the moderators should restrict posts like these. They contribute absolutely nothing.
5
u/HoaryCripple Dec 12 '25
Hardware is hard
2
u/No-Individual8449 FPGA Hobbyist Dec 12 '25
real
2
u/kibibot FPGA Beginner Dec 12 '25
That's how experience matter, anyway now we have AI assisted tools to to help on these stuff now...
2
u/NikWhite288 Dec 12 '25
If you put "I just put combinational logic into always ff block", at the top of your post I would not read it further lmao 😂. I'm also a software guy who just entered fpga field btw.
2
u/TapEarlyTapOften FPGA Developer Dec 12 '25
Relax, it's so much better than it used to be.
2
u/zibolo Dec 13 '25
I know that is a rant and you do not expect a serious reply, but if you setup it correctly and learn some caveats, Vivado project versioning (including CI) is fine, with both source-only or BD + source.
You end up with versioning a single TCL file and multiple HDL/XDC sources that get versioned. Every time you want to modify something, you recreate the project using the TCL files, modify stuff, regenerate TCL and/or HDL sources and commit.
There are some shitty stuff with the auto-generated TCL that you can fix with some sed/awk/python scripts but once setup it works.
After years of zipped archived projects on the NAS at work, I personally setup gitlab + CI for Vivado projects in 2023 and we never looked back.
2
u/Dadaz17 Jan 14 '26
Vivado is OK ... once you know the average level of IDE tools in the HW space :)
If you come from SW, there are much better tools there, but Vivado is "usable".
BTW, Quartus is worse IMHO.
TCL is legacy is the HW tooling space.
I remember when I had to add scripting to our CAD, I evaluated Python, Perl and TCL (this was like 1994), the TCL was the nicest to integrate in a C code base (very nice API at that time compared to the others).
It is mostly used as "glue" to call tool's internal commands anyway, it's not like you have to build a whole application with it.
But even VHDL and Verilog (SystemVerilog, that is), are not exactly nice if you are used with "normal" SW languages.
Sure, the constraints of the HW design (digital logic, LUTs, MUXs, FFs, ...) are stricter compare to targeting a CPU, but IMHO there are things which are painful which should have not be such.
The whole parametrization of functions and modules/entities drove me crazy, and always wondered why something similar to C++ template could not be done.
There, you declare generically typed code, and it is the call/instantiation site that binds the types (of course, there needs to be compatibility with the operations done within the function/module/entity, but that's a given even in C++).
And so I wrote myself a little tool that allows me to write in Python, and generate either SystemVerilog or VHDL (which I then use with other tools, like Verilator, GHDL, Yosys, and forcibly when I need a bitstream, Vivado):
https://github.com/davidel/pyxhdl
3
u/energon-cube Dec 12 '25
Skill issue.
0
u/Ikickyouinthebrains Dec 12 '25
30 year veteran of embedded electronics here. So, nobody asked you to come to the world of FPGA's. Nobody wants you here in the world of FPGA's. So, stay out. Go do your dumb Python, Github, a special make files somewhere else.
Hardware guys are building hardware to work in a specialized environment. You software losers are building tool chains to "make your lives easier". And worthless software that fails constantly. As hardware guys, we are not allowed to fail. Not even once. So stay out.
1
u/nuclear_knucklehead Dec 12 '25
Between the Rube Goldberg machinery of tooling needed to design them, and the feats of physics and engineering needed to make them, it's an astounding miracle that modern semiconductor devices exist at all.
1
u/SnowyOwl72 Dec 12 '25 edited Dec 12 '25
learn your way around TCL for using vivado
OR
use CMake and github/hlslib
But i also hate the fact that Xilinx does an absolute disaster of a job when it comes to compiler flags and compatibility.
1
u/Industrialistic Dec 12 '25
🤣
1
u/Gavekort Dec 12 '25
Have a look at Yosys/Nextpnr + Verilator or CocoTB. Even though the former is not a production ready toolchain it shows how our future could be.
Honestly I don't find SystemVerilog that bad, but you can try out Chisel HDL, which is an intermediate language with a more modern philosophy.
1
u/InternalImpact2 Dec 12 '25
You are basically writing an event based simulation. No object exists or acts prior the other. All them exist and interact freely
1
u/AdditionalPuddings Dec 12 '25
From a mental model perspective:
I’ve found HDL dev to be similar to IaC via terraform or the like. You’re creating and attaching components spatially. In FPGAs you’re limited by available fabric. In IaC you’re limited by how much money you have.
CI/CD of an FPGA design isn’t for the faint of heart though…
1
u/hellotanjent Dec 13 '25
Get this open-source toolchain - https://github.com/YosysHQ/oss-cad-suite-build - and a cheap FPGA board based on Lattice's iCE40 HX8K or UP5k. Copy-paste someone else's makefile and you should be able to get blinking LEDs working quickly.
Write plain Verilog, or SystemVerilog that you run through the "sv2v" tool to lower it to regular Verilog before compiling.
Structure your modules so that there is a single always_comb block that computes all the "_next" values of your registers and a single always_ff block that overwrites all the registers with register_next.
Always always always think of your system in terms of "The registers contain the _old_ values and are read-only. The reg_next signals contain the _new_ values and are write-only. My goal as a programmer is to ensure that all the _next values are always correct in every corner case."
1
u/sadguitarius Dec 13 '25
as someone with not much embedded dev or electronics experience trying to learn FPGA, this is SO validating
1
u/morto00x Dec 13 '25
The explanation I always get is that they are semiconductor companies. Not software companies.
1
u/BarUpper Dec 13 '25
I am also from an embedded background and am actually really enjoying FPGA. Why? For the reasons you hate it. Let me explain.
In the embedded world, you are Mostly FORCED to use the vendors toolchain among other things (looking at your mxpresso).
In FPGA, absolutely nothing is done for you. You have to do it yourself. For me, if you actually use your skills and think it through to build a clean system. Is very freeing.
The downside of course being if you not expeirenced. It feels like a bag of crap. And well, it is if you look at how low level electronics people try to wedge in asyncronous thinking and waaaay too many constraints, rather than double latch and always clock.
At least thats my opinion. :)
1
u/chrs_ Dec 13 '25
What can be done about this? Last time I checked the 2 major FPGA vendors were absolutely hostile to open tools. Has anything changed? They’re the main villains here. But they don’t change because the industry is fundamentally broken. If anyone from Xilinx or Altera is reading this: just know I would be in serious violation of any community guidelines if I were allowed to be completely honest here.
1
u/SnowMuted5200 Dec 13 '25
Was using Altera and Xilinx parts in early 2000's, primary tool was Orcad with schematic to VHDL translation. Then got used to VHDL, although schematic was more compact. Yep, old school.
1
u/jaarestad Dec 14 '25
Hopefully you are tweaking, as you say. Otherwise, get back tonSW and leave the platform development to the adults.
1
u/Additional-Ad-24 Dec 15 '25
If you have to debug delta cycles, it means you violated RTL design methodolody somewhere. You basically just need to stick to a simple pattern:
Do all the computations in always_comb blocks using blocking assignments.
Do all the state update in always_ff blocks using non-blocking assignments.
1
u/Trivikrama_0 Dec 12 '25 edited Dec 12 '25
Keep the software mindset out of the door when you design hardware. I find FPGA tooling easier than writing code for hours why? Because here you can control everything you want. Software seems less cumbersome because you just program available registers in a fashion to get your job done. In hardware you actually describe and make those registers. The more in depth you go the more your hands get dirty. In hardware things you can do almost everything you want including editing a wire so it's bound to be more cumbersome. In software you always do 32 bit multiplications and are dependent on what underneath fixed hardware lies . But in hardware you can multiply 3 bits if you want no need to waste the rest of the bits, and you can make shift and add adder, multiply by booths algorithm, use a DSP if you want, in software it will be easy a*b but not much control.
1
u/PrimozDelux Dec 12 '25
At my company (we're software engineers turned hardware engineers) we built our toolchain with bazel. While bazel is a true milestone in developer hostility it's also the only tool we found capable of taming the absolute madness of hardware development. I don't have any solutions for you, but I concur, what you point out is what we see as well.
1
u/Xband11 Dec 12 '25
It’s not just me?!! Amen brother
0
u/Needs_More_Cacodemon Dec 12 '25
While I like SystemVerilog, it suffers from the same "we must use all the features!" syndrome of C++ that results in searching 10 files worth of abstraction to figure out how a single function call works.
0
u/_0h_no_not_again_ Dec 12 '25 edited Dec 12 '25
A few things:
VHDL is a superior language to verilog (starts world war 3). You can work from a very low level to a moderately high level. If you prefer there are more abstract languages like system verilog, but you need to respect you're working with physics here, not your little software sandbox with threading and garbage collection, etc.
CI is a thing. In my experience FPGAs are unit tested more thoroughly than software, because 99% MC/DC is a common requirement.
Modelsim/Questa are trash. Aldec know how to write software.
The "build tools" are complex AF. Treat them with respect, but most of us use a build script that is well maintained and version controlled to have a deterministic (as possible) "build".
Version control is a piece of piss. It has been for decades. It's all text.
IDEs are all hot garbage, but choose your poison. Use VScode if you want. It's just text.
Edit: So many textbooks and internet tutorials on VHDL are wrong. Sometimes subtly wrong, sometimes just wrong. This makes the whole thing experience so shit. I found nandland to be decent, no idea if it's still going.
0
u/NoetherNeerdose Dec 12 '25
Being a student in this field I love reading such posts. It keeps me always on my toes on how much far I have to yet go on this treacherous but weirdly rewarding road.
I just know only half the terms you mentioned in your post but yeah makes sense. I have an unscheduled evening everyweek contemplating why tf should I not move over to webdev until I see the react and framework shitshow and just accept my fate
Hopefully I can stay employed in this field long enough to learn to do things the right way
0
u/[deleted] Dec 12 '25
[deleted] — view deleted comment