Files

50 lines
1.7 KiB
Markdown

# 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/