Verilog Clocked Logic: Flip-Flops, Registers, and Pipelines

The Building Block: A D Flip-Flop

Everything in synchronous design comes back to one tiny piece of hardware: the D flip-flop. It has a clock input, a data input, and a data output. On each rising clock edge, it captures the value of D and holds it until the next edge. That's it.

In Verilog:

always @(posedge clk) begin
    q <= d;
end

Three lines, one flip-flop. The <= is non-blocking, which is exactly the behavior of real flip-flops (covered in Blocking vs Non-blocking). The posedge clk sensitivity is what makes it sequential.

Stack many of these with combinational logic between them and you have any synchronous circuit you'd want to build.

A Register With Reset

Real designs always need a reset - a way to put the system into a known state at power-on or on demand:

module reg_with_reset #(
    parameter WIDTH = 8
)(
    input  wire             clk,
    input  wire             reset,
    input  wire [WIDTH-1:0] d,
    output reg  [WIDTH-1:0] q
);
    always @(posedge clk) begin
        if (reset) q <= 0;
        else       q <= d;
    end
endmodule

module test;
    reg clk = 0;
    reg reset = 1;
    reg [7:0] d;
    wire [7:0] q;

    reg_with_reset dut(.clk(clk), .reset(reset), .d(d), .q(q));

    always #5 clk = ~clk;

    initial begin
        d = 8'hA5;
        #20 reset = 0;
        #10 d = 8'h3C;
        #10 d = 8'hFF;
        #20 $finish;
    end

    always @(posedge clk)
        $display("t=%0t reset=%b d=%h q=%h", $time, reset, d, q);
endmodule

That's a synchronous reset - the reset condition is evaluated on a clock edge like any other input. The synthesizer produces a flip-flop with a 2-to-1 mux on its data input: when reset is high, the mux feeds zero; otherwise it feeds d.

For most designs, synchronous reset is the right choice. It's simpler timing, it plays nicely with FPGAs, and the reset signal can come from anywhere - it doesn't need its own clock-aligned source.

A Register With Enable

Often you want a register that only updates when something tells it to. Use an if inside the clocked block, and rely on the implicit "hold previous value" behavior of the missing else:

module reg_with_enable(
    input  wire       clk,
    input  wire       reset,
    input  wire       enable,
    input  wire [7:0] d,
    output reg  [7:0] q
);
    always @(posedge clk) begin
        if (reset)       q <= 8'd0;
        else if (enable) q <= d;
        // No else - q holds its previous value, which is what a FF does
    end
endmodule

This is the canonical "load-enabled register". It shows up everywhere - configuration registers, pipeline stages that only advance when downstream is ready, counters that pause and resume. The omission of the final else is deliberate and safe inside a clocked block: a flip-flop already remembers its previous value, so "do nothing" means "hold".

In a combinational block the same code would infer a latch. Different rules, same syntax.

A Counter

A counter is a register whose next value is its current value plus one:

module counter #(
    parameter WIDTH = 4
)(
    input  wire             clk,
    input  wire             reset,
    input  wire             enable,
    output reg  [WIDTH-1:0] count
);
    always @(posedge clk) begin
        if (reset)        count <= 0;
        else if (enable)  count <= count + 1;
    end
endmodule

module test;
    reg clk = 0;
    reg reset = 1;
    reg enable = 0;
    wire [3:0] count;

    counter #(.WIDTH(4)) dut(.clk(clk), .reset(reset), .enable(enable), .count(count));

    always #5 clk = ~clk;

    initial begin
        #12 reset = 0;
        #5  enable = 1;
        #80 $finish;
    end

    always @(posedge clk)
        $display("t=%0t count=%0d", $time, count);
endmodule

The counter increments on every clock cycle when enable is high. After 16 cycles it wraps back to 0 (because we declared 4 bits and 15 + 1 overflows to 0). That wrapping is intrinsic to N-bit arithmetic and is exactly how a real hardware counter behaves.

A Shift Register

Stacking flip-flops gives you a shift register. The trick is to do all the shifts in one non-blocking statement:

