# Phase 0.2 - Block Diagram

## Context

The block diagram is the visual source of truth for the datapath. It should show what
talks to what, what is registered, and what can stall.

## Goals

- Draw fetch, decode, register file, ALU, M unit, memory/LSU, and writeback.
- Label stage-boundary structs from the package.
- Mark clocked state, combinational paths, handshakes, and reset behavior.

## New Concepts

- Datapath: the route operands and results take through the CPU.
- Control path: signals that choose operations, mux inputs, stalls, and traps.
- Mux: hardware selector that chooses one of several inputs.
- Stall: deliberately holding state while waiting for a multi-cycle event.

## How To Think About It

Draw movement of information, not just boxes. A useful hardware diagram answers: where is
state stored, what changes each clock, what can wait, and what happens on an exception?

## Learning Tasks

- Use arrows for data flow and separate arrows for control when helpful.
- Mark every register or memory with a clock edge symbol.
- Identify the longest combinational path you expect in early phases.

## Pitfalls

- Drawing BRAM like a zero-latency array.
- Forgetting that multi-cycle units need explicit state and stall control.
- Hiding reset and trap paths because they are visually inconvenient.

## Tooling And Testing

- Keep the diagram in `Docs/` and update it when interfaces change.
- Compare waveform signal names against the diagram after each integration phase.
- Use the diagram as a checklist when adding ILA probes.

## References

- nand2tetris CPU/data-path intuition: https://www.nand2tetris.org/
- RISC-V reader for datapath examples: http://www.riscvbook.com/
- Vivado ILA overview: https://docs.xilinx.com/