dwn2rtl
A tool that turns a trained Differentiable Weightless Neural Network into synthesizable Verilog, generates its test vectors and testbenches, and verifies the result — without a vendor toolchain.
- Period
- Summer 2026
- Role
- 2-person team with Krithik Sama
- Stack
- Python 3.10+ · PyTorch · Verilog · Icarus Verilog · Verilator · yosys
- Source
- Repository Co-authored with Krithik Sama
- 77
- configurations, all matching software
- 166K / 166K
- correct on hardware
- 3 commands
- build · verify · estimate
- MIT
- open source
Why this exists
A Differentiable Weightless Neural Network uses lookup tables as its learned parameters. That means one neuron becomes one LUT6 — the network is logic rather than arithmetic, which makes it an unusually direct fit for an FPGA. No multiplier array, no DSP blocks, no quantization scheme to design around.
The gap is everything between “I trained a DWN in PyTorch” and “it’s running on a board.” That path is normally hand-written Verilog per model, which doesn’t survive contact with a design-space sweep: change the network shape and you write it again, and you re-verify it by hand, and eventually you stop re-verifying it carefully.
dwn2rtl closes that gap as a tool rather than as a one-off script.
What it does
Three commands, with deliberately different dependencies:
| Command | Purpose | Requires |
|---|---|---|
dwn2rtl build model.pt --out rtl/ | Checkpoint → synthesizable Verilog | Python only |
dwn2rtl verify rtl/ | Check the RTL against the model | Icarus or Verilator |
dwn2rtl estimate rtl/ | Per-module resource reporting | yosys (optional) |
No vendor toolchain is required to get from a checkpoint to verified RTL. That was a design goal, not an accident — needing a Vivado license to find out whether generation worked would put the slowest, most restricted tool in the fastest loop.
From a trained checkpoint (model plus thermometer encoder, with optional input scaling), it emits:
dwn_top.v,dwn_core.v,thermometer_encoder.v- Test vectors and expected results as
.hexfiles - Testbenches for verification
- Parameter headers as
.vhfiles
Precision is inferred automatically from the checkpoint rather than passed in, which removes the most likely way to get a silently wrong result: hand-specifying a width that doesn’t match what the model was actually trained at.
The verification argument
The testbench and test vectors are generated alongside the RTL, from the same checkpoint. This is the part I’d defend as the real contribution.
A generator that emits only RTL moves the verification burden onto whoever runs it, once per configuration. At scale that’s exactly where checking quietly stops happening — the tenth config gets less scrutiny than the first, and the seventieth gets none. Generating the testbench with the design means verification isn’t a separate discipline the user has to remember to apply.
Evidence that it holds:
- 77 configurations across two datasets, every one producing identical answers to its software model
- 166,000 / 166,000 and 10,000 / 10,000 correct on real hardware
Full-dataset agreement rather than sampled agreement, on the board rather than only in simulation.
Notes
Open source under MIT, built with Krithik Sama. It implements the DWN formulation from Bacellar et al. (2024) — the training method is theirs; the checkpoint-to-hardware path is ours.
The DWN FPGA study is what this tool was built to make possible: sweeping the accuracy-versus-area trade across dozens of implementations, which is not a thing you do by hand.