Planning a Controller-Plus-Datapath Project Slice

A controller-plus-datapath slice combines two kinds of behavior. The controller watches events and decides when an action should happen. The datapath selects, stores, or transforms the value involved in that action.

Before writing code, state the boundary in plain language, as behavior rather than as circuitry:

• when the controller requests the action, and for how long;
• which value the datapath should hold after a request, and after every other clock edge;
• what reset does, including when reset and a request arrive at the same edge.

How you build each behavior is the design work of the slice, so plan it yourself before choosing any structure.

Test the boundary as well as each block. A useful check proves that the action request appears at the intended moment, the new value is captured on that event and not before it, and the old value is preserved when no event occurs.

A design tradeoff names a choice, the alternative you considered, and what the choice changes. As an example from a different system: a traffic-light controller could give every light phase its own state, or use fewer states plus a counter that times each phase. The first is easier to read against the spec; the second needs fewer states and changes its timing in one place. Explain your own choice the same way, in terms of clarity, reuse, or behavior, rather than claiming one style is always best.