O futuro do projeto de CI analógicos com IA agêntica

A parte interessante de entregar dois blocos analógicos a um agente de IA não foi ele ter dimensionado cada transístor. Foi conseguir manter ao mesmo tempo a especificação, a implementação, o estado da verificação e o registo do projeto, alterar um deles e pôr os restantes de novo em concordância sem que ninguém tivesse de o pedir.

Isto não é a mesma coisa que automação, e aponta para algo maior do que um único bloco. Afasta o engenheiro de transportar à mão cada pressuposto por cada representação, e aproxima-o de definir intenção, codificar restrições, avaliar compromissos e controlar um ciclo continuamente verificado.

Por IA agêntica entendo software capaz de inspecionar o estado de um projeto, modificar os seus artefactos, invocar ferramentas de engenharia, interpretar os resultados e prosseguir em direção a um objetivo explícito. Não me refiro a um chatbot que sugere uma topologia e fica à espera da instrução seguinte.

Dimensiono transístores analógicos há catorze anos, e vi a primeira fase desta mudança em dois blocos analógicos num processo CMOS comercial de 180 nm. O agente executou a maior parte da implementação e da otimização. Eu escrevi e revi as especificações, escolhi ou rejeitei as opções com consequências, impus restrições físicas, reconstruí o oscilador por um caminho de simulação comercial independente e mantive a autoridade para promover cada versão.

A unidade de trabalho está a mudar

O projeto analógico organizou-se tradicionalmente à volta de um bloco e do engenheiro que o tem na cabeça. As especificações escritas raramente captam todos os pressupostos sobre carga, arranque, layout, escolha de dispositivos e sistema envolvente; o resto é absorvido enquanto o circuito está a ser desenhado, e sobrevive como critério, memória e conversas. Isto funciona porque é a mesma pessoa que leva o bloco de um enunciado incompleto até candidato a aprovação final. Torna-se frágil no momento em que o projeto atravessa uma fronteira.

Um agente muda isto de três maneiras.

1. A especificação passa a ser estado vivo do projeto, em vez de um documento congelado no início. Requisitos confirmados, objetivos por decidir, restrições físicas e testes de aceitação podem ser representados em separado. Um número não confirmado continua visivelmente não confirmado, em vez de se tornar em silêncio um alvo de otimização.
2. Os artefactos de implementação são derivados, não copiados. Uma fonte de dimensionamento pode produzir netlists, testbenches, parâmetros de layout e dados de relatório. Isto não torna a divergência impossível, e implementações independentes continuam a ser essenciais, mas elimina uma classe inteira de divergências acidentais.
3. A verificação corre sempre que um pressuposto muda. O agente não precisa de se lembrar de que uma nova carga invalida um resultado de estabelecimento antigo, ou de que uma alteração de relógio afeta o testbench de um comparador. A própria relação pode fazer correr de novo as verificações afetadas.

A capacidade importante não é, portanto, o dimensionamento autónomo. É a manutenção contínua daquilo que o projeto afirma sobre si próprio.

De um bloco ao produto completo

A mudança começa dentro de um bloco analógico, mas não tem de parar na fronteira do bloco. Um chip é construído através de vários domínios: projeto analógico e de sinal misto, implementação digital, firmware, software de aplicação, e teste e produção. Cada domínio tem ferramentas maduras e pessoas que percebem a sua definição local de trabalho concluído. A parte difícil é preservar os contratos entre eles à medida que o programa muda.

Uma interface é uma afirmação sobre outro artefacto:

• uma especificação de relógio é uma afirmação sobre um circuito;
• um mapa de registos é uma afirmação sobre o RTL;
• uma garantia de driver é uma afirmação sobre firmware e hardware em conjunto;
• um limite de produção é uma afirmação sobre a relação entre simulação, caracterização e peças fabricadas.

