SynthRisk

SynthRisk uses GPT-5.6 to triage RTL lint warnings by synthesis risk, not rule severity — separating style nits from issues that become unintended hardware before it's cast in silicon.

Comment

Inspiration

I'm a digital circuit designer working on the base die of HBM (High Bandwidth Memory). Every day I write RTL — the code that describes physical circuits — and every day I run lint tools to catch problems before they reach silicon. But RTL lint has two frustrating gaps. First, a linter reports rule violations, not circuit consequences: a missing else in combinational logic silently synthesizes into an inferred latch, yet the linter often says nothing about it. Second, a linter treats every warning equally — a missing newline and a latch-inferring case statement are printed with the same weight. On a real design that's hundreds of lines of output, and the one issue that becomes broken hardware drowns in the noise. In software you can patch a bug after release. In silicon you can't — a respin costs millions. I wanted a tool that reads lint output the way a senior designer does: by consequence, not by rule.

What it does

SynthRisk wraps an RTL linter (Google's open-source Verible) with GPT-5.6 and adds the one thing a linter lacks — judgment about circuit impact. For each SystemVerilog file it:

  • runs verible-verilog-lint and collects every violation;
  • sends the violations plus the full source to GPT-5.6, which classifies each one by synthesis risk — critical / warning / style;
  • independently inspects the source and reports latch-inference risks the linter never flagged (e.g. a combinational if with no else), tagged as [!] AI-DETECTED;
  • prints a risk-sorted report, each finding with a plain-language why and a suggested fix, plus a cross-file summary table.

Crucially, it only suggests fixes — it never rewrites RTL. In hardware, automatic edits are too dangerous; the designer decides.

How we built it

The entire tool was built with Codex (GPT-5.6 Terra) in a spec-driven workflow: each module — the lint-output parser, the triage engine, the report renderer, the multi-file runner — was generated from a detailed prompt in a single Codex session, verified against real Verible output, and committed immediately. The commit history documents each Codex-generated change.

The runtime triage engine calls gpt-5.6-terra via the OpenAI API, one request per file, with the source and violations batched into a single structured prompt that returns JSON.

Challenges we ran into

  • The linter's silence was the real problem. Early on I confirmed that Verible — even with --ruleset=all — never reports the missing-else latch or the blocking-assignment risk in sequential logic. That turned a "nice-to-have" into the core feature: GPT-5.6 had to detect risks from the source directly, not just re-rank existing warnings.
  • Keeping the AI honest. LLM-based detection is a heuristic, not formal analysis. The tool is positioned to complement the linter, not replace it, and the model was tuned to avoid over-flagging — verified against a clean reference file where it correctly reports zero synthesis risks despite eight style warnings.
  • Robust output. Handling Verible's nonzero exit code on violations, parsing both single-column and range positions, and stripping stray markdown fences from JSON responses all had to be solid before the demo. ##Accomplishments that we're proud of
  • GPT-5.6 correctly detects an inferred-latch risk that the linter stays completely silent on — and explains why it becomes a latch, in language a software engineer can follow.
  • The triage is genuinely discriminating: on the same run, a latch risk is critical, a legacy always block is a warning, and a missing newline is style — no flat wall of equal-weight noise.
  • Zero false alarms on clean code.
  • Built end-to-end in about a day, entirely with Codex.

What we learned

RTL lint is a solved problem for detection but an unsolved one for prioritization and consequence. An LLM turns out to be a natural fit for exactly that gap — not for finding rule violations (a deterministic linter is better at that), but for reasoning about what a violation means for the resulting circuit. The right architecture wasn't "AI instead of lint," it was "AI on top of lint."

What's next for SynthRisk

  • Support additional linters (Synopsys SpyGlass and others) behind the same triage layer — the wrapper design is linter-agnostic.
  • CI / git-hook integration so triage runs on every pull request.
  • Timing-risk hints alongside latch-risk detection, moving from "will this synthesize wrong?" toward "where will this hurt performance?"

Built With

  • cli
  • codex
  • colorama
  • digital-circuit
  • dotenv
  • eda
  • gpt-5.6
  • hardware-design
  • hbm
  • lint
  • openai-api
  • python
  • rtl
  • static-analysis
  • systemverilog
  • verible
Share this project:

Updates