Teaching Machines to Read Silicon: An Open, Generated Dataset of SoC RTL
By Hasan Kurşun
The data problem hiding inside chip design
Machine learning is quietly reshaping electronic design automation (EDA). Models now predict a circuit's area, timing, and power before synthesis finishes; they flag routing congestion before a placer runs; they suggest RTL refactors, estimate critical paths from a netlist graph, and explore design spaces that a human would never have time to sweep. The research is exciting, the conference papers are multiplying — and almost all of it is trained on data that you and I will never see.
That is the uncomfortable secret of ML-for-EDA: the field is data-starved at the open level. The datasets that actually matter live inside foundries and EDA vendors, wrapped in NDAs and tied to proprietary PDKs. Academic groups scrape together a few dozen open cores, synthesize them by hand, and call it a benchmark. There is no ImageNet for chips. There is no Common Crawl for RTL. If you want to train a model that reads Verilog and predicts what the gates will do, you mostly have to build your own corpus first — and that corpus is usually small, inconsistent, and impossible for anyone else to reproduce.
This dataset is an attempt to change that, and it starts from a deliberately different premise.
Don't scrape it. Generate it.
The instinct when you need a lot of RTL is to go scraping: crawl GitHub, pull every Verilog file you can find, deduplicate, and hope the distribution is useful. That gives you a pile of files, but it does not give you designs. Most scraped RTL doesn't elaborate, doesn't connect to anything, has no consistent labels, and can't be regenerated or extended. You inherit whatever licenses and quality the internet happened to contain.
So this project takes the opposite approach. Instead of a static scrape, it ships a reproducible generator — whose v1 output is published on the Hugging Face Hub (the generator's source code will be open-sourced on GitHub soon) — a compact library of real, permissively-licensed IP blocks — RISC-V CPU cores, network-on-chip interconnects, cryptographic and DSP accelerators, peripherals, memories — plus a seeded, deterministic engine that wires them into complete, coherent, synthesizable System-on-Chip designs.
The first materialized slice of that generator is v1: 5,000 small SoC designs, every one of them lint-clean, hierarchical, and self-contained. But the number to keep in mind isn't 5,000. It's the property behind it: a given (seed, library snapshot, generator version) regenerates any design bit-for-bit. The dataset is not a frozen artifact you download and hope to understand — it is the output of a process you can rerun, audit, and extend.
That single property changes what the dataset can be.
What a single design looks like
Pick any seed. The generator draws an interconnect fabric, one or more CPU cores, a set of slave IP, and a parameter configuration for each block, then assembles them into a top-level design. Out comes a folder:
soc_2451/
├── rtl/soc_top.v a generated, hierarchical Verilog top
├── src/<mirror>/ a copy of every source file it references (self-contained)
├── filelist.f portable file list, relative paths
└── manifest.json the full label set
The soc_top.v instantiates the CPU(s), the chosen NoC or bus, the network interfaces, address decoders, protocol bridges, and the slaves — all parameterized and connected with a real address map. The src/ tree is a complete copy of every module the design uses, so you can hand a single folder to a tool and it just works; nothing reaches back into a shared pool. And manifest.json is the part an ML practitioner cares about most: it records the exact regeneration command, the library snapshot, the fabric and its randomized parameters, every master and slave with its resolved knobs, the address map, and the bridge insertions. The labels aren't bolted on afterwards — they fall out of the construction.
That's the difference between a folder of Verilog and a dataset.
The library: real IP, not toy RTL
A generator is only as good as the parts it assembles, and a recurring failure of synthetic RTL datasets is that the "IP" is trivial — counters and FIFOs dressed up as a SoC. This library is built from genuine, recognizable, permissively-licensed open hardware.
RISC-V cores span the spectrum. At the small end sits SERV, the award-winning bit-serial RV32I core — arguably the smallest real RISC-V CPU in existence. Alongside it: PicoRV32 (the area-optimized workhorse), darkriscv, lowRISC's Ibex, and OpenHW Group's CV32E40P — five distinct microarchitectures that the generator draws from with roughly equal probability, so the corpus isn't dominated by one CPU's idioms. Pinned for opt-in use (because they're large and slow to process) are heavier cores including Syntacore's SCR1, CHIPS Alliance's VeeR EL2, and T-Head's XuanTie family up to the RV64GC-class C906 — a Linux-capable application core. The SystemVerilog cores are converted to Verilog with sv2v and adapted onto the system bus through purpose-built bridges.
The interconnect is where this dataset gets unusual. Most SoC corpora offer a shared bus and maybe a crossbar. This one ships twenty network-on-chip topologies on a single validated substrate: ring, bidirectional ring, line, 2D mesh, torus, star, binary tree, quad-tree, hypercube, concentrated mesh, fully-connected, butterfly, spidergon, fat-tree (leaf-spine), dragonfly, flattened butterfly, hierarchical ring, king-mesh, chordal-ring — plus a multi-master, flow-controlled mesh with real valid/ready back-pressure and elastic buffering. Each NoC carries AXI4-Lite over separate request and response networks, with shared, topology-agnostic network interfaces and dimension-ordered, deadlock-free routing. Every topology is functionally simulated: a flit is written through the network to a slave and read back, exercising the distinguishing behavior (the diagonal hop of a king-mesh, the up-spine-down of a fat-tree, the intra-global-intra path of a dragonfly). For a model trying to learn how interconnect structure maps to area and latency, that topological diversity is the whole point.
And here is a detail that should make graph-ML researchers sit up: every NoC is a graph. Routers are nodes, links are edges, the routing function is a labeled relation over them. The same generated design that hands a sequence model tens of thousands of lines of Verilog hands a graph neural network a clean, labeled topology graph — twenty distinct graph families, at controllable sizes, with the area and (soon) timing of each one attached. If you work on graph representation learning and you have wanted a hardware-native benchmark that isn't a single hand-drawn mesh, this is built for you.
The accelerators and peripherals fill out the SoC. Real cryptographic cores from the secworks family — AES, the SHA-1/2 hash family, ChaCha, SipHash, BLAKE2s, Poly1305, AES-CMAC — sit next to compute blocks (a multiply-accumulate unit, an FIR filter, an unrolled CORDIC, a radix-2 FFT butterfly, an integer divider and square-root, a GF(2⁸) multiplier, population count, min/max, a comparator sorting network), memory structures (a scratchpad RAM, a content-addressable memory), and a full set of control peripherals (UART, GPIO with edge interrupts, timers, PWM, watchdog, SPI and I²C masters, an interrupt controller, an RTC, a quadrature decoder, PS/2 and 1-Wire). regbus-style IP attaches to any fabric through an automatically inserted protocol bridge, so a crypto core written for a simple register bus can ride an AXI-Lite NoC without anyone hand-wiring an adapter.
The result is that a generated SoC looks like a real SoC — a CPU talking over a real interconnect to a believable mix of accelerators, memories, and I/O — because its parts are real.
Why "generated" beats "scraped"
It is worth being explicit about what reproducible generation buys you, because it is more than convenience.
Labels all the way down. Because the generator chose every component and parameter, it can record them perfectly. There's no need to parse RTL to recover the topology or count the masters — the manifest already knows. When synthesis labels arrive (more on that below), they attach to a design whose entire provenance is already captured.
Controlled diversity. Scraped data gives you whatever distribution the internet had. A generator lets you dial the distribution — more of this topology, fewer of that core, a deliberate spread of sizes. The v1 corpus already exercises all 23 interconnects, all five random-pool CPUs in near-equal proportion, and 28 distinct slave IPs, with an average of ~3.9 slaves per design. None of that is luck; it's a design choice you can change.
Reproducibility and extensibility. A collaborator doesn't download 1.9 GB and trust it — they rerun the generator and get the identical corpus, then widen the seed range to make it bigger. The dataset is a function, and functions compose.
Scale bounded by compute, not by the library. With ~28 slave IPs, a dozen cores, two dozen fabrics, per-IP parameters, and variable sizing, the space of meaningfully distinct synthesizable SoCs runs into the hundreds of thousands before designs start to rhyme. v1 samples 5,000 of them. The ceiling is your synthesis budget, not the generator.
Validation: clean by construction
A dataset of broken RTL is worse than no dataset. Every one of the 5,000 v1 designs passes Verilator's linter — that is the v1 quality gate, and it is 5,000 for 5,000 with zero failures. The interconnect substrate is additionally validated by functional simulation (nineteen testbenches, one per topology family, all passing), and the IP blocks are individually checked through synthesis with Yosys. The generator enforces determinism through sorted iteration everywhere, so "rerun and diff" is a real test, not an aspiration. The corpus is clean not because someone filtered it afterwards, but because it could only be built from parts and rules that were already known-good.
The road ahead: from RTL to netlist to timing to placement
v1 is deliberately a beginning, and it is deliberately RTL-only. The stated north star of the project is netlist and timing prediction, and the honest truth is that those labels come from synthesis and physical design, which are far slower than linting — minutes per design instead of seconds. Rather than hold the corpus hostage to that cost, v1 ships the RTL and its structural labels now, and treats the heavier work as staged processing that follows.
Here is where it goes.
A wider library. The IP set is growing from its v1 size toward roughly 120–150 blocks: more CPU cores (targeting 20–25, including the SpinalHDL and Chisel families as toolchains allow), more NoC topologies, and a much deeper bench of accelerators and peripherals drawn from real upstream projects — the secworks crypto family, Forencich's interconnect and I/O IP, and beyond. Every addition widens the distribution a model gets to learn from. Crucially, more IP doesn't inflate the design count — that's already astronomical — it broadens the kinds of structures the corpus contains, which is what actually helps an ML-for-EDA model generalize.
A size dimension. The generator now draws a small/medium/large size tier, scaling the number of on-chip slaves so designs range from a handful of blocks up to sixteen-plus, across every fabric. Area and timing scale with size; a model that has only ever seen tiny SoCs won't generalize to big ones. Spanning the size axis — and labeling it — is essential.
Netlists. The next subset runs every design through synthesis and ships the gate-level netlist alongside cell counts and module structure. That turns the RTL corpus into something a graph-neural-network can chew on directly, and gives area a hard label.
Timing studies. With an open standard-cell library (Nangate45, Sky130) dropped into a static-timing flow, each netlist gains a critical-path-delay label — the core target of netlist-timing prediction. Suddenly you have paired (RTL, netlist, timing) examples at scale, reproducibly, in the open.
Placement and physical-design studies. Further out, an open place-and-route flow adds floorplan and placement data, plus routability and congestion signals — the labels that physical-design ML actually needs and almost never gets in open form.
The end state is a coherent, fully-open RTL → netlist → timing → placement dataset family with consistent provenance across every release, built on a generator anyone can rerun and extend. That is the thing the field has been missing.
How to use v1 today
The dataset lives at huggingface.co/datasets/hasankursun/soc-builder-rtl-v1. Load the label index and walk the designs:
from datasets import load_dataset
ds = load_dataset("hasankursun/soc-builder-rtl-v1", "designs", split="train")
# each row: seed, fabric/topology, size tier, master/slave counts, the slave IP list, lint_ok
# the RTL + full manifest live in each soc_<seed>/ folder
For RTL-representation learning — tokenizing Verilog, building AST or netlist graphs, pretraining an HDL model, studying how interconnect topology relates to structure — v1 is ready now. As the netlist, timing, and placement subsets land, the same designs gain the labels that turn representation learning into prediction.
Why this matters
The promise of ML-for-EDA is faster, cheaper, more accessible chip design — design-space exploration that doesn't take weeks, timing estimates that don't require a full synthesis run, quality predictions that put a foundry-grade intuition in the hands of a student with a laptop. But that promise runs on data, and right now the data is locked up. An open, reproducible, richly-labeled corpus of real SoC designs — one that spans topologies, cores, sizes, and eventually netlists and timing — is a small piece of infrastructure that a lot of useful work can stand on.
That's what this is meant to be: not a one-off benchmark, but a generator and a growing dataset family that the open community can build with.
Built by, and available for, custom work
I'm Hasan Kurşun. I build large-scale datasets and ML data pipelines — and increasingly, hardware datasets and ML-for-EDA data infrastructure: reproducible RTL/SoC corpora, IP packaging and design-space generation, and synthesis/timing/placement label pipelines.
If your team needs a bespoke hardware dataset — your IP, your PDK or flow, your target labels (netlist, timing, power, routability) — or custom EDA-data / ML consulting, I'd be glad to help.
Available for freelance and contract work on EDA data engineering, RTL/netlist dataset construction, and applied ML for chip design.