O Bug de US$ 10 Milhões Que a IA Escreveu — E Por Que Fundei uma Empresa para Eliminá-lo

Eu me lembro do momento exato em que decidi criar a Veriprajna.

Não foi um lampejo de inspiração. Foi um telefonema. Do tipo em que ninguém fala nos primeiros cinco segundos porque a pessoa do outro lado está tentando descobrir como dizer o que precisa dizer. Uma equipe de projeto — pessoas que eu respeitava, pessoas que eram genuinamente boas no que faziam — tinha acabado de receber o primeiro silício de volta da fundição, um acelerador RISC-V customizado. O chip estava morto. Não morto no sentido de "precisa de uma solução alternativa". Não morto no sentido de "podemos corrigir no firmware". Inutilizado. Sob um alinhamento específico e raro de throttling térmico e tráfego de memória de alta largura de banda, o módulo de arbitragem entrou em um estado indefinido e a coisa toda travou em deadlock.

A causa raiz foi uma condição de corrida. Uma única e sutil incompatibilidade entre atribuições bloqueantes e não bloqueantes no RTL — o tipo de coisa que simula perfeitamente, passa pelo lint sem um sussurro, passa em todos os testes de regressão que você jogar contra ele e então te trai no silício, onde não há segunda chance.

O conjunto de máscaras para aquele chip de 5nm custou cerca de US$ 10 milhões. Perdido. Mas o dano real não foram as máscaras. Foram os seis meses necessários para diagnosticar, corrigir, reverificar e refabricar. No mercado de aceleradores de IA, onde as gerações de produto duram cerca de 18 meses, um atraso de seis meses pode corroer 50% do lucro bruto total ao longo de toda a vida útil de um produto. Para uma empresa que mira US$ 100 milhões em receita, aquela condição de corrida não custou US$ 10 milhões. Custou US$ 50 milhões.

E aqui está a parte que me tirava o sono à noite: o código que a causou foi gerado por um LLM.

A Corrida do Ouro Que Ninguém Está Questionando

Neste momento, a indústria de semicondutores está no meio de uma corrida do ouro. Todo mundo — e eu digo todo mundo — está numa corrida para plugar Grandes Modelos de Linguagem no fluxo de trabalho de Automação de Projeto Eletrônico (EDA). O discurso é irresistível: pegar ciclos de projeto que costumavam durar anos e comprimi-los para meses. Democratizar o projeto de chips. Deixar a IA cuidar da tediosa codificação em nível de transferência entre registradores para que os engenheiros possam se concentrar na arquitetura.

Eu entendo o apelo. Eu mesmo já o senti. Na primeira vez que vi um LLM gerar um módulo Verilog sintaticamente correto a partir de um prompt em linguagem natural, pensei: isso muda tudo.

Mas então comecei a olhar com mais cuidado para o que "sintaticamente correto" realmente significa quando você está escrevendo hardware em vez de software. E percebi que a indústria estava construindo sobre uma fundação de areia.

As ferramentas que inundam o mercado agora são o que eu chamo de "Wrappers" (invólucros). Elas pegam um LLM de propósito geral — GPT-4, Claude, Llama — envolvem-no em uma interface de chat com alguns prompts de sistema com sabor de Verilog e o vendem como um "Copiloto de Projeto de Chips". Alguns deles são demonstrações genuinamente impressionantes. O código parece limpo. Ele compila. Ele até simula.

Mas aqui está o que essas ferramentas fundamentalmente são: preditores estocásticos de tokens com uma casca de hardware. Elas não entendem a topologia do circuito. Não entendem o fechamento de temporização (timing closure). Não entendem a metaestabilidade. Elas preveem o próximo token provável com base em padrões estatísticos em seus dados de treinamento.

Quando um LLM alucina em software, você recebe um erro de tempo de execução que pode corrigir remotamente. Quando um LLM alucina em hardware, você recebe um peso de papel de US$ 10 milhões.

Essa assimetria é a razão inteira de a Veriprajna existir.

Por Que a IA Escreve Código de Hardware Ruim?

Esta é a pergunta que mais me fazem, geralmente por engenheiros de software que viram LLMs escrever Python perfeitamente funcional e não conseguem entender por que Verilog é diferente. A resposta vai mais fundo do que "hardware é mais difícil". É uma incompatibilidade fundamental entre como os LLMs pensam e como o hardware funciona.