Existem formatos estruturados para algumas destas afirmações: metadados de interface em IP-XACT¹, mapas de registos em SystemRDL², a partir dos quais é possível gerar lógica, modelos e documentação de uma só fonte. Mas a cobertura é parcial, a adoção varia, e o comportamento analógico fica em grande medida fora do que descrevem. Muitas afirmações de interface continuam a atravessar ferramentas e fronteiras de responsabilidade como documentos mantidos à mão: escritos uma vez, consumidos noutro sítio, e atualizados apenas quando alguém repara que ficaram desatualizados. O problema não é os engenheiros não saberem gerir interfaces. É que a rederivação contínua é fastidiosa, atravessa fronteiras de responsabilidade e não mostra progresso visível até evitar uma falha tardia.

Um agente ligado ao registo de engenharia poderia derivar um contrato do comportamento medido de quem o produz, registar que consumidores dependem dele, rederivá-lo depois de uma alteração e repetir as verificações afetadas. Poderia comunicar não apenas que um bloco continua a passar nos seus próprios testes, mas que um pressuposto noutro ponto deixou de ser válido.

Esperaria que essa progressão chegasse por fases. As quatro seguintes são uma arquitetura proposta e não um modelo de maturidade observado: nenhum trabalho publicado demonstra a sequência de ponta a ponta.

1. Dentro de uma via analógica. O agente dimensiona dispositivos, corre corners, produz layout, corre as verificações e mantém a evidência de um único bloco. É a fase para a qual tenho evidência direta. A investigação publicada demonstra versões mais estreitas, como agentes sem treino prévio que iteram sobre circuitos analógicos através da realimentação da simulação³; um sistema geral que cubra dimensionamento, corners, layout e verificação em conjunto não está publicamente estabelecido.
2. Entre blocos analógicos. Carga, polarização, relógio, arranque, ruído e estabelecimento passam a contratos explícitos. Uma alteração num gerador de relógio obriga a reverificar os seus consumidores face ao novo pior caso. O que se entrega deixa de ser apenas um bloco aprovado e passa a incluir uma descrição verificável por máquina do que esse bloco promete e do que pressupõe.
3. Através da fronteira de sinal misto. Os contratos passam a cobrir níveis lógicos, comportamento de reset, sincronização, sequências de calibração e semântica de registos. É aqui que a independência mais conta: um modelo gerado não pode ser aceite só por concordar com o gerador que o produziu.
4. Ao longo da cadeia do produto. As alterações de projeto chegam ao firmware, aos drivers, aos testes de produção e aos limites. Um tempo de arranque revisto chega à sequência de arranque; uma condição de falha alterada chega à API do driver. Não demonstrei esta fase, e o que a torna plausível não é um agente perceber de cada disciplina melhor do que os seus engenheiros. É que estas relações atravessam vários responsáveis e várias ferramentas, que é exatamente a razão por que hoje ninguém as verifica continuamente.

Evidência de dois blocos analógicos

As contagens de dispositivos são instâncias de esquemático antes da multiplicidade de layout, segundo a convenção de contagem dos próprios projetos.

O Claude Code⁴ usou tabelas de dispositivos pré-caracterizadas, segundo a abordagem de tabelas de consulta descrita por Jespers e Murmann⁵, avaliou 121 dimensionamentos candidatos para o oscilador através da sua infraestrutura de simulação, e construiu a automação do projeto, as entradas de simulação e a infraestrutura de verificação e de layout. Eu escolhi a topologia do oscilador, rejeitei implementações propostas para a referência de corrente, forneci restrições físicas e aprovei todas as promoções.

Para o oscilador, introduzi o circuito de forma independente no Virtuoso e corri-o no Spectre. Em 27 pontos de processo, temperatura e alimentação, o resultado comercial ficou entre 0,06% abaixo e 0,18% acima do resultado gerado em ngspice⁶, com uma diferença RMS de 0,08%. Os dois caminhos usaram netlists introduzidas em separado e simuladores diferentes, embora partilhassem o circuito pretendido, a mesma geração de modelos de processo e as mesmas definições de corner. Essa concordância próxima reduz a probabilidade de erros de netlist, de configuração e de interpretação do simulador próprios de cada caminho, nos pontos testados. Não é evidência independente de que os modelos de processo subjacentes prevejam o silício, e um erro de modelação partilhado apareceria igualmente nos dois caminhos.

