Agents + verifiers

Design
hardware.
Prove it.

Chips, boards and physical parts, checked by verifiers the model cannot argue with.

3.86×
best Silicon speedup, run r_w1_final: 63 / 93
candidate CPUs rejected by the ladder: 8 / 8
catalogued board faults detected

ss_insn_dot4.v 5 of 6 rungs pass

module ss_insn_dot4 (
    input  wire [31:0] rs1,
    input  wire [31:0] rs2,
    output wire [31:0] rd
);
    wire signed [7:0] a0 = rs1[ 7: 0];
    wire signed [7:0] a1 = rs1[15: 8];
    wire signed [7:0] a2 = rs1[23:16];
    wire signed [7:0] a3 = rs1[31:24];
    wire signed [7:0] b0 = rs2[ 7: 0];
    wire signed [7:0] b1 = rs2[15: 8];

Board check

fault_gpio12_vs_gpio14

B1B2B3B4B5

4 of 5 pass. Firmware and netlist disagree on a pin.

Matter · heat spreader

72.56 °C, baseline 72.82 °C

Scroll to explore

The problem

Models state hardware facts with confidence.

Confident is not correct. These are the real numbers from our runs.

63 Candidates rejected

of 93 proposed CPUs never made it past the ladder.

56 Failed a hard check

candidates broke a compile, test or proof stage.

3 Board drafts judged

before one passed all five rungs. The first ones did not.

+0.26 Kelvin of real gain

best margin over the baseline. Small wins, said plainly.

The solution

Meet Hardwright

Agents propose. Verifiers decide. Same question, two answers.

SiliconBoardMatter

Hardwright · BoardRecorded session

My ESP32 battery sensor board (BME280 on I2C, USB-C charging, 3.3 V LDO) has the wake button on GPIO12 in the firmware pin header, but the netlist wires it to GPIO14 (template fault_gpio12_vs_gpio14). Is this board OK to send to fab?

Verified agent · nemotron-super

We need to check using board_check with template fault_gpio12_vs_gpio14. Let's call board_check.

board_check{"template_id":"fault_gpio12_vs_gpio14"}

fault_gpio12_vs_gpio14: 4 of 5 rungs pass; unknown or failing rungs do not count

The board fails rung B4 because the wake button is wired to GPIO14 while firmware expects GPIO12, a boot‑strapping pin. This mismatch means the board is not OK to send to fab as‑is. Evidence: board:fault_gpio12_vs_gpio14#B4.

Evidence · fault_gpio12_vs_gpio14

B1B2B3B4B5

Rungs passing4 of 5

Failing rungB4

Tool calls1

board:fault_gpio12_vs_gpio14#B4

Netlist-level check against author-curated part facts. It does not claim the board works on a bench.

Both answers were recorded on 2026-10-23 from Nemotron through Nebius Token Factory. The chat answer used no tools and costs $0.0011.

Explore a real board

Every part, and why it is there

This is a board Hardwright placed, routed and checked with KiCad. Pick a part.

Loading the routed board…

U1 · R3

ESP32 module, the brain

Runs the firmware and talks to the sensor over I²C. A pull-up resistor holds its enable pin high so it runs. Its GPIO12 is a boot-strapping pin: its level at reset picks the boot mode, which is why a button wired there is a classic mistake the checks catch.

Part names marked placeholder in the parts list are stand-ins for real parts. Open the Board workbench to make one for your own design.

See it in action

Watch the agent use the tools

Real sessions, replayed. Press Play.

Recorded sessionnemotron-super · 2026-10-23

Press Play to replay “Board: a clean design”.

The events are the saved stream from the live agent. Only the playback speed is set for reading.

See the difference

The same board question, answered by a chatbot and by the agent with its tools.

After

Verified answer

1 tool call1 evidence idB4 fails

Before

Chatbot answer

