The Future of Analog IC Design with Agentic AI

The interesting part of handing two analog blocks to an AI agent was not that it sized every transistor. It was that it could hold the specification, the implementation, the verification state and the project record at the same time, change one of them, and bring the rest back into agreement without being told to.

That is a different thing from automation, and it points somewhere larger than a single block. It moves the engineer away from carrying every assumption through every representation by hand, and towards defining intent, encoding constraints, judging trade-offs and controlling a continuously verified loop.

By agentic AI, I mean software that can inspect the state of a project, modify its artefacts, invoke engineering tools, interpret their results and continue towards an explicit goal. I do not mean a chatbot that suggests a topology and waits for the next prompt.

I have been sizing analog transistors for fourteen years, and I have seen the first stage of this change in two analog blocks on a commercial 180 nm CMOS process. The agent performed most of the implementation and optimisation. I wrote and revised the specifications, chose or rejected consequential options, imposed physical constraints, reconstructed the oscillator through a separate commercial simulation path and retained the authority to promote each design.

The unit of work is changing

Analog design has traditionally been organised around a block and the engineer who holds it in their head. Written specifications rarely capture every assumption about loading, start-up, layout, device choice and the surrounding system; the remainder is absorbed while the circuit is being drawn, and survives as judgement, memory and conversations. That works because the same person carries the block from an incomplete brief to a sign-off candidate. It becomes fragile the moment the design crosses a boundary.

An agent changes this in three ways.

1. The specification becomes live project state, rather than a document frozen near the beginning. Confirmed requirements, undecided targets, physical restrictions and acceptance tests can be represented separately. An unconfirmed number remains visibly unconfirmed instead of quietly becoming an optimisation target.
2. Implementation artefacts are derived rather than copied. A sizing source can produce netlists, testbenches, layout parameters and report data. This does not make disagreement impossible, and independent implementations remain essential, but it removes a large class of accidental drift.
3. Verification runs whenever an assumption changes. The agent does not need to remember that a new load invalidates an old settling result, or that a clock change affects a comparator testbench. The relationship itself can cause the affected checks to run again.

The important capability is therefore not autonomous sizing. It is the continuous maintenance of engineering claims.

From one block to the whole product

The change begins inside an analog block, but it need not stop at the block boundary. A chip is built through several domains: analog and mixed-signal design, digital implementation, firmware, application software, and test and production. Each domain has mature tools and people who understand its local definition of done. The difficult part is preserving the contracts between them as the programme changes.

An interface is a claim about another artefact:

• a clock specification is a claim about a circuit;
• a register map is a claim about RTL;
• a driver guarantee is a claim about firmware and hardware together;
• a production limit is a claim about the relationship between simulation, characterisation and manufactured parts.

Structured formats for some of these claims exist: interface metadata in IP-XACT¹, register maps in SystemRDL², from which logic, models and documentation can be generated from one source. But coverage is partial, adoption varies, and analog behaviour sits largely outside what they describe. Many interface claims still cross tools and ownership boundaries as hand-maintained documents, written once, consumed elsewhere, and updated only when somebody notices they have gone stale. The problem is not that engineers cannot manage interfaces. It is that continuous re-derivation is tedious, cuts across ownership boundaries and shows no visible progress until it prevents a late failure.

An agent connected to the engineering record could derive a contract from measured producer behaviour, record which consumers rely on it, re-derive it after a change and repeat the affected checks. It could report not merely that a block still passes its own tests, but that an assumption elsewhere no longer holds.

I would expect that progression to arrive in stages. The four below are a proposed architecture rather than an observed maturity model: no published work demonstrates the sequence end to end.

1. Inside one analog lane. The agent sizes devices, runs corners, produces layout, runs the checks and maintains the evidence for a single block. This is the stage I have direct evidence for. Published research demonstrates narrower versions, such as training-free agents that iterate on analog circuits through simulation feedback³; a general system covering sizing, corners, layout and verification together is not established publicly.
2. Between analog blocks. Loading, bias, clocking, start-up, noise and settling become explicit contracts. A change in a clock generator causes its consumers to be re-checked against the new worst case. The deliverable stops being only a signed-off block, and starts including a machine-checkable account of what that block promises and what it assumes.
3. Across the mixed-signal boundary. The contracts now cover logic thresholds, reset behaviour, synchronisation, calibration sequences and register semantics. This is where independence matters most: a generated model cannot be accepted merely because it agrees with the generator that produced it.
4. Across the product chain. Design changes reach firmware, drivers, production tests and limits. A revised start-up time reaches the boot sequence; a changed fault condition reaches the driver API. I have not demonstrated this stage, and what makes it plausible is not that an agent understands every discipline better than its engineers. It is that these relationships span several owners and tools, which is exactly why nobody checks them continuously today.