O comparador deu a lição mais importante. O seu enunciado tinha quatro palavras: um comparador com offset quase nulo. O agente escolheu uma topologia, desenvolveu quatro versões e gerou um layout, e chegou a um offset referido à entrada entre −11,9 e −4,3 µV em 45 pontos PVT extraídos. O projeto estimou depois o ruído térmico do próprio circuito em cerca de 56 µV rms por decisão, maior do que o offset em todos os pontos representados. O agente tinha otimizado com êxito a grandeza pedida. A questão em aberto era se o offset, por si só, alguma vez tinha sido a grandeza certa.

O layout gerado do comparador passou nas verificações de regras de desenho e de LVS do projeto. O verificador de LVS passou também um autoteste em que foram injetadas seis falhas deliberadas e as seis foram detetadas. Em simulação extraída, o projeto atribuiu uma contribuição adicional de 0,61 µV no offset referido à entrada a 69 attofarads de acoplamento desigual provenientes da linha de strobe do latch. O resultado é um diagnóstico útil, mas o comparador não foi reproduzido num caminho de simulação comercial independente.

Estes projetos demonstram um agente competente a operar dentro de uma via analógica, sob pontos de decisão humanos explícitos. Não demonstram integração entre domínios, prontidão para produção nem fidelidade ao silício. A sua importância está em o método de trabalho apontar para além dos circuitos em si.

O que fez o ciclo agêntico funcionar

A especificação era estado executável. Os objetivos viviam num ficheiro legível por máquina, com os requisitos confirmados distinguidos dos valores provisórios e das questões em aberto, e uma regra permanente: o agente tinha de expor a incerteza em vez de otimizar em silêncio contra um palpite. As especificações analógicas tradicionais podem ficar incompletas porque o projetista fecha as lacunas enquanto desenha. Quando a implementação passa para um agente, essas lacunas ou continuam explícitas ou tornam-se requisitos acidentais. O comparador tornou isso concreto: offset quase nulo era uma direção válida mas um requisito de sistema incompleto, e o enunciado trazia contexto a menos para decidir se o que importava à aplicação era o offset, o erro total de decisão, a energia ou a latência.

Os verificadores tinham códigos de saída. Os artefactos mais valiosos não foram ideias de circuito, mas verificações que falhavam de forma bem visível: guardas de ponto de funcionamento, verificações de regras de desenho, comparação LVS e testes à própria infraestrutura de verificação. Um agente pode introduzir erros no seu código, na sua infraestrutura e na sua leitura de um simulador, e nestes projetos introduziu vários:

• alguns encontrou-os sozinho, a partir de resultados que não concordavam entre si;
• um problema de tolerância numérica precisou de uma revisão adversarial para vir ao de cima;
• uma execução sem etiqueta sobrescreveu um resultado anterior, antes de a infraestrutura ser corrigida.

A lição não é que um agente se verifica a si próprio. É que a verificação tem de ser construída como um produto separado e testável. Um verificador que nunca se mostrou capaz de rejeitar um erro conhecido é apenas mais uma afirmação por verificar.

A derivação reduziu a divergência, mas não substituiu a independência. Dados de dimensionamento partilhados alimentaram netlists, testes, parâmetros de layout e figuras, o que eliminou desacordos acidentais entre artefactos. O esquemático comercial foi deliberadamente construído por um caminho separado, para poder expor erros no caminho gerado. É por causa dessa separação que a Figura 2 significa alguma coisa: se os dois resultados viessem do mesmo gerador, uma concordância próxima provaria muito pouco. Os fluxos agênticos precisam das duas propriedades.

