Gerar uma biblioteca de standard cells com um agente de IA

O flip-flop da Figura 1 foi gerado pelo LibreCell, um gerador de layout open-source, num processo CMOS comercial de 180 nm. O contorno a tracejado ao lado mostra o espaço exato que ocupa a célula equivalente, desenhada à mão por um engenheiro de layout profissional para uma biblioteca de standard cells de produção usada como referência interna. Essa célula não vos posso mostrar (é propriedade intelectual de produção, e é também por isso que os layouts gerados aparecem pixelizados), mas o contorno diz o essencial. Ao fim de dezoito fases de trabalho documentadas, a biblioteca gerada ocupa 1,04× a área da versão desenhada à mão, com exatamente a mesma altura de linha e sem uma única violação de LVS.

E é aqui que este artigo se afasta das outras histórias de automação de layout: a maior parte da engenharia foi feita pelo Claude Code, o agente de programação da Anthropic para a linha de comandos. Os ficheiros de tecnologia, o deck de DRC, os scripts de medição, os patches ao router, as provas de impossibilidade geométrica e o diário de bordo que serviu de fonte a este artigo saíram todos do agente, em sessões em que eu definia objetivos e revia resultados, com o agente a trabalhar de forma autónoma entre revisões.

Quero convencer-vos de duas coisas ao mesmo tempo: de que, neste caso, as ferramentas open-source para silício conseguiram ficar a 4% da qualidade de um layout artesanal, e de que um agente de IA é capaz da engenharia profunda, ingrata e guiada pela verificação que isso exige. Nenhuma das duas afirmações sobrevive ao exagero, por isso os fracassos ficam cá dentro. E há vários.

Porque é que esta experiência importa

As standard cells são os tijolos do design digital: inversores, NANDs, flip-flops, desenhados uma vez e instanciados milhões de vezes. Na empresa onde trabalho desenhamos circuitos de consumo ultrabaixo a operar perto do limiar de condução (near-threshold), o que obriga a uma biblioteca própria, desenhada à mão e cara de estender. Cada drive strength novo, cada variante de célula, custa tempo de um engenheiro de layout.

Uma biblioteca gerada muda esta equação. O layout deixa de ser um artefacto congelado e passa a ser o resultado de um build com duas entradas: as netlists e o ficheiro de tecnologia. Faz falta outro drive strength? Redimensionam-se os transístores na netlist, simula-se outra vez e regenera-se; o layout sai em minutos. Faz falta a biblioteca noutro processo? Escreve-se um ficheiro de tecnologia novo e reconstrói-se tudo: o trabalho no router e no placer descrito abaixo transita, porque corrigiu o gerador e não uma biblioteca em particular. O verdadeiro prémio desta experiência é este, iteração e portabilidade. A comparação de área serve apenas para responder a uma pergunta: quanto silício custa esse prémio?

A literatura de IA aplicada a EDA tem aqui uma lacuna curiosa. Já há LLMs adaptados ao domínio do design de chips (ChipNeMo) e agentes LLM capazes de orquestrar fluxos digitais completos de RTL a GDS (ChatEDA). A aprendizagem por reforço já gerou standard cells em nós avançados (NVCell). Mas, tanto quanto sei, não existe trabalho publicado sobre um agente LLM a fazer síntese de células ao nível do transístor contra um processo real: adaptar as ferramentas, escrever a descrição da tecnologia, depurar o router e ser avaliado por DRC e LVS. Essa interseção (agentes de IA com projeto ao nível do transístor, de sabor analógico) é precisamente a minha área, por isso fiz a experiência.

O teste é honesto porque a referência é honesta: uma biblioteca de produção, desenhada por um profissional, num processo real de 180 nm. Não é uma PDK académica nem um benchmark sintético. A pergunta nunca foi “será que uma ferramenta desenha um inversor?”; foi “até onde chega um gerador open-source, comparado com um bom humano, quando é um agente de IA a fazer o trabalho de adaptação?”.

A montagem: uma ferramenta de 2021, uma VM fechada e um processo real

O LibreCell (de Thomas Kramer) gera standard cells a partir de netlists SPICE: coloca os transístores, faz o routing com um router de congestão negociada e produz GDS e LEF. É software de investigação, sem alterações desde cerca de 2021. Por dentro é uma montra de otimização combinatória clássica: solvers SMT para a legalidade do placement, algoritmos de grafos para emparelhar transístores e um router ao estilo PathFinder, que resolve a congestão por negociação iterativa.

