Almost everyone learns GPUs top-down — CUDA grids, warps, occupancy — without ever seeing the silicon those abstractions ride on. tiny-gpu inverts that: the whole design fits in under 15 SystemVerilog files, small enough to read end-to-end in an afternoon, yet complete enough to trace one instruction from the dispatcher through an ALU and finally see why SIMD and memory bandwidth dictate the programming model you already use.
What Sets It Apart
- Every stage a real GPU has is present, just shrunk: a device control register, a thread dispatcher, multiple compute cores (each with ALUs, load-store units, register files, and a scheduler), and dedicated program/data memory controllers. Nothing is hand-waved into a black box.
- An 11-instruction ISA runs working matrix add and multiply kernels under simulation, so "threads executing the same instruction over different data" becomes something you watch in an execution trace rather than read about.
- It runs on open tooling (iverilog + cocotb), so stepping through the hardware costs a Python test, not a vendor license or an FPGA board.
- The docs deliberately mark what's left out — caching, pipelining, warp scheduling, memory coalescing — and explain why each matters, pointing toward production hardware instead of pretending to be it.
Who Should Read It
Great fit if you write CUDA or Triton and want a concrete mental model of what runs underneath, or if you're studying computer architecture and want a codebase short enough to hold in your head. Look elsewhere if you need a synthesizable GPU for real silicon: there's no graphics pipeline, no cache hierarchy, and no performance tuning. The design optimizes for legibility over realism, and that trade-off is the entire point.