About

I get paid to doubt things.

That is the honest job description of a verification engineer.
Someone designs a chip and believes it works.
My job is to ask, politely at first, how it could fail.

I’m Hardik. I started The Art of Verification in 2021 as a notebook in public: the explanations I wished someone had given me when a test failed and the waveform made no sense.

Timing diagram with clk, req, gnt and data signals. A one-cycle pulse on gnt, after the request has ended, is circled in gold with the note: why here?
Every test above passed. The interesting part is the pulse nobody asked for.

Why call it an art

Simulators run tests. Tools count coverage.
None of them tell you which question to ask.

That part is human. It is the habit of looking at a clean result and thinking: too clean.
Every article here tries to teach that habit, not only the syntax.

The quiet kid who learned to ask

I grew up introverted. The kid who knew the answer and still didn’t raise his hand.

At 17 I got tired of that version of me, and I started treating myself like a design under test.
What do I believe about myself that nobody has ever checked?

Most of my limits turned out to be untested assumptions.
Years later, verification gave that idea a name.

What volleyball taught me about bugs

For years I played competitive volleyball.

A good dig doesn’t happen when the ball arrives.
It happens earlier, when you read the hitter’s shoulder and start moving before the spike.

A dotted ball trajectory falling toward a volleyball. On the timeline below, the gold point marked read comes well before the points marked move and contact.
Read, move, contact. The first step decides the other two.

Good verification works the same way.
You read the design, guess where it will break, and you are already standing there when it does.

Injuries ended that chapter. The instinct stayed.
At 36 I’m rebuilding my body the way I debug: one measured change at a time, and I believe the numbers over the mood.

What you’ll find here

  • Learning paths that go in order: SystemVerilog, UVM, Assertions, Functional coverage and Verification fundamentals.
  • Practical guides built around code you can run and change.
  • Interview prep that explains the reasoning, not only the answer.
  • Advanced topics for working engineers: SoC, formal, AXI, Portable Stimulus and debugging.
  • AI in verification, written with both eyes open.

Where I stand on AI

AI can write a testbench skeleton in seconds.
It cannot tell you that the spec is ambiguous.

Use it to go faster. Keep the checking deterministic, and keep the judgment yours.

Every chip that works is a few thousand questions someone was stubborn enough to ask.
This site is where I keep mine. Take whatever helps you ask better ones.

Start a learning path · Get new guides by email · Say hello