RuC: HDL-Agnostic Rule Completion Benchmark Generation

1. Énoncé du problème

Bien que les modèles de langage de grande taille (LLM) aient montré des promesses dans l'automatisation de la conception électronique (EDA), les benchmarks existants pour évaluer leurs capacités de complétion de code dans les langages de description matérielle (HDL) souffrent de limitations significatives :

• Manque de contrôle de la granularité : Les benchmarks actuels se divisent généralement en deux catégories : Complétion de module (MC), qui masque un module entier (souvent trop complexe et chargé en contexte pour être reconstruit sans spécifications), et Complétion de ligne unique (SLC), qui masque une ligne aléatoire.
• Unités arbitraires : La SLC repose sur les « lignes » comme unité de masquage, qui est un artefact de mise en forme plutôt qu'une construction HDL sémantiquement significative. Une ligne aléatoire peut être triviale ou syntaxiquement incomplète, échouant à tester des fonctionnalités spécifiques du langage.
• Rigueur de l'évaluation : De nombreux benchmarks reposent sur des métriques de correspondance exacte ou une simulation simple, qui ne capturent pas la correction partielle ou l'équivalence fonctionnelle rigoureuse dans les conceptions matérielles.

Les auteurs soutiennent qu'il existe un besoin d'un cadre permettant une granularité arbitraire et sémantiquement significative (d'une simple affectation à un bloc logique complet) et utilisant un masquage piloté par la grammaire pour évaluer systématiquement la compréhension des LLM de constructions HDL spécifiques.

2. Méthodologie : Le cadre RuC

Les auteurs proposent RuC (Rule-based Completion), un cadre piloté par la grammaire et agnostique au langage pour générer des benchmarks de complétion de règles.

A. Concept de base : Masquage piloté par la grammaire

Au lieu de masquer des lignes aléatoires ou des modules entiers, RuC analyse le code source HDL en un arbre de syntaxe basé sur la grammaire formelle du langage (par exemple, SystemVerilog).

• Sélection de règles : Les utilisateurs sélectionnent des règles de grammaire spécifiques (non-terminaux) à masquer, telles que port_declaration, continuous_assignment, case_statement, ou always_construct.
• Contrôle de la granularité : En choisissant différentes règles, la difficulté de la tâche peut être ajustée. Par exemple, masquer un simple_identifier est plus facile que masquer un always_construct entier.
• Agnostique HDL : Le cadre fonctionne pour n'importe quel langage pourvu qu'une définition de grammaire (par exemple, via ANTLR) soit disponible.

B. Pipeline de construction des tâches

Le pipeline se compose de trois étapes :

1. Prétraitement : Résout les directives de compilateur et fusionne les projets multi-fichiers en une source unifiée pour fournir un contexte complet.
2. Analyse et échantillonnage de règles : Analyse la source pour générer un arbre de syntaxe, identifie les occurrences des règles de grammaire sélectionnées et les masque. Il filtre le code mort ou les constructions supprimées lors de l'élaboration.
3. Gestion du budget de contexte : Aborde les limites de la fenêtre de contexte des LLM. Il extrait les dépendances de modules (instanciations et imports) et élague le contexte pour n'inclure que les dépendances pertinentes, permettant aux utilisateurs d'échanger la taille du contexte contre des informations structurelles.

C. Stratégies de prompting

RuC prend en charge deux paradigmes de prompting pour s'aligner sur différentes stratégies d'entraînement de modèles :

• Basé sur le chat : Remplace la région masquée par un token <MASK> et fournit le contexte environnant avec une instruction.
• Remplissage du milieu (FIM) : Divise le code en Préfixe, Milieu (masqué) et Suffixe. Le modèle est sollicité avec Préfixe + Suffixe + <TOKEN_MILIEU> pour générer le milieu manquant. Cela s'aligne sur les objectifs de pré-entraînement de nombreux LLM de codage.

D. Pipeline de vérification

Pour assurer une évaluation rigoureuse, RuC emploie un processus de vérification en deux étapes :

1. Validation syntaxique (STX) : Réinsère le code généré et le vérifie (en utilisant Verilator) pour s'assurer qu'il compile et respecte les règles du langage.
2. Équivalence fonctionnelle (EQV) : Utilise la vérification formelle (solveurs SAT via Yosys) pour prouver que la conception générée par le LLM est fonctionnellement équivalente à la vérité terrain originale. Il construit un « circuit miter » et vérifie si une séquence d'entrées quelconque peut produire des sorties différentes.

3. Contributions clés

• Cadre RuC : Un système automatisé novateur pour générer des benchmarks de complétion de code HDL avec une granularité contrôlable basée sur des règles de grammaire formelle.
• Conception agnostique HDL : L'approche est applicable à n'importe quel langage de description matérielle avec une grammaire définie, pas seulement SystemVerilog.
• Évaluation rigoureuse : Va au-delà des métriques de similarité textuelle simples pour inclure une vérification formelle de l'équivalence fonctionnelle, garantissant que le code généré fonctionne réellement comme prévu.
• Génération de benchmarks : A créé deux nouveaux benchmarks SystemVerilog dérivés du shuttle Tiny Tapeout TT07 et du cœur CVE2 RISC-V, couvrant un large éventail de complexités de conception.

4. Résultats expérimentaux

Les auteurs ont évalué cinq LLM open-source (y compris Qwen2.5/3 Coder, Seed Coder et DeepSeek) sur les benchmarks générés.

• Stratégie de prompting : Le prompting FIM a systématiquement surpassé le prompting basé sur le chat. Cela suggère que l'objectif de « remplissage » est critique pour les tâches HDL où le contexte est bidirectionnel.
• Variantes de modèles : De manière surprenante, les modèles de base (pré-entraînés uniquement) ont souvent surpassé leurs homologues ajustés par instruction dans la complétion de règles. Cela indique que l'ajustement par instruction, bien qu'utile pour le codage général, peut dégrader les capacités spécifiques de prédiction du token suivant requises pour un remplissage de code précis.
• Difficulté des règles : Les performances variaient considérablement en fonction de la règle de grammaire :
  • Plus faciles : PORT (déclarations de ports) et PARAM (paramètres), car ceux-ci peuvent souvent être déduits de l'utilisation de l'interface.
  • Modéré : Règles d'affectation (CONT, BLK, NBLK).
  • Plus difficiles : Règles de flux de contrôle (COND, CASE, ALWAYS), qui nécessitent de reconstruire une logique comportementale complexe.
• Taille du modèle vs Performance : Bien que les modèles plus grands aient généralement mieux performé, la corrélation n'était pas absolue. Des modèles plus petits (par exemple, Seed Coder 8B) ont parfois surpassé des modèles plus grands sur des règles spécifiques, suggérant que la sélection de modèles spécifique à la règle est plus efficace qu'une approche universelle.
• Influence de la base de code : Les performances ont été influencées par les régularités stylistiques dans la base de code (par exemple, les affectations non bloquantes dans CVE2 suivaient un schéma hautement régulier, augmentant les scores).

5. Importance

• Évaluation granulaire : RuC fournit le premier cadre capable d'isoler et de tester la compréhension d'un LLM de constructions HDL spécifiques, dépassant l'évaluation « tout ou rien » des modules entiers ou des lignes aléatoires.
• Évolutivité : En automatisant la génération de tâches à partir de conceptions open-source réelles, il permet un benchmarking évolutif qui était auparavant limité par la curation manuelle de jeux de données.
• Intégration au flux de travail EDA : Les résultats soulignent que le prompting FIM et les modèles de base sont actuellement supérieurs pour l'assistance de type copilote RTL, guidant le développement des futurs outils EDA.
• Recherche future : Le cadre ouvre la porte à l'étude de la manière dont les LLM gèrent les longueurs de contexte variables et les motifs logiques spécifiques, ce qui est essentiel pour construire des assistants IA fiables pour la conception matérielle.

En conclusion, RuC établit une nouvelle norme pour l'évaluation des LLM dans la conception matérielle en combinant l'analyse de grammaire formelle avec une vérification fonctionnelle rigoureuse, révélant que les modèles actuels peinent avec la logique de contrôle complexe mais excellent dans la reconstruction structurelle lorsqu'ils sont sollicités correctement.