⚡ electrical engineering

LLM-Driven, Datasheet-Aware Automated Hardware Compatibility Verification for Early-Stage, Pre-Schematic Embedded System Design

本文提出了一种由大语言模型（LLM）驱动的框架，该框架通过将数据手册和连接描述转化为设计图谱，以提取特定的工程属性并生成确定性的评估脚本，从而实现早期阶段的硬件兼容性验证，在达到 97.5% 准确率的同时，显著降低了与传统基于查询的方法相比的上下文开销。

原作者： Haotian Qiao, Robert P. Dick

发布于 2026-08-27

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Haotian Qiao, Robert P. Dick

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

从简单的气象站到复杂的医疗监护仪，构建一个新的电子设备都始于一个高风险的选择时刻。工程师必须选择微控制器、传感器、电源和通信模块，然后想象它们将如何组合在一起。在现实世界中，这些组件并不仅仅是插在一起；它们必须使用相同的电气语言，能够耐受相同的温度，并且在共享电力时不会烧毁彼此。如果选定的部件不兼容，整个项目可能会失败，有时甚至直到电路板已经制造完成时才会显现。修复此类错误既昂贵又耗时，往往需要废弃并重新开始整个设计。几十年来，捕捉这些不匹配情况的唯一方法是让人类手动阅读数百页的技术手册，寻找像电压限制或通信速度这样微小的细节，这是一个缓慢、乏味且容易产生人为错误的流程。

密歇根大学的一个研究小组开发了一种处理此问题的新方法，使用的是先进的人工智能，但其方式并非人们所预期的那样。他们创建了一个名为 DEVICES 的系统，全称为“嵌入式系统接口兼容性数据手册提取与验证”（Datasheet Extraction and Verification of Interface Compatibility for Embedded Systems）。该工具旨在设计项目的最初阶段工作，即在绘制任何详细的布线图之前。它接收一份硬件部件清单和一个关于它们如何连接的简单描述，然后自动检查它们是否能协同工作。研究人员发现，仅仅要求一个强大的计算机程序阅读所有手册并回答一个问题是不够的；程序往往会错过埋藏在长篇文档中间的关键细节。相反，他们的系统将这一庞大任务分解为细小、易于管理的片段，仅检索每个检查所需的特定数值，并编写一段计算机脚本来进行数学运算。这种方法使系统的验证准确率达到了 97.5%，较以往的尝试有了显著提高，同时使用的信息量也更少。

研究人员面临的核心挑战在于，现代人工智能模型虽然非常聪明，但在被要求阅读一份海量文档并寻找几个特定事实时却表现不佳。想象一下，试图在一堆堆叠在一起的数千本书籍中寻找一条特定的规则；书越多，找到正确页面的难度就越大。当工程师尝试将整个数据手册（这些文档可能长达数百页）上传到 AI 中并询问其兼容性时，系统经常会忽略重要细节或混淆同一部件不同版本的规格。AI 有时会将一种类型传感器的电压要求与另一种设备的功率限制搞混，从而导致错误的结论。研究人员意识到，问题不在于 AI 的智能程度，而在于信息的呈现方式。

为了解决这个问题，DEVICES 系统更像是一个细心的图书管理员，而不是一个简单的阅读者。首先，它根据工程师对部件连接方式的描述来构建一个系统地图。这个地图将连接分为三个不同的类别：电力如何流动、数据如何移动以及部件共享的环境条件。系统并没有要求 AI 同时查看每一份手册的所有页面，而是确定了每次检查具体需要的哪些数字。如果它需要检查两个部件是否可以进行通信，它就只检索讨论通信速度和电压水平的页面。如果它需要检查电源，它就只查看电池和调节器规格。通过隔离这些细小且相关的信息块，系统防止了 AI 被无关文本淹没或分散注意力。

一旦系统收集到了所需的精确数字，它并不会要求 AI 自己进行数学计算。大语言模型擅长理解语言和寻找信息，但在执行计算方面并不总是可靠。相反，该系统利用 AI 编写一段小型计算机程序来执行必要的比较。这段程序获取检索到的数字，并根据严格的规则进行检查，例如确保一个设备输出的电压足以被接收设备识别。由于计算机程序执行的是确定性的数学运算，因此结果是精确且可重复的。研究人员在七种不同的嵌入式系统设计上测试了这种方法，涉及 34 本不同的硬件手册和超过一千页的文本。该系统成功识别兼容性问题的准确率达到 97.5%，而采用简单上传所有文档并提问的标准方法，其正确率仅约为 15%。

