Datapath and Control Separation

1. Engineering intuition — what moves data vs what decides

Almost every nontrivial design has two kinds of logic tangled together, and separating them is the key to keeping it understandable. One kind carries and crunches data: it is wide (matches the data width), regular, and mostly the same shape regardless of the algorithm — registers, adders, muxes, memory. The other kind makes decisions: it is narrow, irregular, and entirely about sequencing — "now load this, now select that, wait until done." Mixing them produces sprawling processes nobody can follow. Separating them — a datapath of data-movers and a control FSM that drives it — turns the design into "the machinery" and "the operator," each simple on its own. The operator pulls levers (control signals); the machinery reports gauges (status); and you can reason about, reuse, and verify each independently.

2. Formal explanation — the FSMD structure

-- DATAPATH: registers + ALU/mux/mem that move/transform data. Driven by CONTROL, produces STATUS.
process (clk) begin
  if rising_edge(clk) then
    if load_a = '1' then acc <= (others => '0'); end if;          -- control signal 'load_a'
    if en     = '1' then acc <= acc + (x * w); end if;            -- control signal 'en'
  end if;
end process;
zero <= '1' when acc = 0 else '0';                                -- STATUS back to control
done <= '1' when count = N else '0';
 
-- CONTROL: an FSM that SEQUENCES the datapath via control signals and reads STATUS.
process (clk) begin
  if rising_edge(clk) then
    case state is
      when IDLE => if start='1' then load_a<='1'; state<=RUN; end if;
      when RUN  => en<='1'; if done='1' then state<=FIN; end if;  -- reads 'done' status, drives 'en'
      when FIN  => en<='0'; state<=IDLE;
    end case;
  end if;
end process;

The datapath holds data and is driven by control signals (load, en, sel), producing status (zero, done). The control FSM sequences the datapath: it asserts control signals and branches on status. The interface is one-directional each way — control → datapath, status → control — the FSMD pattern.

3. Production usage — one datapath, sequenced by control

-- The split makes each side independently designable, reusable, and verifiable:
--
-- DATAPATH (wide, regular):   registers, MAC/ALU, muxes, memory, counters.
--   • optimized for WIDTH and timing (pipelining, DSP/BRAM mapping, 16.x/17.x).
--   • exposes: control INPUTS (load/en/sel) and status OUTPUTS (zero/done/compare).
--
-- CONTROL (narrow, irregular): an FSM (9.x).
--   • optimized for SEQUENCING/decisions; small, easy to reason about and cover.
--   • drives control signals; branches on status.
--
-- REUSE: same datapath under a different control sequence (e.g. multiply vs MAC vs divide schedule),
--        or the same control template over a different datapath.
-- VERIFY: test the datapath's transforms independently; test the control's sequencing independently.

What hardware does this become? A wide datapath block (the registers/ALU/mux/memory that carry the data) plus a small control FSM wired to it by control and status signals — physically the same gates as a tangled design, but organized. The organization is the value: the datapath optimizes for width and timing (pipeline it, map it to DSP/BRAM) while the control optimizes for clear sequencing; you can reuse one with different versions of the other, and verify each in isolation (does the datapath compute correctly? does the FSM sequence correctly?). This FSMD structure scales from a small multiply-accumulate controller to an entire CPU's datapath-plus-control-unit.

4. Structural interpretation — control FSM and datapath

5. Why this is structural, not timing

Datapath/control separation is an architecture principle — how to partition a design into data-moving and decision-making parts with a directional control/status interface — so the FSMD diagram above is the right picture, not a waveform. It changes no behavior (the same computation results); it changes how the design is organized for clarity, reuse, verification, and timing. The behaviors of the FSM and the datapath registers were covered in Modules 9 and 7; here the substance is the structural split itself, a design-time property rather than a signal trace.

6. Debugging example — tangled control and datapath

Expected: a design that is clear, reusable, and easy to verify and time. Observed: sprawling processes mixing data computation with sequencing, hard to follow, hard to test, with the wide datapath logic and the control decisions on shared critical paths so timing is tangled. Root cause: control and datapath were not separated — selects/enables/loads were computed inline with the data transforms in the same monolithic logic, so no part had a single job, nothing could be reused or verified in isolation, and optimization couldn't treat the wide datapath and the small FSM separately. Fix: split into a datapath (registers/ALU/mux/memory exposing control inputs and status outputs) and a control FSM (drives control signals, branches on status) — the FSMD structure — so each is clear, independently verifiable, reusable, and separately timed. Engineering takeaway: separate what moves data from what decides — a datapath plus a control FSM with a clean control/status interface turns a tangled design into two simple, reusable, independently-verifiable parts.

-- BUG: one monolithic process computes data AND sequencing inline → tangled, unreusable, hard to time.
-- FIX: FSMD — datapath exposes control inputs + status; control FSM drives control, branches on status.
--   datapath:  acc <= acc + x*w when en;   done <= '1' when count=N;
--   control :  case state ... en<='1'; if done then ...   -- sequences the datapath

7. Common mistakes & what to watch for

• Mixing control and datapath. Separate the data-movers from the sequencing FSM; one monolithic process is hard to read, reuse, and verify.
• Bidirectional/muddy interfaces. Keep it directional — control signals out to the datapath, status back to control.
• Putting decisions in the datapath. The datapath transforms data and reports status; sequencing decisions belong in the control FSM.
• Not exploiting reuse. A clean split lets one datapath serve different control sequences (and vice versa); design the interface for that.
• Verifying only the whole. Test the datapath's transforms and the control's sequencing independently for better coverage.

8. Engineering insight & continuity

Datapath/control separation — the FSMD pattern — splits a design into a datapath that moves and transforms data and a control FSM that sequences it, joined by a clean control-out / status-in interface. It buys clarity, reuse, independent verification, and separable timing, and scales from a small controller to a whole CPU. Separating concerns within a block leads naturally to separating concerns across blocks — how to compose many such units into a large design — which is the next lesson, Structuring Large RTL Designs: hierarchy, module boundaries, and interfaces at scale.