49 lines
1.6 KiB
Markdown
49 lines
1.6 KiB
Markdown
# Phase 7.3 - Bus Decoder + MMIO
|
|
|
|
## Context
|
|
|
|
The D-bus now routes requests to either RAM or UART registers. This is the first small
|
|
SoC-style memory map.
|
|
|
|
## Goals
|
|
|
|
- Decode address ranges for RAM and UART.
|
|
- Implement UART TX, RX, and status registers.
|
|
- Preserve the D-bus handshake contract.
|
|
|
|
## New Concepts
|
|
|
|
- Address map: assignment of address ranges to memory or devices.
|
|
- Register side effect: read or write that changes device state.
|
|
- Unmapped access: address with no valid target, later an access fault.
|
|
- Peripheral slave: bus endpoint that responds to device register accesses.
|
|
|
|
## How To Think About It
|
|
|
|
MMIO registers are a hardware/software ABI. Once firmware depends on them, changing
|
|
semantics becomes painful. Document behavior precisely.
|
|
|
|
## Learning Tasks
|
|
|
|
- Write a register table with access type and side effects.
|
|
- Decide read behavior for write-only registers and write behavior for read-only registers.
|
|
- Trace a store to UART TX through the D-bus decoder.
|
|
|
|
## Pitfalls
|
|
|
|
- Having two slaves respond to the same address.
|
|
- Letting no slave respond and hanging the bus forever.
|
|
- Making status bits unclear or inverted relative to software expectations.
|
|
|
|
## Tooling And Testing
|
|
|
|
- Unit-test the decoder separately from UART timing.
|
|
- Use ILA probes on selected slave, request, response, and UART status.
|
|
- Test unmapped access behavior once trap support exists.
|
|
|
|
## References
|
|
|
|
- Memory-mapped I/O overview: https://en.wikipedia.org/wiki/Memory-mapped_I/O
|
|
- RISC-V privileged spec for access faults later: https://riscv.org/technical/specifications/
|
|
- AXI-Lite valid/ready concepts for comparison: https://developer.arm.com/documentation/ihi0022/latest
|