ACL 2026 论文解读 

原文作者来自东南大学、国家 EDA 技术创新中心、上海交通大学

用 C 语言写硬件，是芯片行业追求了三十年的效率梦想。高层次综合技术，也就是业界常说的 HLS，把算法级的 C/C++ 代码自动翻译成寄存器传输级的硬件描述，设计者不必再逐拍推敲电路行为，开发效率和仿真速度都上了一个台阶。在深度学习加速、高频交易、基因测序这些对迭代速度极度敏感的场景里，HLS 几乎是标配选项。

但真正用过 HLS 的工程师都知道，这条路远没有宣传中平坦。代码要改写成满足可综合性约束的特殊写法，性能要靠一条条编译指令反复试错调出来，报错信息晦涩难懂，调试周期动辄以周计。大模型兴起之后，一个自然的问题浮现出来：能不能让 LLM 把这摊子事接管过去？ACL 2026 收录的一篇论文给出了迄今最系统的回答。来自东南大学、国家 EDA 技术创新中心和上海交通大学的研究团队提出多智能体框架 ChatHLS，把 HLS 代码生成、错误调试和性能调优三件事装进同一条自动化流水线：调试通过率相对 Gemini-3-pro 提升 32.6%，性能调优拿到 18.1 倍几何平均加速，而单个设计的调试耗时被压进十分钟以内。

一、HLS 的理想很丰满，落地却有三座大山

HLS 的核心承诺，是让硬件设计者专注算法逻辑本身。同一段 C 代码，经过 HLS 工具综合就能变成硬件电路，仿真验证的速度比传统手写硬件描述快出一个数量级，设计迭代从以月计压缩到以周甚至以天计。问题在于，代码只是起点。同样的算法，加上不同的编译指令，综合出来的硬件可能天差地别。循环展开、流水线、数组切分这些指令的组合空间轻松达到百万量级，指令之间还存在复杂的相互依赖：给循环做完全展开却不配合数组切分，访存端口立刻成为新的瓶颈，展开带来的并行度一点都兑现不了。改一个参数，资源占用和吞吐率就可能剧烈波动。每试一次组合都要完整跑一遍综合流程，耗时几分钟到几小时不等。人工调优本质上是在高维空间里盲人摸象，想在合理的开发周期里摸到最优设计，几乎不可能。

调试是另一个重灾区。HLS 对代码有严格的可综合性要求，根本原因在于硬件资源必须在编译期就静态确定。动态内存分配意味着运行期才知道要多少存储，这和硬件预分配资源的原则直接冲突；不受约束的指针可以指向任意地址，综合工具无法把它映射成确定的存储结构。这类写法在标准 C 里完全合法，到了 HLS 里要么直接报错，要么悄悄综合出行为错误的硬件。定位并修复这类问题依赖资深工程师的领域经验，论文给出的传统流程图景里，调试往往要消耗数个人周。

图 1：传统 HLS 设计流程中，性能调优需要在百万级指令组合中试错，错误调试动辄消耗数人周。

图源：原论文图 1。

大模型看起来是天然的救星，近两年也确实有不少工作尝试用 LLM 自动完成 C/C++ 到 HLS-C 的重写和指令插入。实际效果如何呢？论文作者用 108 个从自然语言描述生成 HLS-C 的任务做了实测，每项任务重复 20 次取平均，DeepSeek-V3.2 和 Gemini-3-pro 这类旗舰模型的仿真通过率普遍不到 60%。一半左右的代码跑不通，这就是现状。

作者把症结归结为三座大山。第一是数据稀缺：高质量 HLS 数据集靠专家手工构建，成本高昂，而且现有数据几乎不暴露可综合性约束、指令选择的理由以及指令与结果质量之间的关联，模型无从学习硬件约束和指令语义。第二是优化低效：指令组合爆炸，加上指令对结果质量的影响高度非线性、因设计而异，通用 LLM 缺乏针对具体设计的架构直觉，给出的优化方案往往次优。第三是调试能力不足：通用模型的预训练语料以标准 C/C++ 为主，面对 HLS 特有的兼容性错误和指令误用错误，既认不出来也修不对。

