Preview · 6 models validated: YOLOv5n → YOLO26n

ONNX in.
GDSII out.

A compiler that takes a trained YOLO model and produces a chip layout in days — not years.

Try the demo →
Graph
RTL
module top( input clk, input [7:0] d, always @(posedge clk) q <= d;
Netlist
Layout
GDS

Every stage above runs on real, open tools — Yosys, OpenROAD, KLayout, Sky130 — not a rendering or a simulation of what a chip might look like.

We show the whole pipeline, including what isn't done yet.

Most of this industry oversells. Here's exactly what's validated today, pulled straight from the repo's own status checks.

status.log
compileONNX → RTLPASS6/6 models: v5n/v5nu/v10n/v11n/v12n/v26n
numerical check640×640 HW vs softwarePASSbit-exact, all models
synth smokeYosys coarse synthesisPASSstructural checks + stats
temporal GDSshared-engine M4PASS~174k cells, real GDS at 20 ns
timing closuretemporal engine, 20 nsPASSpositive WNS on 5/6 models
mapped PnRreduced real gate netlistPASSfinite setup/hold slack, all models
signoff routedetailed route, light presetPASSDRC clean, GDS emitted
spatial PnRfull per-layer designIN PROGRESS~4M cells, OOM on Yosys (temporal path preferred)
tape-outMPW submissionTARGETmid 2027

The model becomes the chip.

Two ways your trained weights end up on silicon, chosen automatically per layer.

Activations

SRAM macro

Live activations and line buffers live in a prebuilt Sky130 SRAM macro, banked and tiled to the required word width. Read/write, like memory should be.

Weights

Compiled ROM

case(addr) 8'h3F: w <= ...;

Trained weights compile directly into synthesized case logic that Yosys maps onto standard cells — no SRAM, no weight-load path. No weights to load, because the weights are the wires.

Hardware blocks the compiler builds.

Every YOLO model decomposes into a known set of hardware primitives. The Filosic compiler instantiates, sizes, and connects them automatically.

01

Convolution engine

Systolic MAC array with parameterized kernel size, stride, and channel count. Line buffers feed input windows; accumulator tree produces each output pixel. Supported: conv1d, conv2d, grouped conv.

02

Pooling unit

Configurable MaxPool and AveragePool with kernel and stride parameters. Shared datapath selected by a mode flag so only one pool unit is instantiated per model.

03

Activation engine

ReLU, LeakyReLU, SiLU, Sigmoid — implemented as piecewise-linear approximations or direct lookup. Fused into the convolution pipeline to avoid intermediate memory round-trips.

04

Upsample unit

Nearest-neighbor and bilinear upsampling with configurable scale factor. Bilinear uses a sequential divider and registered beat counters to keep area small.

05

Detection head

YOLOv5-style (Conv + FC layers) and YOLOv8-style (split TaskDecouple) heads both supported. The compiler detects the head pattern from the ONNX graph and maps it to the correct hardware template.

06

Temporal shared engine

Time-multiplexed backend (M4) that runs the whole model through one shared copy of each compute unit. ~174k cells vs ~4M for the spatial design — the path that makes full-model GDS practical.

07

Pipeline controller

Sequencer, address generator, and handshake logic that orchestrates data movement between modules. Generated per-model; no microcode, no firmware.

Full support

YOLOv5 / v8

v5n, v5nu, v8n, v8s, v8m — compile, close timing, DRC-clean GDSII

Full support

YOLOv10n

Validated end-to-end. Hardware boundary at detect-merge output; later ONNX postprocess is software cutoff.

Full support

YOLO11n / 12n

Compiled, timed at 20 ns (yolo11n) and 21 ns (yolo12n), GDS emitted

Full support

YOLO26n

Validated to detect-merge boundary. ~440k cells, 20 ns timing closed

On roadmap

Custom models

General ONNX graph compiler in design — not limited to YOLO families

100 ns to 20 ns, one pipelining pass at a time.

100ns 60ns 20ns 50 MHz, closed

Sequential divider in the DFL stage, replacing a combinational variable division that was setting the critical path.

Registered beat counters in the upsample unit, breaking a long comparison chain into pipelined stages.

Running max in DFL instead of a wide combinational reduction tree.

Result: temporal engine closes timing at 20 ns. 5/6 models show positive setup and hold WNS.

Model Period Setup WNS Hold WNS Cells Status
YOLOv8n20 ns+0.86 ns+0.35 ns162kPASS
YOLOv5nu20 ns+1.03 ns+0.35 ns151kPASS
YOLO11n20 ns+2.41 ns+0.35 ns437kPASS
YOLO12n21 ns+0.33 ns+0.35 ns615kPASS
YOLO26n20 ns+1.77 ns+0.35 ns440kPASS
YOLOv10n20 ns*893kOOM†

* Closes at 20 ns once timing is repaired, but Yosys produces ~893k cells due to a large-kernel depthwise layer. † Fix is moving input_buf to SRAM macro — tape-out roadmap item.

Dual-PDK support: temporal engine runs on both Sky130 (130 nm, real foundry) and FreePDK45 / Nangate45 (45 nm, ~8× denser, whole model fits at ~28 mm²). See docs →

Two ways in, depending on your volume.

for scale

Bring your own model

Compiler-as-a-service. Upload a supported YOLO-family ONNX model, get back synthesizable RTL and a GDSII layout validated bit-exact against your original weights — on the Sky130 open PDK for testing and evaluation.

Talk to us about integration →
for robotics

Pick from the catalog

A standardized chip catalog for lower-volume customers — pre-validated model + package combinations on Sky130 for testing and evaluation.

See what's in the catalog →
Built on the open EDA stack
YosysOpenROADKLayoutMagicSky130FreePDK45ngspice