01Implementation

Count with one rule

Problem

mkIntroCounter should report a counter that starts at zero, advances once per firing, reaches five, and then stays there. The starter's step rule is ready, but its current assignment writes the same value back, so no progress is visible.

Repair the TODO with one register assignment. The intended change is the next value calculation in that assignment; the surrounding rule and methods already provide the rest of the behavior.

Warm up with the starter

Read mkIntroCounter before mkTop. Locate the initial value of count, the condition on step, the assignment in its body, and the two reported values. Then trace one starter cycle by hand:

1. At cycle entry, count is zero.
2. The current right-hand side reads that zero and schedules zero to be written.
3. The clock edge commits the scheduled write, so the next cycle still reads zero.

Before selecting Run, predict that every displayed value remains zero and counting remains true. Run the unchanged starter once and check that prediction.

Repair, then predict again

Change only the existing assignment so a firing schedules the value after the current count. Before running the repaired design, write down this trace:

The expected value path is 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> hold.

Run and interpret

Select Run and compare each line with the prediction. On the cycle that reports four, the assignment's right-hand side reads the old state, four, and schedules five. The register still reads as four during that firing. The clock edge commits the scheduled value, so the next observation reports five. At five, step is no longer ready; no later transition is made, and the value holds.

What grading checks

Grading uses the module's observable behavior:

• value starts at zero and advances by exactly one until it reaches five.
• Later observations continue to report five.
• counting is true with values zero through four and false at five and after.

Progressive hints

Variation: stop at three

After the required repair works, temporarily use three for both the stopping decision and the counting report. Predict 0 -> 1 -> 2 -> 3 -> hold, identify the edge that commits three, and confirm that counting becomes false with that observation. Restore five before submitting the required solution.