HSCO-Bench: An Agent-Driven End-to-End Hardware-Software Co-design Benchmark for Systems-on-Chip

原文链接: arXiv:2605.19399

PDF

摘要

大语言模型（LLMs）正越来越多地被应用于软件和硬件设计，但这两个领域目前仍被分开评估。软件基准通常假设硬件目标固定，而硬件基准则专注于组件级优化，不考虑完整的硬件-软件栈。因此，现有的基准测试都无法评估 LLM 代理是否能够执行端到端的系统级硬件-软件协同设计。

本文介绍的 HSCO-Bench 是首个针对端到端硬件-软件协同设计和加速器丰富的异构 SoC 生成的基准测试。该基准要求 LLM 代理完成以下完整流程：

1. 分析应用程序以识别需要加速的内核
2. 设计和集成异构加速器到资源受限的 SoC 中
3. 映射内核到生成的加速器上

实验结果表明，端到端集成对当前模型仍然具有挑战性。在评估的五个前沿模型中，只有两个能够成功生成有效的 SoC 原型。即使在成功的实例中，生成的设计也远非最优——虽然观察到最高 16.22× 的加速，但最大额外资源利用率仅达到 23.67%。

图1: HSCO-Bench 端到端硬件-软件协同设计流程（来源：原文 Figure 2）

1. 问题定义

“Software benchmarks typically assume fixed hardware targets, while hardware benchmarks focus on component-level optimization without considering the full hardware-software stack.”

现有基准测试的根本局限在于软硬件评估的割裂。软件基准（如 KernelBench、TritonBench）假设硬件目标固定，将硬件设计排除在优化空间之外。硬件基准（如 RTLLM、VerilogEval）则假设算法目标已预定义，仅关注硬件优化而不延伸到应用层。

然而，最具影响力的设计决策往往跨越软硬件边界，特别是在异构多核 SoC 的开发中。这类架构包含多个针对多样化应用定制的专用加速器，是现代计算系统的支柱。在这样的系统中，软硬件可以被视为统一的设计空间，需要在专用硬件和通用计算组件之间进行战略平衡。

HSCO-Bench 的核心挑战：评估 LLM 代理是否能够

• 自主识别需要加速的软件内核
• 通过 HLS 设计和生成定制硬件
• 为 SoC 集成做出系统级架构决策
• 生成可在 FPGA 上验证的 SoC 原型

2. 方法框架

图2: Agent 驱动的自主 SoC 生成和硬件-软件协同设计（来源：原文 Figure 1）

2.1 技术基础

高层次综合（HLS）：HSCO-Bench 使用 HLS 作为硬件设计抽象，将未计时的行为描述（C/C++ 或 SystemC）编译为可综合的 RTL。从 LLM 的角度来看，HLS 提供了两个关键优势：

• C 类语法与 LLM 已经熟练掌握的软件语料库对齐，显著降低了硬件生成的门槛
• HLS 使硬件/软件边界变得可协商：代理可以以最小的源代码更改灵活地将计算内核移入或移出硬件

ESP 开源 SoC 平台：HSCO-Bench 基于 ESP 平台构建，选择 ESP 是因为其具备两个对 LLM 驱动基准至关重要的特性：

• 原生支持 HLS 流程，简化代理的硬件设计
• 基于片上网络（NoC）互连的瓦片式 SoC 架构，标准化 socket 抽象了底层系统集成挑战

2.2 测试用例集合

HSCO-Bench 精心策划了 10 个涵盖机器学习和数字信号处理的工作负载：

类别	应用	描述
异常检测	Autoencoder	面向工业制造的全连接模型
NLP	BERT-Tiny	通用句子分类的蒸馏 Transformer
NLP	MiniLM	用于释义检测的 Transformer
NLP	TinyCLIP-T	TinyCLIP 架构的文本编码组件
计算机视觉	EfficientViT	低延迟基于 Transformer 的图像分类器
计算机视觉	MiniDeiT	数据高效图像 Transformer
计算机视觉	TinyCLIP-V	TinyCLIP 的视觉组件
计算机视觉	MobileNetV4	为移动部署优化的 CNN
信号处理	NightVision	通过直方图均衡化改善低光对比度
信号处理	WAMI	ISP 流水线：去拜耳、Lucas-Kanade、变化检测

3. 实验结果

3.1 整体性能与能力差距

图3: 10 个应用的评估结果（来源：原文 Figure 3）

实验评估了五个前沿模型：MiniMax-M2.5、Kimi-K2.5、Claude Opus 4.6、GPT-5.4 和 Gemini 3.1 Pro。

模型	平均加速	平均资源开销	成功率
MiniMax M2.5	1.00×	+0.0%	10%
Kimi K2.5	1.00×	+0.0%	0%
Opus 4.6	2.32×	+2.22%	70%
GPT-5.4	1.92×	+5.86%	50%
Gemini 3.1 Pro	1.00×	+0.0%	10%

结果表明存在显著的能力差距：Claude Opus 4.6 和 GPT-5.4 是唯一能够有意义地参与端到端协同设计任务的模型。

Opus 4.6 提供了最稳健的整体性能，成功率达 70%，平均加速 2.32×，资源占用极低（+2.22%）。GPT-5.4 虽然成功率较低（50%），但展现了最高的峰值性能——在 TinyCLIP-T 和 TinyCLIP-V 应用中分别实现了 16.22× 和 11.02× 的加速。

