Schedule shared resources with an FSM

Control state expresses an operation schedule

A shared resource requires operations to be scheduled over time. Consider summing x0 through x3 with one adder and a ten-bit accumulator. Capture all four operands when a request is accepted. Later external changes must not alter an outstanding request. The controller selects an operand, enables accumulation, and decides when the result becomes valid.

Use states IDLE, ADD0, ADD1, ADD2, ADD3, and DONE. The acceptance edge in IDLE captures inputs and clears acc. The next four edges add one stored operand each. Immediately after the ADD3 edge, the final sum is stored and state becomes DONE. DONE holds the result until the consumer accepts it. This simple version returns to IDLE at that edge and does not simultaneously accept a new request.

Distinguish becoming available after edge 4 from transferring at edge 5. Consumer stalls can extend DONE indefinitely. Resource reuse reduces arithmetic hardware, but limits throughput compared with a pipeline accepting every cycle. Supporting simultaneous completion and a new request requires an explicit priority between old-result delivery and new-request initialization.

Derive controls from state: accumulator enable in ADD states, an operand selection matching the state, and result valid in DONE. Give combinational control outputs defaults. Define acceptance so a continuously asserted request does not repeat accidentally. Reset returns to IDLE and discards outstanding work. A counter-based implementation can reduce the state encoding, but still needs the same edge-by-edge schedule.