在他人的探索里，这些瓶颈也各有印证。自动重构工具 HeteroRefactor 和 HeteroGen 能把标准 C 转成 HLS-C，但依赖预定义模板和人工监督。Dahlia、HeteroCL、Allo 这类领域专用语言抽象层次更高，却带来额外的学习成本和表达力限制。检索增强方案给模型外挂领域知识库，检索结果不准反而干扰推理。还有工作把 LLM 当作贝叶斯优化框架里的指令比较器，或者用图神经网络监督微调模型，优化质量有提升，却始终没有建立起设计、指令与结果质量三者之间的关联，面对新设计时泛化乏力。

二、ChatHLS：一条两阶段的多智能体流水线

针对这三座大山，ChatHLS 把 HLS 开发拆成生成和调试两个阶段，由一组各司其职的 LLM 智能体协同完成，再配上一套自我进化的数据机制为整个系统持续供血。

图 2：ChatHLS 工作流全景。A 为两阶段主流程，B 和 C 分别是优化数据集与调试数据集的构建管线。

图源：原论文图 3。

生成阶段，第一个 LLM 借助检索增强技术，从 Vitis HLS 官方文档构建的知识库中取回相关规范，把输入的 C 算法或自然语言描述转换成 HLS-C。知识库按 1000 字符切块、相邻块重叠 200 字符的方式组织，保证检索时上下文完整。随后登场的 HLSTuner 是一个经过专门微调的模型，负责选定指令组合策略，并把指令插入循环和数组等具体结构上。论文支持的指令有三类：PIPELINE 让循环各次迭代交叠执行以提高吞吐，UNROLL 复制循环体挖掘并行性，ARRAY_PARTITION 把数组切成多个小存储器以支持并行访问。

代码生成之后进入调试阶段。HLS 工具先对代码做仿真和综合测试，一旦报错，系统解析编译报告，把提炼后的错误信息和出错代码配对，交给专门微调的错误诊断模型。这个模型输出带详细分析的修改指令，再由一个严格遵循指令的修复模型执行修改。如果错误超出训练分布，系统会把错误信息交给一组 LLM 从多个角度给出修复建议，再由评分智能体选出最合适的方案。修完的代码不会直接交付，而是回到 HLS 工具重新验证，失败的案例继续进入调试回路，同时被数据机制收集存档。整条链路最后还有一道 QoR 检查，确认性能与资源占用满足用户需求后才输出最终 HLS-C。

这套设计里有个贯穿始终的哲学：让工具反馈说话。无论调试还是调优，模型的推理都锚定在 HLS 工具返回的仿真与综合报告上，而不是依赖模型内部的先验记忆。这一选择直接决定了后面所有训练数据的构建方式。

与单模型路线相比，多智能体拆分的收益很实际。生成、诊断、修复各自面对的任务分布差异很大，让一个模型包打天下，等于要求它同时精通创造性写作、法医式归因和机械化执行。拆开之后，每个环节可以独立选用最合适的模型和训练方式：生成环节用检索增强的通用模型，诊断环节用吃下上万条错误案例的微调模型，修复环节用低温采样的指令遵循模型。哪一环弱就补哪一环，系统整体的可维护性远好于一个黑箱大模型。

三、HLSTuner：让模型理解指令与硬件之间的因果链

先看调优这一端。HLSTuner 的输入包括源 HLS-C 代码、设计元数据如数组维度和循环次数，以及初始 QoR。QoR 是结果质量的简称，具体指延迟周期数和 DSP、查找表、触发器三类硬件资源的占用率。

HLSTuner 的输出不是直接改好的代码，而是一份结构化的优化计划，明确三要素：用哪些指令组合、各自配置什么参数与因子、作用在哪段代码上并按什么动作插入。计划由插入智能体执行。规划之前，模型会先对资源消耗做粗略预估，论文给出的上下文示例是：对深嵌套循环或高迭代次数的内层循环施加流水线，会显著抬高 DSP 和查找表的占用。有了这层预估打底，计划不至于一上来就偏离硬件预算。如果首次尝试没达到性能目标，HLSTuner 会启动迭代精化，结合当前指令配置和实测 QoR 决定下一步走向。资源占用超出预算，就把循环并行度砍半，并同步修改相关指令去配合访存；发现 DSP 或查找表大量闲置，就优先加深嵌套循环的并行度。一收一放之间，优化过程始终贴着资源红线前进。

