Turn an equation into a datapath contract

Specify what the circuit promises

A datapath stores, selects, and computes values. Its controller decides which values move and when. These are separate design responsibilities, but they are not independently running software tasks. At a clock edge, control signals decide register updates; those register values become inputs to combinational logic during the following cycle. An equation without this timing contract can produce the right number for the wrong transaction.

Our small calculator accepts unsigned eight-bit operands a and b and a two-bit operation. Operation 0 adds, 1 subtracts, 2 computes AND, and 3 computes XOR. Arithmetic returns the low eight bits, with a separate addition carry or subtraction borrow. Later projects also carry a tag. A tag does not change the calculation, but it identifies the input that produced a result, so it must travel with that result.

For a=250, b=10, and ADD, the mathematical sum is 260. The output is 4 with carry=1. Signed interpretation or saturation would give a different contract. Do not let an accidental language conversion choose the policy. Wrapping arithmetic may suit address counters, while a brightness calculation may require saturation.

An invalid ALU output may still change electrically; it does not represent a transaction. A valid result with an old tag is also incorrect. Inspect data, tag, and valid together. For every output, answer both what the bits mean and when a consumer may trust them. The cycle models here check functionality and ordering, not physical gate delays. Translate the contract into a reference model before choosing register boundaries for a latency or throughput target.