1. Home
2. Academy
3. Verilog & SystemVerilog
4. Volume 01

1.1 Hardware concurrency vs Von Neumann sequential thinking

In C, a program is a list of instructions that a processor executes one after another. Time is created by the sequence. In hardware there is no processor reading your Verilog - the Verilog becomes the circuit. Every module, every assign, every always block exists simultaneously and permanently, all of them computing at once, continuously, forever.

Software is temporal: one unit of hardware (the ALU) reused across many moments in time. Hardware is spatial: many units of silicon area, all live at the same moment. That single inversion is the whole discipline.

What a gate physically is

The smallest useful unit is the CMOS inverter: one PMOS transistor pulling the output up to V_DD and one NMOS pulling it down to ground. They are complementary - exactly one conducts at a time, which is why static CMOS burns almost no power when idle.

That propagation delay, t_pd, is not a constant of the gate - it is set by the load. Every downstream gate input adds capacitance, and every millimetre of wire adds more. This is why fanout matters, why buffers get inserted during synthesis, and why the longest chain of gates between two flip-flops determines your maximum clock frequency. We make that quantitative in Volume 07.

Concurrency in code

Consider three continuous assignments. In software order would matter; here it cannot, because all three are wires that exist at the same time.

module concurrency (
  input  wire a, b, c,
  output wire x, y, z
);

  // These three lines describe three separate pieces of silicon.
  // Reordering them changes NOTHING. There is no "first" statement.
  assign z = y & c;      // depends on y
  assign y = x | b;      // depends on x
  assign x = a ^ b;      // depends on inputs only

  // Written in this order deliberately: a software reader expects z to be
  // computed from a stale y. Hardware has no such concept - when a, b or c
  // changes, all three gates re-settle together after their own t_pd.

endmodule

Now the mirror image. A for loop inside synthesizable Verilog is not a loop in the software sense at all - it is a textual replication directive resolved entirely at elaboration time.

module popcount8 (
  input  wire [7:0] data,
  output reg  [3:0] ones
);

  integer i;

  always @(*) begin
    ones = 4'd0;
    // The synthesis tool UNROLLS this completely. It does not build a
    // counter, a sequencer, or a state machine. It builds eight adders
    // wired in a chain - all of which settle within ONE clock cycle.
    for (i = 0; i < 8; i = i + 1) begin
      ones = ones + data[i];
    end
  end

endmodule

1.2 The IEEE 1364 stratified event queue

Simulation has to impose an order on things that physically happen at once. The IEEE 1364 standard does this by splitting each simulation time step into ordered regions. Understanding these regions is what separates engineers who can debug a race condition from engineers who add random delays until the waveform looks right.

Within a single time step, the simulator drains regions in order. Crucially, executing events in a later region can schedule new events back into an earlier region - so the whole loop repeats until the time step is genuinely quiet.

Why $display lies and $strobe does not

$display executes in the Active region - potentially before the NBA updates have been applied. So printing a flip-flop output with $display inside a clocked block shows you the value from before the edge.

always @(posedge clk) begin
  q <= d;                       // scheduled into the NBA region

  $display("display: q = %b", q);  // Active region -> prints the OLD q
  $strobe ("strobe:  q = %b", q);  // Postponed region -> prints the NEW q
end

This is not a simulator quirk to work around. It is the queue behaving exactly as specified, and it is Cummings' Golden Rule 7: use $strobe to display values assigned non-blockingly.

The #0 anti-pattern

The Inactive region exists to service #0 delays. Engineers reach for #0 to "push this to the end of the time step" and make a race go away. It does make that particular race go away - and creates a new one, because if two processes both use #0, their relative order is once again undefined.

always @(posedge clk) a <= b;
always @(posedge clk) b <= a;

always @(posedge clk) a = b;
always @(posedge clk) b = a;

1.3 Data types, net types & strength modeling

Verilog models a wire with four states, not two. The extra two exist because real wires can genuinely be in conditions that 0 and 1 cannot express.

wire vs reg - the worst-named keyword in the language

reg does not mean register. It means "a variable that holds its value between assignments in procedural code". A reg assigned inside always @(*) synthesizes to pure combinational logic with no storage whatsoever. Whether you get a flip-flop depends entirely on the sensitivity list, never on the keyword.

Drive strengths and tri-state buses

When two drivers fight over one net, Verilog resolves the winner by strength. In descending order: supply > strong > pull > weak > highz. Equal strengths in opposite directions produce X - which is the simulator telling you that you have built a short circuit between V_DD and ground.

