Code Review for AI Chip Design Pipelines Before Tapeout
How AI-driven analog and RF chip teams can review the optimizer, simulation, and verification code behind every layout, so software bugs do not become silicon respins.
If your team uses AI to generate and rank analog or RF layouts, your design-automation code is now part of your tapeout risk. The optimizer, the simulation harness, the scoring function, and the scripts that parse DRC and LVS results decide which designs reach the foundry. A bug in that code does not fail loudly. It quietly ranks the wrong layout first, and you find out when silicon comes back.
This article gives you a review framework for that code: where defects hide in a generate, evaluate, optimize loop, which patterns to check in every pull request, and how to pilot automated review on the repositories that matter most. The framework works with any review tooling. Later sections show where SlopBuster fits if you want an automated reviewer in the loop.
Why Design-Automation Code Is Now Tapeout Risk
Traditional analog design kept a human in the loop for every topology and sizing decision. AI-driven flows change that. A model proposes candidates, a simulator scores them, and an optimizer keeps the winners. Thousands of layouts can pass through that loop before an engineer looks at the shortlist. The engineer reviews the shortlist. The code that produced the shortlist often gets far less scrutiny.
That matters because first-pass silicon is getting harder, not easier. The 2024 Siemens EDA and Wilson Research Group functional verification study found that only 14% of ASIC/SoC projects achieved first-silicon success, the lowest level in more than two decades of tracking [1][2]. That figure covers ASIC and SoC projects broadly rather than analog blocks alone, but the lesson carries over: every escape that reaches the fab costs a mask set and months of schedule.
At the same time, more of the automation code is written with AI assistance. Veracode tested over 100 large language models on 80 coding tasks and found that the generated code introduced security flaws in 45% of cases [3]. Design tools are moving the same way. Keysight's ADS 2027 release adds an MCP server so AI assistants such as Visual Studio Code can connect to an active ADS session, along with Python macro recording for automation [4]. Open-source flows such as gdsfactory already expose layout, DRC, and LVS steps as Python [5]. The result is more code, written faster, sitting directly between your models and your masks.
Where Defects Hide in an AI Analog Design Loop
Most AI-driven analog flows share three stages, even when the models differ. Each stage has its own code and its own failure modes. Use this table to decide which repositories need the strictest review.
| Loop Stage | Typical Code | Common Failure Mode | What Review Should Check |
|---|---|---|---|
| Generate | Topology templates, parameter samplers, layout generators | Parameters sampled outside PDK limits or device rules | Bounds come from the PDK, not from hardcoded constants |
| Evaluate | Netlist writers, simulator wrappers, result parsers | Failed or partial simulations scored as valid results | Every simulator exit path returns an explicit infeasible state |
| Score | Objective functions, figure-of-merit math | Mixed dB and linear units, wrong sign on a penalty | Units are named and converted in one place |
| Optimize | Search loops, surrogate models, ranking | Non-reproducible runs, leaked test data in surrogate training | Seeds, data splits, and versions are recorded per run |
| Verify | DRC and LVS runners, waiver handling, report parsers | A parser that skips error lines, or a waiver broad enough to hide them | Parsers fail closed and waivers are explicit and reviewed |
The Evaluate and Verify rows deserve the most attention. They are where a software bug turns into a false pass, and a false pass is the defect your designers are least likely to catch by eye.
Five Defect Patterns to Check in Every Pull Request
These patterns come up repeatedly in simulation-driven optimization code. Each one looks reasonable in a diff and produces wrong rankings at scale.
1. Failed simulations that look like perfect designs
When an optimizer minimizes cost, any error path that returns zero rewards broken candidates.
# Before: a crashed or non-converged simulation scores as the best possible design
def evaluate(candidate: Candidate) -> float:
try:
result = run_simulation(candidate)
except SimulationError:
return 0.0 # lower cost is better, so failures win
return cost(result)# After: failures are infeasible, counted, and visible in the run report
import math
def evaluate(candidate: Candidate) -> float:
try:
result = run_simulation(candidate)
except SimulationError as error:
run_log.record_failure(candidate.id, reason=str(error))
return math.inf
if not result.converged:
run_log.record_failure(candidate.id, reason="did not converge")
return math.inf
return cost(result)A reviewer should also ask what fraction of candidates failed. A run where a large share of simulations fail is telling you something about the sampler, even if the top result looks good.
2. Mixed units in the objective
RF figures of merit combine gain, noise, linearity, and power. Mixing decibels and linear ratios in one expression produces a number that still sorts, which is why this bug survives.
# Before: gain is in dB, noise figure is a linear noise factor
score = result.s21_db - 2.0 * result.noise_factor
# After: convert once, name the unit in the variable
noise_figure_db = 10 * math.log10(result.noise_factor)
score = result.s21_db - 2.0 * noise_figure_db3. Corners that silently shrink
Optimizing at the typical corner only is a common shortcut during development. The risk is that the shortcut ships. Keep corner coverage in configuration that reviewers can see, and fail the run if a required corner is missing.
# evaluation.yaml
required_corners: [tt, ff, ss, fs, sf]
temperatures_c: [-40, 27, 125]
fail_if_corner_missing: true4. Verification parsers that fail open
A DRC or LVS report parser that returns "clean" when it cannot find the summary line will pass every corrupted or truncated report. Parsers should return an explicit unknown state, and only an explicit clean result should advance a design.
5. Hardcoded PDK paths and limits
Device limits, layer numbers, and rule decks belong to a PDK version. When they are copied into Python constants, a PDK update leaves the generator producing layouts against stale rules. Review should confirm that limits are read from the PDK the run declares.
A Review Checklist for Design-Automation Repositories
Use this checklist as a pull request template for repositories that touch simulation, scoring, or verification. It keeps reviews consistent across designers and software engineers, who often read the same diff with very different instincts.
| Area | Question for the Reviewer | Evidence to Ask For |
|---|---|---|
| Failure handling | Does every tool error, timeout, and non-convergence produce an infeasible result? | A test that injects a failed simulation |
| Units | Are all quantities in the objective named with units and converted in one place? | Unit tests on the figure-of-merit function |
| Corners | Does the change keep the required PVT corners and temperatures? | Run config diff and corner coverage report |
| Verification | Do DRC and LVS parsers fail closed on missing or truncated reports? | A fixture with a truncated report |
| PDK binding | Are device limits and rule decks read from the declared PDK version? | Run metadata showing the PDK version |
| Reproducibility | Are seeds, model versions, and data splits recorded for each run? | Run manifest attached to the result |
| Secrets and IP | Are foundry credentials, license servers, and NDA paths kept out of code? | Secret scan result on the pull request |
The last row matters more in semiconductor work than in most software. Foundry PDKs are often under NDA, and license server details are sensitive. A leaked credential in an automation script is both a security problem and a contractual one. For broader guidance on securing assistant-written code, see AI code security and vulnerability prevention.
How SlopBuster Reviews Design-Automation Code
Human reviewers are good at judging whether a topology makes sense. They are less consistent at reading every error path in a simulator wrapper on the fortieth pull request of the week. That is the gap automated review is suited to.
SlopBuster is Connectory's GitHub pull request reviewer. When a pull request opens or updates, it runs three reviewers in parallel and posts one structured review:
1. Code review. It explores the full repository clone, not only the diff, so it can see that a new scoring function ignores the unit helper you already have, or that a parser change bypasses an existing fail-closed check.
2. AI slop detection. It flags copy-pasted logic, reinvented utilities, and code that ignores your existing patterns, which are common in assistant-written automation scripts.
3. Security review. It looks for exposed credentials, unsafe subprocess calls to EDA tools, and other security issues in the changed code.
On later commits it runs a delta review that focuses on the new changes and checks whether earlier findings were fixed, so a long-running optimizer pull request does not get the same comments repeated.
For teams with sensitive IP, data handling decides whether a reviewer can be used at all. Connectory processes code in an isolated, stateless pipeline and persists review metadata, not your source code. It is SOC 2 Type II, and a self-hosted deployment is available for teams that need code to stay inside their own network. The details are on the security page.
Running a Two-Week Pilot on One Optimizer Repository
You do not need to roll out review across every repository to learn whether it helps. A focused pilot gives a clearer answer.
1. Pick one repository with real risk. The evaluation harness or the scoring code is a better choice than a utilities package, because defects there change which designs advance.
2. Install the GitHub app on that repository only. Leave the rest of the organization untouched during the pilot.
3. Add the checklist above to the pull request template so human reviewers and the automated reviewer are looking for the same things.
4. Track three numbers for two weeks: findings your engineers accepted and fixed, findings they rejected as wrong, and defects found later that review missed.
5. Review the results with both designers and software engineers. Designers will judge whether findings touched results that matter. Engineers will judge the noise level.
| Pilot Metric | How to Measure It | What a Useful Result Looks Like |
|---|---|---|
| Accepted findings | Findings that led to a code change | Several per week on active repositories |
| Rejected findings | Findings dismissed as incorrect or irrelevant | A minority of total findings, falling over time |
| Escapes | Defects found after merge that review missed | Each one turned into a checklist item or test |
| Review latency | Time from pull request open to first feedback | Minutes, not days |
If the accepted findings touch failure handling, units, or verification parsing, review is paying for itself in the parts of the loop that decide silicon outcomes. If most findings are style comments, tune the scope before expanding. Plan details, including private repository limits, are on the pricing page.
Frequently Asked Questions
Does automated review replace DRC, LVS, or simulation sign-off?
No. DRC, LVS, and simulation remain your sign-off. Code review checks the software that runs those tools and interprets their results, so that a passing report actually means the design passed.
Our automation code is mostly Python and tool scripts. Is that in scope?
Yes. Python optimizers, simulator wrappers, report parsers, and configuration files are ordinary code in a Git repository, and they are exactly where the defect patterns above appear.
Will a reviewer understand RF and analog design?
A general reviewer will not replace a design expert's judgment on topology or sizing. It is useful for the software defects around that judgment: error handling, units, configuration drift, duplicated logic, and security issues. Keep design decisions with your designers.
Can we use this if our PDKs are under NDA?
Keep NDA material out of the repository wherever possible and reference PDKs by version. Connectory does not persist source code, and teams with stricter requirements can run a self-hosted deployment.
Which repository should we start with?
Start with the evaluation or scoring code, because a defect there changes which designs reach the foundry. Utility repositories can wait.
Next Steps
1. Add the five defect patterns to your pull request template this week.
2. Write one test that injects a failed simulation and one that feeds a truncated DRC report to your parser.
3. Pick the one repository whose bugs would change which designs advance.
4. Run a two-week review pilot on that repository and count accepted findings, rejected findings, and escapes.
5. Expand only to the repositories where the pilot surfaced defects worth fixing.
If you want to run that pilot with SlopBuster, start with the GitHub app on a single repository and compare the results against your checklist.
References
[1] Siemens EDA and Wilson Research Group, "IC/ASIC Functional Verification Trend Report, 2024," Verification Academy. https://verificationacademy.com/topics/planning-measurement-and-analysis/wrg-industry-data-and-trends/2024-siemens-eda-and-wilson-research-group-ic-asic-functional-verification-trend-report/
[2] Siemens Verification Horizons, "Why first-silicon success is getting harder for system companies," September 3, 2025. https://blogs.sw.siemens.com/verificationhorizons/2025/09/03/why-first-silicon-success-is-getting-harder-for-system-companies/
[3] Veracode, "AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals," July 30, 2025. https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/
[4] Keysight, "ADS 2027 Product Release." https://www.keysight.com/us/en/lib/resources/software-releases/ads-2027-product-release.html
[5] gdsfactory on PyPI. https://pypi.org/project/gdsfactory/