Verilog For Loops: Unrolled at Compile Time

The Software Look-Alike

Verilog's for loop is a copy of C's:

for (i = 0; i < 8; i = i + 1) begin
    // body
end

The same three parts: initializer, condition, increment. The body re-runs as long as the condition holds.

In a testbench, this behaves exactly like you'd expect from software. The simulator steps through each iteration in turn:

module testbench_for;
    integer i;
    initial begin
        for (i = 0; i < 4; i = i + 1)
            $display("iteration i=%0d", i);
        $finish;
    end
endmodule

Four iterations, four lines of output. No surprises.

The surprise comes when you put a for loop inside synthesizable code.

The Unroll

A for loop in a synthesizable always block does not become a runtime loop in hardware. The synthesizer unrolls it at elaboration time - it expands the loop into N copies of the body, where N is the iteration count:

module count_ones(
    input  wire [7:0] data,
    output reg  [3:0] count
);
    integer i;
    always @(*) begin
        count = 0;
        for (i = 0; i < 8; i = i + 1) begin
            if (data[i]) count = count + 1;
        end
    end
endmodule

module test;
    reg [7:0] d;
    wire [3:0] c;
    count_ones dut(.data(d), .count(c));

    initial begin
        d = 8'b0000_0000; #1 $display("data=%b count=%0d", d, c);
        d = 8'b1111_1111; #1 $display("data=%b count=%0d", d, c);
        d = 8'b1010_1100; #1 $display("data=%b count=%0d", d, c);
        d = 8'b0010_0001; #1 $display("data=%b count=%0d", d, c);
        $finish;
    end
endmodule

That looks like a loop. In simulation, the simulator does loop through eight iterations. In synthesis, the loop is unrolled into eight parallel checks of data[0] through data[7], all happening at the same time. The synthesizer sees:

count = 0;
if (data[0]) count = count + 1;
if (data[1]) count = count + 1;
if (data[2]) count = count + 1;
...
if (data[7]) count = count + 1;

…and then turns the sequence into an adder tree. The runtime behavior is "look at all 8 bits at once and count how many are 1", in a single combinational sweep.

The implication: a for loop in synthesizable Verilog is not free. A 64-iteration loop becomes 64 copies of the body in hardware. If the body is complex, you've just built a large combinational block. Use loops when N is small (handful to a few dozen). For larger counts, you usually want a clocked counter and a state machine.

Constant Bounds Are Required

The synthesizer can only unroll the loop if it knows N at elaboration time. That means the loop bounds must be constants:

// Works - bound is constant
for (i = 0; i < 8; i = i + 1) ...

// Works - bound is a parameter
for (i = 0; i < WIDTH; i = i + 1) ...

// Doesn't synthesize - bound depends on a runtime signal
for (i = 0; i < dynamic_count; i = i + 1) ...

The last form might still work in simulation, but the synthesizer will reject it. If you genuinely need a runtime-counted loop, you build it with a clocked state machine and a counter register - hardware doesn't have variable-trip-count loops in the way software does.

generate for vs Procedural for

A separate but related construct is generate for, which uses a genvar and lives outside always blocks:

genvar i;
generate
    for (i = 0; i < 8; i = i + 1) begin : g
        bit_inverter inv(.x(in[i]), .y(out[i]));
    end
endgenerate

That stamps out 8 instances of bit_inverter (covered in Module Instantiation). It's structural - you're saying "make 8 copies of this sub-module" - not behavioral.

Quick distinction:

• Procedural for (inside always) - unrolls statements within a single behavioral block.
• Generate for (outside always) - replicates entire structural constructs: instances, assign statements, named blocks.

Use the one that matches what you're replicating.

When for Shines: Vector Operations

Loops are at their best when you're doing the same operation to every bit of a vector. Population count, parity, byte reversal, lookup-table generation:

module reverse_bytes(
    input  wire [31:0] in,
    output reg  [31:0] out
);
    integer i;
    always @(*) begin
        for (i = 0; i < 32; i = i + 1) begin
            out[i] = in[31 - i];
        end
    end
endmodule

module test;
    reg  [31:0] x;
    wire [31:0] y;
    reverse_bytes dut(.in(x), .out(y));

    initial begin
        x = 32'hDEAD_BEEF; #1 $display("in=%h out=%h", x, y);
        x = 32'h0000_0001; #1 $display("in=%h out=%h", x, y);
        $finish;
    end
endmodule

32 iterations, each doing one bit assignment - much more readable than writing out 32 hand-rolled wire assignments. The synthesizer unrolls cleanly.

while, repeat, forever

Beyond for, Verilog has three other loop constructs - mostly for testbenches:

// Run until a condition fails
while (~done) begin
    @(posedge clk);
    cycles = cycles + 1;
end

// Run N times - simpler than for when you don't need a counter
repeat (8) @(posedge clk);

// Run forever - clock generators, monitoring loops
always #5 clk = ~clk;
forever begin
    @(posedge clk);
    $display("count=%0d", count);
end

while, repeat, and forever are synthesizable only in narrow cases (notably repeat with a constant count and a clocked body). In testbenches they're useful tools; in synthesizable RTL prefer a counted for plus an explicit state machine.

Procedural for in Testbenches

In a testbench, for loops behave the way software does. Use them freely:

module sweep_test;
    reg [7:0] a, b;
    wire [8:0] sum;

    assign sum = a + b;

    initial begin
        for (integer i = 0; i < 4; i = i + 1) begin
            for (integer j = 0; j < 4; j = j + 1) begin
                a = i;
                b = j;
                #1 $display("%0d + %0d = %0d", a, b, sum);
            end
        end
        $finish;
    end
endmodule

Nested loops sweep every combination of two 2-bit inputs. The simulator runs the iterations sequentially. No unrolling concerns - testbenches don't synthesize.

Common Mistakes

Using a for loop in synthesizable code with a non-constant bound. The synthesizer will reject it. If the bound is runtime, build a counter and a state machine.

Forgetting that the loop body becomes parallel hardware. A 64-iteration loop with a multiplier in the body is 64 parallel multipliers - probably not what you want. For wide datapaths, build a single multiplier and feed it sequentially.

Mixing integer i and a reg named i. The two are different scopes; the integer wins inside the loop. Pick clear names to avoid the confusion.

What Comes Next

You now have every procedural construct Verilog offers. The next chapter pulls it all together into the patterns digital designers actually ship: Clocked Logic - flip-flops, registers, and pipelines - and Finite State Machines - the standard idiom for any controller with multiple operating modes.