I’m Sorry Dave, You Shouldn’t Write Verilog

There are titles that whisper, and there are titles that stride into the room wearing steel-toe boots. I’m Sorry Dave, You Shouldn’t Write Verilog belongs to the second category. It sounds rude. It sounds dramatic. It sounds like something a grumpy senior engineer mutters after a junior designer accidentally infers a latch, breaks timing, and then says, “But the simulation looked fine.”

And yet, under the theatrics, there is a serious point: for modern FPGA design, ASIC prototyping, and scalable RTL development, hand-writing large amounts of raw Verilog is often the wrong starting point. Not always. Not universally. Not for every block. But often enough that the old habit deserves a very public side-eye.

This is not an argument that Verilog is worthless. That would be silly. Verilog still matters because the tooling ecosystem still speaks it fluently, generated RTL still lands there, and many real projects still depend on it. The better argument is this: Verilog is too low-level, too permissive, and too easy to misuse to remain your primary creative medium for complex hardware work. In other words, Verilog is still the lingua franca of digital design, but it should not always be the language you think in first.

Why the Title Hits a Nerve

The phrase “you shouldn’t write Verilog” lands because every hardware engineer has a scar story. Maybe it was a reset strategy that looked elegant until synthesis mapped it into expensive glue logic. Maybe it was a state machine that worked in simulation but quietly became something far less charming in hardware. Maybe it was a clock-domain crossing handled with the confidence of a person who had not yet met metastability. Hardware has a way of turning optimism into lab time.

Verilog also carries historical baggage. It was born in an era when describing and simulating hardware behavior came first, and synthesis became the practical follow-up act. That history matters because it explains why writing “legal Verilog” and writing “good hardware” are not the same thing. A language that lets you describe behavior is not automatically a language that protects you from bad implementations, ambiguous intent, or painful maintenance.

That gap is precisely why experienced teams lean on stricter coding styles, linting, templates, assertions, formal checks, and higher-level hardware construction tools. Nobody adds all that scaffolding for fun. They add it because raw RTL, left unsupervised, has the temperament of a raccoon in a server room.

What Makes Raw Verilog So Easy to Regret?

1. It lets you say too many dangerous things too easily

One of Verilog’s biggest strengths is expressive flexibility. One of Verilog’s biggest weaknesses is expressive flexibility. Yes, that is the same sentence wearing two different hats.

In practice, raw Verilog makes it easy to create code that is syntactically valid, simulation-friendly, and architecturally unwise. You can mix concerns. You can bury control logic in datapaths. You can write reset behavior that blocks efficient use of memory or DSP resources. You can forget defaults in combinational blocks and accidentally request latches like you are ordering them off a lunch menu.

That is not just a beginner problem. It is a scale problem. The bigger the design, the more chances there are for small ambiguities to become expensive misunderstandings. A permissive HDL is manageable when the block is tiny. It becomes hazardous when the codebase is large, collaborative, and under schedule pressure.

2. Simulation success can flatter bad design choices

Verilog’s roots in simulation are still visible in the way many engineers learn and use it. The trap is obvious in hindsight: if the waveform looks right, people assume the hardware is right. Unfortunately, synthesis tools do not care about your emotional bond with the waveform.

They care about resource inference, timing closure, mapping, routing, placement, and whether your lovingly crafted description matches the structures the target device actually wants. That mismatch is where many “but it worked in ModelSim” tragedies begin. A design can be behaviorally plausible and physically awkward at the same time. Hardware is rude that way.

3. Reset logic is where many noble intentions go to die

If you want to watch a room of digital designers become philosophical, ask when a reset is truly necessary. Then step back.

The blunt truth is that many designers over-reset. They reset everything because it feels safe, symmetrical, and emotionally complete. But broad reset usage can hurt clock frequency, increase routing burden, inflate control complexity, and prevent the tool from mapping logic into the most efficient resources. In many datapaths, a reset is not a badge of seriousness; it is extra baggage.