Evidence from two analog blocks

Device counts are schematic instances before layout multiplicity, under the projects’ own counting convention.

Claude Code⁴ used pre-characterised device tables, following the lookup-table approach described by Jespers and Murmann⁵, evaluated 121 candidate sizings for the oscillator through its simulation harness, and built the project automation, the simulation inputs and the verification and layout infrastructure. I chose the oscillator topology, rejected proposed current-reference implementations, supplied physical restrictions and approved every promotion.

For the oscillator, I independently entered the circuit in Virtuoso and ran it in Spectre. Across 27 process, temperature and supply points, the commercial result was between 0.06% below and 0.18% above the generated ngspice⁶ result, with an RMS difference of 0.08%. The two paths used separately entered netlists and different simulators, while sharing the intended circuit, the same generation of process models and the same corner definitions. That close agreement reduces the likelihood of path-specific netlist, setup and simulator-interpretation errors at the tested points. It is not independent evidence that the underlying process models predict silicon, and a shared modelling error would appear in both paths equally.

The comparator produced the more important lesson. Its brief was four words: a comparator with near-zero offset. The agent chose a topology, developed four versions and generated a layout, reaching an input-referred offset between −11.9 and −4.3 µV across 45 extracted PVT points. The project then estimated the circuit’s own thermal noise at about 56 µV rms per decision, larger than the offset at every plotted point. The agent had optimised the requested quantity successfully. The open question was whether offset alone had ever been the right quantity.

The generated comparator layout passed the project’s design-rule and LVS checks. The LVS checker also passed a self-test in which six deliberate faults were injected and all six were detected. In extracted simulation, the project attributed an incremental 0.61 µV input-referred offset contribution to 69 attofarads of unequal coupling from the latch strobe line. That result is a useful diagnostic, but the comparator has not been reproduced in a separate commercial simulation path.

These projects demonstrate a capable agent operating inside one analog lane under explicit human gates. They do not demonstrate cross-domain integration, production readiness or silicon accuracy. Their importance is that the working method points beyond the individual circuits.

What made the agentic loop work

The specification was executable state. Targets lived in a machine-readable file, with confirmed requirements distinguished from placeholders and open questions, and a standing rule that the agent expose uncertainty rather than optimise silently against a guess. Traditional analog specifications can stay incomplete because the designer closes gaps while drawing. When implementation moves to an agent, those gaps either remain explicit or become accidental requirements. The comparator made that concrete: near-zero offset was a valid direction but an incomplete system requirement, and the brief carried too little context to decide whether the application cared about offset, total decision error, energy or latency.

The referees had exit codes. The most valuable artefacts were not circuit ideas but checks that failed loudly: operating-point guards, design-rule checks, LVS comparison, and tests of the checking infrastructure itself. An agent can create errors in its code, its harness and its reading of a simulator, and in these projects it introduced several:

• some it found itself, from results that did not agree with each other;
• a numerical tolerance problem needed an adversarial review step to surface;
• an untagged run overwrote an earlier result before the harness was corrected.

The lesson is not that an agent verifies itself. It is that verification has to be built as a separate, testable product. A checker never shown to reject a known error is only another unverified claim.

Derivation reduced drift, but did not replace independence. Shared sizing data drove netlists, tests, layout parameters and figures, which removed accidental disagreement between artefacts. The commercial schematic was deliberately built through a separate path so that it could expose mistakes in the generated one. That separation is why Figure 2 means anything: had both results come from the same generator, close agreement would have proved very little. Agentic flows need both properties.

The agent could not promote its own work. It could recommend a change, assemble evidence and argue against my decision, but it could not turn a recommendation into project state. That is not only a safety mechanism. It separates implementation from authority, and forces whoever approves a transition to decide whether the evidence answers the right question.

The engineer’s job moves, but does not disappear

The work left to the engineer is not residual cleanup after automation. It becomes the highest-leverage part of the design, and nothing below is specific to the analog lane I happened to run this in.

Defining the problem. The engineer has to separate requirements from convenient placeholders, define acceptable trade-offs and say which uncertainties stay open. A precisely optimised answer to the wrong question is more dangerous than a rough answer to the right one.

Supplying physical judgement. Several constraints in these projects did not follow from simulation: what the parameterised cells accept, which device options exist, what can be laid out sensibly, what the manufacturing flow supports. Each time the agent violated one, the rule became explicit project state. That was a surprise: knowledge I had treated as tacit turned out to be writable down once its absence became visible. The residue still matters, because no simulation determines what a customer will accept or whether an area increase is affordable.

