🤖 AI

ContractHIL-HLS: Contract-Aligned Multi-Agent Workflow with Hardware-in-the-Loop Feedback for HLS Design

Cet article introduit ContractHIL-HLS, un flux de travail multi-agents aligné sur les contrats qui intègre une traduction structurée du langage naturel vers des contrats avec un retour d'information matériel dans la boucle (hardware-in-the-loop) afin d'améliorer considérablement les taux de réussite dans les tâches de conception HLS et d'optimiser les accélérateurs de cryptographie post-quantique au niveau de la carte.

Auteurs originaux : Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

Publié 2026-07-29

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'enseigner à un robot brillant et hyper-rapide comment construire une machine complexe, comme une console de jeux vidéo personnalisée ou un coffre-fort ultra-sécurisé. Vous donnez au robot des instructions en langage clair, comme « Faites en sorte que ce soit rapide et sécurisé ». Le robot, propulsé par un LLM (une IA qui lit et écrit du code), tente de construire l'objet. Mais voici le problème : le robot est excellent pour écrire l'idée du code, mais il oublie souvent les règles minuscules et ennuyeuses dont les vraies machines ont besoin pour fonctionner, comme la consommation électrique ou si les pièces s'emboîtent correctement. C'est le monde de la Synthèse de Haut Niveau (HLS), où les humains tentent d'utiliser l'IA pour transformer des idées simples en véritables conceptions matérielles pour des puces. La grande question n'est pas seulement « L'IA peut-elle écrire du code ? », mais « L'IA peut-elle construire quelque chose qui fonctionne réellement sur une carte sans que nous ayons à corriger chaque erreur à la main ? »

C'est là qu'une équipe de chercheurs de l'Université de Technologie de Pékin intervient avec une nouvelle idée appelée ContractHIL-HLS. Voyez cela comme un « chef de projet intelligent » pour l'IA. Au lieu de simplement laisser l'IA discuter avec vous, ils la forcent à signer un « contrat » formel d'abord. Ce contrat est une liste stricte et structurée de règles : « Voici exactement ce que la machine doit faire, voici ce qu'elle ne peut absolument pas faire, et voici comment nous allons la tester. » Si l'IA tente de transgresser les règles, le système l'intercepte immédiatement. Plus cool encore, ils connectent ce processus à du matériel réel. Si l'IA conçoit une puce qui chauffe trop ou qui est trop lente, la machine réelle envoie un « rapport d'échec » en retour à l'IA, qui doit alors réécrire la conception pour corriger le tir. C'est comme dans un jeu vidéo où le personnage ne se contente pas de deviner la solution ; il se fait piéger, voit exactement pourquoi il a échoué, et essaie à nouveau avec un meilleur plan.

Le Problème : L'IA est excellente pour discuter, médiocre pour construire

Habituellement, quand vous demandez à une IA de concevoir du matériel, elle agit comme un écrivain créatif. Elle génère du code basé sur votre instruction, mais elle oublie souvent les « petits caractères ». Peut-être utilise-t-elle une fonctionnalité que la puce matérielle ne supporte pas, ou crée-t-elle une conception qui semble bonne sur le papier mais qui plante quand vous essayez de l'exécuter. Les méthodes précédentes tentaient de corriger cela en faisant jouer à l'IA différents rôles, comme « Architecte » ou « Codeur », mais l'IA oubliait souvent ce que l'Architecte avait dit au moment où le Codeur commençait à travailler. L'intention de conception se perdait dans la conversation.

Les chercheurs ont réalisé qu'au lieu de compter sur une conversation longue et désordonnée, ils avaient besoin d'un contrat structuré. Imaginez que vous commandez une pizza personnalisée. Au lieu de dire simplement « Je veux une pizza délicieuse », vous remplissez un formulaire : « Croûte : Fine. Garnitures : Poivron uniquement. Pas de champignons. Doit être prête en 10 minutes. » Ce formulaire est le « contrat ». Dans le monde de la conception de puces, ce contrat traduit votre idée vague en un ensemble strict de règles que l'IA doit suivre.

La Solution : Le flux de travail à trois agents

