ChipNeMo : LLM adaptés au domaine pour la conception de puces : applications LLM

Tableau des liens

• Résumé et introduction
• Base de données
• Méthodes d'adaptation de domaine ChipNemo
• Candidatures LLM
• Évaluations
• Discussion
• Travaux connexes
• Conclusions
• Remerciements, contributions et références
• annexe

IV. DEMANDES DE LLM

Nous avons mené une enquête sur les applications LLM potentielles au sein de nos équipes de conception et les avons classées en quatre catégories : génération de code, questions et réponses, analyse et reporting , et triage . La génération de code fait référence au LLM générant du code de conception, des bancs de test, des assertions, des scripts d'outils internes, etc. ; Q & A fait référence à un LLM répondant à des questions sur les conceptions, les outils, les infrastructures, etc. ; L'analyse et le reporting font référence à un LLM analysant des données et fournissant des rapports ; le triage fait référence à un LLM aidant à déboguer les problèmes de conception ou d'outils à partir des journaux et des rapports. Nous avons sélectionné une application clé de chaque catégorie à étudier dans ce travail, à l'exception de la catégorie de triage que nous laissons pour des recherches plus approfondies. La motivation et les détails techniques de chaque candidature sont donnés ci-dessous.

A. Chatbot assistant d'ingénierie

Cette application vise à aider les ingénieurs concepteurs à répondre à leurs questions d'architecture, de conception, de vérification et de construction, ce qui pourrait améliorer considérablement leur productivité globale sans affecter la productivité des autres. On observe que les ingénieurs de conception aiment souvent réfléchir, concevoir du matériel et écrire du code, mais peuvent être ralentis en attendant des réponses sur les connaissances en conception qui leur manquent. La productivité de la conception peut également être améliorée en évitant aux ingénieurs d'écrire du code basé sur des hypothèses erronées ou de déboguer du code qu'ils ne connaissent pas. Des études internes ont montré que jusqu'à 60 % du temps d'un concepteur de puces typique est consacré à des tâches liées au débogage ou à la liste de contrôle sur une gamme de sujets, notamment les spécifications de conception, la construction de bancs de test, la définition de l'architecture et les outils ou l'infrastructure. Les experts sur ces questions sont souvent répartis dans le monde entier au sein d'une entreprise multinationale, de sorte qu'il n'est pas toujours pratique de trouver une aide immédiate. Par conséquent, un chatbot d'assistant d'ingénierie basé sur les connaissances extraites des documents de conception internes, du code et de toutes les données enregistrées sur les conceptions et les communications techniques telles que les e-mails et les communications instantanées d'entreprise, etc. pourrait contribuer à améliorer considérablement la productivité de la conception. Nous avons implémenté cette application avec la méthode RAG adaptée au domaine mentionnée dans la section III-D.

B. Génération de scripts EDA

Une autre tâche courante dans un flux de conception de puces industrielles consiste à écrire des scripts EDA pour accomplir diverses tâches telles que

que la mise en œuvre du design, l'introspection et la transformation. Ces scripts exploitent souvent des bibliothèques de scripts internes spécifiques à l'outil et personnalisées. L'apprentissage de ces bibliothèques, la navigation dans la documentation des outils, ainsi que l'écriture et le débogage de ces scripts peuvent prendre beaucoup de temps d'ingénierie.

Les LLM se sont révélés experts dans la génération de code à petite échelle sur un large éventail de tâches [32] et, par conséquent, la personnalisation de ces modèles pour accélérer la productivité des ingénieurs dans cette tâche spécifique à un domaine est une solution naturelle. Dans ce travail, nous nous concentrons sur la génération de deux types différents de scripts à partir de descriptions de tâches en langage naturel. Les premiers sont des scripts qui exploitent Tool1, une bibliothèque Python interne pour l'édition et l'analyse de la conception. Les seconds sont des scripts Tcl qui utilisent l'interface de commande fournie par Tool2, l'un des principaux outils industriels d'analyse temporelle statique.