module shift_register #(
    parameter WIDTH = 4
)(
    input  wire             clk,
    input  wire             reset,
    input  wire             in,
    output reg  [WIDTH-1:0] out
);
    always @(posedge clk) begin
        if (reset) out <= 0;
        else       out <= {out[WIDTH-2:0], in};
    end
endmodule

module test;
    reg clk = 0;
    reg reset = 1;
    reg in = 0;
    wire [3:0] out;

    shift_register #(.WIDTH(4)) dut(.clk(clk), .reset(reset), .in(in), .out(out));

    always #5 clk = ~clk;

    initial begin
        #12 reset = 0;
        in = 1; #10;
        in = 0; #10;
        in = 1; #10;
        in = 1; #10;
        in = 0; #40 $finish;
    end

    always @(posedge clk)
        $display("t=%0t in=%b out=%b", $time, in, out);
endmodule

The body is out <= {out[WIDTH-2:0], in} - concatenate the lower bits of the current out with the new in, and assign the whole thing. Because it's non-blocking, the RHS reads the old out before the LHS updates. The effect is a clean N-bit shift in a single clock cycle.

This is the shift-register pattern in its smallest form. It generalizes to LFSRs, serial transmitters, deserializers - any design where data moves through a chain of flip-flops on each clock.

Pipelines

A pipeline is a chain of registers separated by combinational logic. Each stage processes data from the previous stage and feeds the next:

module pipelined_add(
    input  wire        clk,
    input  wire        reset,
    input  wire [7:0]  a, b, c, d,
    output reg  [9:0]  result
);
    reg [8:0] stage1_ab, stage1_cd;
    reg [9:0] stage2;

    always @(posedge clk) begin
        if (reset) begin
            stage1_ab <= 0;
            stage1_cd <= 0;
            stage2    <= 0;
            result    <= 0;
        end else begin
            // Stage 1: two parallel adds.
            stage1_ab <= a + b;
            stage1_cd <= c + d;
            // Stage 2: combine the two partial sums.
            stage2    <= stage1_ab + stage1_cd;
            // Stage 3: forward to output.
            result    <= stage2;
        end
    end
endmodule

module test;
    reg clk = 0;
    reg reset = 1;
    reg [7:0] a, b, c, d;
    wire [9:0] result;

    pipelined_add dut(.clk(clk), .reset(reset), .a(a), .b(b), .c(c), .d(d), .result(result));

    always #5 clk = ~clk;

    initial begin
        a = 0; b = 0; c = 0; d = 0;
        #12 reset = 0;
        a = 10; b = 20; c = 30; d = 40; #10;
        a = 1;  b = 2;  c = 3;  d = 4;  #10;
        a = 5;  b = 5;  c = 5;  d = 5;  #40;
        $finish;
    end

    always @(posedge clk)
        $display("t=%0t a=%0d b=%0d c=%0d d=%0d result=%0d", $time, a, b, c, d, result);
endmodule

Three stages, three cycles of latency, but a new result every cycle once the pipeline is full. The latency is 3 clocks because the data passes through three flip-flops; the throughput is 1 operation per clock because all three stages work simultaneously on different inputs.

This is how high-performance designs hit their throughput targets: keep stages short, pipeline more deeply, and let parallelism do the work.

Asynchronous Reset (When You Need It)

Sometimes you can't wait for a clock edge to assert reset - the chip is being powered down, the clock is gated, an external watchdog is yanking the line. In those cases:

always @(posedge clk or negedge reset_n) begin
    if (~reset_n) q <= 0;
    else          q <= d;
end

The sensitivity list now has both a clock edge and a reset edge. The flip-flop responds immediately to either. reset_n is by convention active-low (asserted when low), which is why the test is ~reset_n.

Asynchronous reset has tradeoffs: harder to time-analyze, can cause metastability if not handled carefully on de-assertion, not portable across all FPGA architectures. Use synchronous reset by default, async only when the design requires it.

What Comes Next

You can now build any synchronous datapath. The next doc - Finite State Machines - puts a clocked register together with a case statement to produce the standard FSM idiom: the workhorse of every controller, protocol engine, and decision-making block in digital design.