O Verificador Formal Disse "Comprovado". O Chip Continuava Quebrado.

A primeira vez que uma de nossas próprias ferramentas mentiu para mim, ela o fez com educação. O motor formal retornou uma marca de verificação verde. Toda propriedade que pedimos que ela provasse voltou comprovada. A biblioteca de asserções parecia completa. No papel, o projeto estava verificado.

Levamos dois dias para perceber que o certificado não valia nada — e que tudo o que eu havia presumido sobre verificação de IA para semicondutores estava nos protegendo da falha errada.

As propriedades haviam sido geradas por um grande modelo de linguagem que envolvemos em torno do motor formal — exatamente o tipo de demonstração vistosa e agêntica de projeto de chips que todo mundo estava construindo. E o motor as havia comprovado em milissegundos, o que deveria ter sido o indício. Elas foram comprovadas porque as condições que as testariam nunca foram disparadas. Uma propriedade que diz "toda requisição acaba recebendo uma concessão" é trivialmente verdadeira se a requisição nunca pode acontecer. O solucionador não estava errado. Ele respondeu à pergunta que fizemos por acidente, e a pergunta era vazia. Esse foi o momento em que entendi contra o que esses pipelines de verificação por IA de fato precisam se defender — e por que quase ninguém que vendia um estava se defendendo da coisa certa.

Quero contar o que descobrimos, porque as classes de bugs que matam os chips modernos não são as que a indústria anuncia ser capaz de capturar. Construímos pipelines de verificação sob medida para equipes de chips fabless — modelos de pesos abertos ajustados finamente e envolvidos em torno do motor formal que a equipe já possui, rodando inteiramente no próprio hardware dela — e toda a abordagem nasceu de errarmos isso primeiro. Você pode ver o formato disso em veriprajna.com/solutions/semiconductor-ai-verification. Mas a abordagem só faz sentido depois que você viu um projeto "aprovado" falhar.

Um número que deveria assustar todo CFO de empresa fabless

Uma estatística resume o problema inteiro. O estudo de Verificação Funcional de 2024 do Wilson Research Group / Siemens EDA — o benchmark mais longevo da indústria — colocou o sucesso no primeiro silício em 14%. O menor patamar em vinte anos de monitoramento. Em 2020 esse número era de cerca de 32%. Ele mais do que caiu pela metade em quatro anos.

Essa não é uma história sobre engenheiros ficando preguiçosos. É uma história sobre a complexidade ultrapassando as ferramentas, e sobre uma especificação que sofre mutação mais rápido do que o testbench que a persegue. O mesmo estudo constatou que aproximadamente 70% dos respins são causados por erros ligados a mudanças de especificação — não por bugs puros de lógica.

O sucesso no primeiro silício não caiu porque as equipes de chips pioraram. Caiu porque a especificação agora se move mais rápido do que a verificação consegue fechá-la.

Fiquei remoendo esse número de 70% por muito tempo, porque ele silenciosamente condena muitos discursos de venda de "IA para projeto de chips". Se a maioria dos respins vem do desvio de especificação, então uma ferramenta que só captura bugs de lógica está resolvendo uma fatia do problema e chamando isso de bolo inteiro.

E o custo de errar é brutal de um jeito que o pessoal de software subestima. Um conjunto de máscaras de 5nm custa US$ 10–20 milhões. Em 3nm você se aproxima de US$ 40 milhões, com mais de setenta camadas de máscara, incluindo mais de vinte camadas EUV. Um tape-out completo de 2nm agora custa da ordem de US$ 725 milhões no total. Quando algo passa despercebido, um respin representa um atraso de 3 a 6 meses no cronograma, somado à conta das máscaras. Em uma janela de produto de dezoito meses, um atraso de seis meses pode eliminar metade da receita de todo o ciclo de vida de um chip. O CFO não enxerga a verificação como um centro de custo. Ele a enxerga como um seguro contra um único erro de oito dígitos.