让 HLSTuner 具备这种判断力的关键，是作者所称的 QoR 感知推理。训练时没有让模型简单学习从源代码到优化后代码的映射，而是要求它显式推理每一步指令修改如何改变综合后的硬件架构、进而改变性能。论文里有个例子很能说明问题：给循环插入 UNROLL 指令后，延迟显著下降而 DSP 和查找表占用上升，模型要学会把这件事归因于并行度提升复制了更多硬件单元，并且记住这是用资源换时间的典型交易。模型学的是定性规律而非精确数值预测，这带来两个好处：能泛化到训练中没见过的代码结构，也不会过拟合到某一款具体硬件平台。

训练数据的构建同样讲究。作者用多目标遗传算法 NSGA-II 在 20 个 Rosetta 内核上生成多样的优化设计，收集对应的 QoR 报告，再让教师模型 DeepSeek-V3.2 对照优化前后的真实代码与真实 QoR 数据，解释为什么这样改有效，生成优化思维链。思维链的内容有固定套路：分析 QoR 变化，识别数据依赖为流水线选择提供依据，权衡访存带宽与数组切分方案，评估硬件并行架构的合理性。最终得到 4804 条样本，每条包含源代码、插入的指令和完整推理过程。教师模型只允许解释已经验证过的结果，不能凭空生成方案，这个约束从源头避免了训练数据混入幻觉。

四、HLSFixer：把调试拆成诊断和执行两步

调试这一端的 HLSFixer 是一个分层修复框架，核心理念是把调试解耦成错误诊断和代码修改两个环节，由不同智能体分别负责。

流程从日志解析开始。HLS 工具的原始报告动辄几千行，充斥着资源分配、调度、绑定信息，直接喂给模型只会适得其反。系统用正则匹配和关键词检测，把报告压缩成结构化摘要：每个阶段通过与否、失败原因的高层分类、具体问题所在的代码行。诊断模型拿到摘要后，按一种从推理到指令的方式工作。它的推理过程刻意模仿人类专家的调试动线：先对照错误信息定位出错代码行，再就每个错误的成因提出假设，用日志证据验证假设，每步之后反思结论并规划下一步，最后才收敛出精确的修改动作。修复模型拿到指令严格执行，改完的代码重新跑仿真与综合，并与黄金参考结果比对，确保功能与原设计意图一致。

单次修不好怎么办？系统启动升级策略：把修改后的代码和错误信息交给一组 LLM 分别给出调试建议，评分智能体再从清晰度、逻辑性、与错误信息的吻合度、修改范围四个维度打分，选出最优建议执行。消融实验里这组会诊阵容是 GPT-5、Claude-opus-4.5 和 Qwen3-8B 三家同场提案，由长上下文能力见长的 Gemini-3-Pro 担任裁判。不同模型对同一类错误的敏感点不同，集思广益再加一道筛选，把单次修复搞不定的硬骨头又啃下来一块。

图 3：mvt 内核上的完整优化调试实例。HLSTuner 插入的指令引发冲突报错，诊断模型给出定位、原因与修改动作。

图源：原论文图 4。

论文给出的实例很直观。HLSTuner 给 mvt 内核的循环同时加上 PIPELINE 和 UNROLL，HLS 工具报告两条指令在同一循环上冲突。诊断模型分析后指出，对内层循环做完全展开会让流水线失去意义，给出的修改动作是移除其中一条指令。这个判断触及了 HLS 指令语义的核心：pragma 不是可以随意叠加的装饰品，每条指令背后都是对硬件架构的具体承诺。

诊断模型的训练分两步。作者用自动错误注入技术，在 PolyBench 和 Vitis 的 35 个正确设计上构造了 10878 条带错代码，覆盖 33 种错误类型，配对错误信息和调试思维链做监督微调。这些错误类型相当接地气：标准 C 里随手就写的 malloc，在 HLS 里属于不可综合的动态内存分配，必须换成固定大小的静态数组；不受约束的指针访问要改成显式数组；流水线加在过深嵌套的循环上会引发资源爆炸和综合超时，需要收缩到关键内层循环；数组切分的维度参数和声明不匹配，工具会直接警告切分失败。思维链由教师模型对比带错代码与正确代码生成，推理部分解释某类错误如何导致具体的报错信息，指令部分给出出错行、原因和修复动作。随后用直接偏好优化继续训练，3716 对偏好数据里，被拒绝的样本是故意抹掉错误信息后生成的分析。这个设计很巧妙：模型如果不看工具报错也能写出似是而非的诊断，就给它负反馈。几轮下来，模型被迫学会紧扣解析后的错误信息做诊断，分析习惯与人类专家对齐。

