ChipNeMo: LLM adaptados al dominio para diseño de chips: aplicaciones LLM

Tabla de enlaces

• Resumen e introducción
• Conjunto de datos
• Métodos de adaptación del dominio ChipNemo
• Aplicaciones de Maestría en Derecho
• Evaluaciones
• Discusión
• Obras relacionadas
• Conclusiones
• Agradecimientos, Aportes y Referencias
• Apéndice

IV. APLICACIONES DE LLM

Realizamos una encuesta de posibles aplicaciones de LLM dentro de nuestros equipos de diseño y las categorizamos en cuatro grupos: generación de código, preguntas y respuestas, análisis e informes , y clasificación . La generación de código se refiere a LLM que genera código de diseño, bancos de pruebas, afirmaciones, scripts de herramientas internas, etc.; Preguntas y respuestas se refiere a un LLM que responde preguntas sobre diseños, herramientas, infraestructuras, etc.; Análisis e informes se refiere a un LLM que analiza datos y proporciona informes; La clasificación se refiere a un LLM que ayuda a depurar problemas de diseño o herramientas según registros e informes. Seleccionamos una aplicación clave de cada categoría para estudiarla en este trabajo, excepto la categoría de clasificación que dejamos para futuras investigaciones. La motivación y los detalles técnicos de cada aplicación se detallan a continuación.

A. Chatbot asistente de ingeniería

Esta aplicación tiene como objetivo ayudar a los ingenieros de diseño con respuestas a sus preguntas sobre arquitectura, diseño, verificación y construcción, lo que podría mejorar significativamente su productividad general sin afectar la productividad de los demás. Se observa que los ingenieros de diseño a menudo disfrutan de la lluvia de ideas, el diseño de hardware y la escritura de códigos, pero pueden verse ralentizados esperando respuestas sobre los conocimientos de diseño de los que carecen. La productividad del diseño también se puede mejorar evitando que los ingenieros escriban código basado en suposiciones erróneas o depurando código con el que no están familiarizados. Estudios internos han demostrado que hasta el 60% del tiempo típico de un diseñador de chips se dedica a tareas relacionadas con la depuración o listas de verificación en una variedad de temas que incluyen especificaciones de diseño, construcción de bancos de pruebas, definición de arquitectura y herramientas o infraestructura. Los expertos en estos temas suelen estar repartidos por todo el mundo en una empresa multinacional, de modo que no siempre es conveniente encontrar ayuda inmediata. Por lo tanto, un chatbot asistente de ingeniería basado en conocimientos extraídos de documentos de diseño internos, códigos, cualquier dato registrado sobre diseños y comunicaciones técnicas, como correos electrónicos y comunicaciones instantáneas corporativas, etc., podría ayudar a mejorar significativamente la productividad del diseño. Implementamos esta aplicación con el método RAG adaptado al dominio mencionado en la Sección III-D.

B. Generación de guiones EDA

Otra tarea común en un flujo de diseño de chips industriales es escribir scripts EDA para realizar una variedad de tareas como

como implementación del diseño, introspección y transformación. Estos scripts a menudo aprovechan bibliotecas de scripts internas personalizadas y específicas de herramientas. Aprender estas bibliotecas, navegar por la documentación de las herramientas y escribir y depurar estos scripts puede consumir una cantidad significativa de tiempo de ingeniería.

Los LLM han demostrado ser expertos en la generación de código a pequeña escala en una amplia gama de tareas [32] y, por lo tanto, personalizar estos modelos para acelerar la productividad de los ingenieros en esta tarea específica de dominio es una opción natural. En este trabajo nos centramos en generar dos tipos diferentes de guiones a partir de descripciones de tareas en lenguaje natural. Los primeros son scripts que aprovechan Tool1, una biblioteca interna de Python para edición y análisis de diseños. El segundo son scripts Tcl que utilizan la interfaz de comando proporcionada por Tool2, que es una herramienta industrial líder en análisis de temporización estática.

Para construir nuestro conjunto de datos de ajuste específico de dominio para esta tarea, se recopilaron guiones de producción para ambas herramientas de expertos en diseño. Observamos que nuestros modelos DAPT pueden generar comentarios en línea razonables para el código. Esto nos permitió utilizar estos modelos para mejorar la calidad de los scripts recopilados generando comentarios en línea adicionales. Posteriormente, los expertos humanos verificaron y corrigieron estos comentarios y crearon un mensaje asociado. Estas indicaciones y pares de códigos constituyen los datos utilizados para DSFT en el formato analizado en la Sección III-C.

Para proporcionar y recopilar comentarios de la manera más significativa, dedicamos un gran esfuerzo a crear el flujo que se muestra en la Fig. 4, donde los ingenieros pueden consultar el modelo y ejecutar el código generado a través de la misma interfaz. Esto nos permite tener confianza en la exactitud del código generado y brindar comentarios precisos al permitir a los ingenieros ver cuántas correcciones podrían necesitar para obtener un script que funcione. Admitimos la integración de Tool1 y Tool2 estableciendo conexiones interactivas con servidores de herramientas.

Además, proporcionamos un formulario de comentarios de los usuarios, lo que nos permite comparar diferentes modelos y obtener información valiosa de los comentarios de los usuarios. Esta valiosa información puede ayudarnos a perfeccionar aún más nuestros modelos.

C. Resumen y análisis de errores

El seguimiento de los informes, la clasificación, la depuración y la resolución de diversas funciones y errores en las distintas etapas del flujo de producción es un proceso que requiere mucho tiempo. Los gerentes de ingeniería dedican mucho tiempo a revisar las bases de datos internas de seguimiento de problemas para comprender el estado del proyecto y ayudar a acelerar su ejecución. Por lo tanto, una herramienta que sea capaz de analizar toda la información de respaldo y resumir rápidamente los datos técnicos y administrativos, así como sugerir los próximos pasos, aumentaría la productividad del equipo. Nos centramos en utilizar los LLM para generar tres resultados diferentes: uno centrado en detalles técnicos, otro en detalles administrativos y otro en recomendar la asignación de tareas.

Para estudiar estas tareas utilizamos la base de datos de errores interna de NVIDIA, NVBugs. Esta base de datos se utiliza para informes, seguimiento y resolución de errores, así como para el seguimiento de funciones y tareas generales en toda la empresa. Esperamos que los modelos ChipNeMo funcionen bien en esta tarea, ya que se incluyó una gran cantidad de datos de errores en el conjunto de datos DAPT. Además, creamos un conjunto de datos SFT específico de dominio para esta tarea que incluye ejemplos de resumen de errores y tareas de asignación de tareas.

A menudo, las descripciones de errores contienen grandes fragmentos de archivos de registro o volcados de código junto con largos historiales de comentarios. En tales casos, el texto del error es demasiado grande para nuestras ventanas contextuales de LLM. Para solucionar este problema, implementamos dos soluciones. Primero, encontramos y reemplazamos nombres de rutas largas con alias más cortos para permitir que el modelo asocie rutas que ocurren en múltiples lugares del error sin necesidad de procesar la cadena completa. En segundo lugar, dividimos la tarea de resumen en una tarea incremental en la que el modelo tiene la tarea de acumular datos en múltiples fragmentos de datos de resumen y errores. Usamos un enfoque jerárquico en el que el error se separa primero en partes que encajan en la ventana contextual. Luego, esos fragmentos se resumen y los resúmenes se acumulan y luego se separan en fragmentos. Este proceso se repite hasta que todo el conjunto de resúmenes cabe en una única ventana de contexto y se genera un único resumen. Utilizamos este mismo enfoque independientemente del LLM utilizado para el resumen.