Add phase-by-phase tutorial notes

Add a Tutorial tree that mirrors the roadmap from Phase 0 through Linux bring-up.
Each phase and subphase gets a short learning note with consistent sections for
context, goals, new concepts, mental model, learning tasks, pitfalls, tooling,
testing, and references.

The tutorial material is intentionally explanatory rather than implementation
code. It gives a systems-oriented learner enough FPGA, SystemVerilog, RISC-V,
firmware, and Linux bring-up context to approach each roadmap phase without
turning the notes into copy-paste RTL.

Tutorial/phase-04-first-cpu/phase-04-01-fetch-datapath-integration.md

@@ -0,0 +1,49 @@
+# Phase 4.1 - Fetch + Datapath Integration
+
+## Context
+
+This subphase builds the first CPU loop: fetch an instruction, decode it, execute it,
+write back a result, and advance PC.
+
+## Goals
+
+- Integrate instruction BRAM at `0x2000_0000`.
+- Execute straight-line arithmetic and M-extension operations.
+- Learn stall control around BRAM and the M unit.
+
+## New Concepts
+
+- Reset PC: address where execution begins after reset.
+- FSM state: named control state such as fetch, execute, wait, writeback.
+- Instruction retirement: point where an instruction's architectural effects are complete.
+- Stall: holding PC/state while waiting for a dependency.
+
+## How To Think About It
+
+The CPU is a protocol participant with its memories and M unit. Correct sequencing matters
+more than minimizing cycles.
+
+## Learning Tasks
+
+- Write a cycle-by-cycle timeline for a simple `addi` instruction.
+- Write a cycle-by-cycle timeline for a multiply/divide instruction.
+- Decide what happens on illegal instruction before Phase 9 traps exist.
+
+## Pitfalls
+
+- Double-executing an instruction because PC or state advances at the wrong time.
+- Starting the M unit repeatedly while waiting for it to finish.
+- Losing the destination register number while a multi-cycle op is in flight.
+
+## Tooling And Testing
+
+- Use a testbench that stops after a fixed halt condition or maximum cycle count.
+- Compare final register state and intermediate writeback events.
+- Inspect PC, instruction, state, register write enable, and writeback data in waveforms.
+
+## References
+
+- RISC-V unprivileged ISA: https://riscv.org/technical/specifications/
+- Vivado simulation documentation: https://docs.xilinx.com/
+- Project F memory initialization: https://projectf.io/posts/initialize-memory-in-verilog/
+

Tutorial/phase-04-first-cpu/phase-04-02-ila-verification.md

@@ -0,0 +1,49 @@
+# Phase 4.2 - ILA Verification On FPGA
+
+## Context
+
+ILA lets you capture internal FPGA signals during real hardware execution. This is the
+first serious hardware-debug milestone for the integrated CPU.
+
+## Goals
+
+- Learn how to select useful ILA probes.
+- Capture PC, instruction, writeback, and state transitions.
+- Compare hardware behavior to simulation.
+
+## New Concepts
+
+- ILA: Integrated Logic Analyzer, on-chip waveform capture over JTAG.
+- Trigger: condition that starts or centers a capture.
+- Sample depth: number of cycles stored in on-chip debug memory.
+- Probe preservation: keeping signals from being optimized away.
+
+## How To Think About It
+
+ILA is an oscilloscope for internal logic. Use it to answer a specific question, not to
+record everything. Every extra probe has cost.
+
+## Learning Tasks
+
+- Choose a trigger such as PC reaching the last instruction.
+- Decide which signals prove correct instruction retirement.
+- Compare one hardware trace with the simulator trace for the same program.
+
+## Pitfalls
+
+- Capturing too few cycles before/after the trigger.
+- Debugging a different bitstream than the source you are reading.
+- Assuming ILA changes nothing; debug IP consumes resources and can affect timing.
+
+## Tooling And Testing
+
+- Archive the program image, bitstream, and source commit used for hardware tests.
+- Use `dont_touch` sparingly and only on debug-critical nets.
+- Check timing again after inserting ILA.
+
+## References
+
+- Vivado ILA documentation: https://docs.xilinx.com/
+- Digilent Arty A7 reference: https://digilent.com/reference/programmable-logic/arty-a7/reference-manual
+- AMD/Xilinx debug methodology: https://docs.xilinx.com/
+

Tutorial/phase-04-first-cpu/phase-04.md

@@ -0,0 +1,49 @@
+# Phase 4 - First CPU
+
+## Context
+
+This phase connects fetch, decode, arithmetic, register-file, and writeback into a minimal
+non-pipelined CPU. It executes straight-line arithmetic programs from instruction BRAM.
+
+## Goals
+
+- Build the first integrated datapath.
+- Learn how BRAM latency shapes control flow.
+- Verify architectural state changes instruction by instruction.
+
+## New Concepts
+
+- BRAM: block RAM, dedicated on-chip FPGA memory with synchronous access.
+- PC: program counter, the address of the current or next instruction.
+- Writeback: stage where a result is committed to the register file.
+- CPI: cycles per instruction.
+
+## How To Think About It
+
+This is not a performance exercise. It is an integration exercise. The goal is to make
+one instruction at a time retire correctly while respecting real memory latency.
+
+## Learning Tasks
+
+- Draw the fetch/execute FSM.
+- Decide exactly when PC advances.
+- Trace a short program and record expected register state after each instruction.
+
+## Pitfalls
+
+- Treating BRAM like a combinational array.
+- Updating PC while a multi-cycle M operation is still in progress.
+- Writing back results for instructions that should not write a register.
+
+## Tooling And Testing
+
+- Start with very small programs and known final register values.
+- Use simulation waveforms before ILA.
+- Add a visible "halt" or terminal condition for test programs.
+
+## References
+
+- AMD/Xilinx block memory documentation: https://docs.xilinx.com/
+- RISC-V unprivileged ISA: https://riscv.org/technical/specifications/
+- Digital design FSM overview: https://www.chipverify.com/verilog/verilog-fsm
+