Como um LLM realmente alucina em hardware?

Sua equipe já está usando LLMs em Verilog. Não vou fingir o contrário, e ninguém que vende para você deveria fingir. O campo de pesquisa agora é real — os artigos sobre LLMs escrevendo Verilog passaram de um em 2020 para sessenta e quatro em 2025. Nos problemas mais difíceis do benchmark VerilogEval, modelos da classe do GPT-4 atingem cerca de 43% de correção funcional. Úteis. Não confiáveis.

A pergunta interessante não é se os modelos ajudam. É como eles falham, porque os modos de falha não se parecem com as falhas que os engenheiros de software são treinados para temer. Depois de noites suficientes em claro encarando por que um RTL de "aparência correta" deu errado, comecei a classificar as falhas em cinco categorias.

A primeira é a inofensiva. Sintática — alucinação de código que simplesmente não compila. O Verilator ou o front-end de síntese a captura em segundos. Todo mundo já sabe lidar com isso, e é a classe que as pessoas apontam quando querem alegar que o problema está resolvido.

A segunda é onde começa a doer. Semântica — alucinação, e o caso clássico é a atribuição bloqueante versus não bloqueante. Um modelo treinado em Python e C lê Verilog como se as instruções rodassem de cima para baixo. Então ele escreve uma atribuição bloqueante — um simples = — dentro de um bloco always_ff sincronizado, onde a linguagem exige o não bloqueante <=. O projetista queria um pipeline de dois ciclos. Com atribuições bloqueantes, o segundo estágio lê o novo valor do primeiro, não o antigo, e o silício acaba entregando um bypass de um ciclo em vez disso. Alguns simuladores agendam os eventos em uma ordem que esconde totalmente a condição de corrida. Ele simula perfeitamente. Ele sintetiza para a máquina errada.

A terceira classe é a que me ensinou a manter a especificação AMBA aberta em um segundo monitor. Protocolo — alucinação. O código compila, passa em noventa por cento dos testes direcionados e então ativa um sinal de write-data-valid antes de o slave estar pronto para aceitar o endereço — uma violação do handshake AXI. Ou mantém um sinal valid em alto enquanto vira os dados por baixo dele. Ou dispara uma subcláusula enterrada na página 84 da especificação do barramento que nenhum humano memorizou. O chip funciona perfeitamente no seu ambiente de teste interno e trava no instante em que é ligado a um controlador de memória de terceiros. Você não consegue resolver isso na força bruta com mais ciclos de simulação. Você o captura com bibliotecas de asserções pré-verificadas escritas contra cada protocolo.

A quarta classe é a que nos enganou, e é a perigosa.

Por que "comprovado" é a palavra mais perigosa em um relatório de verificação?

Vacuidade — alucinação. O modelo gera uma asserção SystemVerilog. O motor formal a prova. Você fabrica. E a propriedade era trivialmente verdadeira porque seu antecedente — a parte do "se" — nunca se tornou verdadeiro em primeiro lugar.

Imagine uma propriedade de árbitro: se uma requisição é levantada, uma concessão deve vir dentro de um certo número de ciclos. Agora suponha que o mesmo modelo, tentando ser útil, também tenha escrito uma suposição que força o sinal de requisição para baixo. O motor formal obedientemente prova a propriedade de concessão em milissegundos, porque não há requisição alguma para jamais violá-la. O árbitro real por baixo pode estar completamente quebrado. O certificado diz "comprovado". Ele não vale nada.

Uma prova formal que roda em milissegundos não é rápida. É suspeita. O motor pode não ter provado absolutamente nada.

Isso não é um risco marginal. A Siemens vem publicando alertas sobre provas vácuas desde 2017, e a área ainda entrega fluxos sem verificação automática de vacuidade. Quando digo às pessoas que um fluxo de verificação formal sem detecção de vacuidade é pior do que nenhuma verificação formal, elas acham que estou sendo dramático. Não estou. Nenhuma verificação deixa você adequadamente assustado. Um "comprovado" vácuo deixa você confiante e errado, com um bloco aprovado seguindo para o tape-out. Essa é a falha que quase foi entregue em nosso próprio protótipo inicial, e mudou permanentemente o que construímos.

