imple
b008b37d49
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.
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
# Phase 0 - Architecture Contract
|
|
|
|
## Context
|
|
|
|
Before writing RTL, define the vocabulary of the CPU: stage boundaries, signal bundles,
|
|
enums, reset behavior, memory map, and debug expectations. This is similar to defining an
|
|
internal kernel ABI before implementing subsystems.
|
|
|
|
## Goals
|
|
|
|
- Establish `rv32_pkg.sv` as the shared contract for the design.
|
|
- Decide what signals cross between fetch, decode, execute, memory, and writeback.
|
|
- Create a block diagram that can guide implementation and later refactors.
|
|
|
|
## New Concepts
|
|
|
|
- RTL: register-transfer level description of hardware behavior.
|
|
- Package: SystemVerilog namespace for shared types, constants, enums, and structs.
|
|
- Struct: named bundle of related signals; useful for stage outputs and bus payloads.
|
|
- Enum: symbolic encoding for choices such as ALU operation or branch type.
|
|
- Combinational logic: output depends only on current inputs.
|
|
- Sequential logic: output/state changes on a clock edge.
|
|
|
|
## How To Think About It
|
|
|
|
You are designing interfaces between hardware blocks, not function signatures. Every
|
|
field becomes wires or registers, so changing it later can ripple through the whole
|
|
datapath. Bias toward clarity and explicitness, not clever compression.
|
|
|
|
## Learning Tasks
|
|
|
|
- Sketch the datapath by hand and label every stage boundary.
|
|
- Write down which signals are data, control, status, or exception metadata.
|
|
- Decide which fields are needed now and which are placeholders for later phases.
|
|
|
|
## Pitfalls
|
|
|
|
- Overfitting the package to Phase 1 and then reworking it repeatedly.
|
|
- Mixing unrelated control signals into loose wires instead of structured bundles.
|
|
- Treating the diagram as disposable; it should be updated as the design changes.
|
|
|
|
## Tooling And Testing
|
|
|
|
- Use the package in the smallest possible test module to confirm Vivado accepts it.
|
|
- Keep package dependencies acyclic; shared types should not import implementation modules.
|
|
- Run syntax checks early, before several modules depend on a broken type.
|
|
|
|
## References
|
|
|
|
- SystemVerilog IEEE overview: https://www.accellera.org/downloads/standards/systemverilog
|
|
- LowRISC style guide: https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md
|
|
- RISC-V specifications: https://riscv.org/technical/specifications/
|
|
|