Introduction & Overview of Verilog HDL

Chapter 1 · Page 1.1 · Foundations

1. The Engineering Problem

Open the back of any smartphone, server, or electric car and you will find a piece of silicon a few millimetres on a side carrying somewhere between five and one hundred billion transistors. That silicon was not assembled by hand. Drawing the schematic of a billion-transistor system on paper — or in a CAD tool, gate-by-gate — would take a thousand engineers ten thousand years. The economics of the chip industry require that one team of fifty engineers ship that design in eighteen months.

So engineers do not draw gates. They write a text file that describes the gates the chip should contain, and a software tool — the synthesiser — reads that text file and produces the gate-level netlist that the foundry will manufacture.

That text file is written in Verilog HDL.

The problem Verilog exists to solve is the gap between what an engineer can describe in a day (a few hundred lines of carefully reasoned text) and what a chip can implement in a square millimetre (millions of gates). The language is the lever that closes that gap.

2. Why Verilog Exists

Before HDLs, digital designs were schematics — gate-level netlists drawn by hand in CAD tools. A one-thousand-gate chip was a serious effort; ten-thousand gates was a multi-person multi-month project. By the late 1980s Moore's law was doubling transistor density every two years and "draw a hundred thousand gates by hand" had become impossible at industry speed.

Verilog — Phil Moorby and Prabhu Goel at Gateway Design Automation, 1984 — solved this with two language moves that the working RTL of 2026 still depends on every day:

1. Textual representation. A counter in Verilog is a ten-line module. The same counter as a schematic is dozens of placed-and-wired gates. Text is faster to write, faster to review, easier to version-control, and trivially diff-able. Every modern code-review and CI flow assumes the design is text.
2. Behavioural description. You do not tell the tool which gates to instantiate; you describe what the circuit should do and the synthesiser emits the gates. Engineer productivity jumps by an order of magnitude — a designer who could ship 200 gates a day on a schematic ships 2 000 gate-equivalents a day in Verilog.

That trade-off — surrender direct control of the netlist in exchange for design scale — is what makes a billion-transistor SoC commercially viable. Modern smartphone application processors ship 10–50 billion transistors. None of that is feasible without an HDL.

Verilog is standardised as IEEE 1364. The 2005 revision is the canonical working reference. SystemVerilog (IEEE 1800) is the superset every modern design house uses for verification; the synthesisable RTL itself almost always still ships in plain Verilog because synthesis tools, IP libraries, and silicon-vendor sign-off flows expect it.

3. Where Verilog Fits in the VLSI Flow

Verilog source is the input to the front-end flow and the canonical artefact every downstream stage derives from. From a one-page architectural specification to a manufactured silicon die, the path runs through eight major stages:

For this opener, three things matter:

1. Verilog source is the single source of truth. Every downstream artefact — simulation traces, gate netlist, place-and-route layout, GDSII tape-out — is derived from the same .v files.
2. The synthesisable subset is smaller than the language. Simulators understand 100% of Verilog — including initial blocks, #10 delays, $display, $finish. Synthesisers understand only the subset that maps to gates. Mixing the two carelessly in your RTL produces a design that simulates correctly but won't synthesise.
3. Every stage has its own verification. RTL simulation checks functionality. Gate-level simulation checks the synthesised netlist. Sign-off timing checks the post-route layout. A bug at each downstream stage is roughly 10× more expensive to fix than the previous stage.

The full design flow has 16 sub-stages and 8–14 months of project calendar time — covered in detail in the next chapter, Typical VLSI Design Flow. For now, hold the eight-stage spine above as the map.

4. Verilog as an RTL Language

"RTL" stands for Register Transfer Level. The name is the mental model: a digital system is a set of registers (state-holding flip-flops) connected by combinational logic that computes what value each register should hold on the next clock edge. Every clock cycle the registers update, the combinational logic between them re-computes, and the design takes one step forward.