L'équipe a construit un système composé de trois « agents » spécialisés (des assistants IA) qui travaillent ensemble comme une machine bien huilée :

L'Agent Contrat : Cet agent prend votre demande désordonnée en langage naturel (ex: « Créez un système de messagerie sécurisé ») et la transforme en ce contrat strict de type « commande de pizza ». Il définit l'interface, les contraintes (ce qui est interdit) et les règles de test.
L'Agent HTML : Cet agent prend le contrat et le transforme en une page web (HTML) propre et structurée. Pourquoi une page web ? Parce qu'elle est facile à lire pour les humains, facile à comprendre pour le prochain agent IA, et facile à vérifier par des scripts informatiques. Elle sert de registre permanent et immuable des règles.
L'Agent HIL (Hardware-in-the-Loop) : C'est le bâtisseur. Il regarde le contrat HTML, écrit le code, et ensuite — voici la partie magique — teste réellement le tout sur du matériel ou via une simulation. Si le matériel dit : « Hé, cette conception consomme trop de mémoire », l'agent HIL voit cette preuve, lit le contrat et réécrit le code pour corriger le problème. S'il n'y parvient pas, le système sait qu'il doit faire un « retour en arrière » et essayer une approche différente.

Ce qu'ils ont découvert : Petites victoires et grands bonds en avant

L'équipe a testé ce système de deux manières très différentes pour voir s'il fonctionnait réellement.

1. Le test de « Petite Conception » (HLS-Eval)
D'abord, ils ont testé le système sur 94 petites tâches de codage standards. Ils ont comparé trois méthodes :

Direct : Demander simplement à l'IA sans règles spéciales.
Contrat : Utiliser le contrat structuré, mais sans le retour d'expérience du matériel réel.
ContractHIL-HLS : Utiliser le système complet avec le contrat et le retour du matériel.

Les résultats sont clairs. La méthode « Direct » a réussi les tests environ 64,0 % du temps. En ajoutant le Contrat, le taux de réussite est passé à 70,2 %. Le système complet a atteint 70,4 % pour une tentative unique et 76,6 % si l'on laisse l'IA essayer cinq fois. Cela prouve que le simple fait de forcer l'IA à suivre un contrat structuré la rend beaucoup plus fiable, avant même qu'elle ne touche au matériel réel.

2. Le test du « Monde Réel » (Étude de cas PQC)
Les petits tests sont utiles, mais fonctionnent-ils pour des systèmes plus vastes et complexes ? Pour le savoir, l'équipe a construit un accélérateur de messages sécurisés utilisant la Cryptographie Post-Quantique (PQC) — une méthode de communication ultra-sécurisée que même les futurs ordinateurs quantiques ne pourront pas percer. C'est un défi d'ingénierie massif impliquant la mémoire, le timing et la puissance.

Ils ont commencé avec une conception unique (un seul « bitstream ») qui mettait 207,3 ms pour traiter un message. Le système a analysé le retour du matériel et a réalisé que la conception était trop encombrée et lente. En suivant les règles du contrat, l'IA a divisé la conception en deux parties distinctes (une organisation à « double bitstream »). Une partie gérait l'envoi, et l'autre gérait la réception.

Le résultat ? La nouvelle conception traite les messages en seulement 52,4 ms. C'est une accélération massive ! Elle utilise également moins de puissance et respecte tous les contrôles de timing. Le système a réussi à utiliser le « contrat » pour guider l'IA d'une conception unique et lente vers une conception divisée et rapide, tout en préservant les règles de sécurité.

Pourquoi cela compte

L'article montre que nous n'avons pas besoin d'attendre que l'IA devienne un « génie » par elle-même. Au lieu de cela, nous pouvons construire un flux de travail où l'IA est guidée par un contrat strict et inviolable, et corrigée par des preuves du monde réel. Les chercheurs ont découvert que cette approche ne permet pas seulement à l'IA d'écrire du code plus vite ; elle permet au code de fonctionner.

Cependant, l'article note prudemment que ce n'est pas une baguette magique pour tout. Dans leurs tests, il y avait un groupe de tâches (appelées « machsuite ») où l'IA a totalement échoué, même avec le contrat. Cela suggère que si le contrat aide l'IA à suivre les règles, il ne peut pas compenser si l'IA ne possède pas encore la logique ou les mathématiques sous-jacentes.

