Generate RTL.
Prove it.
Sign off with Confidence.
“Trust me” is not an engineering standard
AI can now write RTL. It cannot prove RTL. Blue Pearl AI pairs AI generation with deterministic, repeatable static verification, so your team gets the speed of AI without gambling the sign-off.
RTL Generation & Verification Flows
// Two ways in. One standard of proof.
TRACK 1 : AI-GENERATED RTL
STEP 1
DOORS Jama CSV
Author / import design requirements
The flow starts from the intent, not the code. Import requirements from DOORS, Jama, or plain CSV, and they become the reference everything downstream is proven against. When the design is finally verified, it is verified against these, not against the design’s own account of itself.
Why this gate exists
A generated bench can share the generator’s blind spots. Human-owned requirements are a reference the model didn’t write.
STEP 2
BPS On-Premises Cloud – e.g. Codex
AI generates RTL from requirements
Generation runs on BPS On-Premises or Cloud (e.g. Codex), guided by two decades of knowledge about what good RTL looks like: the rules, the patterns, the failure modes. The AI is the junior engineer you direct. You remain the author of record.
Why this gate exists
LLMs are strong generators and unreliable analysers. The two capabilities do not correlate, which is why generation and proof are separate stages.
STEP 3
Static analysis identifies coding / structural issues in generated RTL
Lint / Analyze RTL (generated code)
Deterministic structural analysis runs immediately after generation, because static analysis is cheap and simulation debug is expensive. It builds the parse tree and the graphs: width mismatches, CDC, latch inference, combinational loops, reset methodology, FSM reachability. Same answer, every run. 69 findings on a real generated I2C master, in seconds. Findings feed back as the ‘correct issues’ loop until the report is clean.
Why this gate exists
LLMs are strong generators and unreliable analysers. The two capabilities do not correlate, which is why generation and proof are separate stages.
TRACK 2 : EXISTING / HANDWRITTEN RTL
STEP 1
Legacy / handwritten RTL enters flow directly
Track 2 starts from the code you already have: legacy blocks, thin documentation, decades of hand-written RTL. AI adoption does not mean starting over.
Why this gate exists
You don’t need a greenfield project to benefit. Prove what you have first, then let the flow improve it.
AI generates fixes
Findings direct an AI remediation loop; corrected RTL re-enters lint until clean. On IP-sensitive programmes the correction loop runs on BPS On-Premises, inside the boundary. A waiver with documented rationale is evidence a qualified human reviewed the finding, not an ignored warning.
Why this gate exists
An unsupervised ‘fix everything’ pass makes designs subtly worse. Correction is gated by the same analysis that found the issue.
STEP 2
Static analysis identifies issues in existing code base
Lint / Analyze RTL (existing code base)
The same deterministic gate as Track 1, pointed at hand-written code. Checks align to RMM, STARC, DO-254 and vendor methodology guides, so findings are backed by industry standards, not tool opinion. Each finding is dispositioned by an engineer: fix in block, waive with documented rationale, or monitor.
Why this gate exists
AI-generated and human-written RTL pass exactly the same gates. The process is the process.
Requirements Verification - both tracks
RTL checked against requirements to confirm it implements intended functionality
Track 2 feeds in when requirements are available for the RTL
Requirements verification: both tracks
Both tracks end here: RTL checked against the imported requirements to confirm it implements the intended functionality, with an audit trail a human signed off. Track 2 feeds in when requirements are available for the RTL. Competitors sell generation or lint. Blue Pearl AI sells the closed loop.
Why this gate exists
Verified against what? With this flow, never ‘against itself’. The convergence gate is the differentiator.
The Evidence Base
Documented, not claimed
One shows why an LLM cannot lint its own output, the other shows the closed loop catching a real functional gap. Both report limits as readily as wins. That is the point.
Negative Proof
The Limitations of LLMs as RTL Linting Tools
A controlled evaluation of a frontier LLM on three Verilog review tasks against a Blue Pearl VVS baseline.
The findings are architectural, not fixable by prompting:
A five-line module defeated it: a standard comma-separated port declaration was misread, and every downstream check built on that parse was wrong.
Run-to-run inconsistency: the same missing case item was sometimes found, sometimes not. Non-determinism alone rules LLM linting out of any audit-trail workflow
Where it looked strongest, the source comments did the work.
Under DO-254, IEC 61508 and ISO 26262, tools must show known, repeatable behaviour. Deterministic lint qualifies. LLM linting cannot.
Technical position paper · April 2026
Positive Proof
The bug the toolchain would have buried
A practitioner-authored case study: AI generates a VHDL I2C master.
Blue Pearl VVS runs 29 check packages against it, and returns 69 findings in seconds, including this one:
SEV
FINDING
DISPOSITION
ERR
scl_in driven, never read: master cannot detect slave clock stretching
fix in block
WARN
async reset de-assertion: belongs in top-level reset controller
waive + rationale
INFO
fan-out above threshold: FPGA toolchain handles replication
monitor
Synthesis would have silently optimised the unused signal away. Directed simulation would never have hit it. A deterministic structural check surfaced it in seconds. And a waiver with documented rationale is not an ignored warning: it is evidence a qualified engineer reviewed the finding.
I2C master case study · March 2026
The Flow, for your Situation
Same gates. Your entry point.
Safety-critical & regulated
Certification needs determinism
DO-254-class projects need traceability, repeatability and audit trails. An LLM’s output is non-deterministic and cannot certify itself. Checks align to RMM, STARC, DO-254 and vendor methodology guides.
AI writes the first draft. Blue Pearl proves it against the requirement, with the audit trail your certification authority expects.
Large legacy code bases
You don’t need a greenfield project
Decades of hand-written RTL and thin documentation are the Track 2 entry point, not a barrier. Point the flow at the code you already have.
Prove what you have. Fix it with AI. Verify it against requirements when you’re ready.
Engineering managers
The governance answer
Leadership wants AI productivity; engineering wants sign-off discipline. AI-generated RTL goes through exactly the same gates as human-written RTL: same lint, same waivers, same audit trail, more throughput.
The process is the process. Blue Pearl AI just makes both tracks faster.
Design engineers
You stay the author of record
Deterministic, explainable findings, not a black box’s opinion. Lint immediately after generation dispositions the structural noise cheaply, so your review time goes to judgement calls, not width mismatches..
AI writes the first draft. You stay the engineer. Nothing ships on the model’s say-so.
Defence·security·export-controlled
Generate it. Prove it.
Inside your perimeter.
Classified programmes, ITAR/EAR designs and air-gapped facilities can’t send RTL to a cloud, and shouldn’t be locked out of AI productivity because of it. BPS On-Premises runs the entire flow, generation, lint, correction loops and requirements verification, end-to-end on hardware you control. No external calls. Deployable air-gapped.
No design data leaves the site. Ever.
[ requirements → generate → lint → verify ]
All inside the security boundary · from a vendor that has served these programmes for two decades
Take the Prove It Challenge.
Let us know your requirements and your situation using the form below. We’ll be in touch to arrange a call with one of our engineers, and then show you how Blue Pearl AI can resolve your specific challenges.