五、VODA：让错误库自己长大

HLS 数据稀缺的问题，靠一次性构建数据集解决不了。ChatHLS 的答案是 VODA，一种面向验证的数据增强机制，让系统在运行过程中不断从失败里学习。

VODA 的地基是 BugRAG，一个模块化的错误切片库。作者系统分析了 AMD 官方论坛上的用户提问、前人研究总结的 HLS 错误，以及系统运行中积累的新错误，把 HLS-C 生成和优化两个阶段遇到的错误整理成 33 种类型、五大类别：不可综合的兼容性错误、仿真错误、编译错误、功能错误和指令错误。每种错误做成一个切片，包含助记标识符、文字描述、代码示例、综合报错和根因分析。比如动态数组分配错误的切片会写明，动态内存分配不可综合，诊断动作是把 malloc 换成固定大小的静态数组。助记标识符的设计也有讲究，它给每类错误一个简短好记的名字，检索时先对标识再对内容，命中率明显更稳。检索采用稠密向量检索，每次只把最匹配的两条切片注入提示词，避免整库灌水稀释注意力。

图 4：VODA 的错误库扩展与受控错误注入流程，示例为流水线与循环展开指令冲突的错误切片。

图源：原论文图 5。

在 BugRAG 之上，VODA 做两件事。一是持续扩充错误案例：每当一个设计验证失败，检查智能体就分析出错代码和错误信息，生成新的错误切片并查询 BugRAG，如果没有匹配条目，就作为新错误类型登记入库，配上新的助记标识。二是受控错误注入：注入智能体从 BugRAG 检索相关错误切片作为上下文，评估潜在 bug 与当前代码结构的适配性，再生成带错代码。这一步的上下文评估很重要，它降低了模型硬造低级错误凑数的概率，保证产出的训练样本真实可信。

这套机制让 ChatHLS 的能力边界随使用不断外推。系统处理的错误种类越多，诊断模型能学到的模式就越全，应对复杂 HLS 错误的底气也越足。VODA 产出的带错代码和配对分析会回流为训练数据，诊断模型因此能跟上真实世界里不断翻新的错误形态，而不是守着一份静态数据集慢慢过时。

六、实验：从通过率到物理实现的全面检验

先说配置。全部微调基于 140 亿参数的 Qwen2.5-Coder-14B-Instruct，在 8 张 H800 显卡上完成，先做全参数监督微调，再叠加 LoRA 方式的直接偏好优化。训练本身并不昂贵：调试数据的监督微调用时 72 分钟，优化数据 50 分钟，偏好优化 30 分钟。评测覆盖 108 个自然语言到 HLS-C 的生成任务，其中 85 个来自 HLS-Eval 基准、23 个为作者自建，横跨 PolyBench、MachSuite、CHStone 等科学计算、嵌入式与密码学负载；调试评测包含 591 个测试用例，由 32 个正确设计注入 34 种错误生成；优化评测则覆盖线性代数、密码算法、神经网络加速器等对象。综合工具为 Vitis HLS 2022.1，目标器件是赛灵思 ZCU106，频率 100 MHz。一个设计算不算通过，要连闯三关：C 仿真验证功能正确性，综合生成时序与资源报告，协同仿真确认高级设计与生成硬件行为等价。作者还专门用 Rouge-L 指标检验了训练集与测试集的相似度，全部分数远低于 0.15，排除了数据泄漏的嫌疑。

调试能力上，HLSFixer 的总体单次通过率达到 93.4%，比 Claude-opus-4.5 高 36.8%，比 Gemini-3-pro 高 32.6%。

图 5：调试能力对比。HLSFixer 在三类测试集上全面领先通用大模型。

图源：原论文图 6。

消融实验拆开了这个优势的来源。相比只用单个修复模型，加入微调后的诊断模型带来 16.6% 的提升，偏好优化再加 3.7%，多模型评估兜底再贡献 16.5%。每一层设计都在实实在在地干活，没有装饰性模块。按错误类型细看的对比更能说明问题：面对动态数组分配和指针访问这类 HLS 兼容性错误，HLSFixer 能稳定修复，说明模型在训练中真正内化了面向硬件的编码习惯，而不只是记住了几条报错文本。