En résumé, ContractHIL-HLS est un pont entre le monde désordonné des idées humaines et le monde rigide des puces matérielles. Il transforme l'IA d'un écrivain créatif en un ingénieur discipliné, garantissant que lorsque nous demandons une machine sûre et rapide, nous en obtenons une qui fonctionne réellement.

Résumé Technique : ContractHIL-HLS

Énoncé du Problème

Bien que les grands modèles de langage (LLM) aient démontré une capacité à générer du code matériel, l'ingénierie pratique de la synthèse de haut niveau (HLS) nécessite des flux de travail capables de maintenir l'intention de conception à travers les itérations, garantissant ainsi l'alignement avec le retour d'information de l'automatisation de la conception électronique (EDA), le contrôle de l'hôte, la propriété de la mémoire et les mesures de déploiement sur FPGA. Les benchmarks existants (ex. : Chip-Chat, RTLLM, HLS-Eval) montrent que les modèles peuvent générer du code valide, mais ils échouent souvent à établir un flux de travail où l'intention de conception reste traçable par rapport aux retours des outils et aux résultats de déploiement. Les approches actuelles reposent généralement sur des prompts de rôle conversationnels ou l'historique de la conversation comme état, ce qui peut entraîner l'omission de contraintes introduites par un prompt d'« architecte » par un prompt de « codeur » ultérieur. De plus, les travaux actuels d'assistance par LLM en HLS restent principalement centrés sur le noyau (kernel), manquant de couverture pour le partitionnement de bitstream, la propriété de l'état vivant (live-state ownership) et les frontières de sécurité entre les étapes.

Méthodologie

Le document propose ContractHIL-HLS, un flux de travail multi-agents aligné sur un contrat, conçu pour transformer des requêtes imprécises en langage naturel en implémentations HLS traçables. Le flux de travail se distingue par trois mécanismes fondamentaux :