Os LLMs são treinados esmagadoramente em software — Python, Java, C++, JavaScript. Essas são linguagens imperativas e sequenciais. A Linha A executa, depois a Linha B. O estado do sistema é definido pela ordem das operações. Os LLMs internalizaram esse paradigma tão profundamente que ele é basicamente sua língua materna.

Verilog e VHDL são declarativas e concorrentes. Em um módulo de hardware, cada bloco always, cada instrução assign, cada instanciação de módulo executa simultaneamente e continuamente. A ordem das linhas no código-fonte muitas vezes não tem nenhuma relação com a ordem de execução no silício.

Vi isso acontecer em tempo real durante um de nossos primeiros experimentos. Pedimos a três LLMs de ponta diferentes que implementassem um simples registrador de pipeline de três estágios. Todos os três usaram atribuições bloqueantes (=) em vez de atribuições não bloqueantes (<=). O código parecia perfeitamente razoável se você o olhasse de soslaio como se fosse código C. Mas em hardware, atribuições bloqueantes em um bloco síncrono significam que stage2 é atualizado com o valor de stage1 imediatamente, e então stage3 recebe o valor novo de stage2 — colapsando efetivamente um pipeline de dois ciclos em um único ciclo.

Uma das minhas engenheiras, Priya, encarou a saída por um minuto e disse: "Ele está escrevendo C com ponto e vírgula nos lugares errados." Ela estava exatamente certa. O LLM tinha viés sequencial — ele estava tratando Verilog como uma linguagem de programação quando ela é, na verdade, uma linguagem de descrição. A distinção é sutil sintaticamente e catastrófica fisicamente.

E fica pior. O projeto de hardware depende de protocolos de interface rígidos — AXI, AHB, PCIe, TileLink — com regras temporais complexas. "Ready não pode esperar por Valid." "Grant deve ser asserido dentro de 5 ciclos." Os LLMs conseguem gerar código que respeita essas regras 90% do tempo, o que soa ótimo até você perceber que os 10% que ele erra são precisamente os casos extremos que matam chips. Um mestre AXI que asserta WVALID antes de AWREADY em uma violação de subcláusula específica não lançará um erro de sintaxe. Ele compilará, simulará e então travará quando conectado a um controlador de memória em conformidade no silício.

O problema dos dados de treinamento agrava tudo. O volume de Verilog de alta qualidade e de nível de produção disponível para treinamento é ordens de magnitude menor do que o de Python ou JavaScript. Grande parte do Verilog de código aberto no GitHub são projetos de estudantes, protótipos abandonados, implementações de brinquedo que jamais sobreviveriam a uma revisão de tape-out. Quando você treina com dados medíocres, obtém saídas medíocres — saídas que parecem profissionais, mas contêm o DNA de erros de amador.

A Regra Que Assombra Todo Projetista de Chips

Existe uma heurística no projeto de semicondutores chamada "Regra dos Dez" e, uma vez que você a entende, entende por que sou tão obcecado por pegar bugs cedo.

O custo para corrigir um defeito aumenta em 10x a cada estágio subsequente do ciclo de vida do projeto. Um bug pego durante o projeto RTL custa cerca de US$ 100 para corrigir — alguém edita um arquivo e roda novamente uma verificação. O mesmo bug pego durante a verificação de bloco custa US$ 1.000. Na verificação de sistema, US$ 10.000. Se ele escapar para a validação pós-silício — quando você está depurando chips reais em um laboratório — você está olhando para US$ 10 milhões ou mais para um respin. E se ele chegar aos clientes em campo? Aí é território de US$ 100 milhões. Recalls, processos judiciais, destruição da marca. Pergunte à Intel sobre o bug FDIV do Pentium.

As ferramentas de IA Wrapper operam quase exclusivamente no estágio de projeto RTL. Elas ajudam os engenheiros a escrever código mais rápido. Mas, como carecem de qualquer capacidade de verificação além de "ele compila?", elas injetam bugs que passam batido pela verificação de bloco e de sistema, apenas para detonar no silício.

Aqui está a ironia cruel: ao aumentar a velocidade de geração de código sem aumentar o rigor da verificação, essas ferramentas aceleram a injeção de defeitos de alto custo no pipeline. Você não está apenas indo rápido e quebrando coisas. Você está indo rápido e assando bugs dentro de conjuntos de máscaras de US$ 10 milhões.