把 HLSFixer 装进完整生成流程后，ChatHLS 的生成通过率全面压制单模型基线。以最严格的协同仿真为例，ChatHLS 单次通过率为 77.2%，Gemini-3-pro 为 48.1%，DeepSeek-V3.2 只有 31.5%。仿真阶段单次通过率从 Gemini-3-pro 的 57.9% 提升到 82.1%，相对提升 41.8%。允许每个任务采样 20 次、取 5 次机会的情况下，ChatHLS 的协同仿真通过率进一步爬到 87.6%，说明多数失败案例并非能力盲区，多几次尝试就能覆盖。与同领域的 C2HLSC 和 HLSRewriter 相比，ChatHLS 在 SHA256、AES 等八个测试内核上的平均通过率也高出约 30%。

优化能力的对比更有戏剧性。实验给每种方法 15 次尝试的预算，单次综合时限设为 1 小时，超时或资源超限都记为失败尝试。HLSTuner 相对 Vitis 自动优化基线取得 18.1 倍几何平均加速，分别是 DeepSeek-V3.2 的 4.0 倍、Gemini-3-pro 的 1.5 倍、检索增强方法 RALAD 的 3.3 倍，而资源占用始终压在 80% 以内。

图 6：优化加速比对比。HLSTuner 在 15 个内核上取得 18.1 倍几何平均加速。

图源：原论文图 9。

通用大模型在这项任务上的翻车方式很典型：激进并行导致资源爆掉，或者干脆综合失败。DeepSeek-V3.2 在 gemm、2mm、symm 等五个内核上 15 次尝试全军覆没，只能按罚分记为 1 倍。作者分析它的优化轨迹后认为，模型更像是背下了特定内核的最优配置，疑似训练数据污染，换个内核就露馅。HLSTuner 则表现出真正的策略性：逐轮根据 QoR 反馈增减并行度，五轮迭代轨迹里能清楚看到它在资源红线内持续改进的过程。

面对 Dahlia、HeteroCL、Allo 这些领域专用语言和基于层次图神经网络加贝叶斯优化的 HGBO-DSE，HLSTuner 分别取得 19.4 倍、4.0 倍、2.3 倍和 1.6 倍的几何平均加速。对手各自的短板也值得一看：Dahlia 侧重存储分块与展开因子对齐，缺少循环流水线的优化手段；Allo 和 HeteroCL 要求用户手工指定每个计算节点的展开因子，设计空间导航高度依赖专家经验。使用成本的差异同样悬殊：领域专用语言要求用户投入大量时间学习专用原语，HGBO-DSE 要搜索 100 次才能收敛，HLSTuner 在五次迭代内就能给出有效方案，而且全程不改代码的功能语义，避开了 LLM 改写代码带来的正确性隐患。

在更贴近现实的 MobileNet 和 Transformer 加速器上，HLSTuner 相对基线分别加速 2.233 倍和 1.216 倍，相对 RALAD 则是 2.3 倍和 1.3 倍。两个加速器资源占用的差异也很有信息量：MobileNet 用掉 33.2% 的 DSP，Transformer 则用掉 70.3%。两者算数强度和访存结构不同，HLSTuner 为每个设计定制了不同的指令决策，生成的都是专用电路，而不是拿一套万能配置到处套。与领域专用语言的资源对比同样有意思：在 Mvt 和 Gesummv 上，HLSTuner 的 DSP 占用与 Dahlia 基本持平；在 Gemm 和 Bicg 上则敢于动用更多资源，把硬件预算吃干榨净换成性能。最硬的检验来自布局布线后的物理实现：16 个最优设计全部满足目标频率，关键路径平均 5.859 纳秒，片上功耗平均 0.705 瓦。这说明报告的加速比不是过度展开堆出来的纸面数字，而是物理上真实可达的。

