A RISC-V SoC with an INT8 systolic-array accelerator —
cascade-rv32i's 5-stage
RV32IM(+Zicsr) core plus systolic-tile's
8×8 INT8 matmul array, wired together as a memory-mapped accelerator,
integration-verified four independent ways and taken through DFT
(scan-chain insertion + a measured fault-coverage number) on sky130hd.
The RTL-to-GDSII backend flow (synthesis through place-and-route to a
real GDSII, via OpenROAD-flow-scripts) is configured and pre-flight-
checked in syn/sky130/ but not yet run to completion — see
Results below for exact status and syn/sky130/RUNBOOK.md for how to
run it.
Both cores were already independently verified in their own repos. What's new here is the integration — a register-mapped bus adapter, four layers of integration verification, scan-chain DFT, a measured fault-coverage number, and a backend flow configuration (run in progress) — the part of the pipeline neither source repo touches on its own.
The integration is checked four independent ways, not just simulated once and trusted:
- The bus adapter, against the systolic tile's own golden model
(
model/golden.py, reused verbatim) — single-pass and 4-pass K-tiled + ReLU cases, driven through the register interface exactly as a real CPU would. - The full SoC regression — cascade-rv32i's entire existing test suite, directed and random programs alike, co-simulated against its RISC-V ISS — proving the new accelerator decode doesn't disturb the CPU/UART/LED path it sits beside.
- The same regression against a synthesized gate netlist, so the claim survives a synthesiser rewriting the design.
- A hand-computed RISC-V assembly program (
tests/asm/14_accel_smoke.s) that pushes an identity weight matrix through the accelerator via ordinarysw/lwand checks the result equals the input by inspection — proving the real fetch/decode/execute pipeline reaches the accelerator, not just a bus-functional testbench.
Four real integration bugs were found and fixed along the way — a reversed
byte-packing in the register split, a read-triggered hazard interacting with
the core's halt logic, and two deadlocks (one in test stimulus, one a genuine
host/FIFO backpressure constraint any firmware driving this accelerator has
to respect). All four are documented at the point they were fixed, in
docs/architecture.md and in the RTL itself.
tb_tile_mmio : PASS (basic 4/4, multi-pass 16/16, cosim vs golden.py)
full regression : 15/15 directed + 53/53 random, cosim-matched
gate-level regr. : 18/18 cosim-matched (post-synthesis netlist)
14_accel_smoke : PASS (real RISC-V program, real pipeline)
scan chain (1847 flops) : PASS (1911-bit shift, negative control confirmed
a broken chain fails this test)
fault coverage : 33.3% (10/30), 15 sampled sites / 18,215 candidates
-- 3-test fast subset, NOT the full regression;
see docs/architecture.md for what this number
does and doesn't claim
RTL to GDSII flow (ORFS) : config written and pre-flight-checked
(syn/sky130/), not yet run to completion --
see docs/architecture.md for status and
syn/sky130/RUNBOOK.md for exact commands
PPA / power / DRC-LVS : not yet run
See docs/architecture.md for the block diagram,
address map, register map, the dmem_re hazard fix explained in full, and
what was deliberately left out of scope.
rtl/ cascade_core.v (cascade-rv32i, one hazard fix) + tile_mmio.v
(new) + systolic_tile.sv and its submodules (systolic-tile,
unmodified)
tb/ tile_mmio unit test + both source repos' unit testbenches
tests/asm/ cascade-rv32i's directed test suite + 14_accel_smoke.s
tools/ assembler, ISS, mutation tester, regression driver
(cascade-rv32i, unmodified)
model/ golden.py (systolic-tile, unmodified) + gen_case.py (new,
generates tile_mmio's integration test vectors)
dft/ scan insertion, scan-chain shift test, fault coverage
(all new)
syn/yosys/ technology-independent synthesis (Yosys, generic gates)
syn/sky130/ ORFS backend flow config -- synthesis through GDSII on
sky130hd (config.mk, constraint.sdc, RUNBOOK.md)
docs/ architecture.md
MIT licensed, same as both source repos.