Os dados da indústria comprovam isso. Apenas 32% dos projetos alcançam sucesso no primeiro silício. Os 68% restantes exigem pelo menos um respin, e a causa principal são falhas lógicas e funcionais — exatamente o tipo de erro que os LLMs geram quando alucinam protocolos ou entendem mal a concorrência.

Expliquei isso a um investidor certa vez, no início da nossa captação de recursos. Ele escutou com paciência e então disse: "Você não pode simplesmente usar o GPT-4 com prompts melhores?"

Puxei o exemplo do registrador de pipeline. Mostrei a ele o bug da atribuição bloqueante. Mostrei que ele passava no lint, passava na simulação, passava em todas as verificações automatizadas que as ferramentas Wrapper ofereciam. Depois mostrei o que ele faria no silício.

Ele não perguntou de novo sobre prompts melhores.

E Se Você Pudesse Provar Que o Código Está Correto em Vez de Apenas Testá-lo?

É aqui que a história vira. Porque a resposta para o problema da alucinação dos LLMs não são prompts melhores, modelos maiores ou mais dados de treinamento. É uma abordagem fundamentalmente diferente para a verificação.

A verificação tradicional depende de simulação — você escreve testbenches, roda milhões de ciclos e verifica se o projeto faz o que você espera. Isso é como testar os freios de um carro dirigindo ao redor do quarteirão mil vezes. Se os freios não falharem, você presume que estão seguros. Mas e se eles só falharem quando está chovendo, você está indo exatamente a 100 km/h e o rádio está sintonizado em uma frequência específica? A simulação só pode verificar os cenários que ela testa explicitamente. Todo o resto é uma prece.

A Verificação Formal não roda o projeto de forma alguma. Ela converte o projeto inteiro em uma fórmula matemática e usa solucionadores de Teorias do Módulo de Satisfatibilidade (SMT) — ferramentas como o Z3 da Microsoft — para provar exaustivamente que uma propriedade se mantém sob todas as combinações possíveis de entrada e estado interno. Cada uma delas. Não uma amostra. Não uma aproximação estatística. Uma prova matemática.

A simulação pergunta: "Isso funciona nos casos que testei?" A verificação formal pergunta: "Existe algum caso possível em que isso falha?" A diferença é a diferença entre esperança e prova.

Quando o solucionador retorna "UNSAT" — insatisfatível — significa que não existe nenhum contraexemplo. A propriedade é matematicamente garantida. Quando ele retorna "SAT", ele te entrega uma sequência específica de entradas que quebra seu projeto, até o exato ciclo de clock.

A verificação formal existe há décadas. A razão pela qual ela não dominou a indústria é que escrever as propriedades formais — Asserções SystemVerilog, ou SVA — é notoriamente difícil. Requer um conjunto de habilidades especializado que a maioria das equipes de projeto não tem. As asserções são o "contrato" para o hardware: "Se request sobe, grant deve seguir dentro de N ciclos." "O dado lido do endereço X deve corresponder ao último dado escrito no endereço X." "O pipeline nunca deve entrar em deadlock." Escrevê-las corretamente é uma forma de arte, e não há praticantes suficientes para atender à demanda.

O que é exatamente onde a IA se torna útil — não para escrever o código de hardware, mas para escrever a prova.

O "Sanduíche Formal" — Como Realmente Construímos Isto

Passei meses discutindo com minha equipe sobre a arquitetura certa. O debate foi acirrado e, em retrospecto, esclarecedor. Um lado queria fazer um fine-tuning de um LLM até que ele gerasse Verilog correto por padrão. O outro lado — aquele com quem eu acabei concordando — argumentava que correção por treinamento era uma fantasia. Você não pode treinar para eliminar a alucinação. Você só pode pegá-la.

Chegamos ao que chamamos de "Sanduíche Formal" — uma arquitetura neuro-simbólica onde o LLM é o motor criativo e um solucionador de verificação formal é o crítico inflexível. Nenhum funciona sozinho. Juntos, eles fazem algo que nenhum consegue fazer independentemente.

Veja como isso funciona na prática. Um projetista fornece uma especificação — "Projete uma ponte APB-para-AXI" ou até mesmo uma captura de tela de um diagrama de temporização. Nosso agente Analisador de Especificação decompõe isso em requisitos funcionais. Então vem a inovação central: em vez de gerar apenas código, o LLM gera dois artefatos simultaneamente.

