# Phase 13 - Pipeline

## Context

Pipelining overlaps multiple instructions to improve throughput. This is optional for
the Linux goal but highly educational for computer architecture.

## Goals

- Insert registers between conceptual stages.
- Handle data and control hazards.
- Re-run regression tests after changing timing structure.

## New Concepts

- Pipeline stage: portion of instruction work separated by registers.
- Hazard: situation where overlapping instructions would produce wrong behavior.
- Forwarding: using a result before it reaches the register file.
- Flush: discarding wrong-path instructions.
- Stall: holding one or more stages until a hazard clears.

## How To Think About It

A pipeline is not just adding registers. It changes when values are available and when
instructions retire. Correctness depends on explicit hazard handling.

## Learning Tasks

- Draw instruction timelines for dependent arithmetic operations.
- Identify where branch decisions occur and what must be flushed.
- Decide how multi-cycle M and memory operations interact with the pipeline.

## Pitfalls

- Adding pipeline registers before defining valid/kill/stall behavior.
- Forgetting load-use hazards.
- Letting exceptions retire out of order.

## Tooling And Testing

- Keep a non-pipelined core as a conceptual reference.
- Run compliance tests before and after each pipeline milestone.
- Add trace logging of retired instructions if possible.

## References

- Computer Organization and Design RISC-V edition: https://shop.elsevier.com/books/computer-organization-and-design-risc-v-edition/patterson/978-0-12-820331-6
- Hazard overview: https://en.wikipedia.org/wiki/Hazard_(computer_architecture)
- RISC-V formal interface concepts: https://github.com/SymbioticEDA/riscv-formal