Before writing RTL, what do you decide, and how do you sketch it?
The spec says what each clock edge must produce. It does not say which boxes produce it. The step between them is the microarchitecture, which means the structure that meets the spec: where data is held, how it is combined, and what decides when.
You draw that structure before you code it. A sketch on paper forces the timing decisions out in the open, where the spec author can still correct them. Code written first hides those decisions inside syntax, where nobody reviews them.
A microarchitecture splits into two halves. The datapath is where data is held and combined: registers that keep values and logic such as an adder that makes new ones. Control is what decides when: which value the datapath keeps on each edge.
For the counter, the datapath is small: one 4-bit register holding the count, and an adder making count plus 1 with wrap from 15 to 0. Control is the priority order from the spec: reset first, then clear, then count, then hold. On every rising edge, control selects one of three candidates, 0, count plus 1, or the current count, and the register captures the choice.
The figure below draws that sketch. Trace the loop first: the register output feeds back into the priority logic, so each decision sees the current count. Then check the three input arrows on the left and the clock arrow on top of the register.
The sketch needs one more piece before anyone codes: the cycle contract, which means the agreement about when inputs are sampled, when outputs change, and how many cycles each result takes. For this block the contract has three lines: inputs are sampled at the rising edge, the count changes only after that edge, and each event is accepted on exactly one edge.
That contract answers the questions coders would otherwise guess at. A testbench knows it must hold inputs steady around the edge. A designer knows the new count is visible after the edge, never before. A reviewer knows that any output movement between edges breaks the contract, which is how the asynchronous reset mutant in lesson 5.1 gets caught.
The table below maps each row of the spec behaviour table onto the sketch. It is a worked trace of the design decision, not a measurement: read each row as the priority logic asking its questions from the top down and stopping at the first yes.
Spec row | Inputs at the edge | Priority logic selects | Register captures |
|---|---|---|---|
Reset |
| 0 | 0 |
Clear |
| 0 | 0 |
Count |
| count + 1, wrapping 15 to 0 | count + 1 |
Hold | all control inputs quiet | current count | unchanged value |
Two rows select 0, and that sharing is deliberate: reset and clear need no separate paths, only the shared selection of zero with reset checked first. The counting row is the only one that uses the adder, and the hold row feeds the register its own output back unchanged.
Latency is the delay from an input to its visible result, counted in clock edges. Throughput is how many inputs the block handles per cycle. The two move independently: a block can be slow to answer yet accept new work every cycle, or answer fast yet take turns.
This block takes one event per cycle and shows the result after the next rising edge. Its throughput is one event per cycle and its latency is one cycle. Both are derived from the spec, not measured: exactly one increment per edge, visible after that edge.
Now change the requirement, illustratively, to accepting two events in one cycle. The sketch must change shape: the adder path handles a plus-two candidate, the interface grows a way to offer the second event, and the priority table gains new rows for collisions such as two events arriving with clear. New questions follow, such as whether clear beats one event or both. The point is not the new answer but the new questions: a changed requirement reopens the sketch before it reopens the code.
It selects count plus 1 with wrap, which is 0, and the register holds 0 after the edge. The first two priority questions answer no, the counting question answers yes, and the adder wraps 15 to 0.
Starting to code before the cycle contract exists. Without agreed sampling and update times, the designer and the testbench author each invent their own, and the mismatch surfaces as a failure neither side can explain. Write the three contract lines first: when inputs are sampled, when outputs change, how many cycles each result takes.
Leaving reset behaviour unstated. A sketch with no reset box leaves the power-on value and the reset priority to chance, and every later stage pays for the gap. Draw where reset enters, state its type and polarity, and give it the top priority row as this sketch does.
Rule: draw the boxes and the cycle contract before you write a line of RTL.
Control is the priority logic box with its reset, clear, count, hold order: it decides which candidate wins. Datapath is the 4-bit register plus the adder making count plus 1: it holds the value and builds the candidates. The feedback arrow between them closes the loop the decision needs.
A clocked register captures something every edge, so holding still needs a selected value: its own current output. Naming it in the table forces the coder and the testbench to agree that idle keeps a nonzero value instead of drifting to zero.
On throughput. The requirement asks for two events per cycle, which is a throughput demand: the interface and the adder path must handle the wider input. Latency may stay at one cycle since the result is allowed the same delay as before. So you widen the selection to cover the two-event case and add its priority rows, while the register still captures one cycle later.
Microarchitecture is the structure that meets the spec: datapath holds and combines, control decides.
The cycle contract states when inputs are sampled, when outputs change, and how many cycles each result takes.
Latency measures delay to the result; throughput measures inputs per cycle; each can change without the other.