效率方面，单个内核的完整流程是两次验证加最多五次优化迭代，生成不到 3 分钟，调试不到 10 分钟，优化不到 30 分钟。token 消耗上，HLSFixer 平均总量不到 Gemini-3-pro 的一半，因为大多数错误一次修复即可完成，需要多模型会诊的场景并不频繁。模型规模的scaling实验也有看点：从 15 亿到 140 亿参数，调试性能随规模稳定上升，而监督微调能让 140 亿参数代码模型的通过率达到 77.33%，反超 6000 亿参数级别的 DeepSeek-V3.2 的 66.3%。专门训练抹平参数差距，这个结论对行业落地很友好。

还有一组对照实验值得单独说。作者给通用模型配上检索增强做公平比较，发现单纯把官方文档或错误切片检索给模型，提升有限，有时反而拉低早期正确率。以调试任务为例，DeepSeek-V3.2 配上精简检索后从 66.3% 提到 79.2%，Gemini-3-pro 从 70.4% 提到 84.5%，说明检索确实有用；但把完整训练集当检索语料的方案反而略逊于精简检索，弱匹配的噪声上下文会稀释证据、干扰推理。而 HLSFixer 不靠检索也有 93.4%。结论很清楚：瓶颈不在于模型看不到参考资料，而在于缺少面向可综合性、指令语义和反馈修正的专门推理模式。检索补的是资料，微调内化的才是手艺。

七、冷静看待：能力边界在哪里

论文对局限的交代相当坦率，这部分信息对真正想用的人反而最重要。

其一，ChatHLS 的优化聚焦循环并行相关指令，暂不支持带生产者消费者逻辑的复杂 DATAFLOW 指令，也不会插入 AXI 接口指令，所以生成的是可综合的计算内核，还不是能直接部署到 FPGA 上的完整 IP。其二，优化策略只在 ZCU106 这一款器件上验证过，换用资源约束不同的 FPGA，可迁移性还需要更多案例支撑。其三，优化过程刻意不做算法级的 C/C++ 重构，作者给出的理由是不受约束的结构改写会引入难以从综合日志归因的功能偏差。这是保守但务实的选择，代价是优化天花板被限制在指令层面。

作者还强调，LLM 生成的 HLS-C 在部署前必须走标准的仿真验证流程。这句话值得所有看到 93.4% 通过率就跃跃欲试的人记住：剩下 6.6% 的存在，意味着人在回路里仍然不可省略。

从工程部署的视角再算一笔账。整套框架的微调成本是 8 张 H800 跑两个多小时，推理阶段每个内核的开销是几十分钟机时加几万 token，对比一位熟悉 HLS 的工程师数周的薪酬和排期，账是算得过来的。框架对基座模型也没有苛刻要求，论文的scaling实验表明，更小尺寸的开源代码模型经过同样训练也能逼近 DeepSeek-V3.2 的水平，企业完全可以按预算选择配置。

八、结语

ChatHLS 的价值，不止于 32.6% 的调试提升或 18.1 倍的加速比。它展示了一条让中等规模模型在专业领域战胜旗舰通用模型的可行路径：140 亿参数的 Qwen2.5-Coder，加上结构化错误知识、QoR 感知推理和工具反馈驱动的训练，就在 HLS 这个高度专业的领域里全面反超了体量远大于自己的对手。

这条路径对行业的意义，可以放回芯片设计民主化的大图景里看。HLS 本来就是为了降低硬件设计门槛而生，结果自身的学习曲线又成了新门槛，算法工程师想给模型配一块定制加速器，往往还要先啃半年指令语义。ChatHLS 这类系统成熟之后，用一句需求描述换一份经过验证的高性能 HLS 设计，可能真会成为日常开发方式。对 EDA 行业来说，这套方法论的可迁移性或许比框架本身更有想象空间。凡是拥有严格工具链反馈、领域数据稀缺、专家经验昂贵的硬件设计环节，都可能复制同样的配方：用工具反馈当老师，用受控注入造数据，用分层智能体拆解复杂任务。论文代码已在 GitHub 开源，仓库名为 ChatHLS-ACL-26。用大模型设计芯片这件事，正在从演示视频里的噱头，变成可以复现的工程系统。

参考资料

本文基于 ACL 2026 论文 ChatHLS: Towards Systematic Design Automation and Optimization for High-Level Synthesis 撰写，作者来自东南大学、国家 EDA 技术创新中心和上海交通大学。文中部分图片改编自原论文图 1、图 3、图 4、图 5、图 6 和图 9，仅用于论文解读与学术交流。文中所有实验数据均引自原论文。