A quinta classe é a que a simulação estruturalmente não consegue enxergar. Cruzamento de domínios de clock — pontos cegos. Um LLM lê nomes de sinais; ele não percebe domínios de clock. Então ele conecta um sinal de um domínio de CPU de 2 GHz diretamente em um flip-flop de domínio periférico de 400 MHz, pulando o sincronizador de duplo flip-flop que previne a metaestabilidade. A simulação RTL não modela a metaestabilidade — então a regressão passa, toda vez, e o silício trava em campo. É por isso que os bugs de CDC devoram conjuntos de máscaras. É também por isso que a Accellera abriu um padrão de interoperabilidade CDC/RDC em 2024: a fragmentação entre as ferramentas comerciais de CDC havia ficado ruim o suficiente para quebrar o sign-off.

As classes dois a cinco compartilham uma propriedade aterrorizante: elas passam na simulação. Elas só aparecem no silício. Esse é o subconjunto de bugs que ainda faz os tape-outs explodirem, e é precisamente o subconjunto que um discurso de venda do tipo "captura bugs de lógica" deixa de fora.

A parede de fornecedores diante da qual uma equipe de chips realmente está

Quando fui procurar ajuda genuinamente independente em um tape-out, encontrei menos opções do que tinha alguns anos antes — e isso não é nostalgia, é a estrutura do mercado. Os três fornecedores de EDA entre os quais um líder de verificação de projeto pode de fato escolher — Synopsys, Cadence, Siemens — passaram de menos de 75% do mercado uma década atrás para mais de 85% hoje. Some a isso a aquisição da Ansys por US$ 35 bilhões e as quatro maiores controlam cerca de 90%. O campo em que uma startup fabless está fazendo compras se estreitou, não se ampliou, exatamente quando o problema ficou mais difícil.

E as empresas estabelecidas não estão paradas em relação à IA. A Synopsys lançou o AgentEngineer em março de 2026, um fluxo de trabalho de verificação agêntica que promete de duas a cinco vezes mais produtividade, e ele roda em cima do VC Formal — a pilha agêntica de fornecedor mais crível que já avaliei. A Cadence anunciou seu ChipStack AI Super Agent em fevereiro de 2026 e roda o Cerebrus AI Studio para implementação guiada por aprendizado por reforço, com o JasperGold permanecendo o motor formal padrão-ouro contra o qual todos os outros são medidos. Digo isso sem rodeios: o JasperGold e o VC Formal são genuinamente excelentes. Qualquer um que comece um discurso de venda detonando-os já lhe disse que nunca fechou um tape-out de verdade.

O problema é o preço e a postura. A linha de base histórica do JasperGold girava em torno de US$ 225 mil mais US$ 45 mil por licença — tranquilo para uma grande empresa fabless, fora do alcance das startups de RISC-V e de aceleradores de IA em estágio inicial que fazem o trabalho mais interessante. E os recursos de IA mais recentes das empresas estabelecidas são cloud-first, o que colide frontalmente com o único requisito no qual esses clientes não vão ceder. Mais sobre isso em instantes.

Depois há a onda de startups, e ela é barulhenta. No último DAC e DVCon, um líder de DV com quem trabalho havia recebido propostas de oito empresas diferentes de "IA agêntica para projeto de chips" em um único trimestre. ChipAgents levantou US$ 74 milhões até o início de 2026 e afirma ter dez vezes mais produtividade em projeto e verificação. Normal Computing levantou US$ 50 milhões liderados pelo Catalyst Fund da Samsung, construindo autoformalização — LLMs que traduzem a intenção do engenheiro diretamente em propriedades formais e as provam — e diz que metade das dez maiores empresas de projeto de semicondutores do mundo a utiliza. Há mais: a MooresLabAI gerando testbenches completos, a Bronco em análise de regressão, a Silimate em predição de potência-desempenho-área.