3.2 失败模式分析

图4: 评估 LLM 代理的失败模式分布（来源：原文 Figure 4）

研究将集成瓶颈分为四种主要模式：

1. 不可编译的硬件：无效的 SystemC 语法或 HLS 综合失败
2. 不可编译的软件：C 语法错误或裸机违规
3. 硬件功能不正确：行为模拟失败
4. 软件功能不正确：运行时挂起或数值不匹配

关键瓶颈：

• 语法和接口不一致：MiniMax 和 Gemini 经常生成缺少标准寄存器接口的不完整 HLS 内核
• 过于雄心勃勃的设计：Kimi-K2.5 经常忽略提供的模板，从头构建整个子系统，导致多加速器设计的协调失败
• 软硬件边界摩擦：即使是能力强的模型也在 DMA 逻辑和数据对齐方面遇到困难

3.3 微架构洞察

微架构权衡：Opus 4.6 和 GPT-5.4 在处理相同工作负载时表现出不同的设计理念：

• Opus 4.6 倾向于设计小占用加速器，并严重依赖软件管理的分块来处理机器学习内核。这种策略将硬件资源利用率严格限制在较低水平，但由于频繁的 CPU-加速器数据传输引入了软件开销。
• GPT-5.4 偏爱单体式大规模加速器。虽然利用更多硬件资源，但这种方法通过有效绕过复杂的软件数据编排瓶颈，为 TinyCLIP 等应用产生了卓越的峰值性能。

算子融合：前沿模型展示了执行更复杂算子融合的能力。对于 Autoencoder，Opus 4.6 正确地将 dense_bn_relu 序列识别为一个连贯的逻辑块，将矩阵乘法和 ReLU 融合到单个定制 HLS 加速器中，同时将批归一化层战略性地委托给主机 CPU。

保守设计与硬件利用不足：尽管强大的前沿模型成功实现了功能正确性，但观察到普遍存在保守行为——它们几乎只实例化具有单个通用加速器（如矩阵乘法器）的 SoC。这揭示了一个关键的优化差距：在现实工程中，多加速器集成和复杂的数据传输策略对于最大化系统吞吐量和硬件利用率至关重要。

3.4 成本效率

图5: 跨应用的成本效率（η）对比（来源：原文 Figure 5）

研究定义了专门的成本效率指标：

\[\eta = \frac{1 - \frac{1}{S}}{C}\]

其中 S 表示实现的加速，C 表示尝试的 API 成本（美元）。

GPT-5.4 平均实现了比 Opus 4.6 高 7.14× 的成本效率。虽然 Opus 4.6 提供了更高的成功率和整体加速，但其多步推理带来的高推理成本产生了较低的边际回报。相比之下，GPT-5.4 在设计复杂性和性能增益之间提供了更好的平衡。

4. 与现有基准的对比

基准	领域	设计入口	内核选择	硬件设计	SoC 集成	加速评估	资源感知
KernelBench	SW	CUDA	✓	✗	✗	✓	✗
TritonBench	SW	Triton	✗	✗	✗	✓	✓
RTLLM	HW	Verilog	✗	✓	✗	✗	✗
VerilogEval v2	HW	Verilog	✗	✓	✗	✗	✗
ResBench	HW	Verilog	✗	✓	✗	✗	✓
SLDB	HW	Verilog	✗	✓	✓	✗	✗
HLS-Eval	HW	C/C++	✗	✓	✗	✓	✗
HSCO-Bench	HW/SW	C + SystemC	✓	✓	✓	✓	✓

HSCO-Bench 的独特之处在于它是首个涵盖完整协同设计流程的基准：从软件分析、内核选择，到硬件设计、SoC 集成和性能验证。

5. 局限与未来方向

当前局限

1. 资源利用不足：即使成功的代理也经常未充分利用可用硬件资源（最大额外利用率仅 23.67%）
2. 单加速器偏好：模型倾向于实例化单一通用加速器，而非多加速器协同设计
3. 复杂工作负载失败：MobileNetV4 和 WAMI 等工作负载对所有模型都构成挑战

未来研究方向

1. 多目标优化：扩展基准以在性能-资源权衡的帕累托前沿上智能导航
2. 社区贡献：模块化工件和标准化集成接口鼓励社区驱动的贡献
3. 硅实现路径：利用 ESP 的硅验证基础架构，提供从 LLM 生成逻辑到真实 ASIC 实现的低风险路径

6. 总结

HSCO-Bench 是首个针对端到端硬件-软件协同设计和加速器丰富的异构 SoC 生成的基准测试。实验结果表明，完全自主的 SoC 生成仍然具有挑战性，但最先进的前沿代理可以成功构建具有可测量加速的有效 SoC 原型。

关键发现：

• Claude Opus 4.6 在稳健性方面领先（70% 成功率，2.32× 平均加速）
• GPT-5.4 在峰值性能方面表现出色（最高 16.22× 加速）
• 硬件资源利用不足揭示了未来研究的关键优化差距
• 多加速器集成和复杂数据传输策略仍是未解决的挑战

HSCO-Bench 为评估 LLM 驱动的硬件-软件协同设计提供了标准化框架，为完全自主的协同设计和 AI 生成的定制 SoC 铺平了道路。

---

项目链接: https://github.com/B07901087/hsco_bench