研究还表明，即使给 AI 提供了一系列规则供其遵循，如果强迫它阅读完整且无序的文档，它仍然会出错。这证实了成功的关键不仅在于给 AI 更好的指令，还在于给它一套更清晰、更聚焦的信息。通过将问题分解为小的、独立的检查项，并且只向 AI 展示每次检查所需的特定数据，研究人员创建了一个可以高效扩展的系统。随着设计变得更大、更复杂，系统不需要阅读更多的文本；它只是执行更多的微小检查。这种方法确保了无论涉及多少个组件，验证过程都能保持快速且准确。

研究人员谨慎地指出，他们的系统是为设计的早期阶段设计的，即在详细布线最终确定之前。它目前还无法解释某些手册中发现的复杂图形或图表，这限制了它检查某些依赖视觉数据的电源转换器的能力。然而，对于绝大多数标准组件，该系统提供了一个强大的安全网。它允许工程师在投入制造资金之前捕捉潜在的故障，将重点从繁琐的手动检查转向创造性的系统设计。这项工作表明，工程自动化的未来不在于让 AI 一次性完成所有事情，而在于构建结构化系统，引导 AI 在正确的时间获取正确的信息，从而确保最终结果既可靠又值得信赖。

技术摘要：用于早期阶段硬件兼容性验证的 DEVICES 框架

问题陈述

在当前的嵌入式系统设计实践中，在原型制作前验证硬件兼容性依赖于对数据手册（datasheet）的人工检查以及对组件规格的对比。这一过程耗时耗力且易出错，往往导致在后期才发现不兼容问题（例如电压失配、通信协议冲突或环境范围违规），从而导致昂贵的 PCB 返修（respin）和开发周期延长。

虽然大语言模型（LLM）为自动化信息提取和推理提供了潜力，但直接的“上传并查询”工作流在这一领域并不适用，主要原因有两点：

上下文过载与属性遗漏： 硬件数据手册篇幅冗长且信息分散。将整个文档输入 LLM 会超出有效的上下文窗口，并触发“迷失在中部”（lost-in-the-middle）现象，导致模型忽略关键且分布式的工程属性。
验证标准的歧义性： 随机的自然语言提示缺乏可靠验证所需的显式、特定领域的规则。由于缺乏结构化标准，LLM 会产生不一致的评估、遗漏必要属性或产生约束条件的幻觉。

现有的自动化工具通常在电路图层面（设计后）运行，或依赖于详细的网表。在早期架构阶段存在自动化验证的空白——此时仅有高层级的连接描述和制造商数据手册，但尚未定义详细的引脚级电路图。

方法论：DEVICES 框架

作者提出了 DEVICES（面向嵌入式系统的接口兼容性数据手册提取与验证），这是一个由 LLM 驱动的框架，旨在在原理图捕获之前检测接口层面的不兼容性（电气、通信、电源和环境）。该系统通过可追溯、模块化的验证阶段来转换工程信息，而非依赖端到端的 LLM 直接决策。

该流水线由四个核心组件组成：

1. 验证标准（形式化规则）

DEVICES 不使用随机提示，而是利用一套面向领域的验证标准库。每个标准明确定义了：

必需的工程属性： 特定的定量和定性属性（例如 $V_{OH,min}$ 、 $V_{IH,max}$ 、工作温度）。
评估程序： 用于比较的确定性规则，包括针对缺失规格的备选逻辑（例如，在缺乏特定 $V_{OH}$ 时使用典型的 I/O 电源轨电压）。
兼容性规则： 用于判定“通过”或“失败”的逻辑条件（例如， $V_{OH,min} \ge V_{IH,min}$ ）。

2. 连接感知的设计图构建

LLM 将自然语言描述的连接关系转换为结构化的设计图（Design Graph, DG）。该图将系统分解为三种类型的网络节点（netnodes）：

电源网络节点： 代表电源域，区分电源供应者（sources）和负载（sinks）。
数据网络节点： 代表连接对等设备的通信通道（如 SPI、I2C、UART）。
环境网络节点： 代表共享的物理运行条件（温度、湿度）。
这种分解使系统能够将验证任务分割为局部的子问题，从而避免了同时对整个系统规范进行推理的需求。

