VLSI KoreaRTL Vibe Coding: 5 Verification Gates Engineers Must Enforce
AI can now generate RTL and testbenches. A practicing engineer lays out five verification gates that must be checked in real projects and portfolios.
“Can I use AI to write RTL?” and “Can I trust a testbench generated by an LLM?” These are questions I often hear these days from design and verification engineers and job seekers. Without citing any specific person or project, I generalize only recurring anonymous concerns and answer them from a practicing engineer's perspective.
One-line answer: AI can create an RTL draft. However, a human must approve five verification gates: specification → lint → simulation and coverage → formal and CDC → synthesis, STA, and PPA.
AI has moved beyond assisting with a few lines of Verilog. Cadence says its ChipStack AI Super Agent connects specialized agents for RTL generation, testbench generation, regression orchestration, and debug. In April 2026, it announced that it had observed productivity gains of up to 10x in early customer work. This is a vendor-reported figure, not an independent benchmark, so it should not be generalized as-is. Still, the direction is clear: EDA interfaces are shifting from GUI- and Tcl-centric workflows toward agents that receive objectives and feed tool results back into the process.
The broader shift in where AI EDA will first reshape the industry was covered in AI EDA Productivity Stack: Verification and Closure Will Change Before RTL. This article focuses on approval gates that can be applied to real projects and portfolios.
The problem begins when the software vibe-coding standard of “if it compiles and the demo runs, it's done” is applied to RTL. RTL is not code that is complete once it is functionally correct. It is an implementation specification that must simultaneously satisfy clock, reset, protocol, CDC, power intent, synthesizability, PPA, and signoff constraints.
Gate 1: Has Natural Language Been Turned into an Executable Specification?
“Build me an AXI slave” is not a specification. At a minimum, the following must be decided.
- supported protocol and subset
- data/address width
- number of outstanding transactions
- latency and throughput targets
- reset type and polarity
- invalid-access handling
- backpressure conditions
- clock and power domains
Do not let AI fill in the blanks arbitrarily. It should return unresolved items as questions. Recent LLM RTL research has likewise found that a substantial share of errors stems not only from limitations in model reasoning, but also from ambiguous descriptions and misunderstandings of circuit concepts.
Pass criteria: The requirements list, I/O table, state transitions, timing examples, and error behavior are documented, and each has a traceability ID.
Gate 2: Have You Checked RTL Quality, Not Just Syntax?
A successful compile is the lowest bar. Static checks must cover latch inference, width truncation, signedness, incomplete assignments, combinational loops, missing resets, and potential simulation-synthesis mismatches.
Even if an AI agent reads lint results and applies fixes automatically, it must not be allowed to suppress warnings indiscriminately. Each waiver needs a rationale, owner, scope, and expiration condition.
Pass criteria: Compile/elaboration succeeds, lint severity criteria are met, and the basis for every waiver is documented.
Gate 3: Is There Self-Checking Simulation and Coverage?
If AI generates both RTL and the testbench, it can replicate the same misunderstanding in both files. The reference model, assertions, and testbench should use independent representations wherever possible.
The minimum test set should include the following.
- reset and reset release
- normal single transactions and back-to-back transactions
- backpressure and maximum delay
- boundary values and illegal inputs
- possible combinations of protocol ordering
- long random regression
That is also why the VerilogEval line of research evaluates LLM-generated RTL with testbenches, and why recent studies have improved performance by adding simulation error localization and correction loops. Tool-driven feedback loops matter more than one-shot generation.
Pass criteria: Every requirement ID maps to a test or assertion, the regression is reproducible, and any unhit functional coverage items are explained.
Gate 4: Has It Passed Independent Formal, CDC, and Equivalence Checks?
Simulation sees only the paths it executes. Formal properties are powerful for blocks where the state space matters, such as control logic, arbitration, and protocol safety properties. If there are multiple clocks or asynchronous resets, CDC/RDC analysis must be a separate gate.
If AI has optimized existing RTL or created an ECO, equivalence is especially important. Cadence describes the Conformal family of equivalence tools as an independent auditor that checks whether results produced by implementation tools are logically equivalent. The key word here is not AI but independent. The generator and checker must not be tied to the same reasoning.
Pass criteria: Assertion proofs or explicit bounds, CDC/RDC violation dispositions, and pre- and post-change equivalence results are retained.
Gate 5: Does It Meet Synthesis, STA, PPA, and Physical Requirements?
Functionally correct RTL can still fail after synthesis. Common causes include long combinational paths, excessive priority chains, incorrect clock gating, high fanout, and failed memory inference.
Do not give AI a PPA target as a single number. Reducing area alone can damage timing or testability. Fix the constraint, library, corner, and tool version, then compare the following together.
- worst/total negative slack
- area and cell count
- dynamic/leakage power estimate
- congestion and physical feasibility
- impact on DFT and low-power rules
Pass criteria: While maintaining functional equivalence with the baseline RTL, the design meets the agreed ranges for timing, area, power, and physical feasibility.
What AI Can Handle and What Humans Must Approve
| Tasks well suited to AI | Tasks requiring human approval |
|---|---|
| drafting boilerplate RTL and testbenches | architecture and state behavior |
| proposing fixes for lint and compile errors | warning waivers and reset policy |
| generating candidate test scenarios and assertions | verification plan completeness and oracle independence |
| classifying regression failures and summarizing logs | root cause and release decision |
| proposing PPA exploration candidates | constraint, signoff, and tape-out approval |
Engineering Skills That Become More Valuable in the AI Era
Typing code may account for a smaller share of the work. Instead, the value of four skills will rise.
- The ability to turn ambiguous requirements into executable contracts
- The ability to find the real root cause in tool logs and waveforms
- The ability to design independence between the generator and verifier
- The ability to explain trade-offs among functionality, performance, power, and physical implementation
Frequently Asked Questions
Q. Can I use RTL created with ChatGPT or Claude in my portfolio?
Yes. But show verification evidence, not the prompt. You need a specification, test plan, assertions, coverage, synthesis results, and a record of the errors AI introduced and how you found and fixed them.
Q. If AI also creates the testbench, isn't verification complete?
No. The RTL and testbench can share the same misinterpretation. You need other oracles, such as an independent reference model, protocol assertions, formal verification, or commercial VIP.
Q. Does that mean fewer RTL engineering jobs?
The share of repetitive coding and log classification may decline. At the same time, people responsible for specifications, architecture, verification closure, and physical trade-offs will become more important. The center of responsibility is more likely to shift than the role is to disappear.
Q. Can I put company code into an external AI system?
Do not do so unless company policy allows it and security has approved it. RTL, constraints, logs, and waveforms can contain product architecture and vulnerabilities. An approved enterprise environment and data boundary must come first.
Conclusion
“Can AI-generated RTL be trusted?” is not the right question. A better question is this.
Regardless of who created it, did you require it to pass the same five verification gates?
Vibe coding produces drafts quickly. Silicon is still built on verifiable evidence.
Public Sources
- Cadence ChipStack AI Super Agent
- Cadence–NVIDIA agentic AI announcement
- Cadence Conformal AI Studio
- OpenLLM-RTL paper
- Understanding and Mitigating Errors of LLM-Generated RTL Code
- NVIDIA VerilogEval repository
Editorial note: This article generalizes recurring anonymous concerns I have heard. It uses no nonpublic information that could identify an individual or project, and clearly identifies vendor performance figures as vendor claims.