Algumas dessas são reais. Nenhuma delas resolve o problema real do cliente, que é o seguinte: ele agora comprou três dessas ferramentas pontuais e não faz ideia de como fazê-las funcionar juntas dentro do fluxo de sign-off no qual ele já confia.

A história do posicionamento por aprendizado por reforço que ninguém quer dizer em voz alta

Há uma tentação paralela no projeto de chips além da verificação: usar aprendizado por reforço para fazer o floorplanning físico — decidir onde os grandes blocos ficam no die. É sedutor, e o resultado mais citado é contestado de um jeito que a maioria dos discursos de venda convenientemente ignora.

O artigo de 2020 do Google na Nature afirmou que o RL supera o recozimento simulado no posicionamento de macros, e ele foi usado em silício real — gerações de TPU foram fabricadas com ele. Mas, em 2023, a Nature adicionou uma nota editorial depois que preocupações metodológicas foram levantadas. Igor Markov, agora na Synopsys, publicou uma crítica linha a linha cuja comparação central é difícil de esquecer: a abordagem de RL levou 32,31 horas, uma linha de base de recozimento simulado ajustada levou 12,5 horas, e uma ferramenta comercial da Cadence concluiu o mesmo trabalho em 0,05 hora. A DeepMind revidou com um artigo intitulado "That Chip Has Sailed." Anos depois, nenhuma replicação externa independente confirmou as alegações originais, e tanto a crítica quanto a refutação continuam em aberto.

Trago isso à tona por causa do que acontece quando um consultor propõe posicionamento por RL a uma equipe formal de verdade e finge que a controvérsia não existe. Eles farejam em menos de dez minutos, e você perdeu a sala. A posição honesta é que existem nichos genuínos — floorplanning com consciência térmica de chiplets e 3D-IC, layout analógico, otimização de IP RISC-V em ferramental aberto — onde uma abordagem híbrida se paga. Um ataque frontal aos motores de posicionamento das empresas estabelecidas não. Saber a diferença, e dizê-la em voz alta, é o trabalho inteiro.

O que mudou depois que nossa ferramenta nos enganou

Então foi aqui que o desastre da prova vácua nos levou. Paramos de tentar construir uma IA melhor que escreve Verilog, porque essa é uma corrida lotada com oito competidores financiados, e começamos a construir aquilo que nenhum deles vende: a camada de integração neutra em relação a fornecedores que torna confiáveis as ferramentas que uma equipe já tem.

Concretamente, isso significa algumas decisões, cada uma imposta por uma falha que já tínhamos visto. Nós ajustamos finamente um modelo de pesos abertos — Qwen Coder, Llama, o que servir — no próprio corpus RTL do cliente, nas especificações dele, no histórico de bugs passados dele, porque um modelo que não viu o seu estilo de casa alucina contra ele. Nós o envolvemos em torno de qualquer motor formal que a equipe já possua: JasperGold, VC Formal, Questa Formal, ou o SymbiYosys de código aberto. Nunca pedimos que arranquem a ferramenta padrão-ouro na qual já confiam. E toda propriedade que o modelo propõe passa por verificações de vacuidade e cobertura antes que alguém tenha permissão de ler a palavra "comprovado" — porque aprendemos do jeito caro que uma prova desprotegida é teatro.

As bibliotecas de asserções pré-verificadas importam tanto quanto o modelo. Para um núcleo RISC-V, o arcabouço formal já vem com as verificações de conformidade AXI4, AHB e TileLink, as asserções de hazard de pipeline, o scoreboarding de load-store, as propriedades de correção da unidade de depuração — as coisas que capturam a alucinação de protocolo e semântica antes que o silício o faça. Isso não é especulativo. A consultoria formal Axiomise encontrou mais de 65 bugs no Ibex, o núcleo RISC-V aberto dentro do OpenTitan do Google, incluindo bugs de instrução de desvio na unidade de depuração que só a verificação formal conseguiria capturar. A verificação formal funciona em RISC-V. O que é escasso não é o método; é uma equipe que sabe empunhá-lo.

