VeriInteresting: An Empirical Study of Model Prompt Interactions in Verilog Code Generation

Este estudo empírico mapeia as interações entre diferentes classes de modelos de linguagem e estratégias de engenharia de prompts na geração de código Verilog, identificando padrões de desempenho e generalização através de um design experimental controlado.

O essencial

Imagine que você está tentando ensinar um chef de cozinha extremamente inteligente, mas inexperiente, a cozinhar um prato muito específico e delicado: um circuito de hardware (chamado Verilog).

Este prato não é como uma receita de bolo comum (código de software). Se você errar um detalhe no bolo, ele fica com gosto estranho. Se você errar um detalhe no circuito de hardware, o chip pode explodir, superaquecer ou simplesmente não funcionar quando você ligar a máquina. A margem de erro é zero.

O artigo "VeriInteresting" é como um grande experimento de culinária onde os pesquisadores testaram 18 chefs diferentes (modelos de Inteligência Artificial) para ver quem consegue cozinhar esse prato difícil melhor, e como eles devem ser instruídos.

Aqui está o resumo da história, traduzido para o nosso dia a dia:

1. O Problema: "Não é só escrever código"

A maioria das IAs é treinada com milhões de receitas de software (Python, JavaScript). Elas são ótimas nisso. Mas hardware (Verilog) é diferente. É como se você pedisse para um chef fazer um bolo, mas ele precisasse garantir que o bolo não derretesse se a temperatura da cozinha mudasse 0,01 grau, e que cada ingrediente tivesse uma conexão elétrica perfeita.

O grande desafio é que não temos muitas "receitas" de hardware abertas para treinar essas IAs (por segredo industrial). Então, os pesquisadores tiveram que descobrir como fazer essas IAs funcionarem bem sem precisar reensiná-las do zero, apenas mudando como elas recebem as instruções (os "prompts").

2. Os 4 Grandes Perguntas (e as respostas)

Os pesquisadores fizeram quatro perguntas principais, que são como os pilares da pesquisa:

Pergunta 1: É melhor ter um chef "gigante" ou um "especialista"?

• A Analogia: Você prefere um chef famoso e caro que sabe cozinhar de tudo (Modelos Grandes como GPT-4), ou um chef menor que só sabe fazer bolos, mas é um mestre nisso (Modelos Especializados em Verilog)?
• A Descoberta: O tamanho importa, mas a especialização é traiçoeira.
  • Os modelos especializados (treinados apenas em Verilog) são ótimos quando o pedido é exatamente o que eles viram na escola.
  • Porém, se você mudar um pouco a receita ou pedir algo um pouco diferente, eles travam. Eles são como um pianista que só sabe tocar uma música: se você pedir outra, ele esquece tudo.
  • Os modelos grandes e gerais são mais flexíveis. Eles não são tão perfeitos no início, mas entendem melhor as nuances se você explicar direito.

Pergunta 2: A forma como você pede a receita importa?

• A Analogia: Se você pedir "Faça um bolo", o chef pode errar. Se você pedir "Faça um bolo de chocolate, com 3 ovos, forno a 180 graus, e coloque o açúcar por último", o resultado muda.
• A Descoberta: A forma de pedir (Prompting) é crucial, mas depende do chef.
  • Estrutura: Dar um formato rígido (como uma lista de ingredientes obrigatória) ajuda os chefs menores a não se perderem.
  • Pensar antes de agir (Chain-of-Thought): Pedir para o chef "pensar" em voz alta antes de cozinhar ajuda alguns, mas confunde outros. Para hardware, às vezes pensar demais cria suposições erradas que estragam o circuito.
  • Reescrever o pedido: Tentar "melhorar" a receita antes de cozinhar (Refinement) foi o maior desastre. Muitas vezes, a IA tentou "ajudar" reescrevendo o pedido e acabou mudando o que o cliente queria, criando um prato que não servia.

Pergunta 3: Vale a pena treinar o chef ou apenas dar instruções melhores?

• A Analogia: É melhor pagar para um chef fazer um curso de 6 meses (Fine-tuning) ou apenas dar a ele um manual de instruções muito detalhado na hora (Prompting)?
• A Descoberta: O manual detalhado (Prompting) é um ótimo começo e muito mais barato. Ele fecha a maior parte da diferença. Mas, para tarefas muito específicas e difíceis, o chef que fez o curso (o modelo treinado) ainda ganha. O treinamento é como um "atalho" que o manual não consegue totalmente substituir.