Afin de créer notre ensemble de données de réglage précis spécifique à un domaine pour cette tâche, des scripts de production pour les deux outils ont été collectés auprès d'experts en conception. Nous avons observé que nos modèles DAPT peuvent générer des commentaires en ligne raisonnables pour le code. Cela nous a permis d'utiliser ces modèles pour améliorer la qualité des scripts collectés en générant des commentaires en ligne supplémentaires. Des experts humains ont ensuite vérifié et corrigé ces commentaires et créé une invite associée. Ces invites et paires de codes constituent les données utilisées pour DSFT dans le format discuté dans la section III-C.

Pour fournir et collecter des commentaires de la manière la plus significative possible, nous avons déployé des efforts considérables pour créer le flux illustré à la figure 4, dans lequel les ingénieurs peuvent à la fois interroger le modèle et exécuter le code généré via la même interface. Cela nous permet d'avoir confiance dans l' exactitude du code généré et de fournir des commentaires précis en permettant aux ingénieurs de voir le nombre de corrections dont ils pourraient avoir besoin pour obtenir un script fonctionnel. Nous prenons en charge l'intégration de Tool1 et Tool2 en établissant des connexions interactives avec les serveurs d'outils.

De plus, nous fournissons un formulaire de commentaires des utilisateurs, nous permettant de comparer différents modèles et de tirer des informations précieuses des commentaires des utilisateurs. Ces informations précieuses peuvent nous aider à affiner davantage nos modèles.

C. Résumé et analyse des bogues

Le suivi du reporting, du tri, du débogage et de la résolution de diverses fonctionnalités et bogues à travers les étapes du flux de production est un processus qui prend du temps. Les responsables de l'ingénierie passent beaucoup de temps à examiner les bases de données internes de suivi des problèmes pour mieux comprendre l'état du projet et accélérer son exécution. Par conséquent, un outil capable d’examiner toutes les informations complémentaires, de résumer rapidement les données techniques et de gestion, ainsi que de suggérer les prochaines étapes, augmenterait la productivité de l’équipe. Nous nous concentrons sur l'utilisation des LLM pour générer trois résultats différents : un axé sur les détails techniques, un sur les détails de gestion et un sur l'affectation des tâches.

Pour étudier ces tâches, nous avons utilisé la base de données de bogues interne de NVIDIA, NVBugs. Cette base de données est utilisée pour le rapport, le suivi et la résolution des bogues, ainsi que pour le suivi général des tâches et des fonctionnalités dans l'ensemble de l'entreprise. Nous nous attendons à ce que les modèles ChipNeMo fonctionnent bien dans cette tâche, car une grande quantité de données de bogues a été incluse dans l'ensemble de données DAPT. De plus, nous avons créé un ensemble de données SFT spécifique au domaine pour cette tâche, qui comprend des exemples de tâches de synthèse de bogues et d'attribution de tâches.

Souvent, les descriptions de bogues contiennent de gros extraits de fichiers journaux ou de vidages de code ainsi que de longs historiques de commentaires. Dans de tels cas, le texte du bug est trop volumineux pour nos fenêtres contextuelles LLM. Pour contourner ce problème, nous avons mis en œuvre deux solutions. Tout d'abord, nous avons trouvé et remplacé les noms de chemin longs par des alias plus courts pour permettre au modèle d'associer les chemins qui apparaissent à plusieurs endroits dans le bogue sans avoir besoin de traiter la chaîne entière. Deuxièmement, nous divisons la tâche de récapitulation en une tâche incrémentielle dans laquelle le modèle est chargé d'accumuler des données sur plusieurs blocs de données de résumé et de bogues. Nous utilisons une approche hiérarchique dans laquelle le bug est d'abord séparé en morceaux qui s'inscrivent dans la fenêtre contextuelle. Ces morceaux sont ensuite résumés et les résumés sont accumulés puis séparés en morceaux. Ce processus est répété jusqu'à ce que l'ensemble des résumés tienne dans une seule fenêtre contextuelle et qu'un seul résumé soit généré. Nous utilisons cette même approche indépendamment du LLM utilisé pour la synthèse.