Contrat structuré comme artefact d'exécution : Au lieu de s'appuyer sur un historique conversationnel lâche, le flux de travail introduit un contrat formel ( $C = \langle R, I, F, H, K, O, V, B \rangle$ ) qui encode les exigences dans des champs explicites : Rôle/Plateforme, Interface Publique, Intention Fonctionnelle, Contraintes Strictes/Négatives, Compatibilité, Intention d'Optimisation, Preuve de Validation et Politique de Rollback. Ce contrat sert d'artefact d'alignement sémantique et d'exécution des tâches.
Décomposition des agents par abaissement sémantique : Les agents sont définis par leurs tâches de transformation plutôt que par leurs rôles conversationnels :
- Agent de Contrat : Normalise le langage naturel en le contrat structuré.
- Agent HTML : Rendu du contrat en un artefact HTML stable et inspectable contenant des sections, des tableaux et des listes de contrôle. Cet artefact est doublement lisible par les humains et les scripts.
- Agent Hardware-in-the-Loop (HIL) : Implémente et révise la conception en utilisant l'artefact HTML combiné à des preuves matérielles mesurées.
Boucle de rétroaction Hardware-in-the-Loop : Le flux de travail intègre les retours des outils HLS (Vitis), des outils d'implémentation (Vivado) et des mesures de fonctionnement sur carte (PYNQ) directement dans la boucle de génération et de décision. Cela étend la conception assistée par LLM du code de noyau vers la clôture (closure) au niveau du système et de la carte. La boucle comprend des demandes d'implémentation bornées, des vérifications de rejet à faible coût (parsing, compilation, banc de test), des vérifications de synthèse/implémentation, et une décision de maintien ou de rollback basée sur des preuves mesurées (ex. : pire délai négatif (WNS), utilisation des ressources, puissance, temps d'exécution).

Contributions Clés

Le document présente trois contributions principales :

Contrat structuré comme artefact d'exécution : Les exigences sont encodées sous forme de champs explicites (interface, contraintes, validation, optimisation, rollback) pour aligner la génération sur un objet d'ingénierie partagé plutôt que sur une répétition de texte de prompt.
HTML persistant et boucle de rétroaction HIL : Le contrat est rendu en HTML structuré, et les sorties des outils (HLS, Vivado, métriques de déploiement) sont réinjectées comme états de premier rang du flux de travail pour piloter les décisions d'implémentation et de rollback.
Coordination des agents, des benchmarks aux cas d'ingénierie : Le flux de travail démontre qu'une approche alignée sur un contrat améliore les résultats sur 94 tâches HLS-Eval locales et parvient à porter la boucle de conception vers un système de messagerie sécurisée de cryptographie post-quantique (PQC) testé sur carte.

Résultats

Évaluation HLS-Eval (Configuration de conception de petite taille)

Évalué sur 94 tâches HLS-Eval exécutables localement à l'aide d'une chaîne d'outils Vitis HLS :

Baseline vs Contrat : L'introduction du contrat structuré seul a amélioré le taux de réussite estimé du banc de test en échantillon unique (pass@1) de 64,0 % (prompt direct) à 70,2 %.
Flux complet : Le flux complet ContractHIL-HLS a atteint un pass@1 de 70,4 % et un pass@5 de 76,6 %.
Efficacité des tokens : Le paramètre « Contrat » a utilisé moins de tokens (3555) que le paramètre « Direct » (3741) en remplaçant les instructions lâchement répétées par des champs nommés, suggérant une fiabilité accrue sans simplement augmenter la longueur du prompt.
Analyse par catégorie : Des améliorations ont été observées dans la plupart des familles de benchmarks (ex. : chstone, polybench, rosetta), bien que le groupe machsuite soit resté à un taux de réussite de 0,0 %, indiquant que le flux de travail améliore la fiabilité pour des implémentations plausibles mais ne peut compenser des capacités algorithmiques manquantes.

Étude de cas PQC (Déploiement au niveau de la carte)

Validé sur un accélérateur de messagerie sécurisée (ML-KEM/ML-DSA) post-quantique :

Performance : Le flux de travail a réussi la transition d'une conception monolithique à un bitstream unique vers une organisation à double bitstream (division de la logique KEM et DSA/XOR). Cela a réduit le temps d'exécution moyen de 207,3 ms à 52,4 ms.
Efficience : Le produit Énergie-Délai (EDP) conservateur est passé de 171,3 mJ·s à 23,6 mJ·s.
Timing et Ressources : La conception divisée a résolu les violations de timing (le WNS est passé de 1,570 ns dans l'image monolithique à 0,769 ns et 0,171 ns dans les images divisées) et a redistribué la pression mémoire, les deux images atteignant un slack de timing routé positif.
Validation : Le flux de travail a préservé les règles de frontière du récepteur et la vérification du message décrypté, garantissant que la propriété de l'état était visible et correcte.

Signification et Revendications

Le document affirme que ContractHIL-HLS comble l'écart entre la génération de code isolée et l'exécution d'un flux de travail traçable. Sa signification réside dans :

Alignement d'état : Démontrer que la conversion des exigences en langage naturel implicite en structures stables et inspectables (contrats/HTML) améliore considérablement la fiabilité de la génération de code matériel avant tout retour de la carte disponible.
Clôture au niveau système : Prouver que le même flux de travail aligné sur un contrat peut passer de la génération de noyaux à des systèmes complexes testés sur carte, impliquant le partitionnement de bitstream, l'orchestration de l'hôte et les frontières de sécurité.
Révision pilotée par les preuves : Établir un mécanisme où la sortie de l'outil (QoR, timing, puissance) devient un artefact de premier rang qui pilote les décisions de rollback, empêissant la propagation silencieuse de conceptions qui échouent à des portes spécifiques (ex. : contraintes de timing ou de ressources).

Les auteurs maintiennent une position modeste, notant que le flux de travail est un mécanisme d'alignement d'état qui améliore la fiabilité lorsque le modèle est proche d'une implémentation plausible, plutôt qu'une solution universelle pour tous les écarts algorithmiques. Le cas PQC sert de test de stress de déploiement pour la complétude du système plutôt qu'une revendication de supériorité de latence au niveau primitif.