Asynchronous resets make the story even spicier. Used carelessly, they can complicate placement, interfere with resource mapping, and create unpleasant side effects around memories and specialized blocks. A lot of Verilog code looks neat precisely because it hides the implementation cost. That is the sort of neatness that ages poorly.

4. Clock-domain crossing is not impressed by confidence

CDC bugs are among the nastiest because they do not fail politely. They can lurk. They can flicker. They can arrive only after you have announced to everyone that bring-up is “basically done.”

Raw Verilog does not stop you from doing reckless things with asynchronous signals. It will not grab your wrist and say, “Friend, perhaps put that signal through a synchronizer.” Tools can help, attributes can help, and discipline can help, but the base language itself is not exactly your overprotective parent.

This is one reason mature teams do not just “write Verilog.” They write Verilog inside a methodology: lint, CDC analysis, timing constraints, review standards, and repeatable patterns. The language alone is not enough.

5. Hand-written RTL does not scale elegantly

Suppose you need one tiny controller. Fine. Verilog is reasonable. Suppose you need twelve related controllers, five bus adapters, four parameterized datapaths, reusable interfaces, configurable widths, test collateral, and a future-proof way to spin variants next quarter. Suddenly, hand-authoring every signal and module feels less like engineering and more like artisanal suffering.

This is where higher-level hardware construction approaches earn their keep. Tools like Chisel and IR flows like FIRRTL exist because modern chip work often benefits from generators, parameterization, stronger abstraction, reusable structure, and programmatic composition. You still get Verilog out the back end for downstream tools, but you stop pretending that raw RTL is the most elegant place to build everything.

So What Should You Do Instead?

Start with SystemVerilog, not vintage Verilog habits

If you must work close to the metal, at least give yourself better boots. SystemVerilog offers clearer constructs, stronger intent signaling, better organization, and a more modern baseline for design and verification. It is not magical. You can still make a mess. But it narrows the gap between what you mean and what the next engineer can understand.

That matters more than people admit. Good hardware development is not just about making the code compile. It is about making the code legible six months later, during a bug hunt, when past-you is behaving like a stranger with suspicious taste.

Use generators for repeated structure

If a design pattern repeats, parameterize it. If a subsystem varies by configuration, generate it. If interfaces are predictable, encode that predictability in types or construction patterns. This is where Chisel, generator frameworks, and similar approaches shine. They let you express families of designs instead of hand-copying cousins who all share the same nose and timing problems.

The irony is delicious: many teams still depend on Verilog at the tool boundary while increasingly avoiding writing too much raw Verilog by hand upstream. That is not hypocrisy. That is progress.

Lean hard on tools that tell you when you are being clever in a dangerous way

Linting is not optional decoration. It is the early-warning system for a language ecosystem that still leaves too much room for foot-guns. Add CDC checks. Add assertions. Add formal where it fits. Use vendor templates where inference matters. Constrain the design properly. Review reset strategy intentionally. Make naming consistent. Comment the intent, not the obvious mechanics.

If all of that sounds less romantic than freehand RTL wizardry, good. Romance is overrated in hardware design. Repeatability is better.

Use AI as an assistant, not a substitute for engineering judgment

The modern twist is that “don’t write Verilog” now has an AI-shaped subplot. Research projects such as DAVE and later domain-specific models for Verilog generation show that natural-language-to-RTL assistance is not science fiction anymore. Boilerplate, starter modules, simple translations, and partial completions are increasingly fair game.

But this does not mean you should hand your chip to a chatbot, salute, and head to lunch. Generated RTL still has to survive simulation, linting, synthesis, CDC analysis, timing closure, and human review. In other words, AI can save keystrokes, but it cannot repeal physics, tool semantics, or bad architecture.

When Verilog Still Absolutely Makes Sense

Let us be fair. There are times when writing Verilog is still the correct move:

• Small glue modules with straightforward behavior
• Leaf blocks where direct control of RTL matters
• Tool compatibility cases where generated output must stay simple
• Debugging, inspection, or patching generated RTL
• Educational settings where learning hardware structure matters more than abstraction

So no, this is not a call to delete Verilog from civilization. It is a call to stop treating it as the universal starting point for every serious design task. A screwdriver is useful. That does not make it a good replacement for a machine shop.

A Better Workflow for Real Teams

If you want a practical takeaway, here it is: use the highest abstraction level that still gives you confidence, reviewability, and predictable hardware results.

For many teams, that means:

• writing specifications in plain English and diagrams first,
• using SystemVerilog or a generator language for implementation,
• treating resets as a design decision instead of a reflex,
• using vendor-recommended coding styles when inference matters,
• running lint and CDC checks early, not at the panic stage,
• keeping interfaces and naming conventions painfully clear,
• and letting raw Verilog be the output format or the surgical tool, not the entire religion.

That workflow is not flashy, but it is how adults keep projects from turning into archaeology.

The Long, Slightly Personal, Very Familiar Experience of Verilog Pain

Anyone who has spent time around FPGA labs, ASIC teams, university projects, or late-night prototype bring-up knows the emotional arc of a Verilog-heavy project. It starts with confidence. A designer opens a file, writes a few modules, names a couple of signals, and feels terrific. Look at that! Hardware is becoming text! What power! What elegance! What could possibly go wrong besides everything with a clock?

Then the project grows. The first module becomes five. Five becomes twenty. Somebody copies a block because “we’ll clean it up later.” Nobody cleans it up later. A reset gets added everywhere because a bug once happened during startup and now the entire company has reset-related trust issues. One engineer likes terse code. Another likes verbose code. A third uses naming conventions apparently transmitted through a dream. A fourth says comments are for cowards, which is exactly the kind of sentence that should be written on a warning label.

At first, the problems seem small. A warning here. A mysterious timing path there. An inferred latch that feels more accidental than malicious. Then one day the design works in simulation, fails on hardware, and everyone begins the ancient ritual of staring at waveforms as if they contain moral lessons. Someone mutters “metastability” in the tone of a person naming an old enemy. Someone else says the tool “did something weird,” which is often what humans say when the tool followed instructions more literally than expected.

This is the moment the anti-Verilog argument starts making emotional sense. Not because Verilog is evil, but because it offers too little resistance to bad habits. It lets smart people dig elegant holes. It lets teams scale complexity faster than they scale discipline. It rewards cleverness early and invoices maintainability later.

The best teams eventually learn a humbler rhythm. They stop admiring hand-written RTL just because it is hand-written. They value boring patterns. They document intent. They ask whether a reset is necessary before pasting it into every always block. They let generators handle repetition. They use lint like a smoke detector instead of a post-fire report. They accept that good hardware design is not a contest to see who can type the most Verilog from memory.

And that may be the real meaning of the title. “You shouldn’t write Verilog” is not really a ban. It is a warning against ego, nostalgia, and misplaced craftsmanship. Write hardware, yes. Build excellent RTL, absolutely. But when the project gets bigger, the stakes get higher, and the abstractions get richer, do not romanticize the text format. The goal is not to prove that you can write Verilog. The goal is to ship hardware that works.

Conclusion

So, should you write Verilog? Sometimes. Should you default to raw Verilog for serious modern hardware work? Much less often than tradition suggests.

The stronger position is not anti-Verilog. It is anti-unnecessary suffering. Use Verilog where it is sharp. Avoid it where it is brittle. Prefer design flows that communicate intent, scale with complexity, and cooperate with the realities of synthesis, verification, and maintenance. Let generators generate. Let tools analyze. Let humans focus on architecture and correctness.

Because in 2026, the real flex is not typing more Verilog than everyone else. The real flex is building better hardware with fewer surprises, fewer all-nighters, and fewer moments where the lab equipment appears to be laughing at you.