O Artefato A é a implementação RTL — o próprio código Verilog. O Artefato B é a especificação formal — um conjunto de propriedades SVA derivadas dos mesmos requisitos. Se a especificação diz "Grant deve seguir Request", o LLM gera a máquina de estados e a asserção que prova que a máquina de estados faz o que afirma.

Então liberamos o solucionador. Ele pega o Artefato A e tenta quebrá-lo usando o Artefato B. Primeiro, uma verificação de vacuidade — garantindo que as asserções não sejam trivialmente verdadeiras (uma geração "preguiçosa" em que a condição de disparo nunca é acionada). Depois, verificação de modelos limitada (bounded model checking), explorando espaços de estado profundos — 50, 100 ciclos de profundidade — caçando deadlocks, condições de corrida, violações de protocolo.

Se o solucionador encontra um bug, ele não apenas o sinaliza. Ele produz um traço de contraexemplo — uma forma de onda precisa mostrando exatamente como o bug se manifesta. E é aqui que o laço se fecha: alimentamos esse traço de volta no LLM como um prompt. "Seu projeto falhou. Aqui está o traço: Ciclo 1, Reset é desasserido. Ciclo 2, Request sobe. Ciclo 10, Grant ainda está baixo. O grant nunca chegou. Corrija a máquina de estados."

O LLM analisa o traço, identifica a transição de estado que faltava, reescreve o código. O solucionador verifica novamente. Esse laço se repete automaticamente até que o projeto seja provado correto.

Escrevi sobre essa arquitetura com muito mais profundidade na versão interativa da nossa pesquisa, mas o insight central é simples: usamos IA para escrever a prova e matemática para verificar a IA. Nenhum confia no outro. Ambos tornam o outro melhor.

Os Bugs Que Me Tornaram um Crente

Tornei-me um verdadeiro crente nessa abordagem não pela teoria, mas por bugs específicos que pegamos e que nada mais teria encontrado.

A comunidade RISC-V de código aberto produziu núcleos de processador genuinamente excelentes — o Ibex (usado no chip de segurança OpenTitan do Google), a plataforma PULP da ETH Zurich. Esses são projetos rigorosamente escrutinados, com talento de engenharia real por trás deles. E ainda assim eles contêm bugs que apenas a verificação formal consegue encontrar.

A Axiomise, uma consultoria de verificação formal, encontrou um bug no núcleo Ibex em que uma requisição de depuração que chegasse em um ciclo específico durante uma instrução de desvio poderia fazer o núcleo entrar em deadlock ou executar a instrução errada. Pense nisso — um núcleo crítico para a segurança, revisado por dezenas de engenheiros, e uma ferramenta formal encontrou um bug que a simulação deixou passar completamente.

Na plataforma PULP, foi encontrado um bug em que a interconexão AXI poderia deixar um mestre de barramento indefinidamente sem acesso sob um padrão "ocupado" específico de interações de AWVALID e AWREADY. Uma clássica falha de vivacidade (liveness) — o sistema não trava, ele apenas para de progredir. Você nunca escreveria um teste direcionado para aquele padrão de interação específico. Há padrões possíveis demais para enumerar.

Quando apontamos a Veriprajna para uma Unidade de Load-Store de um RISC-V, ela gera automaticamente asserções para conformidade de interface ("se valid é asserido, deve permanecer alto até ready"), integridade de dados ("o dado lido do endereço X corresponde à última escrita no endereço X") e progresso adiante ("a unidade deve eventualmente retornar uma resposta"). Essas não são reflexões tardias aparafusadas ao código. Elas são geradas junto com o código, a partir da mesma especificação, e impostas antes que uma única linha de RTL saia do nosso sistema.

Para o detalhamento técnico completo da nossa metodologia e do motor de verificação formal, veja nosso artigo de pesquisa detalhado.

"Mas a Verificação Formal Não Escala"

As pessoas sempre contestam esse ponto, e eu entendo por quê. A verificação formal tem a reputação de ser computacionalmente explosiva — o espaço de estados de um SoC moderno é astronomicamente grande, e abordagens formais ingênuas se engasgam com qualquer coisa maior do que um projeto de brinquedo.

