TPE is a small AI accelerator, designed the way a real chip team builds one: hardware description, a C++ reference model, and a verification harness that tries — and catches itself — 7 real bugs on purpose. It multiplies matrices, the operation underneath almost every neural network, using 256 tiny calculators wired together so they all work at once.
Almost everything a neural network does — recognizing an image, predicting the next word — boils down to multiplying big grids of numbers together, over and over. A general-purpose CPU does this one number at a time. TPE does it differently.
Weights are the numbers a trained model learned. Activations are the input flowing through it. Multiplying these two grids of numbers together is the single most repeated operation in AI — this chip exists to do that one operation as fast and efficiently as possible.
Instead of one fast calculator, TPE arranges 256 small ones in a 16×16 grid — a systolic array. Numbers enter from the edges and pass from neighbor to neighbor in lockstep, like a stadium crowd doing a wave, each one doing a tiny multiply-and-add as the wave passes through.
Fetching data from memory is slower and more power-hungry than doing math on it. TPE loads a tile of weights into on-chip memory once, then streams activations through it repeatedly — the same idea real accelerators use to stay fast without burning power shuttling data back and forth.
One command — multiply two matrices and store the result — passes through five stages, always in this order. Read it left to right below, or press play to watch it happen.
↳ Click any card for what it does, or press Animate it to watch the command move.
Click any card above, or press Animate it to see this sequence run.
Writing hardware is easy to get subtly wrong — off-by-one row counts, a bit flipped in the wrong direction, a timing race that only shows up once in a hundred runs. So this project ships with seven real bugs, injected on purpose, and a test suite built specifically to catch every one of them. If the tests ever stopped catching a bug, that itself would be the red flag.
One extra row of the compute grid silently joins the sum when a tile doesn't use the full array.
caught by → random matrix-size testingFeeding a partial result back in picks up the wrong column's carried-over value.
caught by → nonzero accumulator testingA result that overflows negative wraps around instead of saturating, while positive overflow works fine.
caught by → directed overflow testA transfer whose last chunk is exactly one unit long silently never gets written.
caught by → multi-burst boundary testA matmul that exactly fills the compute grid is wrongly flagged as out of range.
caught by → exact-boundary testClearing one interrupt bit accidentally clears an unrelated one alongside it.
caught by → independent-clear testThe performance monitor undercounts every command's latency by exactly one clock cycle.
caught by → hand-derived latency test| Parameter | Value |
|---|---|
| Compute array | 16 × 16 weight-stationary systolic array — 256 INT8 multiply-accumulate units |
| Numeric format | INT8 operands, INT32 accumulator (saturating) |
| Max tile size | 256 × 256 × 256 per matmul instruction |
| On-chip scratchpad | 64 KB (4096 × 128-bit rows), dual-port |
| Host interface | AXI4-Lite MMIO, 16-bit address / 32-bit data |
| Memory interface | AXI4, 128-bit data bus, burst-capable DMA |
| On-chip blocks | Command Processor · Scheduler · DMA Engine · Local SRAM · Matrix Compute Engine · PMU · Debug trace |
| Verification methodology | cocotb + pyuvm (class-based, UVM-equivalent) · SystemVerilog Assertions · line/toggle/branch + functional/FSM coverage |
| Reference model | C++17 golden model, cross-checked against RTL every test |
| License / cost | Fully open-source toolchain — Verilator, Icarus Verilog, GTKWave, cocotb, pyuvm |