Adrian Sampson: Back to the Building Blocks’ Building Blocks
Back to the Building Blocks’ Building Blocks
May 26, 2026
This post is based on a keynote I gave at Dagstuhl Seminar #26042, Trustworthy System Architectures for the Age of Custom Silicon. Many thanks to the seminar's organizers and to the Dagstuhl staff for a fun and enlightening workshop.
If there are hardware engineers who love Verilog, I haven’t met them.<br>Almost universally, the attitude toward Verilog seems to be that it’s frustrating, ridiculous, error-prone, and the only pragmatic choice.
Verilog is inescapable because it is the input format to essentially every EDA tool.<br>Its centrality means that it is a de facto intermediate representation implementing for every other HDL:<br>even if you prefer Bluespec, Chisel, Amaranth, or Spade, they all have to compile to Verilog to interact with the rest of the hardware world.
I am worried that Verilog’s flaws will be the cause of a new wave of hardware bugs.<br>There is an analogy to the problems with C and C++:<br>as designing custom hardware becomes more popular, we risk allowing a dangerous HDL to proliferate and fester in the same way that memory-unsafe programming languages have in software.
I don’t know yet what the analog of memory safety is for hardware bugs, or even if there will be a single dominant defect category.<br>Footguns abound in Verilog, though, so there are many good candidates.<br>This post makes the case that we should invest in better understanding the problems with Verilog so that future HDLs can avoid them.
On Building Blocks
As an American programming languages nerd, I believe that<br>“Back to the Building Blocks” was one of the most exciting developments of the last decade.<br>It’s a 2024 report from the White House Office of the National Cyber Director that makes the case for memory safety.<br>It calls for critical infrastructure to move on from memory-unsafe languages like C and C++, and it even mentions Rust by name as a promising alternative.
“Back to the Building Blocks” didn’t break new ground:<br>by 2024, it was obvious to all reasonable people that memory safety was a huge problem.<br>It was exciting because Joe Biden was saying the same things that we had all been saying for years.1<br>I’m not a very patriotic person, but my heart soars like a majestic bald eagle when I read stuff like this in a government report:
Despite rigorous code reviews as well as other preventive and detective controls, up to 70 percent of security vulnerabilities in memory unsafe languages patched and assigned a CVE designation are due to memory safety issues.
And I can hear the national anthem playing when the report says:
For new products, choosing to build in a memory safe programming language is an early architecture decision that can deliver significant security benefits. Even for existing codebases, where a complete rewrite of code is more challenging, there are still paths toward adopting memory safe programming languages by taking a hybrid approach.
God bless America.<br>“Back to the Building Blocks” distills a hard-to-refute syllogism along these lines:
Correctness matters.
There exist large classes of bugs with similar root causes.
Some languages lead to a higher frequency of these bug classes than other languages.
We should therefore see these bugs as the “fault” of the language, not the programmer.
Languages that are harder to use but dramatically reduce the frequency of these bugs may be worth it.
In the original report, this “Building Blocks” argument was about C.<br>But I believe the same reasoning applies to Verilog.
The Claim (Weak and Strong Forms)
I’ll state my thesis in a weak form and a strong form; you can pick which level you want to consider.<br>The weak form is:
Verilog causes lots of bugs.
And the strong form is:
The next “Building Blocks” crisis will happen in hardware, and it will be Verilog’s fault.
In other words: at the same moment that we’re beginning to get a handle on memory safety,<br>we’re producing a lot more Verilog code.<br>So the next scourge of avoidable bugs could occur in hardware.<br>Better HDLs could dramatically reduce the frequency of these bugs.
Verilog’s problems are not new, but until now, hardware design methodologies have attenuated their harm.<br>The traditional way to develop hardware—the kind of process that big CPU vendors use—mitigates Verilog’s problems in part by expending a ridiculous amount of resources on verification.<br>This observation is hard to justify with concrete evidence, but consider this somewhat dubious report from an industry consortium that claims that, in CPU design projects,<br>the ratio of verification engineers to design engineers is 5:1.<br>A terrible HDL matters less when you have a safety net like that.
But today, more people want to design custom, application-specific hardware.<br>Specialized,...