O agente não podia promover o seu próprio trabalho. Podia recomendar uma alteração, reunir evidência e argumentar contra a minha decisão, mas não podia transformar uma recomendação em estado do projeto. Isto não é apenas um mecanismo de segurança. Separa a implementação da autoridade, e obriga quem aprova uma transição a decidir se a evidência responde à pergunta certa.

O trabalho do engenheiro muda, mas não desaparece

O trabalho que fica para o engenheiro não são restos a limpar depois da automatização. Passa a ser a parte do projeto com mais peso no resultado, e nada do que se segue é específico da via analógica em que calhou fazer isto.

Definir o problema. O engenheiro tem de separar requisitos de valores provisórios convenientes, definir compromissos aceitáveis e dizer que incertezas ficam em aberto. Uma resposta otimizada com precisão à pergunta errada é mais perigosa do que uma resposta grosseira à pergunta certa.

Fornecer critério físico. Várias restrições nestes projetos não vinham da simulação: o que as células parametrizadas aceitam, que opções de dispositivo existem, o que se consegue desenhar de forma sensata, o que o fluxo de fabrico admite. De cada vez que o agente violou uma, a regra passou a estado explícito do projeto. Isso foi uma surpresa: conhecimento que eu tratava como tácito acabou por ser possível de escrever, assim que a sua ausência se tornou visível. O resto continua a contar, porque nenhuma simulação determina o que um cliente vai aceitar nem se um aumento de área é comportável.

Recusar respostas boas localmente. Um agente consegue defender bem um projeto que mesmo assim deve ser rejeitado. Rejeitei escolhas de referência de corrente, excluí uma opção de dispositivo e inverti uma configuração de buffer depois de olhar para a forma de onda. É aqui que o critério se concentra: na troca entre desempenho, risco, fabricabilidade, prazo e as necessidades do sistema envolvente.

Ser dono da evidência independente. Quem é responsável tem de decidir que evidência é genuinamente independente, e cada tipo tem o seu ponto cego:

• a concordância entre ferramentas expõe uma classe de erros, mas deixa intactos os pressupostos partilhados;
• as verificações de regras podem ser internamente coerentes e mesmo assim omitir uma regra;
• a extração pode identificar um mecanismo sem provar a sua magnitude em silício.

Se estes blocos seguirem para tape-out, a responsabilidade não se transfere para o agente. O meu nome vai na aprovação porque sou eu que controlo os requisitos, a evidência e a decisão de avançar.

O que as organizações vão ter de construir

Conduzir um programa desta maneira vai exigir mais do que acesso a um terminal de EDA.

• Especificações como dados. Requisitos, pressupostos, questões por resolver e testes de aceitação precisam de representações estáveis que as ferramentas leiam e as pessoas revejam.
• Interfaces como entregáveis. Um bloco tem de ser entregue com promessas e pressupostos verificáveis por máquina, e não apenas com um esquemático, um layout e um relatório.
• Verificação como infraestrutura. As verificações precisam de responsáveis, testes, versionamento e comportamento definido em caso de falha. Injetar falhas conhecidas faz parte de qualificar o verificador.
• Acesso controlado a material confidencial. Aqui, os ficheiros de modelo, os mapas de camadas e os decks da foundry ficaram no servidor de simulação; do lado do agente estavam resumos de regras e tabelas de dispositivos pré-caracterizadas, não os ficheiros de modelo. As netlists atravessavam, as medições voltavam. Isso reduz a exposição, mas se é aceitável depende da licença e da política da empresa.
• Direitos de decisão explícitos. O projeto tem de dizer o que o agente pode alterar, que evidência é exigida para uma transição e quem a pode aprovar.
• Um percurso de aprendizagem deliberado. Os engenheiros juniores aprenderam tradicionalmente o comportamento dos dispositivos a depurar detalhes de implementação. Se os agentes absorverem esse trabalho, a aprendizagem não reaparece sozinha. Os juniores vão precisar de responsabilidade direta por escrever verificadores, reproduzir resultados de forma independente, explicar falhas e argumentar contra as recomendações do agente.