Pergunta 4: O que funciona num teste, funciona no outro?

• A Analogia: Se um chef ganha o prêmio de "Melhor Bolo" num concurso, ele vai ganhar em todos os concursos?
• A Descoberta: Não. Um modelo pode ser o melhor num teste de "simulação" (onde você testa o bolo com um paladar) e ser o pior num teste de "verificação formal" (onde você analisa a química exata do bolo).
• Isso significa que você não pode confiar em apenas um teste para dizer qual IA é a melhor. Você precisa testar de várias formas.

3. As Lições Práticas (O que isso significa para nós?)

O estudo nos dá um mapa para navegar nesse mundo:

1. Não existe "bala de prata": Não adianta apenas jogar o modelo mais caro ou o mais inteligente. O segredo está na combinação certa de Modelo + Instrução.
2. Cuidado com a "ajuda" da IA: Tentar fazer a IA reescrever o seu pedido ou pensar demais antes de agir pode, na verdade, piorar o resultado em hardware. Às vezes, menos é mais.
3. Especialistas são frágeis: Modelos treinados especificamente para Verilog são incríveis, mas se você mudar o formato do pedido, eles podem quebrar. Modelos gerais são mais robustos.
4. Teste de verdade: Para saber se uma IA funciona para criar chips, você não pode confiar apenas em testes simples. Você precisa de testes rigorosos (como simulação e verificação formal), porque um erro pequeno no código pode custar milhões em chips defeituosos.

Conclusão

O artigo "VeriInteresting" nos diz que a Inteligência Artificial para criar hardware está crescendo, mas ainda é como um estagiário brilhante: tem potencial, mas precisa de supervisão cuidadosa.

Não basta apenas "pedir" para a IA fazer o trabalho. Você precisa saber como pedir, escolher o chef certo para a tarefa e testar o resultado de várias formas. A tecnologia avança rápido, mas a engenharia de hardware exige precisão que a IA ainda está aprendendo a respeitar.

Resumo técnico

Resumo Técnico: VeriInteresting

1. O Problema

O avanço rápido dos Modelos de Linguagem (LMs) revolucionou a geração de código de software, mas sua aplicação no design de hardware (especificamente em Verilog) enfrenta desafios únicos e críticos:

• Complexidade Semântica: Diferente do software, onde testes parciais são comuns, o hardware exige garantias de correção em todos os estados de entrada possíveis. Um módulo Verilog que parece correto pode falhar em verificações de tempo (timing) ou introduzir condições de corrida (race conditions) que só aparecem em estágios tardios de fabricação.
• Escassez de Dados Estruturados: A maioria dos designs de hardware é propriedade intelectual fechada (closed-source), limitando a disponibilidade de dados para fine-tuning (ajuste fino) de modelos.
• Trade-off Modelos vs. Prompting: Não está claro se é melhor usar modelos grandes e genéricos com engenharia de prompt avançada ou modelos menores e especializados em Verilog, especialmente quando o fine-tuning não é uma opção devido a restrições de IP ou custo.
• Fragilidade das Técnicas de Software: Técnicas que funcionam bem para Python (como Chain-of-Thought ou refinamento de prompt) podem não transferir-se eficazmente para a geração de RTL (Register-Transfer Level), onde a estrutura e a semântica são rígidas.

2. Metodologia

Os autores realizaram um estudo empírico controlado e em larga escala, avaliando a interação entre classes de modelos e estratégias de prompting.

• Modelos Avaliados (18 LMs):
  • 7 LMs comerciais (ex: GPT-4.1, GPT-5, Gemini 3, Claude Sonnet 4).
  • 11 LMs de código aberto (SLMs), incluindo variantes gerais (Qwen), especializadas em código (Qwen-Coder, DeepSeek) e modelos especializados em Verilog (fine-tuned com SFT e RL, como VeriReason e VeriThoughts).
• Benchmarks (2):
  • Verilog Eval v2: Baseado em simulação dinâmica (testes funcionais contra vetores de teste).
  • VeriThoughts: Baseado em verificação formal (equivalência lógica contra uma implementação de referência "golden" usando Yosys).
• Eixos de Experimentação (Fatorial Controlado):
  • Estratégias de Prompting: Base (zero-shot), Structured (formato de saída estruturado via DSPy), Refine (reescrita da especificação antes da geração), Chain-of-Thought (CoT) e In-Context Learning (ICL).
  • Otimização de Prompt: Uso do método GEPA (Genetic-Pareto) para otimizar prompts sem alterar os pesos do modelo.