O ambiente de trabalho era deliberadamente espartano: uma VM Linux em ARM, sem sudo e sem git. A primeira tarefa do Claude foi simplesmente pôr a ferramenta a correr. Isso significou descarregar tarballs em vez de clonar repositórios, instalar o pip à mão dentro de uma venv que vinha sem ele, aliviar uma página inteira de versões fixadas em 2021 (uma delas com um especificador inválido que o pip moderno se recusa a aceitar) e corrigir uma ambiguidade de API introduzida pelas versões mais recentes do KLayout. Ainda na primeira sessão, um teste com uma tecnologia fictícia produziu um GDS com “LVS result: SUCCESS”. Nada disto é engenharia difícil. É o tipo de atrito que normalmente consome um fim de semana inteiro. O agente despachou-o numa hora, a narrar o que ia fazendo.

Depois começou o trabalho a sério: ensinar um processo real ao LibreCell. Um ficheiro de tecnologia do LibreCell é Python simples que define tudo: o mapeamento de camadas, os valores das regras de desenho, a grelha de routing, a geometria das células. O Claude escreveu um para o nosso alvo: uma biblioteca near-threshold com um comprimento de canal deliberadamente acima do mínimo do processo, routing em dois metais e as convenções da biblioteca de produção.

Duas restrições marcaram tudo o que se seguiu.

Não podíamos correr localmente o DRC de sign-off da foundry. Só corre em ferramentas comerciais que a VM não tinha. O Claude construiu então um deck de DRC parcial na linguagem de regras do KLayout, com as regras lógicas essenciais, e um executor em lote que resume as violações regra a regra. Este deck tornou-se o árbitro do projeto inteiro. Vale a pena parar um momento neste ponto: o agente escreveu o seu próprio examinador e passou dezassete fases a ser avaliado por ele.

O processo usa uma única camada ativa com implantes seletivos. O LibreCell quer desenhar as zonas ativas n e p como camadas separadas, por isso o Claude escreveu um passo de pós-processamento que converte a saída do gerador em bandas de implante contínuas, posicionadas de modo a que duas células encostadas fundam os implantes sem descontinuidades. O abutment (a propriedade de uma fila de células ser, no conjunto, limpa de DRC) tornou-se personagem recorrente desta história, e é mais difícil do que parece.

Os primeiros objetos com forma de silício

As três primeiras células (inversor, NAND, NOR) saíram limpas de LVS e DRC depois da habitual afinação de geometria, feita pelo próprio agente: iterar os offsets dos transístores, os parâmetros da grelha de routing e a geometria das bandas de implante contra o seu próprio deck de DRC, até as violações chegarem a zero. As primeiras lições deram o tom:

• A altura de linha é limitada pelas regras dos poços, não pelos transístores. Uma célula pode passar no LVS e mesmo assim não ser fabricável, porque as distâncias de poço não cabem. O agente aprendeu a verificar esta classe de falha antes de cantar vitória.
• O gerador não sabe criar uma célula sem transístores, por isso a célula de tap foi construída por um script próprio, parametrizado para acompanhar a geometria de linha das células lógicas e chamado pelo mesmo driver de build que o resto da biblioteca.
• “Passou no LVS” não significa “está ligado”. Quando passámos os rails de alimentação para metal-1, e mais tarde os estreitámos para a largura da biblioteca de produção, encontrámos configurações em que o LVS passava nas etiquetas de rede enquanto a ligação física à alimentação nunca chegava a ser desenhada. A resposta do Claude foi típica: escreveu um script de verificação que funde a geometria condutora real (metal, contactos, difusão, vias) em aglomerados ligados e confirma que o aglomerado de cada rail de alimentação contém pelo menos uma fonte ou um dreno de transístor. A partir daí, “rails fisicamente ligados” passou a ser uma propriedade verificada, não um pressuposto.

O bug mais fundo deste período estava na própria ferramenta e cabia num carácter: o gerador da grelha de routing usava um intervalo exclusivo, pelo que a track que devia assentar no rail de alimentação superior nunca chegava a ser criada. As fontes dos PMOS ficavam sem caminho até VDD, com o LVS sempre a passar nas etiquetas. A correção foi pequena. Encontrá-la exigiu que o agente deixasse de confiar na abstração e fosse ver o grafo de routing propriamente dito.

Acrescentámos ainda uma arquitetura de linha com quatro rails (rails de polarização de substrato separados, acima e abaixo dos de alimentação) para body biasing, uma exigência do nosso estilo de projeto de baixa fuga que o pós-processador de implantes e a célula de tap tiveram de acomodar.

