Don't Collect Hardware Bugs. Generate Them.

In the last post I argued that root cause analysis is bottlenecked by data. If you train models to debug Verilog, you know the wall: you need a lot of broken designs, and you need to know exactly why each one is broken. Real bugs with verified root causes are rare, private, and slow to collect. So I don't collect them. I generate them, with a tool called Python2Verilog, or p2v.

It starts with Python, and there is a lot of it

There is a vast amount of Python online: reference implementations of algorithms for machine learning, signal processing, networking, cryptography, and more. p2v describes hardware in Python, so all of that is potential input.

Our agent takes algorithms that already exist online, formalizes them in p2v, and lets p2v take it from there. The supply of starting points is huge, and no one has to write Verilog by hand.

What p2v does

p2v is the tool we use for two jobs: generating many variations of the Verilog for a design, and verifying each one against the Python model that describes it. The flow runs from an algorithm found online to RTL with timing closed:

The p2v flow.

The simulation's test vectors come from the Python model, which also defines which inputs are legal and where the edge cases are. The generated RTL has to match the model bit for bit.

The Python model is the ground truth. The Verilog is judged against it, never against anyone's opinion.

Same logic, many voices

Generated code has a tell: the same shape every time. Anyone who has read machine-written RTL can spot it from across the room.

p2v carries multiple coding styles for each operation, so the same logic can be written the way different engineers would write it. That gives the Verilog the richness of real code, and it matters for debugging models. An agent that only ever sees one style can learn to recognize the style instead of understanding the logic. We design against that.

Real designs, not toy modules

Variety only counts if the designs are realistic. p2v covers what real blocks need:

• Auto-pipeliningPipeline depth is generated, not hand-tuned.
• IEEE floating pointStandard floating-point support.
• Complex numbersComplex arithmetic for DSP and modem-style designs.
• Generic cellsFIFOs, arbiters, shifters, and more.
• Memory generationMemories generated alongside the logic.
• CSR portsRegister interfaces for configuration and status.
• Automatic interface wrappingDesigns wrapped with standard interfaces such as AXI.
• Readable VerilogGenerated in a variety of styles, commented and cleanly indented.

That is how designs for ML accelerators, modems, SmartNICs, and cryptography come out of the same flow.

Every design meets every testbench

Anyone who has built a testbench for a new block knows what it costs. p2v ships with multiple generic testbenches, at three levels:

Any design created in p2v connects to all of them automatically, with no additional manual work. A new design arrives already verified at every level.

Vast, verified, versatile

• Vast.Python algorithms online are the input, so the supply of designs scales without hand-written Verilog.
• Verified.Every design is checked against its Python model, across every testbench.
• Versatile.Many coding styles, a realistic feature set, and designs from many domains, so there is no single pattern to memorize.

Because the designs are generated rather than written, p2v can do one more thing: insert bugs programmatically and label them. The root cause is then known exactly, with no human labeling in the loop.