06Reset, enable and priority

1. A synchronous reset is sampled at the edge like any other input

A register starts the simulation holding x, and it holds x until something assigns it. Reset is the input that gives it a known value. In this course the reset is synchronous: it is tested inside the always @(posedge clock) block, so it takes effect only at a rising edge where it is high, and raising it between edges does nothing until the next edge.

Form

always @(posedge clock) begin
  if (reset) count <= 4'd0;
  else       count <= count + 4'd1;
end

Counter.v is exactly this block, the counter whose trace Registers and nonblocking assignment read line by line. In its testbench reset is high across the first two rising edges and is lowered on the falling edge at time 20.

// A 4-bit counter with a synchronous, active-high reset.
module counter (
  input            clock,
  input            reset,
  output reg [3:0] count
);
  always @(posedge clock) begin
    if (reset) count <= 4'd0;
    else       count <= count + 4'd1;
  end
endmodule

An asynchronous reset, written into the sensitivity list, acts without waiting for an edge. The examples of this course do not use it, and neither does any Practice problem here.

2. Enable means update or hold

An enable input decides whether the register takes a new value at this edge or keeps its current one. In a clocked block, holding is what happens when no statement assigns the register, so an else if (enable) with no final else is the enable:

always @(posedge clock) begin
  if (reset)       count <= 4'd0;
  else if (enable) count <= count + 4'd1;
  // no else: count keeps its value
end

In Nets, variables and the combinational always a missing branch in a combinational block was a defect, because it forced storage into a circuit that should have none. In a clocked block the register is the storage, and a path that assigns nothing simply means "hold". Operate the model below: clear and enable are sampled at each edge, and q counts modulo 16.

reset and clear are different inputs. The model's input is called clear, and so is the input of the Practice problem clear-enable-counter in Design from a requirement. In the code, a synchronous clear looks exactly like this chapter's reset: the first branch of the chain, storing 0. The difference is its job. reset puts the design into its starting state; it is raised when the system starts or restarts, and usually every register shares it. clear is a command of one block's normal operation, like enable: the design that uses the counter raises it whenever it wants to start counting again. A design can have both, and then reset comes first in the chain, clear second. When a requirement names its inputs, use its names and its priority, not this chapter's.

3. Priority is the order of the if/else chain

When two inputs are high at the same edge, the chain decides which one wins: the first condition that is true takes the edge, and the later ones are not even examined. Put reset first and it wins over enable whatever enable is.

A nested version breaks this rule in a way that compiles cleanly:

if (enable) begin
  if (reset) count <= 4'd0;
  else       count <= count + 4'd1;
end

Fill in the table for the counter with the right priority. Both inputs are the values sampled at the edge that ends each cycle; write q after that edge.

4. Wrap where the requirement says, not where the width runs out

A 4-bit register wraps from 15 to 0 by itself: 15 + 1 is 16, and the low four bits of 16 are 0000. A decade counter has to wrap after 9, and the design must decide that on the edge where the current value is 9. The decision is one more branch, placed after reset and before the increment:

if (reset)              count <= 4'd0;
else if (count == 4'd9) count <= 4'd0;
else                    count <= count + 4'd1;

Compare with the last value you want to see, not the first value you want to avoid.

The whole counter is now one transition contract. At every rising edge, the first row whose condition holds decides the next value:

The decade counter is this table with MAX = 9 and enable always 1; the if/else chain is the table written top to bottom.

5. Check every row of the contract in one run

WrapCounter.v follows the table with MAX = 5 in a 3-bit register, so it counts 0 to 5 and wraps. The wrap is the inner if of the enable branch, so it happens only on an enabled edge.

// Counts 0 to 5 and wraps. Priority: reset, then enable, then hold.
module wrap_counter (
  input            clock,
  input            reset,
  input            enable,
  output reg [2:0] count
);
  always @(posedge clock) begin
    if (reset)
      count <= 3'd0;
    else if (enable) begin
      if (count == 3'd5) count <= 3'd0;
      else               count <= count + 3'd1;
    end
    // No final else: with enable low the register holds.
  end
endmodule

Tb.v changes reset and enable only on falling edges and prints one EDGE line per rising edge. Two values are printed for the same register:

• prev is count read at the edge, in the same time step as the <=, before the update. It is the value the if chain decided from.
• count is printed by $strobe, which waits until the end of the time step, after the <= has updated the register. It is the value the edge produced, the same value a read on the next falling edge would see.

module tb;
  reg        clock = 0;
  reg        reset = 1, enable = 0;
  reg  [2:0] prev;
  wire [2:0] count;

  wrap_counter dut (.clock(clock), .reset(reset), .enable(enable), .count(count));

  always #5 clock = ~clock;

  // One line per rising edge: the value read at the edge, then the value after it.
  always @(posedge clock) begin
    prev = count;
    $strobe("EDGE t=%0t reset=%b enable=%b prev=%0d count=%0d", $time, reset, enable, prev, count);
  end

  // Drive both inputs on the falling edge, half a period before they are sampled.
  task apply(input r, input e);
    begin
      @(negedge clock);
      reset = r; enable = e;
    end
  endtask

  initial begin
    // Count twice, hold once, then count up to 5.
    apply(0, 1); apply(0, 1);
    apply(0, 0);
    apply(0, 1); apply(0, 1); apply(0, 1);
    // Wrap to 0 and count once more, then reset while enabled and reset again.
    apply(0, 1); apply(0, 1);
    apply(1, 1);
    apply(1, 0);
    apply(0, 1);
    @(posedge clock) #1 $finish;
  end
endmodule

The inputs reach the edges in this order: reset alone; enable twice; both low; enable five times; reset with enable; reset alone again; enable. Use the contract table to predict count on the lines that test a single row.

Check the result. Press Run and compare the twelve lines with the table.

On every increment or wrap line, prev and count differ. They agree on a hold line or when reset writes 0 to a register that was already 0. That is the edge itself: the chain reads the old value, and the new value exists only after the nonblocking updates of the time step.

Change one thing. In Tb.v, replace $strobe with $display and run again. Predict first.

The scheduling behind this, the active and nonblocking-update regions of one time step, is in Registers and nonblocking assignment. Put $strobe back before you go on.

6. Run, then fix the counter

Press Run on Counter.v above and read the trace with the previous chapter's rule: each EDGE line shows the value before the edge, each AFTER line the value after. Count how many edges reset is high and where the counting starts.

The checkpoint is the Practice problem decade-counter: the plain counter from above resets correctly but keeps going to 10, 11, 12. Add the wrap branch between reset and increment, keeping the synchronous reset. Its testbench prints at the rising edge, so read each line remembering that it shows the value from before that edge when you compare the lines with your prediction.

The nested if of section 3 is a Practice problem of its own, reset-priority in Testbench techniques: a counter that counts correctly while enabled, yet a reset raised while enable is low leaves the value unchanged. When you reach it, trace the nested if with reset=1 enable=0 and restructure it as one chain with reset first. The accumulator of that chapter settles the same kind of priority with its clear input and checks it against a model.

7. Summary