The legitimate use of Z is a shared bus, where several devices take turns driving one set of wires and everyone not driving must release cleanly.

module tristate_driver #(
  parameter WIDTH = 8
) (
  input  wire             oe,       // output enable, active high
  input  wire [WIDTH-1:0] data_out, // value this device wants to drive
  output wire [WIDTH-1:0] data_in,  // value currently on the bus
  inout  wire [WIDTH-1:0] bus       // the shared physical wires
);

  // Drive the bus only when enabled; otherwise release it to high-Z so
  // another device can take over. Forgetting the Z branch means two
  // devices fight and BOTH read X.
  assign bus = oe ? data_out : {WIDTH{1'bz}};

  // Reading is unconditional - always sample what is on the wires.
  assign data_in = bus;

endmodule

1.4 Blocking (=) vs non-blocking (<=): the silicon reality

This is the single highest-yield topic in the volume, and the most reliable interview question in the entire field. The mechanics are simple; the consequences are not.

The three-stage pipeline: same intent, different silicon

Here is the classic demonstration. Both blocks are legal Verilog. Both compile. They synthesize to completely different circuits.

always @(posedge clk) begin
  q1 = d;    // q1 gets d NOW
  q2 = q1;   // sees the NEW q1
  q3 = q2;   // sees the NEW q2
end

// All three collapse: d flows
// straight through in one cycle.
// Synthesis: ONE flip-flop.

always @(posedge clk) begin
  q1 <= d;   // samples d
  q2 <= q1;  // samples OLD q1
  q3 <= q2;  // samples OLD q2
end

// Each stage takes one cycle.
// Synthesis: THREE flip-flops
// in series - a shift register.

The non-blocking version is what a shift register physically does: at the clock edge, every flop simultaneously captures whatever was sitting at its input just before the edge. No flop can see its neighbour's new value, because all of them change at the same instant.

Cummings' eight golden rules

Clifford Cummings' SNUG papers on this subject are the closest thing the industry has to settled law. Follow these eight rules and simulation-synthesis mismatches essentially stop happening.

module swap_test;
  reg clk = 0;
  reg a = 1'b1, b = 1'b0;

  always #5 clk = ~clk;

  always @(posedge clk) begin
    a <= b;
    b <= a;
  end

  initial begin
    $monitor("t=%0t  a=%b  b=%b", $time, a, b);
    #25 $finish;
  end
endmodule

1.5 Accidental latch inference & DFT nightmares

A combinational always block makes a promise: for every possible combination of inputs, every output gets a value. Break that promise on even one path and the synthesis tool has no choice - it must insert a transparent latch to remember the previous value.

The tool is not being clever or malicious. You wrote "when sel is 2, don't change y", and the only hardware that can not-change something is memory.

The three ways to infer a latch by accident

// TRAP 1 - if with no else
always @(*) begin
  if (enable)
    y = a;          // y unassigned when !enable
end

// TRAP 2 - case with no default
always @(*) begin
  case (sel)
    2'b00: y = a;
    2'b01: y = b;
    2'b10: y = c;   // 2'b11 not covered
  endcase
end

// TRAP 3 - output missing from one branch
always @(*) begin
  if (sel) begin
    y = a; z = b;
  end else begin
    y = c;          // z unassigned here
  end
end

// FIX 1 - default assignment first
always @(*) begin
  y = 1'b0;         // every path now covered
  if (enable)
    y = a;
end

// FIX 2 - always include default
always @(*) begin
  case (sel)
    2'b00:   y = a;
    2'b01:   y = b;
    2'b10:   y = c;
    default: y = 1'b0;
  endcase
end

// FIX 3 - assign every output on
// every branch
always @(*) begin
  y = c; z = 1'b0;  // defaults
  if (sel) begin
    y = a; z = b;
  end
end

Why latches are genuinely dangerous, not merely untidy

• Design-for-test breaks. Scan chains stitch flip-flops into a shift register so the tester can control and observe every state element. Latches are not scannable in the same way - coverage drops, and faults escape to the customer.
• Static timing analysis gets much harder. A latch is transparent while its gate is high, so timing can "borrow" across the boundary. Time borrowing is a legitimate advanced technique, but as an accident it produces timing reports nobody can interpret.
• Glitches become permanent. A momentary glitch on the data input while the gate is open gets captured and held. An edge-triggered flop would have ignored it.
• Clock gating gets blocked. Low-power flows rely on predictable edge-triggered structures; stray latches obstruct automatic clock-gating insertion.

Volume 01 recap