O diagnóstico inicial: 2×

Chegou então o teste a sério: a biblioteca de produção, três dezenas de células entre inversores e flip-flops com set e reset, em netlists no formato de produção, mais o GDS desenhado à mão como referência. O Claude escreveu o conversor de netlists (incluindo inferir a direção dos ports a partir de netlists planas, coisa que acertou à primeira), fez o bring-up da biblioteca à altura de linha de produção, e medimos.

As células geradas tinham, grosso modo, o dobro da área das desenhadas à mão.

Começou aqui o arco mais longo do projeto. A primeira ronda de cirurgia atacou a largura:

• Um modelo de router consciente dos pads de via. O router tratava cada nó da grelha como se pudesse vir a receber um pad de contacto completo, o que impunha um pitch de routing grosseiro em todo o lado. O Claude reescreveu o modelo de conflitos: só as posições que têm mesmo uma via projetam zonas de exclusão do tamanho de um pad, os fios simples usam zonas do tamanho de um fio, e as vias vão sendo desencontradas dinamicamente em vez de a grelha inteira pagar por todas elas. O flip-flop principal passou de 18,7 µm para 12,5 µm de largura.
• Espaçamento variável entre gates. As células à mão põem as gates ao pitch mínimo do poli onde a difusão é partilhada, e ao pitch com contacto apenas onde tem de caber um contacto entre gates. O Claude acrescentou isto ao placer. O flip-flop chegou à mesma largura da célula à mão, uma redução total de 44%.

Esta fase deixou também o residual honesto mais teimoso do projeto: com tudo compactado, um punhado de células densas ficou com espaçamentos abaixo do mínimo entre cabeças de contacto de poli vizinhas, uma classe de violação que levaria mais cinco fases a compreender de verdade.

Os requisitos de qualidade de uma biblioteca a sério

Uma biblioteca de standard cells é mais do que células pequenas. Ao longo de duas fases fui subindo a fasquia com os requisitos que uma equipa de physical design imporia: rails de alimentação com a largura da biblioteca de produção, redes de clock tratadas primeiro pelo router e mantidas curtas nas células sequenciais, e nunca mais de duas gates penduradas na mesma rede de poli.

Cada um destes pontos parece uma flag de configuração; nenhum era. Os rails estreitos expuseram o bug da track em falta. O routing do clock em primeiro lugar revelou-se uma questão de ordem, e nada mais: o Claude começou por também descontar os custos das arestas da rede de clock, mediu, e descobriu que o desconto piorava o comprimento do fio (a rede começava a desviar-se para contornar os custos dos nós). Ganhou a ordenação pura por prioridade, medida em −12% de comprimento de clock no flip-flop principal, com as células combinatórias comprovadamente idênticas por XOR de camadas. A regra do poli começou por ser imposta proibindo por completo o poli horizontal, o que mais tarde se revelou demasiado bruto. Já lá vamos.

A campanha de densidade: aprender com o humano

Resolvidas as larguras, todo o excesso que restava era vertical. Dei a instrução que definiu o resto do projeto: estuda as células feitas à mão e aprende como é que elas conseguem.

O Claude escreveu um script de análise e dissecou programaticamente o flip-flop feito à mão. As conclusões parecem o repertório de truques de um projetista de layout: a maior parte das cabeças de contacto de poli desviada da coluna da gate com poli em L; cabeças em posições verticais livres, no canal entre as filas de transístores; pitch de gate misto, apertado onde a difusão é partilhada e folgado onde os contactos precisam de espaço; zonas ativas encostadas aos rails de alimentação à distância mínima; e o segundo metal quase por usar.

Cada observação virou uma alteração:

• O poli em L voltou a ser permitido. A regra das duas gates por rede de poli passou a ser verificada depois da geração, em vez de se proibir o poli horizontal. Mede-se a propriedade que interessa; não se proíbe o mecanismo.
• A grelha de routing ganhou meio passo na vertical, dando ao router uma liberdade parecida com a humana para desencontrar as cabeças de contacto.
• E depois uma sequência de correções ao modelo do router, todas encontradas da mesma maneira: uma célula falha o routing, o agente lê o diagnóstico, percebe onde o modelo está errado sobre a realidade física e corrige o modelo. O próprio diagnóstico foi a primeira correção. O Claude transformou a exceção seca “Failed to route” num relatório que identifica os nós da grelha em disputa, as redes em conflito e o mecanismo pelo qual cada rede reclama o nó (fio próprio, espaçamento ou zona de exclusão de pad de via). Todas as correções seguintes nasceram de um destes relatórios: pads de via fantasma projetados por nós terminais virtuais, fugas na diagonal por se usar a norma de distância errada nas zonas de exclusão, colisões a meio de segmento que escapavam a verificações feitas só nos extremos, terminais de gate afunilados num único nó da grelha quando havia várias linhas fisicamente válidas.

