DESIGN VERIFICATION  ·  ARTICLE 01 OF 06

Why verification is the hardest engineering job nobody talks about

RTL designers get the glory. Verification engineers catch the bugs that would have shipped to a billion devices. It's time we talked about that.

 

There's a conversation that happens at almost every semiconductor company, at some point in every project cycle, that goes something like this:

"So what do you do?"

"I'm a design verification engineer."

"Oh — so you design chips?"

"No. I verify them."

"What does that mean?"

And then you try to explain, in thirty seconds, a job that takes years to understand. A job that is, in many ways, the reason silicon works at all.

Let's fix that.

The invisible discipline

Every chip that ships — every processor in your phone, every AI accelerator in a data center, every microcontroller in your car's braking system — passed through a verification process before it was manufactured. Fabrication is irreversible. A mask set costs millions of dollars. A respin delays a product by six to twelve months and can sink a company's roadmap. The job of design verification is to make sure that never has to happen.

And yet, when people write about chip design, they talk about architects and RTL engineers. When a processor breaks a benchmark, the designers take the stage. When a chip ships late, the schedule slips are blamed on the process, the tools, or the market — rarely on verification.

The discipline is invisible when it works. It only becomes visible when it fails.

The discipline is invisible when it works. It only becomes visible when it fails.

That asymmetry — between the consequences of failure and the recognition of success — is the central reality of a career in design verification. It shapes everything: how the work is structured, how teams are valued, how engineers develop, and why so many talented people in this field quietly feel like they're carrying more than their share of the project.

What design verification actually is

If you asked most people outside the semiconductor industry to describe chip design, they would describe RTL — writing hardware description language, specifying the logic, defining the architecture. That part is real. It's also, on a modern SoC, roughly half the engineering effort. Sometimes less.

The other half — verification — is the systematic, adversarial, creative process of proving that the design does what it's supposed to do. Not just for the happy path. For every legal input sequence. For every corner case the designer never imagined. For the race condition that only appears under a specific combination of clock skew, power state, and bus arbitration.

This involves:

• Building testbench environments from scratch — complex, layered software systems in SystemVerilog and UVM that can rival the design itself in size and complexity

• Writing constrained-random stimulus to explore an enormous space of possible inputs automatically

• Defining coverage models that measure what has been tested — and more importantly, what hasn't

• Creating checkers and scoreboards that can detect when the design is subtly wrong, even when the bug has no obvious symptoms

• Running formal proofs over critical control logic to guarantee properties hold across all reachable states

• Debugging failures — which means reconstructing, from simulation logs and waveforms, exactly what sequence of events led to a problem that might occur only once in a billion cycles

 

None of this is checking boxes. None of it is scripted or mechanical. Good verification requires deep creative thinking — the ability to imagine how a system could fail, often before the system fully exists.

The asymmetry of credit

Here is the uncomfortable truth about verification work: when you do it perfectly, nobody notices. The chip tapes out. It comes back from the fab working correctly. The team celebrates. The designers get asked to give a conference talk. The verification engineers update their LinkedIn profiles with the tapeout date and move on to the next project.

When verification misses something, the consequences are very visible and very expensive. A hardware bug in silicon might be patchable in firmware — at high cost and performance penalty — or it might not be fixable at all. Intel's Pentium FDIV bug in 1994 cost the company $475 million in reserves and permanent damage to its brand. The Therac-25 radiation therapy machine, which killed patients due to software and hardware errors that went undetected, is a case study in what happens when verification is treated as an afterthought.

These examples are extreme, but the pattern holds at every scale. The verification engineer who catches a subtle deadlock in a cache coherency protocol at the simulation stage prevents a respin. The respin that doesn't happen is a ghost — invisible, uncelebrated, and very real.

The bug you caught before tapeout is a ghost. Nobody writes a press release about a problem that never shipped.

This is why DV engineers often feel undervalued in a way that's hard to articulate. It's not that their work isn't recognized as important in the abstract. It's that the specific, concrete, daily contributions — the regressions run, the corner cases caught, the coverage closed — don't generate the same kind of visible artifact as a new feature or an architectural win. You can't demo a bug that didn't ship.

Why DV is harder than design

I want to be careful here. RTL design is hard. Microarchitecture is hard. Getting timing closure on a modern process node is genuinely difficult work. I'm not arguing that one discipline is better or more skilled than another.

But I am arguing that verification has a specific kind of difficulty that is consistently underestimated — even by experienced engineers who've worked in both areas.

Design has a specification. You know what you're building. Your job is to build it correctly. You can be right.

Verification has no such luxury. Your job is to prove that something is correct — comprehensively, across all inputs, under all conditions — without being able to enumerate all inputs and conditions. You are searching for problems in a space that is, in the general case, infinite. You are trying to prove a negative. And the question "have we verified enough?" has no clean answer.

This is a fundamentally different kind of intellectual challenge. It requires:

• Deep knowledge of the design you're verifying — often more detailed than the designer's own knowledge, because you need to understand exactly what could go wrong

• Mastery of a completely separate tool stack and methodology — UVM, SystemVerilog assertions, formal property verification, coverage analysis

• The ability to reason about probability and randomness: which inputs are you likely to miss, and how do you construct stimuli that reach the dark corners

• Software engineering discipline — because a testbench bug can mask a real design bug, which is arguably worse than no testbench at all

• Judgment: when coverage is at 94%, and the deadline is in two weeks, what do you do?

 

That last one doesn't have a textbook answer. It requires experience, judgment, and the ability to communicate risk clearly to people who want to hear that everything is fine.

The case for DV as a first-class discipline

The semiconductor industry is at an inflection point. Designs are getting more complex — more IP blocks, more interfaces, more power domains, more operating modes — faster than verification productivity is scaling. The gap between what can be designed and what can be thoroughly verified is widening.

AI-assisted design is accelerating this. If LLMs can help architects explore design spaces faster and RTL engineers write more code per day, then the verification bottleneck becomes more acute, not less. Every advancement in design productivity that outpaces verification productivity makes the verification problem harder.

This is an argument for elevating verification — in career structures, in tooling investment, in research attention, and in how companies think about engineering headcount. The ratio of verification effort to design effort on complex SoCs is already somewhere between 2:1 and 5:1. The engineers doing that work deserve to be treated accordingly.

It's also an argument for verification engineers to take ownership of their own visibility. The work speaks for itself only to people who understand it. For everyone else, you have to explain it — clearly, repeatedly, and without apology.

Why I'm writing this

I started this blog because there is very little content written specifically for working design verification engineers, by someone who does the work. There are textbooks. There are EDA vendor tutorials. There are conference papers. There are almost no honest, practical, first-person accounts of what it's like to do this job — the methodologies that actually work, the anti-patterns to avoid, the judgment calls that aren't covered in any spec.

Over the next several articles, I'm going to write about exactly that. UVM patterns that help and hurt. What closing coverage actually means (and why 100% isn't what you think). How to debug a failing regression when the log is 400,000 lines long. Where formal verification fits into a simulation-first flow. And what AI tools actually change about this work — and what they don't.

If you're a DV engineer, I hope this is useful. If you're adjacent to DV — a designer, an architect, a manager — I hope it gives you a better picture of what your verification team is actually doing.

And if someone asks you what design verification is, send them this.

 

Next in this series:

Article 02 — UVM anti-patterns I see in almost every new project