English for Verilog and VHDL Developers

Hardware description languages look like software languages but describe physical circuits, and that gap is exactly where miscommunication happens most: a line of Verilog doesn’t execute — it describes hardware that exists all at once, and the vocabulary needs to reflect that difference precisely.

Key Vocabulary

RTL (register-transfer level) — the abstraction level at which most Verilog and VHDL design happens, describing how data moves between registers on each clock cycle and what combinational logic sits between them, rather than a literal gate-level or transistor-level description. “We’re reviewing this at the RTL level, so focus on whether the data actually reaches the right register on the right clock edge — gate-level timing details are the synthesis tool’s problem at this stage, not ours.”

Synthesis — the automated process of converting RTL code into an actual gate-level netlist targeting a specific technology (an FPGA or ASIC library), during which code that behaves identically in simulation can synthesize into very different, or even non-functional, hardware. “This simulates correctly, but it won’t synthesize the way you’d expect — that construct isn’t synthesizable on this target, so the synthesis tool will either reject it outright or infer hardware very different from what you simulated.”

Blocking vs. non-blocking assignment — Verilog’s two assignment operators (= for blocking, <= for non-blocking), where blocking assignments execute and complete sequentially within a block while non-blocking assignments all schedule to update simultaneously at the end of the current time step, a distinction that changes actual synthesized behavior, not just style. “Swap that blocking assignment for a non-blocking one inside the clocked always block — with blocking assignment here, this register update depends on evaluation order in a way that doesn’t match the flip-flop behavior you’re actually trying to model.”

Timing closure — the point at which a synthesized and placed-and-routed design meets all its timing constraints (setup and hold times) across every path, at every corner, achieved through iterative optimization rather than guaranteed by simply writing correct RTL. “Functionally correct RTL doesn’t mean we’re done — we still haven’t hit timing closure on the critical path between the multiplier output and the accumulator register, so we need to either pipeline that path or relax the clock frequency.”

Testbench — a non-synthesizable simulation environment written to drive stimulus into a design under test and check its outputs, distinct from the RTL design itself, since a testbench can use constructs (like delays or file I/O) that could never become real hardware. “Don’t worry that this uses a #10 delay and file reads — none of that needs to be synthesizable, since it’s testbench code exercising the design under test, not part of the design itself.”

Common Phrases

• “Are we reviewing this at the RTL level, or does the gate-level detail actually matter here?”
• “Does this construct actually synthesize, or does it only work in simulation?”
• “Is that a blocking or non-blocking assignment, and does it match the behavior we’re trying to model?”
• “Have we hit timing closure on this path, or is it still failing at the target clock frequency?”
• “Is that testbench code, or does it need to be synthesizable?”

Example Sentences

Explaining a synthesis mismatch: “The simulation passed because the simulator evaluates this loop the way you’d expect from software, but it’s not synthesizable as written — the synthesis tool can’t infer bounded hardware from an unbounded loop condition like this.”

Flagging an assignment bug in review: “This clocked block mixes blocking and non-blocking assignments to the same signal, which is a classic source of simulation-versus-synthesis mismatch — standardize on non-blocking assignments throughout this always block.”

Reporting timing status: “RTL is functionally verified and matches the spec, but we’re not done — the path from the DMA controller to the output FIFO is still 400 picoseconds short of timing closure at the target frequency, so it needs another pipeline stage.”

Professional Tips

• Communicate explicitly which abstraction you’re discussing — RTL behavior, gate-level netlist, or physical layout — since a bug reported at the wrong level sends the wrong engineer chasing the wrong problem.
• Never assume simulation correctness implies synthesis correctness — always confirm a construct is synthesizable on the actual target before relying on simulated behavior, especially for anything unusual like loops with variable bounds.
• Standardize on non-blocking assignment for all clocked sequential logic and blocking assignment for combinational logic — mixing the two within the same always block is one of the most common sources of subtle simulation-versus-hardware mismatches.
• Report timing closure status as its own explicit milestone, separate from functional verification — a design can be functionally perfect in simulation and still fail in real hardware if it doesn’t meet timing at the target clock frequency.
• Keep testbench code and design code clearly separated in both files and conversation — testbench constructs that aren’t synthesizable are completely normal and expected, but only inside the testbench, never inside the design under test.

Practice Exercise

1. Explain the difference between RTL and gate-level abstraction in hardware design.
2. Describe why blocking and non-blocking assignments can produce different synthesized behavior even when simulation results look identical.
3. Write a sentence explaining why timing closure is reported separately from functional correctness.