Verilog Series · Module 12
Behavioral Modelling — Part 3
Deep coverage of if/if-else constructs, assign-deassign, the repeat construct, for loops, and the disable statement — with complete synthesizable and testbench examples.
🔀 if and if-else Constructs — Introduction
The if statement is the most fundamental control flow construct in behavioral Verilog. It allows a procedural block to conditionally execute statements based on the value of an expression — modelling priority logic, enable conditions, and state transitions.
When synthesized, an if-else chain produces a priority multiplexer tree — the first condition that evaluates true wins. This is fundamentally different from case, which produces a balanced multiplexer without priority.
Conditional Execution
Execute one set of statements or another based on a run-time condition. Models hardware mux and enable logic.
Priority Hardware
Each
else if has lower priority than the preceding condition — synthesis produces a cascaded priority chain.Latch Risk
Missing
else in a combinational block leaves outputs undefined for some conditions — synthesis infers a latch.Nested Support
if statements can be nested to any depth. Use
begin...end blocks for multiple statements in any branch.📐 Syntax and Forms
Verilog provides three forms of the if construct, each building on the previous:
Fig 1 — All three if forms: simple, if-else, if-else if-else
// ── Form 1: Simple if ────────────────────────────────────────── if (condition) statement; // executes only when condition is TRUE // no else — output holds previous value! // ── Form 2: if-else ──────────────────────────────────────────── if (condition) statement_true; // executes when condition is TRUE else statement_false; // executes when condition is FALSE // ── Form 3: if-else if-else chain ───────────────────────────── if (cond_1) stmt_1; // highest priority else if (cond_2) stmt_2; else if (cond_3) stmt_3; else stmt_4; // lowest priority — catches all other cases // ── Multi-statement branches: always use begin...end ─────────── if (rst_n == 1'b0) begin count <= 8'h00; flags <= 4'b0000; valid <= 1'b0; end else begin count <= count + 1; valid <= 1'b1; end
Fig 2 — if-else Decision Diagram
Hardware view: each condition maps to a 2-to-1 MUX layer
Condition Evaluation Rules
| Condition value | if branch taken? | Explanation |
|---|---|---|
| 1 (or any non-zero) | ✅ Yes — TRUE | Any non-zero value is treated as logic true |
| 0 | ❌ No — FALSE | Zero means false, else branch taken |
| x (unknown) | ❌ No — FALSE | Unknown treated as false — else branch taken |
| z (high-Z) | ❌ No — FALSE | High-impedance treated as false |
x and z are treated as false. If your condition contains an uninitialized signal or a floating input, the simulator will take the
else branch silently. This can hide bugs during simulation — always ensure condition signals are properly initialized and driven.
⚠️ Latch Avoidance
The most critical rule for if statements in combinational always @(*) blocks: every output must be assigned in every possible execution path. If a path exists where an output isn’t assigned, the synthesis tool infers a latch to hold the previous value.
❌ Missing else — Latch inferred
always @(*) begin if (en) out = data; // No else! // When en=0: out holds // ← synthesis infers latch end
✅ Default assignment — No latch
always @(*) begin out = 8'h00; // default first if (en) out = data; // override if en // All paths covered // ✅ pure combinational end
❌ Multi-output: one missed
always @(*) begin if (sel) begin a = x; b = y; end else begin a = p; // b not assigned! // b gets a latch end end
✅ All outputs defaulted first
always @(*) begin a = 8'h00; // defaults b = 8'h00; if (sel) begin a = x; b = y; end else a = p; // b defaults to 0 ✅ end
Best practice — default at the top: Assign all outputs to their default values at the very beginning of the combinational always block. Then override selectively with if statements. This guarantees no latches regardless of how many conditions you add later.
🏆 Priority vs Parallel Decode
The choice between if-else and case has direct hardware implications. Understanding which to use is a key RTL design skill.
Fig 3 — Priority encoder (if-else) vs decoder (case): different hardware
🟣 if-else → Priority tree (cascaded)
always @(*) begin if (irq3) grant=2'b11; else if (irq2) grant=2'b10; else if (irq1) grant=2'b01; else grant=2'b00; end // irq3 has highest priority — // even if irq2 also asserted, // grant still = 2'b11
🔵 case → Balanced MUX (equal cost)
always @(*) begin case (sel) 2'b00: out=in0; 2'b01: out=in1; 2'b10: out=in2; 2'b11: out=in3; endcase end // All branches equal priority // No priority tree — faster
| Design need | Use | Reason |
|---|---|---|
| Priority interrupt controller | if-else | Highest-numbered IRQ must always win |
| ALU operation selector | case | All opcodes equal — no priority needed |
| Async reset / sync load | if-else | Reset must dominate over all other conditions |
| State machine output decode | case | States are mutually exclusive — equal cost MUX |
| One-hot priority encode | if-else or casez | Need to detect highest-priority set bit |
💡 if / if-else Examples
Fig 4 — Synchronous counter with enable, load, and reset
Priority chain: reset > load > enable > hold
module counter_full ( input clk, rst_n, input en, load, input [7:0] load_val, output reg [7:0] cnt ); always @(posedge clk or negedge rst_n) begin if (!rst_n) cnt <= 8'h00; // highest: async reset else if (load) cnt <= load_val; // sync load else if (en) cnt <= cnt + 1; // count when enabled else cnt <= cnt; // hold (explicit) end endmodule
Fig 5 — Nested if: 2-bit Arithmetic Logic Unit
Nested if-else demonstrating multi-level condition checking
always @(*) begin result = 8'h00; // default — prevents latches carry = 1'b0; ovf = 1'b0; if (mode == 1'b0) begin // Arithmetic mode if (sub) begin {carry, result} = a - b; ovf = (a[7] != b[7]) && (result[7] != a[7]); end else begin {carry, result} = a + b; ovf = (a[7] == b[7]) && (result[7] != a[7]); end end else begin // Logic mode if (op == 2'b00) result = a & b; else if (op == 2'b01) result = a | b; else if (op == 2'b10) result = a ^ b; else result = ~a; end end
Fig 6 — if in Sequential Logic: Moore FSM Traffic Light
3-state traffic light FSM using if-else for state transitions
module traffic_fsm ( input clk, rst_n, output reg [2:0] lights // [2]=Red [1]=Amber [0]=Green ); localparam RED=2'd0, GREEN=2'd1, AMBER=2'd2; reg [1:0] state; reg [4:0] timer; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin state <= RED; timer <= 5'd30; end else begin timer <= timer - 1; if (timer == 0) begin // timer expired — change state if (state == RED) begin state <= GREEN; timer <= 5'd25; end else if (state == GREEN) begin state <= AMBER; timer <= 5'd5; end else begin state <= RED; timer <= 5'd30; end end end end // Output decode (combinational) always @(*) begin lights = 3'b000; if (state == RED) lights = 3'b100; else if (state == GREEN) lights = 3'b001; else lights = 3'b010; end endmodule
📌 assign — deassign Construct
The procedural assign and deassign statements are a special construct used inside procedural blocks to override the normal assignment to a reg variable. They force a register to follow a continuous expression — ignoring any normal procedural assignments — until deassign is called to release it.
Not the same as continuous assign. The module-level
assign keyword (data-flow level) is completely different from the procedural assign statement used inside always/initial blocks. The procedural form overrides the reg‘s normal driving.
Forces a reg
Procedural
assign continuously drives a reg with an expression, overriding any clock-triggered assignments to it.deassign releases
deassign releases the override. The reg retains its last forced value until a normal procedural assignment updates it.Testbench Use
Primary use is testbenches — forcing internal signals to specific values for corner case testing without modifying the DUT.
Not Synthesizable
Procedural
assign/deassign are not supported by synthesis tools. Use only in simulation and testbenches.Fig 7 — assign / deassign syntax and operation
// ── Basic syntax ────────────────────────────────────────────── assign reg_var = expression; // force reg_var to track expression deassign reg_var; // release; reg_var holds last value // ── Modelling an asynchronous clear D flip-flop ─────────────── module dff_async_clr ( input clk, d, clr, // clr: active-high async clear output reg q ); always @(clr) begin if (clr) begin assign q = 1'b0; // force q=0 asynchronously whenever clr=1 end else begin deassign q; // release q — normal clocking resumes end end always @(posedge clk) begin q <= d; // normal D capture (overridden when clr=1) end endmodule
Fig 8 — Testbench use: forcing internal signals for debugging
// Force an internal signal to a specific value for N cycles initial begin // Normal stimulus #100; // Force internal counter to max value to test overflow assign dut.counter = 8'hFF; // hierarchical assign @(posedge clk); // wait one clock deassign dut.counter; // release — normal operation // Verify overflow flag asserted @(posedge clk); if (!dut.overflow) $display("FAIL: overflow not detected"); else $display("PASS: overflow detected correctly"); $finish; end
assign / deassign vs force / release
| Construct | Targets | Overrides | Use case |
|---|---|---|---|
| assign / deassign | reg only | Procedural assignments | Modelling async preset/clear |
| force / release | reg and wire | All drivers including continuous assigns | Testbench debugging, fault injection |
Modern alternative: In SystemVerilog flows,
force/release and UVM register backdoor access have largely replaced assign/deassign in testbenches. However, assign/deassign remains useful for modelling async clear/preset in behavioral flip-flop models.
🔁 The repeat Construct
The repeat statement executes a statement or block a fixed, pre-determined number of times. The count is evaluated once at the start — it cannot be changed during execution. This makes repeat ideal for testbench timing (waiting N clock cycles) and simple initialization patterns.
repeat
Keyword
always lowercase
(
open parens
N
Count
constant or expression
evaluated once at start
evaluated once at start
)
close parens
statement
Body
or begin…end block
Fixed Count
The repeat count is evaluated once at the start — a variable count is evaluated then fixed, not re-checked each iteration.
No Loop Variable
repeat has no built-in loop variable. Use for instead when you need an index.Testbench Staple
Most common use:
repeat(N) @(posedge clk); — wait exactly N clock cycles before the next test step.Synthesis Caution
repeat with constant count can synthesize if the body is simple combinational logic (loop unrolling). With delays or events, it is simulation-only.💡 repeat Examples
Fig 9 — repeat: timing control in testbenches
All common testbench uses of repeat
// ── Wait N clock cycles ──────────────────────────────────────── repeat(5) @(posedge clk); // wait 5 rising edges repeat(10) @(negedge clk); // wait 10 falling edges // ── Generate N clock pulses ──────────────────────────────────── repeat(8) begin clk = 0; #5; clk = 1; #5; // 8 complete clock periods end // ── Apply a burst of N data bytes ────────────────────────────── integer byte_idx; byte_idx = 0; repeat(4) begin @(posedge clk); tx_data = payload[8*byte_idx +: 8]; byte_idx = byte_idx + 1; end // ── Variable count (evaluated once at entry) ─────────────────── integer n_cycles; n_cycles = 12; repeat(n_cycles) @(posedge clk); // waits exactly 12 cycles // Changing n_cycles inside the loop has no effect on count // ── Synthesizable repeat: bit counting (constant iterations) ─── integer ones; reg [7:0] tmp; ones = 0; tmp = data; repeat(8) begin ones = ones + tmp[0]; // count 1s in LSB tmp = tmp >> 1; // shift right end // ones = popcount(data)
Fig 10 — Serial data transmitter using repeat
Behavioural UART transmitter task — sends 8 data bits serially
task uart_send_byte; input [7:0] byte_in; integer bit_idx; begin // Start bit (low) tx = 1'b0; @(posedge baud_clk); // Data bits — 8 iterations using repeat bit_idx = 0; repeat(8) begin tx = byte_in[bit_idx]; // LSB first @(posedge baud_clk); bit_idx = bit_idx + 1; end // Stop bit (high) tx = 1'b1; @(posedge baud_clk); $display("Sent: 0x%02h", byte_in); end endtask
🔄 The for Loop
The for loop is the most versatile loop construct in Verilog. It provides an index variable, an exit condition, and a step expression — all in one compact header. Unlike repeat, you have full access to the loop counter inside the body.
Init
i = 0
Executed once before the loop starts. Sets the starting value of the loop variable.
Condition
i < N
Checked before each iteration. Loop exits when this becomes false.
Step
i = i + 1
Executed after each iteration body. Updates the loop variable.
Fig 11 — for loop syntax and execution flow
// ── Basic syntax ────────────────────────────────────────────── for (init; condition; step) begin statement; end // ── Simple 8-iteration example ──────────────────────────────── integer i; for (i=0; i<8; i=i+1) begin out[i] = in[7-i]; // bit reversal: out[0]=in[7], out[7]=in[0] end // ── Count down ──────────────────────────────────────────────── for (i=7; i>=0; i=i-1) begin $display("Bit %0d = %b", i, data[i]); end // ── Step by 2 ───────────────────────────────────────────────── for (i=0; i<16; i=i+2) begin even_mem[i/2] = mem[i]; // pack even-addressed bytes end
Fig 12 — for loop execution flowchart
1
Execute init
i = 0 — runs exactly once before the loop starts↓
2
Evaluate condition
i < N — if FALSE → exit loop; if TRUE → execute body↓
3
Execute loop body
All statements between begin and end
↓
4
Execute step
i = i + 1 — then go back to step 2💡 for Loop Examples
Fig 13 — Memory operations with for loop
Initialise, copy, and search memory arrays
reg [7:0] mem_a[0:255], mem_b[0:255]; integer i, j; initial begin // Zero-initialise all 256 locations for (i=0; i<256; i=i+1) mem_a[i] = 8'h00; // Fill with ascending values for (i=0; i<256; i=i+1) mem_a[i] = i[7:0]; // Deep copy: mem_b ← mem_a for (i=0; i<256; i=i+1) mem_b[i] = mem_a[i]; // Linear search: find value 0xAB j = -1; for (i=0; i<256; i=i+1) if (mem_a[i] == 8'hAB) j = i; if (j >= 0) $display("Found 0xAB at address %0d", j); end
Fig 14 — Synthesizable for: CRC calculation
8-bit CRC generator — synthesizable because bound is constant
module crc8 ( input [7:0] data_in, input [7:0] crc_in, // running CRC (feed 8'h00 initially) output reg [7:0] crc_out ); integer i; reg [7:0] tmp; always @(*) begin tmp = data_in ^ crc_in; // 8 iterations — synthesizer unrolls this into 8 XOR stages for (i=0; i<8; i=i+1) begin if (tmp[7]) tmp = (tmp << 1) ^ 8'h07; // CRC-8/SMBUS polynomial else tmp = (tmp << 1); end crc_out = tmp; end endmodule
Fig 15 — for loop: Barrel shifter (synthesizable)
Parameterized N-bit barrel left-shifter using for
module barrel_shift #(parameter N=8) ( input [N-1:0] data_in, input [$clog2(N)-1:0] shift_amt, output reg [N-1:0] data_out ); integer i; always @(*) begin data_out = {N{1'b0}}; for (i=0; i<N; i=i+1) begin if (i >= shift_amt) data_out[i] = data_in[i - shift_amt]; end end endmodule
for loop synthesis: A
for loop with a constant bound (e.g., i < 8) is synthesized by unrolling — the tool replicates the body N times. This is how complex combinational logic (CRC, parity, popcount) is efficiently described in few lines of RTL. Variable bounds are generally not synthesizable.
🛑 The disable Construct
The disable statement terminates execution of a named block or named task, skipping any remaining statements within it. It is Verilog’s equivalent of break (for loops) or early return (for tasks) in C, but operates on named scopes rather than loop constructs.
Requires Named Blocks
disable works only on named begin-end blocks or named tasks. Anonymous blocks cannot be disabled.Early Exit
Jumps past the end of the named block — like
break in a loop or return from a function.Simulation Context
Most useful in testbenches for aborting loops on a found condition, implementing timeouts, and cancelling tasks.
Not Synthesizable
disable is a simulation construct. Synthesis tools do not support it — use it in testbenches only.Fig 16 — Named block scopes: disable jumps to the end of the named block
begin : my_loop
stmt_1; ← executes
stmt_2; ← executes
disable my_loop; ← jumps past the end of my_loop
stmt_3; ← SKIPPED
stmt_4; ← SKIPPED
↓ execution resumes here, after end of my_loop
💡 disable Examples
Fig 17 — break from a for loop using disable
Search memory and stop at first match — disable acts as break
// ── Linear search: stop at first match ──────────────────────── integer i, found_addr; found_addr = -1; begin : search_loop // name the block — required for disable for (i=0; i<256; i=i+1) begin if (mem[i] == target) begin found_addr = i; disable search_loop; // ← break out of the for loop end end end // search_loop ends here — disable jumps to this point if (found_addr >= 0) $display("Found at address %0d", found_addr); else $display("Not found");
Fig 18 — Timeout using disable in a fork-join
Implement a watchdog timeout — disable the waiting block if timeout fires
initial begin : sim_top fork // Thread 1: wait for DUT to finish begin : wait_done wait(dut_done); $display("DUT completed at t=%0t", $time); disable timeout_wdog; // cancel the timeout end // Thread 2: watchdog timeout begin : timeout_wdog #10000; // maximum allowed time $display("TIMEOUT — DUT did not finish!"); disable wait_done; // cancel the wait thread $finish; end join end
Fig 19 — disable inside a named task
Early return from a task on error condition
task send_packet; input [7:0] pkt [0:3]; integer k; begin : send_body // Check link is up before sending if (!link_up) begin $display("ERROR: Link down — aborting send"); disable send_body; // early exit — equivalent to return end // Send 4 bytes for (k=0; k<4; k=k+1) begin @(posedge clk); tx_data = pkt[k]; tx_valid = 1'b1; // Error injection check mid-packet if (error_injected) begin $display("Aborting mid-packet at byte %0d", k); disable send_body; // abort the for loop and task end end tx_valid = 1'b0; $display("Packet sent OK"); end // send_body endtask
📋 Summary and Comparison
A quick reference comparing all five constructs covered in this module:
| Construct | Purpose | Has loop variable? | Synthesizable? | Primary use |
|---|---|---|---|---|
| if / if-else | Conditional branch — execute one path or another | — | ✅ Yes | RTL priority logic, reset/load/enable chains |
| assign / deassign | Force a reg to track an expression; release it | — | ❌ No | Async clear/preset models, testbench forcing |
| repeat(N) | Execute body exactly N times | ❌ No index | ⚠️ Constant N only | Testbench: wait N clocks, N-cycle bursts |
| for (init; cond; step) | Counted loop with full index control | ✅ Yes (integer) | ⚠️ Constant bound only | RTL: bit ops, CRC; TB: memory init, search |
| disable | Early exit from a named block or task | — | ❌ No | Testbench: break from loops, timeouts, abort |
Fig 20 — Choosing the right construct
?
Do you need conditional execution?
→ Use
if / if-else — synthesizable, models priority hardware↓
?
Do you need to force a reg from a procedural block?
→ Use
assign / deassign — simulation only, models async control↓
?
Do you need to repeat without an index?
→ Use
repeat(N) — compact, testbench-friendly, no loop variable↓
?
Do you need an indexed loop with full counter control?
→ Use
for — RTL (const bound) or testbench (variable bound)↓
?
Do you need early exit from a loop or task?
→ Use
disable on a named block — simulation only
RTL coding guideline: In synthesizable RTL (
always @(*) and always @(posedge clk)), stick to if/else and for with constant bounds. Everything else — assign/deassign, disable, and repeat with event controls — belongs in testbenches and simulation models only.