What self-driving can teach us about AI-assisted RFIC design

When someone says that AI can design an RF chip, I want to know where the engineer can let go, where they must stay involved, and what evidence comes back. A useful capability framework should make those boundaries visible.

The idea is inspired by automated driving. Its useful lesson for engineering is to describe the work a system takes responsibility for, the conditions in which that responsibility applies, and the role that remains with a person. Counting tools or admiring a successful demonstration tells us much less.

I use that idea to organize six levels of AI-assisted RFIC design. The labels are a working discussion framework, not an industry standard or a direct mapping to automotive automation levels. RFIC design needs its own distinctions because circuit decisions and physical decisions are tightly coupled.

Start with the work already done by a human

Consider three requests: improve this amplifier, create its layout, and design an amplifier that meets these specifications. They may end with similar-looking files. They begin with very different amounts of engineering already supplied.

An existing netlist can contain the most important architectural choices. A parameterized layout can contain the placement strategy, return paths, and the whole family of permitted physical structures. A system that searches within those choices may be extremely useful. Its contribution should be described in terms of the decisions it actually makes.

This is the first question I would ask of a demonstration: what did the system receive before the clock started? Specifications, a topology, a native design, a finished physical template, and a library of reusable components are different starting assets. They should be part of the capability claim.

Two distinctions give us six levels

The framework separates optimization from synthesis, and the circuit from its physical realization. Optimization works within an established design scheme. Synthesis takes responsibility for establishing that scheme. At the broadest level, circuit and physical synthesis form one decision loop.

These numbers describe different responsibilities. They are not a universal score for intelligence, difficulty, or commercial value. In particular, physical optimization does not by itself demonstrate circuit synthesis. A highly capable specialist can occupy one part of the framework without mastering every lower-numbered activity.

L0 to L2: who chooses the circuit?

At L0, an engineer might say, “Change M1's width to 20 micrometers, run the simulation, and plot the result.” The system may save substantial time, but the engineer still directs the consequential design steps.

At L1, the request becomes, “Improve this LNA against these gain, noise, and power requirements.” The system can choose device sizes, bias conditions, and the next simulation within the supplied circuit scheme. A meaningful part of the iteration is now delegated.

At L2, the engineer supplies the gain, noise figure, bandwidth, power budget, and process information. The system must select, combine, or construct a topology, create the netlist, and iterate toward a complete circuit solution. The distinction is the responsibility for the scheme, rather than whether the implementation uses an optimizer, generated code, or a language model.

“Synthesis” does not require inventing every component from scratch. Reusing established circuit ideas can be good engineering. What matters is whether the system makes the substantive choices needed to turn the stated requirements into the circuit.

The physical boundary matters especially in RF

A netlist leaves many physical choices open. Two layouts with the same connectivity can differ in interconnect length, spacing, coupling, and return paths. Their high-frequency behavior can therefore differ in ways that matter to the objective. This is why entering layout means continuing to design.

L3 marks the entry into a physical feedback loop. The system receives an existing layout or a fixed structural family, then adjusts dimensions, spacing, routing, or other permitted geometry. It must use feedback about both manufacturing constraints and RF behavior. A repair that removes a rule violation but leaves the relevant electrical objective unchecked is an intermediate result.

At L4, the system takes responsibility for establishing the physical scheme itself: structures, connections, placement, interconnect, and return paths. The input may be a circuit to implement or a port-performance target for a passive network. The output is a complete, evaluated physical implementation within that task's scope.

PCells, generators, and component libraries remain legitimate tools. The boundary is not whether a library was used. It is how much of the consequential physical plan was supplied in advance and how much the system had to determine.

L5: let physical evidence change the circuit

A circuit-first workflow can do a great deal while keeping the circuit scheme fixed. It can repeatedly reshape a passive network, improve routing, or repair a layout. Joint synthesis adds responsibility for reconsidering decisions on both sides.

For example, suppose the physical implementation of a matching network makes the overall amplifier target difficult to reach. A joint process can reconsider the active configuration or bias together with the passive structure and layout. Those are illustrative choices, not a prescribed sequence. The defining feature is that physical evidence can change the circuit scheme, and the revised circuit can change what the physical implementation should be.

