作者:
(1)刘明杰,NVIDIA{同等贡献};
(2)Teodor-Dumitru Ene,NVIDIA{同等贡献};
(3)NVIDIA 的 Robert Kirby {平等贡献};
(4)Chris Cheng,NVIDIA{同等贡献};
(5)Nathaniel Pinckney,NVIDIA{平等贡献};
(6)梁荣建,NVIDIA{同等贡献};
(7) 乔纳·阿尔本(Jonah Alben),NVIDIA;
(8)NVIDIA 的 Himyanshu Anand;
(9) 桑米特拉·班纳吉(Sanmitra Banerjee),NVIDIA;
(10)Ismet Bayraktaroglu,NVIDIA;
(11) NVIDIA 的 Bonita Bhaskaran;
(12)NVIDIA 公司的布莱恩·卡坦扎罗(Bryan Catanzaro)
(13)NVIDIA 的阿琼·乔杜里(Arjun Chaudhuri)
(14)莎朗·克莱(NVIDIA)
(15) NVIDIA 的比尔·戴利(Bill Dally)
(16) 劳拉·当(NVIDIA)
(17) 帕里克希特·德什潘德(Parikshit Deshpande),NVIDIA;
(18)Siddhanth Dhodhi,NVIDIA;
(19)Sameer Halepete,NVIDIA;
(20)埃里克·希尔(Eric Hill),NVIDIA;
(21) 胡嘉尚,NVIDIA;
(22)苏米特·贾恩(NVIDIA);
(23) NVIDIA 的 Brucek Khailany;
(24) 乔治·科凯(George Kokai),NVIDIA;
(25) 基肖尔·库纳尔(NVIDIA);
(26)李小薇,NVIDIA;
(27) 查理·林德(NVIDIA);
(28)刘浩,NVIDIA;
(29) 斯图尔特·奥伯曼(NVIDIA);
(30) 苏吉特·奥马尔(NVIDIA);
(31)Sreedhar Pratty,NVIDIA;
(23)乔纳森·雷曼(NVIDIA);
(33) 安巴尔·萨卡尔(Ambar Sarkar),NVIDIA;
(34)邵正江,NVIDIA;
(35) 孙汉飞,NVIDIA;
(36)Pratik P Suthar,NVIDIA;
(37)Varun Tej,NVIDIA;
(38)沃克·特纳(NVIDIA);
(39)徐凯哲,NVIDIA;
(40)NVIDIA 任浩星。
我们对设计团队中潜在的 LLM 应用进行了调查,并将它们分为四类:代码生成、问答、分析和报告以及分类。代码生成是指 LLM 生成设计代码、测试平台、断言、内部工具脚本等;问答是指 LLM 回答有关设计、工具、基础设施等的问题;分析和报告是指 LLM 分析数据并提供报告;分类是指 LLM 根据日志和报告帮助调试设计或工具问题。除了分类类别外,我们从每个类别中都选择了一个关键应用程序进行研究,我们将进一步研究。每个应用程序的动机和技术细节如下所示。
A.工程助理聊天机器人
该应用程序旨在帮助设计工程师解答架构、设计、验证和构建问题,从而显著提高他们的整体生产力,而不会影响其他人的生产力。据观察,设计工程师经常喜欢集思广益、设计硬件和编写代码,但等待他们缺乏的设计知识的答案可能会放慢速度。通过避免让工程师基于错误的假设编写代码或调试他们不熟悉的代码,也可以提高设计效率。内部研究表明,典型芯片设计师多达 60% 的时间花在调试或检查表相关任务上,涉及一系列主题,包括设计规范、测试台构建、架构定义以及工具或基础设施。跨国公司的这些问题专家通常分布在全球各地,因此寻求即时帮助并不总是很方便。因此,基于从内部设计文档、代码、任何有关设计的记录数据和技术通信(如电子邮件和公司即时通信等)中提取的知识的工程助理聊天机器人可以帮助显著提高设计效率。我们使用第 III-D 节中提到的领域适应 RAG 方法实现了此应用程序。
B.EDA脚本生成
工业芯片设计流程中的另一项常见任务是编写 EDA 脚本来完成各种任务,例如
作为设计实现、自省和转换。这些脚本通常利用特定于工具和自定义的内部脚本库。学习这些库、浏览工具文档以及编写和调试这些脚本可能会占用大量的工程时间。
LLM 已被证明擅长在各种任务上进行小规模代码生成 [32],因此定制这些模型以加速工程师在此特定领域任务中的工作效率是自然而然的事情。在这项工作中,我们专注于从自然语言任务描述中生成两种不同类型的脚本。第一种是利用 Tool1(用于设计编辑和分析的内部 Python 库)的脚本。第二种是使用 Tool2(领先的工业静态时序分析工具)提供的命令接口的 Tcl 脚本。
为了构建我们针对该任务的领域特定微调数据集,我们从设计专家那里收集了这两种工具的生产脚本。我们观察到我们的 DAPT 模型可以为代码生成合理的内联注释。这使我们能够使用这些模型通过生成额外的内联注释来提高收集的脚本的质量。人类专家后来验证并更正了这些注释并创建了相关提示。这些提示和代码对构成了 DSFT 所用的数据,其格式如第 III-C 节所述。
为了以最有意义的方式提供和收集反馈,我们花费了大量精力构建图 4 所示的流程,工程师可以通过同一个界面查询模型并运行生成的代码。这让我们对生成的代码的正确性充满信心,并通过让工程师了解他们可能需要多少次更正才能获得一个正常运行的脚本来提供准确的反馈。我们通过与工具服务器建立交互式连接来支持 Tool1 和 Tool2 集成。
此外,我们还提供了一份用户反馈表,让我们可以比较不同的模型,并从用户反馈中收集有价值的见解。这些宝贵的信息可以帮助我们进一步完善我们的模型。
C. Bug 总结与分析
跟踪生产流程各个阶段中各种功能和错误的报告、分类、调试和解决是一个耗时的过程。工程经理花费大量时间查看内部问题跟踪数据库,以了解项目状态并帮助加快执行速度。因此,一个能够查看所有支持信息并快速总结技术和管理数据以及建议后续步骤的工具将提高团队生产力。我们专注于使用 LLM 生成三个不同的输出 - 一个侧重于技术细节,一个侧重于管理细节,一个推荐任务分配。
为了研究这些任务,我们使用了 NVIDIA 的内部错误数据库 NVBugs。该数据库用于错误报告、跟踪和解决以及整个公司的一般任务和功能跟踪。我们预计 ChipNeMo 模型将在此任务上表现良好,因为 DAPT 数据集中包含了大量错误数据。此外,我们为此任务构建了一个特定领域的 SFT 数据集,其中包括错误总结和任务分配任务的示例。
通常,错误描述包含大量日志文件或代码转储片段以及长注释历史记录。在这种情况下,错误文本对于我们的 LLM 上下文窗口来说太大了。为了解决这个问题,我们实施了两个解决方案。首先,我们找到并用较短的别名替换长路径名,以允许模型关联错误中多个位置出现的路径,而无需处理整个字符串。其次,我们将摘要任务拆分为增量任务,其中模型的任务是跨多个摘要和错误数据块累积数据。我们使用分层方法,首先将错误分成适合上下文窗口的块。然后汇总这些块,并累积摘要,然后分成块。重复此过程,直到整个摘要集适合单个上下文窗口并生成单个摘要。我们使用相同的方法,与用于摘要的 LLM 无关。