Verilog is an RTL language because the synthesisable subset of the language is exactly the subset that maps cleanly to "registers + combinational logic between them." Any Verilog construct that has a clear register-transfer interpretation — a reg updated on a clock edge, an assign driving a wire, a case statement inside an always_comb — is in the subset. Any construct that doesn't — an initial block, a #10 delay, a $display — lives in the simulation-only half of the language.

The three idioms that compose every clocked digital block in every working RTL file:

// 1. STATE — a clocked register
always @(posedge clk or negedge rst_n) begin
    if (!rst_n) state_q <= RESET_VAL;     // reset to a known value
    else        state_q <= state_d;        // commit next-state on every edge
end
 
// 2. COMBINATIONAL NEXT-STATE LOGIC
assign state_d = f(state_q, inputs);
 
// 3. OUTPUT LOGIC
assign result = g(state_q);                // Moore output (state-only)

This pattern shows up in every register, every counter, every FSM, every datapath, every interface controller. Once you can read those three idioms, you can read 95% of every Verilog file you will ever open.

5. Verilog vs Software Programming

If you arrive at Verilog from a C / Python / Java background, the first mental shift to make is this: every line of synthesisable Verilog must describe a piece of hardware that will exist on silicon.

There is no program counter inside Verilog hardware. There is no call stack. There is no "execute line 1, then line 2." Inside a module, every assign, every always block, every sub-module instance evaluates simultaneously on every relevant event. Carrying a sequential-programming intuition into RTL produces every bug you will write in your first month.

The shorthand: software runs over time; hardware exists in space. A C program with a for loop reuses the same ALU for each iteration. A Verilog for loop unrolls — every iteration becomes its own piece of silicon. The trade-offs you make in hardware (more gates for parallelism vs fewer gates with sequencing) are completely invisible in software.

6. Mental Model

The mental model has two practical consequences for every line you ever write:

• A working test for every line. What gates does this become, and which clock edge updates them? If you cannot answer both, the line is not ready — it is still pseudocode in Verilog syntax.
• A working test for every bug. Does the simulation result match what the blueprint says the gates would do? If the simulator disagrees with the blueprint, either the simulator is right (and your blueprint is wrong) or the blueprint is right (and you misread the simulator). One of the two has to give.

7. Visual Explanation

A Verilog module is the unit of hardware description. It has ports — pins on its boundary, declared as inputs or outputs — and internal logic that drives the outputs from the inputs (and, in clocked designs, from internal state). Everything you write in Verilog lives inside a module.

The three-stage mental model:

The picture is deliberately abstract — every module fits the shape regardless of whether the "internal logic" is one AND gate or one million gates. The interface is what one engineer hands to the next; the internals are the engineer's problem to get right.

Module boundaries are also the unit of hierarchy: a top-level chip is a module that instantiates sub-modules (memory controllers, CPU cores, peripheral blocks) that each instantiate further sub-modules (ALUs, register files, fetch units), and so on for ten to fifteen levels of depth on a real SoC. The same picture applies at every level.

8. Your First Verilog Module — a 2-input AND Gate

The smallest non-trivial Verilog module that does real work. Two input pins, one output pin, one combinational gate.

// Verilog-2001 ANSI-style port declaration.
`default_nettype none
 
module and_gate (
    input  wire a,
    input  wire b,
    output wire y
);
 
    // Continuous assignment — y is driven combinationally by the
    // AND of a and b. This is one AND gate on silicon.
    assign y = a & b;
 
endmodule

What this code says, in the blueprint model: one 2-input AND gate. Inputs a and b are pins on the boundary; output y is a pin driven by the gate's output. That is the entire hardware this module synthesises into — one AND2X1 standard-cell instance from the foundry library, occupying perhaps a square micron on the chip.

Three details to notice on day one:

• `default_nettype none at the top disables Verilog's implicit-net rule. Any undeclared identifier raises a compile error instead of being silently created as a one-bit wire. Every working RTL house puts this at the top of every file.
• wire is the keyword for ports that the module either receives from outside (inputs) or drives to outside (outputs via continuous-assignment). It models physical interconnect — a piece of metal on the chip.
• assign is the continuous-assignment statement — it says "this output is always equal to this expression," which is exactly how combinational logic on silicon behaves.