Refusing locally good answers. An agent can make a strong case for a design that should still be rejected. I rejected current-reference choices, ruled out a device option and reversed a buffer configuration after looking at the waveform. Judgement concentrates here: at the exchange between performance, risk, manufacturability, schedule and the surrounding system.

Owning independent evidence. The person responsible has to decide what evidence is genuinely independent, and every kind has a blind spot:

• cross-tool agreement exposes one class of mistake while leaving shared assumptions untouched;
• rule checks can be internally consistent and still omit a rule;
• extraction can identify a mechanism without proving its magnitude in silicon.

If these blocks proceed to tape-out, accountability does not transfer to the agent. My name goes on the approval because I control the requirements, the evidence and the decision to proceed.

What organisations will have to build

Running a programme this way will require more than access to an EDA terminal.

• Specifications as data. Requirements, assumptions, unresolved questions and acceptance tests need stable representations that tools can read and people can review.
• Interfaces as deliverables. A block must ship with machine-checkable promises and assumptions, not only a schematic, a layout and a report.
• Verification as infrastructure. Checks need owners, tests, versioning and failure behaviour. Injecting known faults is part of qualifying the checker.
• Controlled access to confidential material. Here, model cards, layer maps and foundry decks stayed on the simulation server; the agent side held rule summaries and pre-characterised device tables rather than the model files. Netlists crossed over, measurements came back. That reduces exposure, but whether it is acceptable depends on the licence and on company policy.
• Explicit decision rights. The project must say what the agent may change, what evidence is required for a transition and who can approve it.
• A deliberate apprenticeship path. Junior engineers have traditionally learned device behaviour by debugging implementation details. If agents absorb that work, the learning does not reappear automatically. Juniors will need direct responsibility for writing referees, reproducing results independently, explaining failures and arguing against agent recommendations.

None of those six is a tooling purchase. Each is an organisational change: who owns an interface, what counts as evidence, what a block must ship with, who may approve a transition. So adoption will be uneven, and the unevenness will not track who bought what. A team that re-derives its contracts and repeats the affected checks finds integration problems while they are still cheap. A team that cannot keeps finding them at integration, which is where schedule is lost and where respins come from.

I think firms treating this as optional will end up competing against teams with a structurally shorter path to silicon, and will lose ground to them. That is a forecast rather than an observation, and I hold it loosely. What I hold firmly is the shape of it: getting access to a capable agent takes an afternoon, while changing what a block must ship with, and who may sign it off, takes considerably longer. The advantage goes to whoever starts the second one early, and it will not be visible from outside until a programme that should have slipped does not.

What does not change

• Silicon remains the forcing function. Neither block described here has met it.
• Verification must stay independent of the thing being verified. A perfectly automated circular argument is still circular.
• Specifications can be made executable without becoming correct. Somebody still has to decide what the product should do.
• Accountability remains human. The agent may perform most of the implementation and optimisation. The engineer owns the intent, the trade-offs, the independent evidence and the decision to proceed.

Start now

None of this requires waiting for a fully autonomous chip-design system. Four changes are useful immediately:

1. Write the specification as project state. Record undecided numbers as undecided, and attach every accepted result to the requirement it supports.
2. Make interfaces machine-checkable. Derive contracts from measured behaviour where possible, record their consumers and repeat the consumer checks after change.
3. Build the referee early, and test the referee. Inject errors into checks and confirm that they fail before trusting a pass.
4. Preserve negative results and human decisions. A rejected topology, an unacceptable trade-off and a disagreement with the agent are part of the engineering record.

The future of IC design is not a machine replacing the engineer who sizes the transistors, writes the RTL or owns the test programme. It is an engineering system in which implementation moves continuously across every one of those domains, while intent, evidence and authority stay explicit and stay human. What I would buy is not an artificial colleague claiming to be smarter than the people already on the programme, but a patient keeper of every claim the programme makes about itself, one that re-checks them whenever anything moves and is still doing it in month eleven.

Further reading

Background on the circuit techniques and tools behind the two blocks, none of it cited directly above:

• C. C. Enz and G. C. Temes, “Circuit techniques for reducing the effects of op-amp imperfections: autozeroing, correlated double sampling, and chopper stabilization”, Proc. IEEE, vol. 84, no. 11, pp. 1584-1614, 1996
• H. J. Oguey and D. Aebischer, “CMOS current reference without resistance”, IEEE J. Solid-State Circuits, vol. 32, no. 7, pp. 1132-1135, 1997
• B. Razavi, “The StrongARM latch”, IEEE Solid-State Circuits Magazine, vol. 7, no. 2, pp. 12-17, 2015
• KLayout: high performance layout viewer and editor, klayout.de
• A. Dias, “Generating a Standard-Cell Library with an AI Agent”, americo.dias.pt, 2026