Um momento desta fase ensinou-me mais sobre engenharia com agentes do que qualquer benchmark. Uma build anterior tinha feito o routing “com sucesso” a uma altura mais baixa, e o Claude descobriu que o sucesso era falso: as rotas só cabiam por buracos no modelo de legalidade. Corrigir o modelo piorou o resultado no papel (o mínimo subiu duas tracks), e o agente disse-o tal e qual, sem lhe ser pedido: o modelo honesto encolhe menos a geometria do que o modelo furado. Quem quiser confiar nas vitórias de um agente, repare na forma como ele relata as derrotas.

A altura do core desceu de 1,21× para 1,107× da versão à mão, com a maior parte da biblioteca já com a folga de rail exatamente igual à da referência.

Paridade de altura, e a prova de que três células não podem ser perfeitas

O objetivo seguinte foi concreto: área total do core até 1,10× da referência, DRC e LVS limpos. O primeiro passo do Claude foi uma auditoria vertical célula a célula, à mão contra gerada, que encontrou logo o desperdício restante: nas células à mão, a zona ativa tem exatamente a altura da largura do transístor; nas nossas era um pad de contacto mais alta, porque o gerador pousava o contacto inferior de fonte/dreno na primeira track de routing, com o pad de difusão a sair para fora do canal. As células à mão mantêm esse pad dentro do canal.

A correção parece trivial e não é: desacoplar a posição vertical do transístor da grelha de routing. Com o limite da zona ativa colocado de forma independente e o contacto a cair dentro do canal, as células desceram para a altura exata da biblioteca à mão, 10,0 µm de rail a rail, na maior parte da biblioteca.

As células com muitas cabeças (flip-flops, latch, mux, família XOR) precisaram de uma segunda ideia, e esta o agente deduziu-a geometricamente em vez de a procurar por tentativas: subir as zonas ativas apenas o suficiente para que a base do poli das gates fique afastada de uma fila de contactos junto ao rail exatamente pela regra de espaçamento do poli. Numa combinação específica de altura de linha, pitch de routing e offset, aparece uma fila de cabeças de contacto totalmente legal em todas as colunas de gate, junto a cada rail, e os flip-flops passam a ter routing limpo. Os patamares de “offset elevado” das fases anteriores tinham sido ilegais desde o início (pads de cabeça a escassas dezenas de nanómetros das gates vizinhas: a origem daquela classe teimosa de violações). O modelo novo recusou-se simplesmente a construí-los, e o patamar legal ocupou o lugar.

Depois veio o bloqueio: XOR, XNOR e mux continuavam com violações, fosse qual fosse o offset. O Claude tentou cerca de 25 configurações: seed sweeps, duas grelhas mais finas, o placer hierárquico, que resolvia o problema à custa de duas colunas adicionais, segundo metal com custo reduzido, bloqueio do segundo metal vertical, menor penalização para mudanças de direção, offsets assimétricos e uma variante do modelo de custos do router. Depois parou de procurar e fez melhor: demonstrou que o limite era geométrico. Uma fila legal de cabeças junto ao rail exige as zonas ativas acima de uma certa altura; posições legais a meio do canal exigem-nas abaixo de outra, mais baixa. Os intervalos não se cruzam. As células à mão escapam porque um humano pré-coloca cabeças em L ao nível do transístor, sem grelha de routing nenhuma, coisa que o gerador pura e simplesmente não sabe fazer. Três células ficam por isso com uma pequena classe residual de violações, documentada, atrás de uma exceção explícita no modelo, e o sistema de build di-lo em voz alta.

Sublinho a sequência: um agente que para de queimar computação e prova a impossibilidade está a fazer engenharia, não uma busca cega.

Resultado da fase: altura de linha igual à da biblioteca à mão, área em 1,096×, 29 de 32 células totalmente limpas. Uma biblioteca de standard cells é uma conspiração de restrições à escala do milímetro que têm de se entender à escala do nanómetro.

A reta final da largura