3. 分层属性检索与缓存

为了避免上下文臃肿，DEVICES 不会将原始数据手册直接喂给 LLM。相反，它从预构建的硬件知识图谱中进行任务感知检索：

分层搜索： 系统遍历知识图谱层级，定位与特定网络节点相关的 functional block（功能块）（例如，仅针对 SPI 相关的网络节点检索 SPI 属性）。
模型感知过滤： 确保仅检索当前使用的特定设备变体或系列中的属性，防止混合不兼容的规格。
缓存： 根据设备型号和验证领域对检索到的属性进行缓存，消除重复交互带来的检索成本。
基于引用的操作： LLM 生成引用属性 ID 的结构化指令，而非重新生成属性值，从而确保对源数据的忠实度。

4. 确定性脚本生成与评估

对于每个网络节点，LLM 利用检索到的属性和适用的验证标准生成 Python 验证脚本。

关注点分离： LLM 处理语义检索和程序生成，但不执行数值计算。
确定性执行： 本地脚本执行生成的代码，以进行单位转换、范围比较和数学逻辑运算。这确保了数值准确性并防止了 LLM 的计算幻觉。
级联电源评估： 对于电源网络，系统递归地将下游功率需求传播到上游节点，评估总负载是否符合电源能力。

核心贡献

可扩展的连接感知验证： 该框架将兼容性验证从隐式推理转变为显式的模块化程序。通过将问题分解为特定网络节点的任务，验证工作量随组件交互量而非总数据手册量进行扩展。
面向领域的验证标准： 作者将兼容性规则形式化为结构化标准，用以指导属性检索和脚本生成。这消除了用户手动设计复杂提示的需求，并确保了跨不同硬件类型的一致性评估。
而无需用户手动设计复杂的提示词，并确保了跨不同硬件类型的一致性评估。
任务感知的上下文构建： 通过使用以属性规格为中心的提示，取代了文档级的提示，系统构建了极简且相关的上下文。这显著降低了输入 Token 数量，同时保留了工程完整性。

评估结果

该框架在 7 个嵌入式系统设计上进行了评估，涵盖 34 份数据手册（共 1,210 页），涉及环境传感、健康监测和位置追踪等 IoT 应用。

准确率： DEVICES 实现了 97.5% 的兼容性验证准确率。
- 基准对比： 未使用验证标准的标准“上传并查询”基准方案仅达到了 14.9% 的准确率。
- 消融实验： 使用了验证标准但未进行任务感知上下文精炼（即直接喂入完整数据手册）的基准方案达到了 62.7% 的准确率。这表明仅靠显式标准是不够的；上下文精炼对于防止属性遗漏和变体混淆至关重要。
上下文效率： 与单次处理全 PDF 的工作流相比，DEVICES 将输入上下文大小减少了 8.6 倍。
- 虽然报告了设计的聚合 Token 总数，但任何单个验证查询的上下文大小均保持在 4.6k tokens 以下。在一个涉及五份数据手册（单次处理约 223k tokens）的具体评估示例中，DEVICES 通过对应不同兼容性网络节点的六个查询，使用了约 18k 个输入 tokens。
属性忠实度： 系统始终仅使用输入上下文中明确提供的属性，避免了引入外部或幻觉数据。

意义与主张

论文声称，DEVICES 证明了在设计早期阶段（原理图实现之前）进行 LLM 辅助、基于规格的硬件兼容性验证的可行性。

作者强调，值得信赖的设计自动化不应依赖 LLM 直接从文档中生成答案。其价值在于通过可追溯的验证阶段转换工程信息。通过分解任务、形式化标准并构建紧凑的上下文，该框架：

实现了对文档级不兼容性的早期检测，降低了昂贵 PCB 返修的风险。
提供了一个透明、可审计且可重复的验证过程。
提供了一种可扩展的架构，即使在 LLM 上下文窗口增长的情况下依然有效，因为系统的价值源于结构化的任务分解，而非仅仅是克服上下文限制。

该工作目前局限于文本规范；尚不支持对图形效率曲线（例如开关稳压器）或基于图像的数据手册进行解释，尽管作者指出这是未来与图像理解工具集成的潜在领域。