AI models that write and debug Verilog are only as good as the data they learn from. That data has three problems: there isn’t much of it, its quality is inconsistent, and much of it carries licenses that make training on it risky. For debugging, there is a fourth problem. Almost no hardware code comes with a known-correct reference, so when a model learns from a broken design, nobody can say with certainty what the bug was or where it started.
Today we’re releasing a first look at what we’ve been building for the past year: p2v-training-batch-01, a family of chip designs generated specifically for LLM training and benchmarking.
What we built
Every design starts life in Python, not Verilog. For each design we write a golden model: a Python description of what the hardware must compute. It has two parts:
Reference function
Says what the right answer is.
Bit-accurate function
Says exactly what the hardware must produce, down to the last bit and including every rounding step.
Our proprietary P2V compiler then turns that model into Verilog. For each design it also generates a testbench that checks the hardware bit for bit against the golden model.
Every design in the batch takes this path.
This batch is the first public result of that pipeline. It will be the foundation of our upcoming LLM training set and RCA (root-cause analysis) benchmark.
Correct by construction
“Correct by construction” means we don’t write RTL and then hope to verify it. The design is derived from a model whose behavior is already pinned down, and then checked against it automatically.
Where it matters, we also keep the two halves of the golden model independent:
Reference model
Computes the result the way it’s defined on paper.
Hardware model
Computes it the way a real circuit does, step by step.
If a mistake slips in, it would have to appear in two very different algorithms and produce the same wrong answer in both. That is very unlikely.
Inject a fault into a clean baseline and the root cause is known, not guessed.
Why does this matter for training? Because a design that is correct by construction is a clean baseline. That is what a root-cause-analysis dataset needs: a golden design, a buggy variant, and a label that says what changed and where.
Variations: one design, many ways to build it
A model that sees one implementation of a design learns that implementation. A model that sees many learns the design. So each design in the batch comes in variations along four axes.
Architecture
The same function, built differently:
- a function can be computed directly or read from a lookup table;
- a block can be tuned for area or for performance;
- a block can process more or fewer elements per clock, which changes its critical path;
- tables and buffers can have different sizes and organizations;
- arithmetic units can fuse their rounding or round each step separately.
Data type
p2v supports all IEEE floating-point formats and complex numbers, alongside integer types with wider accumulators and the conversion steps that go with them. Number formats are where hardware and software most often disagree, so the numerics are part of the benchmark, not an afterthought.
Interface
Each design can come as a bare interface, wrapped in AXI, or driven through DMA control. Real bugs often live at the boundary, in alignment, bursts and handshakes, so models should see designs both with and without that surrounding machinery.
Code style
We deliberately vary the syntax and structure of the generated Verilog, so the code reads like it came from many different engineers rather than one tool. A model trained on uniform, machine-looking output learns to expect that pattern and struggles with real-world code.
Why these designs, and why not random ones
You could build a training set from random logic, but you would learn mostly how to read random logic. We chose the families in this batch the way you would choose a curriculum: each one teaches a different engineering problem, and together they cover a wide range of what chip designers actually face.
- AI computeRegular dataflow, utilization, quantization and number formats.
- Signal processingRecursion, data reordering, constant tables and the storage cost of rearranging data.
- Cryptography and bit-level algebraWide state, iterated rounds, the area-versus-speed trade-offs of building one round and reusing it, and serial versus parallel structure.
- NetworkingHashing, parallel comparison, stateful tables and what happens when a table overflows.
- Data movementBursts, alignment, interrupts and the protocols that connect blocks.
- PrimitivesSmall enough to show a loop-carried dependency and how it sets the critical path.
Taken together, these families exercise timing, area, throughput, numerics, protocols and state. A model that has to diagnose failures across all of them can’t get by on pattern-matching one kind of circuit.
See them move
Reading about a microarchitecture is not the same as watching one work. We built an interactive design explorer for this batch. Each design has an animated microarchitecture view that shows how data moves through it, alongside review notes on what an engineer would look at, such as critical paths, storage costs and where the model and the hardware need care.
Open the design explorer →What’s next
This batch is the first look, not the finish line. We’re building a full LLM training set and an RCA benchmark on top of it, with golden and buggy variants of every design, annotated with what changed and why.
If you’re training or evaluating hardware-design models and want to know more, get in touch.