15Implementation

Bump a counter

Problem

Counter.bump is an Action method: one accepted call must schedule exactly one 8-bit state transition and return no value. The starter leaves that transition as a don't-care expression. With the supplied toolchain, the public run ends at decimal 170 rather than the required value 3; that number is an arbitrary choice for ?, not a usable counter implementation.

Edit only the TODO inside mkCounter. Preserve the interface, the value method, and the supplied top module. The repair should express the next-state relation for any current count, not special-case the three calls made by mkTop.

Read, predict, and repair

Read starter/Main.bsv in this order:

1. Classify bump and value from their interface result types.
2. Locate the count register and its initial value.
3. Follow drive: it calls bump once and advances steps once per firing.
4. Follow show: it reads the state only after drive has fired three times.
5. Return to the TODO and state the required old-state-to-next-state relation in words before writing BSV.

The worked trace should be count 0 at reset, then 1, 2, and 3 at successive cycle boundaries. <= does not change the register immediately inside the method; it schedules the value visible in the next cycle. The minimal repair therefore supplies one deterministic next-state expression and adds no new register, rule, guard, or return value.

Run after editing. Completion is observable when the public run reports decimal 3, the method remains Action, and each call accounts for exactly one transition. An implementation that merely forces the final sample to three is incorrect because one call and two calls must expose the corresponding earlier states.

Progressive hints

Transfer experiment

After the required version works, initialize count to 8'hfe and reason through two bump calls. Predict both intermediate states, including the 8-bit wraparound, before running. This separates the general next-state rule from an implementation fitted only to reset value zero.