9. Simulation View — How the Simulator Sees This Module

To verify the AND gate works, we drive its inputs with a testbench — simulation-only Verilog that wraps the DUT (Device Under Test), drives stimulus, and observes outputs.

`timescale 1ns/1ps
`default_nettype none
 
module and_gate_tb;
    reg  a, b;   // testbench drives — `reg` because we assign in initial block
    wire y;      // DUT drives — `wire` because something else drives it
 
    // Instantiate the DUT
    and_gate u_dut (.a(a), .b(b), .y(y));
 
    initial begin
        $display("Time  a  b  |  y");
        $display("--------------|---");
 
        // Walk through all four input combinations, 10 ns apart
        a = 0; b = 0;  #10  $display("%4t  %b  %b  |  %b", $time, a, b, y);
        a = 0; b = 1;  #10  $display("%4t  %b  %b  |  %b", $time, a, b, y);
        a = 1; b = 0;  #10  $display("%4t  %b  %b  |  %b", $time, a, b, y);
        a = 1; b = 1;  #10  $display("%4t  %b  %b  |  %b", $time, a, b, y);
 
        $finish;   // end the simulation
    end
endmodule

The simulator (VCS, Questa, Xcelium, Verilator, Icarus, …) reads both files, schedules events on the simulation timeline, and produces the expected output:

Time  a  b  |  y
--------------|---
  10  0  0  |  0
  20  0  1  |  0
  30  1  0  |  0
  40  1  1  |  1

This is the AND gate's truth table, observed in the simulator. Output y is 1 only when both inputs are 1. Matches the logical definition: ✅.

