010 · 能综合的 HLS 样本，就算有效数据吗？

核心问题：当 Agent 从真实仓库抽取 HLS 设计时，Vitis HLS 综合通过究竟证明了什么，又遗漏了哪些关于功能正确性与数据质量的证据？

论文卡片

• 原题： HLSFactory-Agent: Large-Scale Agentic HLS Dataset Construction from Academic and Open-Source Projects
• 作者： Kaushik Chandana、Jay Imperatori、Tanmay Shukla、Justin Zhou、Stefan Abi-Karam、Callie Hao。
• 机构： Georgia Institute of Technology、Georgia Tech Research Institute。
• 版本： 2026-09-08，arXiv v1；分类为 cs.AR、cs.SE；发表于 ISCA 2026 OSCAR workshop。
• 定位： 用 LLM Agent 从学术项目和开源仓库抽取独立 HLS 设计的数据整理系统与初步实证研究。
• 阅读入口： alphaXiv · arXiv · 免费全文 · PDF

论文讲了什么

HLS 数据集的困难不只在于样本数量少。真实设计往往埋在完整项目里，依赖头文件、辅助函数、测试数据、编译选项和特定工具；把其中一个顶层函数整理成可独立处理的样本，需要理解仓库结构并反复修补依赖。论文试图把这段人工整理过程交给 Agent。

系统由两部分组成。第一部分从 FPGA、EDA 和计算机体系结构会议中，用关键词检索并去重可能包含 HLS 设计的论文。作者得到 2,517 条 1984—2026 年间的候选记录，但明确说明它们仍需人工检查：论文可能只是顺带使用 HLS，也可能没有公开代码，或者代码受生成流程和厂商工具限制。

第二部分才是 HLSFactory-Agent。它基于开源 Pi Agent 框架，在隔离的 Ubuntu 容器中读取一个代码仓库，识别 HLS 顶层函数，为每个设计建立独立目录，补齐源文件、头文件、工具代码和测试数据，并把非 Vitis 写法转换为 ap_int、ap_fixed、hls::stream 等形式。Agent 还会保留已有测试平台，缺失时可生成新的测试平台，最后生成调用 csynth_design 的 synth.tcl。

Agent 在抽取阶段能使用 Clang、文件编辑和 Bash，但只以带 Vitis 头文件路径的 Clang syntax-only 检查进行自测。Vitis HLS 综合是在 Agent 完成抽取后统一执行的，并未作为本轮 Agent 修复循环中的反馈。系统同时保存 JSONL 轨迹和 HTML 会话记录，以便分析工具调用、运行时间和推理成本。

主要结果

作者使用 DeepSeek-V4-Flash，对 26 个公开 HLS 仓库分别运行 Agent。系统共生成 271 个候选设计；以生成的 synth.tcl 能否完整跑通 Vitis HLS 综合作为唯一通过标准，130 个通过，141 个失败。另有 5 个仓库没有生成任何候选设计。

失败条件被设得较严格：Tcl 错误、缺失头文件、目标器件设置问题、不支持的语言构造和超时都会记为失败。因此 130 不是“看起来像 HLS 代码”的数量，而是已经跨过一次真实厂商综合前端的样本数。不同仓库差异很大：结构规整、kernel 边界清晰的项目容易抽取；依赖复杂、含生成代码或隐含构建假设的项目，即使识别出候选 kernel，也可能无法整理为独立设计。

论文的图还显示，产生更多设计的仓库通常消耗更多推理时间和费用。作者据此主张，数据抽取不能只报告最终样本量，还应考虑每美元和每分钟得到多少设计。不过当前稿件没有给出这些效率指标的汇总数值，也没有对不同模型、提示、人工整理流程或非 Agent 方法进行对照。

证据边界

首先，论文把“valid”操作化为 csynth_design 成功。这个定义可以验证代码及其综合脚本已被特定版本的 Vitis HLS 接受，却没有证明生成电路实现了原仓库的功能。虽然抽取提示要求保留或生成测试平台，报告的通过标准没有包含 C 仿真、RTL 协同仿真、与原实现的等价检查或测试覆盖率。因此不能由 130 个综合通过样本推出 130 个功能正确样本。

其次，Agent 会复制、改写并补充代码。综合成功不能区分它是忠实消除了环境依赖，还是在改写过程中改变了边界条件、数值精度或流式协议。论文也没有报告样本之间的近重复程度、许可证筛选、设计复杂度和 QoR 分布，所以“可放入 HLSFactory”尚不等于“对训练或评测具有足够多样性和可用性”。

再次，这是 26 个仓库上的初步结果，没有随机抽样说明、人工正确性审查、重复运行方差或基线。130/271 只能描述这批仓库和当前配置下的产出，不能单独回答 Agent 相比专家节省了多少工作，也不能说明更换模型后是否稳定。

最后，论文中有两种人工边界。论文索引的 2,517 条记录仍需人筛选出有公开仓库的项目；综合失败后，Agent 当前也不能利用 Vitis 诊断继续修复。作者把自动发现仓库和把 Vitis 放入 Agent 容器列为后续工作，因此题目中的“大规模”主要描述系统目标与候选来源，现有实证仍是小规模初步验证。

重点读哪里

先读 §II-A，看 2,517 条候选如何产生以及为何仍需人工复核；再读 §II-B 的七步抽取提示，特别留意 Clang syntax-only 检查与 Vitis 综合的先后关系；最后读 §III 的通过定义和 §IV 的后续工作。这样可以把已经完成的实证、作者对效率的解释和尚未实现的闭环验证分开。

思考启发

以下是导读者由论文引出的理解角度，不是作者额外验证过的结论。

这篇论文把“数据集构建”呈现为一种程序变换任务，而不是简单的代码搜索：Agent 需要从带有隐含环境的仓库中切出闭合依赖、补全工具配置，并把结果送入一个可执行判据。130 个通过样本说明，工具链反馈能够把模糊的“像一个设计”收窄为可复查的“能被该综合流程接受”。

但判据越自动、越稳定，越需要分清它所覆盖的性质。综合器是强反馈，却只对语言、依赖和综合约束中的一部分问题敏感；它可能稳定接纳一个功能已改变的设计。数据整理因此不是从“无验证”一步跳到“可信”，而是形成一串强度不同的证据：语法可接受、可综合、功能一致、实现可行、分布有价值。论文完成了其中关键的一层，也使尚缺的层次更清楚。

三个思考问题

1. “有效样本”的定义应该停在哪里？

如果一个抽取样本能综合却没有功能等价证据，它适合被称为数据集中的有效设计，还是只能称为待验证候选？

2. 把综合器放进 Agent 循环，一定会提高数据质量吗？

作者计划让 Agent 直接利用 Vitis 反馈修复失败样本；这种闭环会减少无效代码，是否也可能让 Agent 过度适配综合器而偏离原设计？

3. 规模增长与多样性增长是同一件事吗？

从结构规整的仓库中抽取出大量设计，是否会让数据集看起来更大，却仍保留强烈的项目结构、代码风格和工具偏差？