Why I Still Write RTL by Hand

The HLS Promise

High-Level Synthesis tools have come a long way. Write your algorithm in C++, press a button, and get synthesizable Verilog. It sounds like the end of manual RTL design.

And for many use cases, it is. If you're prototyping a DSP pipeline or building a one-off accelerator, HLS is fantastic. It lets you iterate on algorithms without worrying about clock domains and pipeline stages.

Where It Falls Short

But HLS has limits. The generated RTL is often:

• Harder to debug — the mapping from C++ to hardware is opaque. When timing fails, good luck tracing it back to a source line.
• Less area-efficient — HLS tools are conservative. They insert extra registers, use wider datapaths, and struggle with resource sharing across complex control flows.
• Inflexible at the boundary — integrating HLS blocks with hand-written AXI interfaces, custom protocols, or legacy IP requires manual glue logic anyway.

The Sweet Spot

My rule of thumb:

1. Use HLS for datapath-heavy, algorithm-focused blocks where iteration speed matters more than area.
2. Write RTL for control logic, protocol interfaces, and anything on the critical timing path.
3. Always write RTL for the top-level interconnect and memory subsystem.

The best hardware engineers I know are fluent in both. They reach for HLS when it's the right tool and drop to RTL when precision matters.

The Real Skill

The value of knowing RTL isn't just about writing it. It's about reading it — understanding what the synthesis tool actually produced, catching timing violations before they become silicon bugs, and having the mental model to reason about hardware behavior at the cycle level.

That mental model doesn't come from C++. It comes from years of thinking in flip-flops and state machines.

So yes, I still write RTL by hand. Not because I'm nostalgic, but because some problems demand it.