• Métricas: Taxa de aprovação (Pass@k para k=1, 5, 10) em ambos os benchmarks.

3. Contribuições Principais

1. Mapa Empírico de Interações: A primeira avaliação sistemática de como diferentes classes de modelos (escala vs. especialização) respondem a diversas estratégias de prompting no domínio de Verilog.
2. Análise de Generalização vs. Overfitting: Demonstração de que modelos especializados em um benchmark específico podem sofrer degradação severa em outros ou sob mudanças de prompt, revelando trade-offs entre desempenho de pico e robustez.
3. Validação de Técnicas de Software no Hardware: Evidência de que técnicas de inferência (como CoT e Refinamento) têm efeitos heterogêneos e muitas vezes negativos em Verilog, diferentemente do que ocorre em software.
4. Guia Prático para Implantação: Diretrizes sobre quando usar fine-tuning versus prompting forte, dependendo do custo, disponibilidade de dados e requisitos de robustez.

4. Resultados Chave

• RQ1: Escala vs. Especialização:

  • Ambos ajudam, mas com comportamentos distintos. Modelos fine-tuned (como VeriThoughts) performam muito bem em seu domínio de treino, mas mostram degradação ao 14B (de 7B) em alguns casos, sugerindo que o fine-tuning em dados limitados não aproveita totalmente a capacidade de modelos maiores.
  • Modelos gerais grandes (ex: Qwen-14B) podem competir com modelos especializados se bem prompted.

• RQ2: Sensibilidade às Estratégias de Prompting:

  • Estrutura (Structured Prompting): Geralmente beneficia modelos menores e especializados em código, mas pode degradar drasticamente modelos fine-tuned em Verilog (ex: VT-7/VT-14), indicando que eles são frágeis a restrições de formato não nativas.
  • Refinamento (Refinement): A estratégia mais instável. Pedir ao modelo para reescrever a especificação antes de gerar o código frequentemente introduz erros semânticos e reduz a taxa de aprovação, especialmente em modelos comerciais de ponta (ex: GPT-5m).
  • Chain-of-Thought (CoT): Efeito misto. Pode ajudar a estabilizar a saída em modelos menores, mas em benchmarks formais (VeriThoughts) pode introduzir suposições não verificadas que propagam erros para o RTL.
  • ICL (Few-Shot): Nem sempre seguro. Pode melhorar modelos pequenos, mas prejudica modelos especializados devido a desalinhamentos semânticos com os exemplos.

• RQ3: Fine-tuning vs. Prompting Forte:

  • O prompting forte pode reduzir a lacuna entre modelos base e modelos fine-tuned, mas não a elimina.
  • Quando o objetivo de adaptação (ex: benchmark de simulação) coincide com o objetivo de fine-tuning, os modelos especializados superam consistentemente os modelos gerais, mesmo com prompting avançado.
  • Otimização de inferência (GEPA) mostrou ganhos marginais e inconsistentes, não substituindo a necessidade de fine-tuning para tarefas específicas.

• RQ4: Estabilidade entre Benchmarks:

  • Há uma correlação positiva (r=0.868), mas com desvios significativos. O benchmark baseado em simulação (Verilog Eval) é sistematicamente mais difícil para muitos modelos do que o baseado em verificação formal (VeriThoughts).
  • Modelos que performam bem em um podem falhar no outro, alertando contra a dependência de um único benchmark para avaliar capacidades de geração de hardware.

5. Significado e Conclusão

O estudo conclui que a geração de Verilog é um regime qualitativamente diferente da geração de software.

• Fragilidade: Técnicas de inferência que funcionam para Python são frequentemente frágeis ou contraproducentes para RTL devido à necessidade de consistência global e semântica estrita.
• Trade-off Robustez-Especialização: Modelos altamente especializados em Verilog atingem picos de desempenho, mas perdem robustez a variações de prompt e distribuição de tarefas. Modelos gerais, embora com desempenho de pico menor, são mais robustos a mudanças de contexto.
• Recomendação: Para implantação em hardware, não existe uma solução única ("best model"). A escolha deve considerar o trade-off entre custo, necessidade de fine-tuning (se os dados permitirem) e a robustez exigida pelo fluxo de trabalho. A avaliação multi-benchmark é essencial para evitar conclusões enganosas sobre a confiabilidade dos modelos.

Este trabalho serve como base fundamental para o desenvolvimento de sinais de treinamento mais alinhados e para a integração mais profunda entre LMs e ferramentas de verificação de hardware.