Teams that catch violations before simulation
Verification engineers at ASIC design houses and FPGA programs running Fpgawright as a first-pass static gate — before the simulation queue.
Verification teams running static analysis before simulation
Results from the field
How Halcyon cut verification cycle time by 40% before their 16nm tape-out
Halcyon's verification team was running 3–4 week simulation cycles to isolate a class of CDC violations appearing late in the design cycle. Their existing RTL linter was configured to suppress a broad category of CDC warnings across one module family — too noisy to be actionable — which masked the real issue. After integrating Fpgawright, the first static analysis pass identified 3 critical CDC violations that had survived their prior simulation runs. One — a reconvergence hazard in the memory controller clock domain where a multi-bit signal crossed from a 250 MHz domain to a 180 MHz domain without synchronization — had been a known failure mode on their previous 28nm project. Fpgawright's learning model ranked it first.
Result: 40% reduction in verification cycle time for that project phase. One simulation re-run avoided — the team estimated 2.5 weeks of engineer time and compute queue time saved.
Torchlight ASIC integrated Fpgawright into their Jenkins pipeline in one day
Torchlight's verification flow lead had a specific problem: engineers were introducing RTL violations in commits that wouldn't surface until the weekly simulation run, by which point the source commit was buried under 30–40 others and root-cause analysis added another day. The Fpgawright Jenkins plugin installed in an afternoon with no changes to their existing Makefile-based build. The plugin runs in diff-aware mode, flagging only violations introduced by the specific commit under review — not the full baseline list, which would have produced too much noise to be actionable.
Result: violations that previously survived into the simulation queue are now caught at commit time, the same day they're introduced. Torchlight imported 4 years of bug report data, and their known reset-topology and CDC failure patterns now surface first in every analysis. Engineers act on findings because the list is short and directly relevant to their change.
What verification engineers say
"We caught a clock-domain crossing on a 72-hour turnaround design that would have cost us three weeks of simulation time. Fpgawright paid for itself on the first run."
"The historical bug learning is the feature I didn't know I needed. Our team's known-bad patterns are now first-class citizens in the analysis. That alone cut false-negative rate significantly."
"Integration with our Jenkins pipeline took one afternoon. Now every commit gets a static verification pass before it touches our simulation queue."
"The diff-aware mode is what made it work in our flow. We didn't want to deal with a list of 200 pre-existing findings. Only seeing what a commit introduces made the team actually act on the results."
Fpgawright is not a replacement for simulation or formal verification. It's the static pass that runs first.
Request access and we'll review your workflow to confirm Fpgawright fits — if it doesn't, we'll tell you that too.