Dedicamos um esforço significativo a isso. Nosso sistema usa técnicas de abstração automatizadas para tornar o formal tratável em escala. Black-boxing nos permite verificar a lógica de cola tratando grandes subblocos como RAMs ou ALUs complexas como entidades abstratas com interfaces definidas. Cut-points quebram os caminhos de handshake valid/ready para que possamos verificar o controle de fluxo independentemente do processamento de dados. Redução por simetria nos permite provar uma propriedade para um canal de um roteador multiporta e induzi-la matematicamente para todos os N canais.

Está completamente resolvido? Não. A física analógica sempre apresentará desafios que os métodos formais não conseguem tocar. Mas os bugs de lógica — as condições de corrida, os deadlocks, as violações de protocolo — tornam-se matematicamente impossíveis no código gerado. E esses são os bugs que causam respins.

A outra objeção que ouço é sobre velocidade. "Rodar um solucionador formal não deixa o processo de projeto mais lento?" Sim, isso adiciona custo computacional. Mas eu trocaria tempo de computação por certeza de cronograma todos os dias. Um solucionador formal rodando por uma hora extra é infinitamente mais barato do que um respin de seis meses.

A Verdade Incômoda Sobre "Chips Projetados por IA"

Há uma narrativa ganhando força na indústria — a de que a IA em breve projetará chips de ponta a ponta, a de que estamos passando do Projeto Auxiliado por Computador para o Projeto Automatizado por Computador. Acredito que essa narrativa esteja direcionalmente correta, mas perigosamente incompleta.

Estamos construindo em direção a fluxos de trabalho agênticos, onde agentes de IA autônomos colaboram — um agente Arquiteto para o particionamento de alto nível, um Codificador de RTL para a implementação, um Engenheiro de Verificação para escrever testbenches e asserções, um Gerente para orquestrar o fluxo em relação a restrições de potência, desempenho e área. Usamos Geração Aumentada por Recuperação (RAG) não apenas para código, mas para conhecimento — puxando regras de protocolo específicas, restrições do kit de projeto de processo e padrões internos de codificação para que o LLM gere código em conformidade sem alucinar.

Mas nada disso funciona — nada disso — sem uma espinha dorsal de verificação formal. Quanto mais autônoma a IA se torna, mais crítico é que cada saída seja matematicamente verificada antes de seguir adiante no fluxo. Um agente de IA que gera código mais rápido só é valioso se esse código estiver correto. Um agente de IA que gera código mais rápido e prova que ele está correto? Esse é o futuro.

O problema da indústria de semicondutores não é que a IA seja lenta demais para escrever código de hardware. É que a IA é rápida demais para escrever código de hardware que está sutilmente errado.

Nós não somos um copiloto. Nós não somos um chatbot. Somos uma fundição de verificação formal que por acaso usa IA generativa como seu front end. A distinção importa porque determina para o que você está otimizando. Copilotos otimizam para velocidade. Nós otimizamos para correção. Em um mundo onde um único bug que escapa custa US$ 10 milhões em máscaras e US$ 50 milhões em receita perdida, eu sei qual otimização escolheria.

A Escolha Já Está Feita

A indústria de semicondutores não pode mais se dar ao luxo da abordagem "gerar e rezar". A Regra dos Dez não é uma sugestão — é física e economia conspirando para punir qualquer um que embarque silício não verificado. Em 5nm e abaixo, com conjuntos de máscaras se aproximando de US$ 20 milhões, a margem de erro colapsou para zero.

Toda semana, converso com equipes de projeto que estão empolgadas com o que os LLMs podem fazer pela produtividade delas e apavoradas com o que os LLMs podem fazer ao cronograma de tape-out delas. Elas têm razão em sentir as duas coisas simultaneamente. A tecnologia é genuinamente transformadora. Ela também é genuinamente perigosa sem uma rede de segurança.

A Veriprajna é essa rede de segurança. Damos a você a velocidade da IA com a certeza da matemática. Não "provavelmente correto". Não "passou na regressão". Comprovadamente correto, em todas as entradas possíveis, todos os estados possíveis, todos os casos extremos possíveis que uma simulação jamais pensaria em testar.

A escolha que todo projetista de chips enfrenta hoje não é se deve usar IA. Esse barco já partiu. A escolha é se deve usar uma IA que pode provar seu próprio trabalho, ou uma IA que apenas torce pelo melhor.

Eu sei em qual delas eu apostaria US$ 10 milhões.