O último esforço atacou os 9,6% que faltavam: largura. Duas descobertas fecharam quase tudo.

Todas as células carregavam a mesma margem morta nas extremidades. Os pads de contacto exteriores ficavam a uma regra de espaçamento inteira da fronteira da célula, mas o abutment só exige meia regra de cada lado; a outra metade é trazida pela célula vizinha. Essa margem, aparada dos dois lados de todas as células, devolveu 7,7 µm ao conjunto da biblioteca, encontrada por um script de medição e recolhida por um passo de corte no pós-processamento.

O corte deu origem ao melhor bug apanhado por verificação em todo o projeto. A primeira implementação classificava as formas de metal “tipo rail” pela bounding box e substituía-as por retângulos, sem saber que o gerador escreve o metal-1 de cada rede como um único polígono fundido: rails, ligações e pads, tudo junto. A substituição transformou uma rede de alimentação inteira numa placa maciça de metal: redes em curto que o DRC, sozinho, não apanharia. Foi detetado porque o agente comparava a área de metal entre builds como verificação de sanidade, viu +145% e foi investigar. A correção (recortar, nunca substituir) tem duas linhas. O hábito que a encontrou é que é a metodologia toda.

Os placements são estáveis com a seed, exceto quando não são. Um seed sweep nas células maiores mostrou quase todas a convergir para a mesma largura, menos o maior flip-flop, que numa seed específica saiu 5% mais estreito e limpo de DRC. E depois a partida: regenerado dentro do sistema de build, com a mesma seed, voltou a sair largo. A ordem de placement da ferramenta é sensível ao contexto do processo, para lá da seed aleatória. Em vez de perseguir o não-determinismo, a célula estreita verificada ficou guardada como artefacto no repositório, com a história documentada.

As contas finais:

E os 4% que restam? Não têm nada de misterioso. São o imposto do pitch com contacto: os nossos contactos de fonte/dreno são nós da grelha de routing, o que empurra o pitch de gate com contacto para o pitch da grelha, enquanto o humano coloca os contactos fora da grelha, ao mínimo físico. A lista de excesso por célula lê-se como uma classificação por número de intervalos com contacto: o flip-flop grande, os buffers de clock, as gates de drive alto. Sabemos exatamente onde mora cada nanómetro da diferença.

Sign-off numa ferramenta comercial

Tudo o que ficou descrito foi avaliado pelo deck interno em KLayout, que é parcial por construção. Com a biblioteca congelada, corremos a prova verdadeira: os decks de sign-off de DRC e LVS da foundry, numa ferramenta comercial, sobre a biblioteca completa. O LVS bateu certo em todas as células. O DRC confirmou o veredicto interno: as violações limitam-se à classe residual prevista das três células, mais uma violação avulsa no half-adder. O árbitro que o agente construiu para si próprio, a partir de um subconjunto das regras, previu o resultado do sign-off.

Como é, na prática, um agente de IA a fazer layout

Tudo isto é também um relato de campo sobre trabalhar com o Claude Code num problema à escala de meses: dezoito fases documentadas de sessões supervisionadas. O método que se foi formando: eu definia um objetivo (“área total até 1,10×, DRC e LVS limpos”, mais tarde “chegar à paridade”) e o agente planeava, explorava, construía e verificava sozinho, com generation sweeps e batches de DRC a correr em segundo plano, e no fim escrevia a sessão no diário de bordo do projeto, que ele próprio mantinha. Este artigo nasce desse diário. O agente documentou os próprios fracassos suficientemente bem para eu agora os poder citar contra ele.

No que era genuinamente bom:

• Exploração sistemática sem cansaço. Dezenas de configurações do router, seed sweeps e testes de altura, executados e registados sem fadiga e sem apego a nenhum deles.
• Ler e reparar código de investigação. As correções ao router são cirurgia algorítmica a sério numa base de código desconhecida, guiada por diagnósticos que o próprio agente acrescentou.
• Medir antes de opinar. Quase todas as afirmações sobre as células à mão vieram de um script a interrogar o GDS, não de olhar para imagens.
• Resultados negativos, ditos com todas as letras. “O modelo honesto piora o resultado”, “o sucesso era falso”, “isto é geometricamente impossível e aqui está a prova”: tudo passagens literais do diário.

Onde precisou de mim:

• Objetivos e critérios de aceitação. “Limpo de DRC” é uma questão de critério quando o deck é parcial e uma classe de violações é comprovadamente impossível de eliminar sem novas capacidades na ferramenta. Decidir que três células podiam ficar com um residual documentado coube-me a mim, não a ele.
• Mudanças de rumo. “A célula tem o dobro da largura”, “para, vai estudar as células à mão”: as frases mais decisivas do projeto foram todas humanas.
• Ceticismo por encomenda. O agente verifica aquilo que se lembra de verificar. O hábito de exigir verificações de conectividade física, comparações de área e filas de abutment nasceu de cada bug que escapou, e o agente automatizou depois esse ceticismo em definitivo.

E os modos de falha, sem rodeios: cerca de 25 becos sem saída numa família de células antes de recuar e provar a impossibilidade; um bug de pós-processamento que teria posto redes de alimentação em curto se não existisse uma verificação de sanidade; e um placement irrepetível que teve de ficar guardado como peça de museu. Nenhum destes é desqualificante. São todos familiares. São os modos de falha de um engenheiro: um engenheiro incansável, rápido, por vezes teimoso de mais, que documenta tudo.

O que falta, e conselhos para quem quiser tentar

A paridade completa exige duas capacidades estruturais no gerador, ambas agora especificadas ao detalhe pelos becos sem saída deste projeto: contactos de fonte/dreno fora da grelha (para recuperar o imposto do pitch com contacto) e pré-colocação de cabeças de poli em L ao nível do transístor (para limpar as últimas três células). São projetos de router e de placer, não de configuração. Depois disso: extração de parasitas e caracterização de timing, que ainda não começámos. A recompensa por fechar o fluxo de ponta a ponta é aquela que o layout à mão nunca dará: uma biblioteca que se redimensiona, se volta a simular e se otimiza em ciclo, e um porte para o processo seguinte que começa num ficheiro Python, em vez de meses a empurrar polígonos.

Se quiserem tentar algo assim, com qualquer processo, qualquer gerador e qualquer agente de IA:

1. Construam o árbitro primeiro. Um deck de DRC executável e uma verificação de LVS, por parciais que sejam, transformam todas as afirmações seguintes em factos de passa ou não passa. Os agentes dão-se bem com árbitros.
2. Ponham o agente a medir a referência, não a descrevê-la. Scripts que interrogam a geometria do layout valem mais do que qualquer quantidade de olhar para imagens, incluindo as do próprio agente.
3. Definam os objetivos como predicados verificáveis (“área ≤ 1,10×, DRC limpo, LVS limpo”) e deixem-no trabalhar. A autonomia é real, mas vale o que valer o predicado.
4. Mantenham um diário de bordo desde o primeiro dia, escrito pelo agente. O meu serviu ao mesmo tempo de memória de longo prazo do agente entre sessões e de fonte para este artigo.
5. Exijam resultados negativos. As saídas mais valiosas deste projeto foram um mínimo que subiu, um falso sucesso desmascarado e uma prova de impossibilidade. Um agente que só relata progresso é um agente em quem não se pode confiar.

A biblioteca desenhada à mão levou muito tempo a um profissional, e nota-se. Li aquelas células com mais atenção do que qualquer layout que eu próprio tenha desenhado, e o respeito é enorme. Pôr um gerador open-source e um agente de IA a 4% desse trabalho, com a mesma altura de linha e a diferença discriminada ao nanómetro, custou dezoito fases documentadas. Os últimos 4% também não são magia. Estão à distância de duas funcionalidades bem especificadas. E não há nenhuma lei física que obrigue a biblioteca gerada a parar na paridade com o humano. Este projeto não tentou ultrapassar as células desenhadas à mão; tentou apenas igualá-las com um gerador a que ainda faltavam duas capacidades estruturais de layout.

Os patches ao LibreCell vivem, para já, num fork privado; terei todo o gosto em discutir os detalhes não confidenciais. A metodologia, essa, não precisa de licença nenhuma.

Referências

1. T. Kramer, LibreCell: layout generator for CMOS standard cells, codeberg.org/tok/librecell
2. M. Liu et al., “ChipNeMo: Domain-Adapted LLMs for Chip Design,” arXiv:2311.00176, 2023
3. Z. He et al., “ChatEDA: A Large Language Model Powered Autonomous Agent for EDA,” arXiv:2308.10204, 2023
4. H. Ren and M. Fojtik, “NVCell: Standard Cell Layout in Advanced Technology Nodes with Reinforcement Learning,” Proc. DAC, 2021, research.nvidia.com
5. KLayout: high performance layout viewer and editor, klayout.de
6. Claude Code, Anthropic, claude.com/claude-code