19Implementation

Swap two registers atomically

Problem

mkAtomicUpdate owns two four-bit registers. Calling start must cause the update rule to exchange their current values exactly once. The starter's two assignments write each register back to itself, so the public run leaves the initial pair unchanged instead of swapping it.

Edit only the two assignments marked by the TODO. Keep the interface, readiness conditions, started protocol, and surrounding test module intact. The solution must work for values supplied through load, not only for the visible initial pair.

Read the starter first

Follow the state in this order:

Read AtomicPair to identify the operations a caller can perform and the two values it can observe.
In mkAtomicUpdate, find the registers that hold the pair and the Boolean that enables update.
Read load and start to see why neither operation is ready while an update is pending.
Finish at mkTop: beginUpdate requests one update, while show waits several cycles before observing the pair.

Before editing, predict the public run. start changes only started at its edge. On the following cycle, update reads the pair but the placeholder assignments preserve both values. Later cycles continue to expose that same unchanged pair.

Make the minimum correction

Change the source of each next-state value, not the protocol around the rule. Both right-hand sides are evaluated from the same rule-entry state, so no temporary register, extra phase, or assignment ordering is required. Your reasoning should identify which old register value belongs at each destination.

Use Run after the edit and check the complete transition rather than only the last line:

Observation point	Required behavior
Before `start` commits	The loaded pair is present and stable.
Entry to `update`	Both registers still contain the pre-swap pair.
Edge that completes `update`	Both replacement values commit together and `started` clears.
Later cycles	The exchanged pair remains stable; no second swap occurs.

Completion means every four-bit pair follows this sequence, including equal values and boundary values. A final display that happens to match one sample is not enough if the design swaps early, changes only one side, or swaps again.

Progressive hints

Hint 1 — state model

Treat one rule execution as a function from one entry state to one next state. List the old pair before writing either right-hand side.

Hint 2 — narrow the edit

Only the two self-assignments under the TODO violate the contract. The started <= False assignment already makes the operation occur once.

Hint 3 — map sources to destinations

Each destination needs the value owned by the other register at rule entry. Use each register read once; do not add sequential control to imitate a software swap.

Transfer experiment

After the required edit works, try an equal pair and then a boundary pair such as zero and the largest four-bit value. Predict why the first case cannot visually reveal a swap by values alone, while the second makes a one-sided or same-source update obvious. This experiment is not part of grading.