How the simulator gets there: at every time step where any signal changes, it re-evaluates every assign that reads the changed signal. The assign y = a & b; re-evaluates whenever a or b changes. The new y value propagates to anything that reads y (here, the $display statement on the next line after the #10 delay).

The two pieces of vocabulary worth carrying:

• reg for signals the testbench drives with = (or <=) inside an initial or always block.
• wire for signals the DUT drives and the testbench observes.

The naming is a historical accident — reg does not mean "register in hardware"; it means "procedurally assignable variable." A reg inside always @(posedge clk) synthesises to a flop. A reg inside always @(*) synthesises to combinational logic. Same keyword, completely different gates, depending on the surrounding context.

10. Waveform Analysis

A simulator's most useful output is the waveform — every signal's value at every time point, viewable in a tool like GTKWave, Verdi, Visualizer, or Vivado Waveform. Reading waveforms is the single most useful skill in RTL debug.

For the AND gate above, the four stimulus combinations and the resulting output read across time:

Three things to read off this waveform — they are the first three things you will read off every waveform for the rest of your career:

1. Cause and effect. When a or b changes, y re-evaluates at the same time step. There is no clock here, so the effect is immediate.
2. Pattern matching. The marker labels (0 & 0 = 0, 1 & 1 = 1) match the AND truth table. A waveform is a visual verification — you compare it against what you expected, point by point.
3. The simulator's event model. The simulator only re-evaluates assign y = a & b; when a or b changes (an event on its right-hand side). Between events, every signal holds its previous value. That event-driven model is the foundation every Verilog simulator is built on.

For sequential designs (always @(posedge clk) blocks), the waveform tells the same kind of story, but with the rising clock edge as the event that updates the registers. Reading sequential waveforms — knowing which signals are sampled at the edge versus driven combinationally between edges — is the bedrock skill of every Verilog debug session.

11. Synthesis View — From Verilog to Silicon

The other tool that reads Verilog is the synthesiser. Where the simulator runs the code to model behaviour, the synthesiser translates the code into a structural description of the gates that implement that behaviour. The translation chain from text to silicon:

The single most important conceptual axis in Verilog is the simulation-vs-synthesis split. Two different tools, two different audiences, two different subsets of the language:

For the AND gate above, the synthesiser produces approximately:

module and_gate (a, b, y);
    input  a, b;
    output y;
    AND2X1 g1 ( .A(a), .B(b), .Y(y) );  // one AND2 cell from the foundry library
endmodule

That's the entire post-synthesis netlist for this module: one library cell with three pins wired up to the module's ports. The same Verilog source (§8) becomes a TSMC AND2X1 on an ASIC flow or a Xilinx LUT2 configured as AND on an FPGA flow — same intent, different cell library, different gates.

12. Industry Usage — Who Writes Verilog and What For

Verilog is the daily working tool of five distinct engineering roles in any silicon house. Each reads and writes Verilog with a different lens.

On a typical ASIC project of fifty engineers, roughly twenty are RTL designers, twenty are verification engineers, five are synthesis/timing engineers, and the remaining five split between SoC integration, DFT, and physical-design hand-off. Every one of them reads Verilog every day; how much they write depends on the role, but reading is universal.

12.1 ASIC vs FPGA — same Verilog, different targets

The same Verilog source can target two very different silicon endpoints. The differences shape what tools you use, what you can build, and what trade-offs you accept.

The same always @(posedge clk) q <= d; becomes a TSMC DFFRX1 on the ASIC flow and a Xilinx UltraScale CLB flip-flop on the FPGA flow. Intent identical; implementation different.

12.2 Industry tools and simulators

The Verilog tool market is small. Five names cover ~95% of production silicon.

Tool choice depends on the company's existing licenses, the target flow (ASIC vs FPGA), and the methodology stack.

13. Debugging Mindset

When a Verilog design misbehaves — and it will — the debug workflow is consistent across every team in the industry:

1. Read the waveform first. Open the .vcd / .fsdb in GTKWave / Verdi / Visualizer / Vivado Waveform. Find the moment things go wrong. Time is the dimension; signals are the rows.
2. Isolate the DUT. When the testbench fails, ask: is the bug in the DUT or in the testbench? Force-drive the DUT's inputs directly and observe — bypass the testbench's logic entirely.
3. Write a smaller testbench. Reproduce the failure with the minimum stimulus. If the bug only shows up after a thousand random transactions, find the single transaction that triggers it.
4. Check reset and initial values. 90% of "weird behaviour at t = 0" bugs are missing or wrong reset values. Walk every reg in synthesisable RTL and confirm it has a defined reset.
5. Compare expected vs observed precisely. State what you expected, in words, before looking at the waveform. Then compare. Vague expectations produce vague debugging; precise expectations find precise bugs.
6. Understand the scheduler at a beginner level. Verilog's event scheduler runs in four regions per time step — Active (blocking assigns, assign), Inactive (#0), NBA (non-blocking assigns), Postponed ($monitor, $strobe). When two events disagree on which one "ran first," it is almost always a region-ordering issue.

13.1 Common beginner mistakes

Five mental-model failures every Verilog beginner makes at least once:

1. Reading Verilog like a C program. if (a > b) c = d; outside an always block does not run — there is no procedure to run it from. Verilog is event-driven, not procedural.
2. Confusing simulation-only with synthesisable. initial, #10, $display, $finish, $random are all simulation-only. Using them inside a synthesisable RTL module is the most common first-week mistake — your RTL passes simulation, the synthesiser silently drops the offending lines, and your silicon does something completely different.
3. Using reg to mean "register in hardware." reg is a Verilog language construct meaning "variable I can assign inside an always block." It does not mean "register in hardware." A reg driven by always @(posedge clk) becomes a flop; the same reg in always @(*) is combinational logic.
4. Ignoring X and Z states. Verilog has four states per bit: 0, 1, X (unknown), Z (high-impedance). An uninitialised reg starts at X; an unconnected output floats at Z. The expression (x == 4'bxxxx) is always false because the comparison itself X-propagates. Use === (case-equal) to test for unknown.
5. Not writing a testbench. A working RTL block in isolation is meaningless — what tells you it is working is the simulation log of a testbench exercising every input combination, edge case, and recovery scenario. RTL without a testbench is a draft, not a deliverable.

14. Design Review Notes

What a senior RTL reviewer flags on a beginner's first Verilog module — eight things that show up in every code-review pass:

1. `default_nettype none at the top of every file. Disables the implicit-net rule. Non-negotiable in any working RTL house.
2. Explicit port directions and types. input wire clk is clearer than input clk. Most lint suites require it.
3. ANSI-style port lists (declared in the module header, not in a separate input/output declaration list inside the body). Industry default since Verilog-2001.
4. Named port connections at instantiation — .a(a), .b(b), .y(y) — never positional (a, b, y). Named connections are robust to port-list changes; positional connections silently break.
5. Every reg in synthesisable RTL has a defined reset path. Either asynchronous (always @(posedge clk or negedge rst_n)) or synchronous (always @(posedge clk) with if (!rst_n) first). Never rely on the simulator's default X.
6. Testbench code lives in separate files with a _tb suffix on the module name. Never mix synthesisable RTL and initial / $display in the same module.
7. Module names match their primary function. and_gate, fifo, axi_master — not module1, block_v2, tmp. Naming is part of the code review.
8. A one-line header comment in every file naming what the module is, who owns it, and where the spec lives. The next engineer will thank you.

A senior reviewer reading the AND gate from §8 would mark it clean: default_nettype none, ANSI port list, explicit wire, single continuous assignment, clear name. The simplest module in the language follows the same review rules as a million-gate IP block.

15. Interview Insights

Foundational questions that come up early in every entry-level RTL or verification interview. Answers reason through the underlying mental model; do not memorise the words — make sure the reasoning lands.

16. Learning Roadmap

The Verilog track on VLSI Mentor is sequenced for a working engineer. The roadmap from here:

16.1 Foundation (Chapters 1–4)

Where you are now plus the lexical layer. Cover everything every line of Verilog uses before going deeper.

• Chapter 1 (this page) — Introduction & Overview.
• Chapter 2 — Typical VLSI Design Flow. The full 16-stage flow from spec to silicon.
• Chapter 3 — RTL Designing. The three RTL idioms applied to a real FSM.
• Chapter 4 — Lexical Conventions. Comments, identifiers, keywords, operators, numbers, strings, whitespace.

16.2 Data Types & Variables (Chapters 5–7)

Nets, variables, constants, and compiler directives. The vocabulary every declaration draws from.

• Chapter 5 — Variables & Data Types. The two families: nets and variables.
  • 5.1 Physical Data Types — the net family.
  • 5.1.1 wire and tri Nets — the workhorse pair.
  • (5.1.2–5.1.6 cover signal strengths, wired-AND/OR, trireg, tri0/tri1, supply0/supply1.)
  • (5.2 covers register-typed variables: reg, integer, real, scalar/vector/array.)

16.3 Operators, Procedural Blocks, FSMs (Chapters 8–11, planned)

The flow-control vocabulary — every if, case, always_comb, always_ff. State machines from scratch.

16.4 Advanced Topics — the Masterpiece-Worthy Five

Four canonical Verilog Masterpiece-grade topics (per VLSI_MENTOR_MASTERPIECE_STANDARD.md §7) live in later chapters; together they cover the bedrock of real RTL design:

• Blocking vs Non-Blocking Assignments — = vs <= and why the wrong choice causes races.
• FSM Design — encoding, reset, latch-free style, Mealy vs Moore.
• Clock Domain Crossing (CDC) — sync, handshake, async FIFO.
• Async FIFO — the canonical CDC structure; gray pointers, full/empty under different clocks, metastability.

Reach those chapters and you will have the L3 Senior RTL Engineer foundation. The path is not short — expect 50–80 focused hours from Chapter 1 to L3 readiness — but every chapter compounds.

17. Exercises

Three exercises to convert the page's mental model into reflex.

Exercise 1 — Recognise the difference

Below are three pieces of Verilog. For each, identify whether it is (a) synthesisable RTL, (b) testbench-only simulation code, or (c) a mix that will fail synthesis. Explain why.

module mux2 (
    input  wire        sel,
    input  wire [7:0]  a, b,
    output wire [7:0]  y
);
    assign y = sel ? a : b;
endmodule

module counter (
    input  wire        clk,
    input  wire        rst_n,
    output reg  [7:0]  count_q
);
    initial count_q = 8'h00;            // (!)
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) count_q <= 8'h00;
        else        count_q <= count_q + 8'h01;
    end
endmodule

module tb_counter;
    reg  clk = 0, rst_n = 0;
    wire [7:0] q;
    counter u_dut (.clk(clk), .rst_n(rst_n), .count_q(q));
    always #5 clk = ~clk;
    initial begin
        #20  rst_n = 1;
        #100 $finish;
    end
endmodule

What to produce. A one-line classification for each plus a one-sentence justification.

Exercise 2 — Build it

Write the smallest possible 2-to-1 multiplexer module called mux2_1 with:

• Inputs: sel (1 bit), a and b (8 bits each).
• Output: y (8 bits).
• Behaviour: when sel = 0, y = a; when sel = 1, y = b.

Use `default_nettype none, ANSI-style ports, and a single continuous assignment. Then write a 5-line testbench that exercises all four interesting cases (sel=0 with two different a values; sel=1 with two different b values).

Hints. The ternary operator (?:) is the canonical one-line mux. The testbench wraps the DUT in a separate module and drives sel, a, b via an initial block.

Exercise 3 — Predict the waveform

Given the following sequential module and stimulus, sketch (on paper or as a <Waveform>-shaped table) the value of q across 8 clock cycles.

module dff (
    input  wire clk,
    input  wire rst_n,
    input  wire d,
    output reg  q
);
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) q <= 1'b0;
        else        q <= d;
    end
endmodule

Stimulus:

Hint. q samples d on each rising clock edge — meaning the new value of q appears on the cycle after d changes. Reset is asynchronous (negedge), so it forces q = 0 immediately when rst_n is low. List q at each cycle and check against what the flip-flop would do on silicon.

18. Summary

Verilog is a hardware description language: text in, hardware out. It is not a programming language — every line of synthesisable Verilog corresponds to gates, flip-flops, and wires that will exist on silicon. The lines that are not synthesisable (initial, #delays, $display, $finish) belong only to the testbench.

The mental model carried through every later chapter:

• Verilog is a blueprint for a physical artefact. Every module is a box with input pins, output pins, and behaviour inside; the synthesiser is the construction crew that builds the box.
• Every line answers two questions. What gates does this become, and which clock edge updates them? If you cannot answer both, the line is not ready.
• Simulation and synthesis are two different tools. Simulation reads 100% of the language; synthesis reads the synthesisable subset only. Mixing the two in a single module is the most common first-week mistake.
• The same Verilog targets ASIC or FPGA. The intent is portable; the implementation differs by tool and cell library.
• Waveforms are the universal debugging surface. Reading them well is the single highest-leverage skill in RTL work.

Internalise the blueprint metaphor, hold the simulation-vs-synthesis cut-line in your head, write `default_nettype none at the top of every file, and you have the foundation every later chapter assumes. Chapter 2 zooms out to the full 16-stage VLSI flow — where the text you just learned to read actually lands.

Related Tutorials

• Typical VLSI Design Flow — Chapter 2; the full path from spec to silicon.
• RTL Designing — Chapter 3; the three RTL idioms applied to a real FSM.
• Variables & Data Types — Chapter 5; the type system every signal declaration draws from.
• Physical Data Types — Chapter 5.1; the deep drill into the net family.
• wire and tri Nets — Chapter 5.1.1; the two workhorse keywords.