No — this board is not safe to send to fabrication as-is. You have a pin assignment mismatch between your firmware and hardware: - ✅ Firmware expects: Wake button connected to GPIO12 - ❌ Hardware actually wired: Wake button connected to GPIO14 This is a critical functional error. The wake-up functionality will not work, because: - The ESP32’s deep-sleep wake-from-pin feature requires the correct GPIO to be configured for external wakeup. - If you configure esp_sleep_enable_ext0_wakeup(GPIO_NUM_12, ...) or similar in firmware, but the physical button is tied to GPIO14 → pressing the button does nothing during sleep. - Conversely, if you accidentally leave GPIO12 floating or misconfigured, you risk unintended behavior (e.g., spurious wakeups, floating input noise). ### Why This Matters: The ESP32’s RTC GPIO pins (which support wake from deep sleep) include both GPIO12 and GPIO14 — so *technically*, either could work *if* the firmware matched the hardware. But since they don’t match, your wake button is effectively broken. ### Options to Fix Before Fab: #### ✅ Option 1: Change Firmware to Match Hardware (Recommended if easy) If modifying firmware is trivial (and you control the source): ``cpp // Change this: // esp_sleep_enable_ext0_wakeup(GPIO_NUM_12, 1); // To this: esp_sleep_enable_ext0_wakeup(GPIO_NUM_14, 1);`Then recompile and flash. → **Board is fab-ready.** No hardware change needed. #### ✅ Option 2: **Change Hardware to Match Firmware (Recommended if firmware is locked)** If firmware cannot be changed (e.g., OTA-locked, third-party binary, or team policy): - **Rewire the wake button net** from GPIO14 → GPIO12 on the PCB. - Ensure GPIO12 is not used elsewhere conflictingly (check your netlist for other uses of GPIO12). - Add a pull-up/pull-down resistor if needed (typically 10kΩ to 3.3V for active-low button, unless internal pullup is enabled in firmware). - Verify GPIO12 is not strapped during boot (see below). #### ⚠️ Critical: Check GPIO12 Boot Strapping! On ESP32, **GPIO12 has a boot strapping function**: - It determines whether the flash voltage is 1.8V or 3.3V **at power-on reset**. - If GPIO12 is held **low** during boot → ESP32 expects 1.8V flash. - If held **high** or floating → expects 3.3V flash. ✅ **Your board uses a 3.3V LDO** → so you **must** ensure GPIO12 is **not pulled low** during boot. If you move the wake button to GPIO12: - Use a **normally open (NO) momentary pushbutton** to GPIO12 → when pressed, it pulls GPIO12 low. - **Problem**: If the button is pressed *during power-on*, it could accidentally trigger 1.8V flash mode → boot failure. - **Solution**: - Add a **10kΩ pull-up resistor** from GPIO12 to 3.3V (so it defaults high at boot). - The button then pulls it low only when pressed → safe for boot, and still wakes from deep sleep (since ESP32 can wake on low level even with pullup — just configure wakeup onLOW`). > 💡 Best practice: Use GPIO12 for wake button only if you add a 10kΩ pull-up to 3.3V and use a normally open button. Avoid using GPIO12 for anything else that might drive it low at boot. ### Final Recommendation: | Scenario | Action | |---------|--------| | You can modify firmware | ✅ Change firmware to use GPIO14 → Send to fab | | Firmware is fixed / cannot change | ✅ Rewire hardware: move button to GPIO12 + add 10kΩ pull-up → Send to fab | | You do nothing | ❌ Do NOT send to fab — wake button will not work | ### Bonus: Double-Check Your Netlist Before sending to fab, run a DRC (Design Rule Check) and specifically verify: - GPIO12: connected only to wake button + 10kΩ pull-up to 3.3V (no other drivers!) - GPIO14: connected only to wake button (if you kept original) or now free (if moved) - No shorts, no floating pins (except intentional NCs) - LDO output stable, USB-C charging circuit intact ### Conclusion: Do not send to fab until the mismatch is resolved. Fix either firmware or hardware — but not both mismatched. Once aligned, and with proper boot-strapping consideration for GPIO12, your board will be safe and functional. If you tell me whether you can change the firmware, I’ll give you the exact code snippet or schematic edit to make. Otherwise, assume you must rewire to GPIO12 with a pull-up.

0 checks run0 evidence ids709 words