Nenhum destes seis é uma compra de ferramentas. Cada um é uma mudança organizacional: quem é dono de uma interface, o que conta como evidência, com o que um bloco tem de ser entregue, quem pode aprovar uma transição. Por isso a adoção vai ser desigual, e a desigualdade não vai acompanhar quem comprou o quê. Uma equipa que rederiva os seus contratos e repete as verificações afetadas encontra os problemas de integração enquanto ainda são baratos. Uma equipa que não o faz continua a encontrá-los na integração, que é onde se perde prazo e de onde vêm os respins.

Acho que as empresas que tratarem isto como opcional vão acabar a competir com equipas que têm um caminho estruturalmente mais curto até ao silício, e vão perder terreno para elas. Isto é uma previsão e não uma observação, e assumo-a sem rigidez. O que assumo com firmeza é o formato do problema: arranjar acesso a um agente competente leva uma tarde, enquanto mudar com o que um bloco tem de ser entregue, e quem o pode assinar, leva bastante mais tempo. A vantagem fica com quem começar cedo a segunda parte, e não será visível de fora até um programa que devia ter derrapado não derrapar.

O que não muda

• O silício continua a ser o teste decisivo. Nenhum dos blocos aqui descritos chegou lá.
• A verificação tem de continuar independente daquilo que verifica. Um argumento circular perfeitamente automatizado continua circular.
• As especificações podem tornar-se executáveis sem se tornarem corretas. Alguém continua a ter de decidir o que o produto deve fazer.
• A responsabilidade continua humana. O agente pode executar a maior parte da implementação e da otimização. O engenheiro é dono da intenção, dos compromissos, da evidência independente e da decisão de avançar.

Por onde começar

Nada disto exige esperar por um sistema de projeto de chips totalmente autónomo. Quatro mudanças são úteis desde já:

1. Escrever a especificação como estado do projeto. Registar os números por decidir como por decidir, e ligar cada resultado aceite ao requisito que sustenta.
2. Tornar as interfaces verificáveis por máquina. Derivar contratos do comportamento medido sempre que possível, registar os seus consumidores e repetir as verificações dos consumidores depois de uma alteração.
3. Construir o verificador cedo, e testar o verificador. Injetar erros nas verificações e confirmar que falham, antes de confiar num resultado positivo.
4. Preservar os resultados negativos e as decisões humanas. Uma topologia rejeitada, um compromisso inaceitável e um desacordo com o agente fazem parte do registo de engenharia.

O futuro do projeto de circuitos integrados não é uma máquina a substituir o engenheiro que dimensiona os transístores, escreve o RTL ou é dono do programa de teste. É um sistema de engenharia em que a implementação se move continuamente por todos esses domínios, enquanto a intenção, a evidência e a autoridade continuam explícitas e continuam humanas. O que eu compraria não é um colega artificial que diz ser mais inteligente do que as pessoas que já estão no programa, mas um guardião paciente de cada afirmação que o programa faz sobre si próprio, que as volta a verificar sempre que alguma coisa muda e que ainda o está a fazer ao décimo primeiro mês.

Leitura adicional

Contexto sobre as técnicas de circuito e as ferramentas por trás dos dois blocos, nada disto citado diretamente acima:

• C. C. Enz e G. C. Temes, “Circuit techniques for reducing the effects of op-amp imperfections: autozeroing, correlated double sampling, and chopper stabilization”, Proc. IEEE, vol. 84, n.º 11, pp. 1584-1614, 1996
• H. J. Oguey e D. Aebischer, “CMOS current reference without resistance”, IEEE J. Solid-State Circuits, vol. 32, n.º 7, pp. 1132-1135, 1997
• B. Razavi, “The StrongARM latch”, IEEE Solid-State Circuits Magazine, vol. 7, n.º 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