From first commit to tape-out confidence
A walkthrough of the full Fpgawright verification workflow — setup, analysis, reporting, and CI loop.
Connect your RTL repository
Add the Fpgawright GitHub Actions workflow or Jenkins plugin to your repository. Point it at your Verilog, SystemVerilog, or VHDL source directories. No refactoring, no new file format — Fpgawright reads your existing layout.
Optionally, import your existing simulation failure logs and past tape-out bug reports to seed the learning model. Supported formats: VCS log, CSV, and JSON incident export. This step is optional but significantly improves first-run accuracy.
name: RTL Verification
on: [push, pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: fpgawright/action@v2
with:
api-key: ${{ secrets.FPGAWRIGHT_API_KEY }}
rtl-path: ./rtl
Static + learned analysis runs
The analysis runs in two sequential passes. The base engine checks all 140+ design rules against your RTL — CDC paths, reset topology, state machine coverage, bus width mismatches, and timing paths.
After the base pass, the learning model re-ranks the violation list based on your team's historical bug patterns. Violations that match known failure modes from your past tapeouts are promoted. Rules that have never fired on your architecture are ranked lower to reduce noise.
A typical 500k-line RTL design completes analysis in 3–8 minutes depending on complexity and the number of clock domains. Fpgawright does not simulate your design — the analysis is structural and static. It reports what the rule engine finds in the RTL graph; confirmation via simulation or formal proof is still your call.
Reading the report
The report is a ranked list — errors first, then warnings, sorted within each category by learned weight. Each violation entry includes the rule ID, file location, module name, and a one-sentence explanation of what to check.
Where the learning model matched a prior incident, the entry includes a link to that incident report so the engineer can immediately see how the previous occurrence was resolved. Reports export to PDF for handoff or JSON for downstream tooling.
CI integration loop
Once in your CI pipeline, Fpgawright runs on every commit to your RTL branches. The GitHub Actions plugin posts inline PR comments on commits that introduce new violations — so your team sees the problem at review time, not after a simulation run.
Configure your merge gates: block on error-severity violations, warn (don't block) on warn. Teams typically use the diff-aware mode to surface only net-new violations introduced by a change, reducing noise from pre-existing baseline findings.