Drag the divider or use the arrow keys. Recorded session, nemotron-3-super-120b-a12b, 2026-10-23. The chatbot answer is unverified and costs $0.0011.

What is real

Play the Bench

Games run on the real engines.

Open the app

Board and Matter checks are free.

Ask the agent

Runs on demo credits.

Reproduce a proof

Run it yourself with the CLI.

siliconsmith verify-entry dot4-tinymaix

Honest limits: Silicon search runs are replays of real runs, Board checks are netlist-level, and Matter gains are small.

Capabilities

Everything you need to trust a design

Verification ladders

Cheap checks first, strict ones last. Unknown never counts as pass.

Silicon runs L1 to L6, Board B1 to B5, Matter M1 to M5. A skipped rung is shown as skipped.

Custom RISC-V instructions

The agent invents an instruction for your hot loop and builds the CPU.

Best recorded: 3.86× wall-clock in run r_w1_final, dot4.

Formal equivalence

A solver proves the RTL equals its spec for every input.

A Yosys SAT miter checks every input of a stored instruction against an independent spec.

Board vs firmware

Pins, voltages, buses and strapping pins checked against part facts.

8 of 8 catalogued faults are detected, plus 3 structural ones. Netlist level only: no layout, no EMC.

Heat on a validated solver

A spreader is simulated, then confirmed by a second solver.

Agent beat the equal-material baseline in 3 of 3 runs. Solver validation: PASS.

Nemotron, and only Nemotron

Ultra, Super and Nano each get the job they fit.

The recorded runs made 406 model calls across 3 Nemotron tiers on Nebius Token Factory.

Isolated sandboxes

Every candidate is built and tested in its own workspace.

93 candidates were each built apart, so one bad draft cannot touch another.

Evidence on every claim

Rule, source and what is not claimed, one click away.

A personal library of verified instructions backs this: 3 entries, each with a reproduce command.

Artifacts you can use

Verilog, a KiCad netlist, a pin header, an STL, a pull request.

Exports are written only for a passing design.

The pipeline

From a sentence to a proven part

Tap a stage. The numbers are from the recorded runs.

Ladder. 63 were rejected, 30 survived. Board and Matter have their own ladders.

93candidates proposed

63rejected

30survived the ladder

Interactive

The Bench

Five short games with the real thing behind them. Guess first, then watch the deterministic verifiers decide.

Five compact reps
Real engines and real runs, no mock data
Explanation first
Mouse, touch and keyboard

Active mode · Silicon

Which custom instruction wins?

Recorded run, real data

Loading the recorded run r_w1_contree3

How it works

Five steps. No trust required.

Brief
Say what you want: a faster loop, a board that boots, a plate that runs cooler.
SiliconBoardMatter
Propose
Nemotron agents draft designs. Many of them are wrong, and that is expected.
Nemotron ultraNemotron superNemotron nano
Verify
Deterministic checkers judge every draft, cheap checks first.
Silicon L1 to L6Board B1 to B5Matter M1 to M5
Evidence
Each pass or fail carries the rule, the source and what is not claimed.
board:fault_gpio12_vs_gpio14#B4
Export
Keep what survived: RTL, netlist, pin header, STL, a pull request.
RTLKiCad netlistSTLPull request

System architecture

Not just a stack. A proof engine in layers.

Every layer has one job: keep the model honest.

Layer 01

Interface: The workstation

Workbenches, canvas and agent in one window.

Next.jsReactTypeScriptVercel

Layer 02

Agents: Nemotron on Token Factory

Ultra architects, Super builds, Nano triages.

Nemotron UltraNemotron SuperNemotron NanoNebius Token Factory

Layer 03

Verifiers: Checkers the model cannot argue with

Plain deterministic code decides what is true.

VerilatorYosysSymbiYosysSciPyFEM solverBoard rules

Layer 04

Isolation: One sandbox per candidate

Untrusted builds never share a workspace.

Token Factory Sandboxes

Open the workstation

Agents that design hardware, and prove it.

Launch App

Board and Matter checks are freeAgent runs on demo creditsNemotron is the only model

Designhardware.Prove it.