A verdadeira oportunidade aqui nunca foi um modelo de Verilog mais inteligente. Foi um arcabouço honesto envolvido em torno das ferramentas caras nas quais uma equipe já confia.

Por que você simplesmente não roda na nuvem?

As pessoas me perguntam isso constantemente, e a resposta é o mesmo motivo pelo qual toda startup de EDA-IA cloud-first já nasce morta com os clientes que me importam: o RTL é a joia da coroa, e ele não sai do prédio.

O código de nível de transferência de registradores de uma empresa fabless é a empresa. Clientes de defesa e aeroespaciais precisam dele isolado por air gap, às vezes em uma instalação segura. Equipes fabless comerciais querem on-premises, nuvem privada virtual no mínimo absoluto. Então rodamos tudo no próprio hardware do cliente — inferência com vLLM ou similar no cluster H100 ou H200 que ele já tem, recuperação local sobre o próprio corpus dele, sem nenhum RTL jamais cruzando a fronteira da rede. Os recursos agênticos mais novos das empresas estabelecidas são cloud-first; isso é uma vantagem para elas e um empecilho para uma equipe de chips sensível quanto a IP. A maior oportunidade que eu vejo não é um problema de algoritmos, de forma alguma. É um problema de implantação e integração que as pessoas com os melhores algoritmos decidiram não resolver.

A outra pergunta vem das equipes automotivas, e é a que decide tudo para elas. Coloque um chip em um carro no nível ASIL C ou D — os níveis de integridade de segurança em que a ISO 26262 deixa de meramente sugerir a verificação formal e passa a exigi-la — e a própria ferramenta tem que trazer um pacote de qualificação TCL2 ou TCL3. Os motores centrais das empresas estabelecidas têm essa certificação de terceiros; uma ferramenta de IA novinha em folha não tem. Já vi uma ferramenta genuinamente melhor ser deixada de lado em um programa automotivo exatamente por esse motivo: sem pacote de qualificação, sem lugar no fluxo de sign-off, fim da conversa. Então não tentamos ser a ferramenta qualificada. Ajudamos as equipes a rodar a assistência de IA junto aos motores estabelecidos qualificados sem quebrar a cadeia de qualificação — porque, no setor automotivo, uma ferramenta tecnicamente superior que não sobrevive a uma auditoria não vale nada.

O certificado não é o chip

Eu não paro de voltar àqueles dois dias que passamos confiando em uma marca de verificação verde que não significava nada. A lição não foi "LLMs são ruins em Verilog". Eles melhoram a cada trimestre. A lição foi que, em hardware, a distância entre parece verificado e está verificado é medida em conjuntos de máscaras de oito dígitos e atrasos de seis meses — e as ferramentas que se apressam para entrar nesse espaço estão, em sua maioria, correndo para tornar mais rápida a parte do "parece verificado".

Em um conjunto de máscaras de US$ 10 milhões, um "comprovado" que você não consegue rastrear até uma prova não vácua, rodado em hardware que você controla, contra asserções escritas por alguém que leu a página 84 da especificação — isso não é verificação. É uma esperança com boa produção. Se você quiser ver como distinguimos a diferença, está tudo exposto em veriprajna.com/solutions/semiconductor-ai-verification.

O chip não se importa com o que o relatório diz. Ele só faz aquilo que o silício foi realmente construído para fazer. A verificação é a disciplina de fazer com que essas duas coisas sejam a mesma — e o momento em que uma IA lhe diz que são a mesma em milissegundos é exatamente quando você deveria pegar a especificação.