The loop is driven by one overall objective: gain, noise, bandwidth, matching, power, area, and the constraints specified for the task. L5 therefore requires synthesis capability on both sides and a joint evaluation of the resulting candidate. Simply running a circuit tool and an EM tool in succession does not establish that responsibility.

Nor does every cross-layer edit establish L5. An engineer may have supplied nearly the entire design and asked for a bounded repair. The edit can be technically difficult and valuable while the demonstrated task remains narrower than joint synthesis from overall requirements.

One LNA, three different assignments

The same amplifier makes the boundary concrete:

• L3: improve an existing layout. Start with a physical design, locate rule violations and RF problems, revise geometry or return paths, and evaluate the revised implementation.
• L4: build the physical implementation. Start with a circuit scheme and physical objectives. Determine placement, passive structures, interconnect, and the complete layout, then close the required physical checks.
• L5: meet the overall amplifier requirements. Choose the circuit scheme and active configuration, synthesize the physical realization, and revisit their trade-offs using joint feedback.

All three assignments can deliver GDS. A screenshot cannot tell us which assignment was solved. We need the starting assets, the decision history, and the acceptance evidence.

Scope also changes the meaning of a label. L4 for a bounded multiport passive network and L4 for a complete LNA describe different coverage. Neither the numeral nor a successful task on one process establishes generalization to another device class or foundry.

Responsibility includes knowing what remains unverified

The driving analogy becomes useful again here: delegation needs a clear boundary and a clear handover. In a design workflow, a system should identify the candidate it evaluated, the checks it completed, the checks it could not complete, and the decisions it needs from the engineer.

The engineer and organization still define the task, authorize resources, and decide whether the delivered evidence is adequate for the intended use. Delegating design decisions does not make a model's confidence an acceptance criterion.

I would keep exploration and acceptance separate. The agent can create tools, test hypotheses, and inspect failures inside its authorized workspace. The formal evaluation should use the agreed criteria and traceable results for the same candidate. Circuit performance from one revision and clean geometry from another do not establish that a single design meets both requirements.

For a physical task, that evaluation may include independent reopening of the native design, DRC, the applicable connectivity or interface checks, and EM or post-layout circuit analysis. The checks should match the task. Missing evidence remains missing, even when the explanation of the design sounds convincing.

This also affects the handoff artifact. An editable native design, its evaluated version, and its remaining limitations let an engineer inspect and continue the work. They make collaboration possible after the autonomous run ends.

A useful claim fits in more than one number

I would describe a capability with three questions before assigning a level:

1. What was given? Record the specifications, netlist, templates, libraries, and existing physical work.
2. What did the system decide? Distinguish parameter selection, circuit scheme, physical scheme, and cross-layer trade-offs. Record consequential human interventions.
3. What was verified? State the candidate, evaluation conditions, acceptance checks, and unresolved limitations.

A compact label might read: “L4, multiport passive networks, system-led synthesis, DRC and EM verified.” To compare tools, I would add success rate over stated attempts, human effort, wall-clock time, simulation cost, supported processes, and deployment maturity.

That gives an engineer something to evaluate against a real need. A single success establishes an example under particular conditions. Repeated tasks and failures tell us more about reliability. Transfer to another process needs its own evidence.

The goal is a workbench that can change gears

I do not want every design problem forced into the most autonomous mode. An engineer may need a diagnosis today, a local repair tomorrow, and a complete new design next week. Each can justify a different depth of delegation.

A useful system should be able to enter an existing project, preserve intentional human changes, take over a bounded task, and return a design that the engineer can continue. Generalization matters too, but moving between processes and devices still requires suitable documentation, models, tools, and verification. Low adaptation cost is a goal to measure.

This is why I care about the engineering environment around the agent: expressive native design tools, controlled execution, recoverable working copies, and independent evaluation. Those capabilities support many levels of assistance and remain useful as models improve.

The most useful question is therefore not simply “How high is the level?” It is: which design responsibility can I delegate, under which conditions, and what verified result will I receive? That question connects autonomy to engineering value.