企业官网建设流程全解析

做AI芯片这行，真正让人掉头发的往往不是某个算子的计算效率上不去，而是软件栈和硬件之间那层接口永远在互相拖后腿。“AI 芯片的软硬件设计”这个系列写到第8篇，我想花一整篇的篇幅，聊聊那些把双方扯得最疼的地方：指令怎么发、数据怎么摆、访存怎么排、联调怎么追。这篇不会去复述教科书里“软硬件协同设计”的宏大定义，而是把我自己在加速器项目里亲手踩过的、修过的、想明白的细节摊开来讲。适合那些正在做加速器架构、编译器甚至只是想把一个网络真正跑上自研芯片的读者。

1. 先把软件栈当成芯片架构的一部分来定义

很多团队做AI芯片的习惯是：先定计算阵列、再说存储、然后把指令集文档丢给软件组，让编译器去适配。我见过最典型的场景是编译器组拿到手册之后发现同步机制没定义清楚，只能靠“轮询状态寄存器+固定延时”凑合，结果每个算子的空闲时间高得离谱。

1.1 软硬件接口的三份契约

如果让我提炼一个加速器和编译器之间必须钉死的接口，我会说是这三份契约：命令流格式、数据布局规则、同步与依赖语义。听起来都很简单，但每一条在真实项目中都能演化出几十个坑。

命令流是软件发给硬件的最基本控制信息，可能是真正的指令字，也可能是一包配置寄存器。它的核心问题不是“编码多紧凑”，而是执行顺序是否可控。编译器生成一条“搬输入到bank0、搬权重到bank1、启动计算”，硬件到底按什么顺序执行？如果只有一条FIFO队列，那编译器没法让搬运和计算重叠，性能就只能线性累加。

数据布局规则往往被忽视。芯片内部对地址对齐、行优先还是列优先、通道维度的摆放位置有极强偏好，编译器必须完全按这个偏好生成访存描述符。我经历过最痛的一次是对齐规则没有写进规格书，硬件要求64字节对齐，编译器生成的特征图tile随机偏移，整个工程里塞满“手动打齐”代码，性能直接掉了15%。

同步协议是三份契约里最容易被低估的。AI计算天然是搬运和计算流水穿插，编译器需要知道某个DMA完成之后可以马上去等待另一个事件，而不是把所有DMA都等完再开算。换句话说，硬件必须提供带粒度的事件ID、等待语义，以及可选的“异步启动”能力。没有这层，计算阵列再快也发挥不出来。

1.2 周期级行为模型是共同基准

我在项目里坚持最早启动的模块，不是RTL，而是一个准周期级的行为模型。它用软件模拟出命令流进去之后每个周期发生什么：搬运要多少个周期、计算单元何时拿到数据、输出何时写回。性能不必精确到每个bank冲突，但结构和延迟的量级必须和最终芯片一致。

这个模型的价值在于它成了软件栈和硬件的共同基准。编译器先对着模型调调度，硬件工程师照着模型定义RTL行为，两边就算吵架也有同一个参照物。很多人觉得这是额外工作量，但以我的经验，这个投入会在联调阶段几十倍地省回来。没有这个公共基准的时候，编译器说“我发的命令没问题”，硬件说“我的RTL没问题”，最后只能靠上板抓波形来断案。

1.3 一个字节对齐引发的性能事故

举一个我们项目里的实际案例。硬件为了简化DMA设计，要求所有描述符里的地址按照64字节对齐，但这条规则只写在了内部邮件里，没有进入指令集手册。编译器团队一开始按自然对齐生成搬运列表，遇到不规则的tile就在kernel里做一次临时拷贝。硬件工程师看到代码里有这么多memcpy，以为是软件写得笨，软件工程师以为是硬件不支持非对齐访问，整整两周双方都在互相猜。

后来把这条对齐规则公开写进规格文档，编译器的分块器直接按64字节边界做tile裁剪，临时拷贝全部消除，性能恢复。问题根源不是某个人笨，而是规格边界没有和编译器实现同时对齐。所以我现在有一个习惯：任何影响软件生成的硬件规则，必须出现在同一个文档里，没有例外。

2. 计算阵列与调度语义：一张结构图对应一套编译规则

芯片的结构决定了编译器能做什么、不能做什么。很多人喜欢讨论计算阵列本身的设计，比如脉动阵列是不是比SIMD更好，但很少有人意识到：架构的复杂度和编译器的自由度是绑在一起的。你为硬件省下的控制逻辑，最后都要让编译器用更复杂的调度来偿还。

2.1 三种阵列形态逼出来的不同编译职责

我把常见AI加速内核粗略分成三类：脉动阵列、向量SIMD和SIMT。它们的结构差异导致编译器的工作重心得完全不同。

我试过用GPU的编译思路去调度一个类脉动阵列的核，把算子铺成线程块就完事。结果每一个tile之间的数据依赖没有被显式管理，硬件只能靠全同步来兜底，算力利用率远远低于预期。反过来想，GPU之所以调度器能那么“粗心”，是因为硬件线程调度器承担了大量依赖管理；而脉动阵列把这个职责交给了编译器，两者不能互相套用。

2.2 tile尺寸不是拍脑袋拍的

调度算法里最核心的参数是tile尺寸，也就是每个时间片内放到计算阵列上的数据块大小。tile太小，数据复用不足，搬运比例高；tile太大，片上存储又装不下，还会引入bank冲突。这个平衡点必须用定量计算来找，不能靠感觉。

一个简化的估算方法：考虑输出tile，假设空域是Tr×Tc，输入通道和输出通道分别是Cin和Cout。那么这次计算需要的访存量约等于输入patch的体积、权重块的体积和输出块的体积之和。把总访存字节数除以MAC数，得到“每MAC搬运字节数”。然后去对标你的硬件平衡点：在板上存储带宽和计算峰值之比的量级。如果算出来是1.2字节/MAC，而硬件平衡点是0.5，那这个tile就是访存受限，应该增加空域tile或者让权重驻留片上。

这个公式不复杂，但它会逼你尽早决定硬件存储分配策略。哪些buffer给输入、哪些给权重、哪些给输出，早在编译器写第一行代码之前就要定好，否则后续调度全在推翻重来。

2.3 “原子指令主义”帮我省了一个月的验证时间

有一段时间，我们为了让编译器生成代码更短，给计算单元的配置包里塞了一个“超级模式”控制位，能把卷积、偏置、激活和池化一把梭。硬件逻辑变得复杂，RTL验证要覆盖的组合瞬间爆炸，编译器也要小心翼翼地为每个算子判断能不能合并。

后来我们把控制包拆成原子动作：一个负责搬运、一个负责计算、一个负责写回。指令数量变多了，但每条指令的行为都变得非常简单，硬件译码逻辑大幅简化，编译器也只需要关心“顺序”而不是“兼容”。整个项目从设计到验证，反而提前了一个月。这件事给我的启发是：软硬件设计的平衡点不在于单边是否优雅，而在于双方加起来的边际成本是否最小。

3. 一次完整的算子映射：从3x3卷积到指令流

前面聊了接口和调度的原则，现在走一遍完整的映射流程。我们用最常见的3x3卷积做例子，把算法层面的算子变成硬件真正执行的指令序列。这个过程决定了最终性能和功耗。

3.1 显式im2col还是隐式GEMM

3x3卷积可以通过im2col展开成矩阵乘，但显式建矩阵需要把输入patch复制进临时缓冲区，内存占用很大。有些芯片选择隐式GEMM，在硬件层面上支持从不同strided地址取数，省掉物理重排。这个选择的代价是硬件复杂度和编译器地址生成的复杂度都会上升。

我们当时的架构为了稳妥，先选择了显式重排，让im2col产生的临时矩阵直接落到一个专用缓冲区。优点是计算阵列看到的访存模式非常规整，编译器调度简单；缺点是多了一整轮搬运。跑小网络还好，跑大分辨率输入时，这部分开销会占到总耗时的15%以上。如果重来一次，我会在架构定义阶段就考虑让输入读取支持strided模式，而不是让软件承担全部重排成本。

3.2 把循环映射写进小代码生成器

映射卷积时最常见的工作是写一堆嵌套循环：外层遍历输出tile，内层遍历输入通道和输出通道，再配上DMA搬运和计算命令。这种代码手动维护特别容易出错，我建议一开始就做一个很小的代码生成器，输入是算子描述和tile参数，输出是一组命令流。

下面这段Python风格的伪代码，基本能表达生成器要做的事：

def emit_conv3x3(cfg, tensor_desc): for rb in range(0, rows, cfg.tr): for cb in range(0, cols, cfg.tc): for cin_blk in range(0, in_channels, cfg.tk): in_tile = build_addr(tensor_desc["input"], rb, cb, cin_blk) w_tile = build_addr(tensor_desc["weight"], cin_blk) out_tile = build_addr(tensor_desc["output"], rb, cb) dma_id = emit_dma_load(in_tile, dma_buf=0) w_id = emit_dma_load(w_tile, dma_buf=1) compute_id = emit_compute( src_buf=[0, 1], dst_buf=2, sycn_wait=[dma_id, w_id], ) emit_dma_store(out_tile, src_buf=2, sycn_wait=[compute_id])

这段代码里最关键的是每个emit_*返回的id。从生成器看到的是“等待对应的事件”，而不是“等待所有事件完成”。这样多个tile之间才能自然形成流水，DMA搬运下一个tile的同时，计算单元还在处理当前tile。很多调度性能问题都出在事件ID被忽略、所有操作被退化成全同步。

3.3 性能模型里的“三明治公式”

生成完指令流之后，先别急着上板，用周期级性能模型跑一遍。我习惯用“三明治公式”做快速判断：把一次tile的输入搬运、计算、输出写回看成三层夹心，分别估算耗时。如果输入搬运时间远小于计算时间，计算是瓶颈，可以放心加大计算阵列利用率；如果搬运时间占了大头，那就要优化tile尺寸或数据复用策略。

比如一个典型tile，计算需要4000周期，输入和输出搬运需要1500周期，流水重叠后理论时间约4000周期。但如果同步事件设计成每次搬运都要等计算结束，那实际时间就变成5500周期。这类差距在性能模型里一眼就能看出来，在上板之后再发现就只能熬夜追波形了。

4. 访存与存储层级：性能大头其实在这里

很多第一次做加速器的人会把注意力放在增加MAC数量上，但真正一跑真实网络就发现，存储带宽和片上数据摆放才是决定性因素。计算阵列再快，如果数据喂不进去，一切白搭。

4.1 片上SRAM的bank意识

片上SRAM不是一块大池子那么简单。为了支持并行读写，我们把存储切成多个bank，每个bank有独立的读写口。编译器必须清楚bank的划分方式，尽量把同一时刻需要并行访问的数据安排到不同bank，否则一旦发生bank冲突，实际带宽会断崖式下降。

举个实际例子：硬件把1MB的buffer切成4个bank，地址按交错方式映射。编译器如果不知道这个映射，把输入tile和权重tile分配在同一个bank的连续区域，DMA读取时就会互相踩踏。我在项目里让编译器加了一个简单的“bank感知分配器”，把输入、权重、输出优先落在不同bank里，同一bank的访问时间错开。这个改动看起来不起眼，却让很多算子的实际性能提升了接近20%。

4.2 双缓冲不是加上就完事

双缓冲几乎是AI加速器的标配：DMA搬运下一块数据的同时，计算单元处理当前块。但真正做联调的时候才发现，双缓冲活得怎么样完全取决于同步位有没有给对。如果你的命令流里每次搬运结束都触发一个全同步事件，那双缓冲就只剩一个空壳，硬件虽然支持双份buffer，软件却没法真正让两个buffer交替使用。

我会在架构设计阶段就要求硬件提供事件标志寄存器，每一个DMA通道和每一个计算核都有独立的完成位，编译器可以在命令包里指定要等待哪些完成位。这个机制做到位之后，流水才能真正跑起来。否则编译器要么写超复杂的轮询逻辑，要么直接放弃治疗开全同步，性能就听天由命了。

4.3 权重重排在模型加载时就该做完

大多数开源模型权重是NCHW布局，而硬件为了行连续访问喜欢NHWC或者CHWN。于是你辛辛苦苦把模型跑通后发现，第一次启动kernel前还要对所有权重做一次转置重排。这个重排如果放在kernel里面做，每次运行模型都要白花好几秒钟；如果放在模型加载阶段做一次，后续就只需要读取已经重排好的权重。

我强烈建议把权重重排放进模型序列化/预处理流程，并把重排后的权重直接缓存成文件。这样既省时间，也让运行时的加载代码变得简单很多。这个小动作不需要任何硬件改动，但在实际部署体验上差距非常明显。

5. 联调与回归：软硬件协同设计不是一次性交付

软硬件协同设计最容易被低估的不是初期设计，而是联调阶段。因为无论前期讨论得多么充分，最终软件生成的命令流和硬件的实际行为总会存在不一致。问题不在于会不会发生，而在于你能不能快速定位。

5.1 三级验证体系怎么分工

我们内部把验证手段分成三层，每一层都有明确的定位：

三层不能互相替代。指令集模拟器帮你快速验证算法对不对，性能模型帮你看调度好不好，FPGA原型帮你确认RTL行为真不真。最怕的是跳过前两层直接上FPGA，遇到问题后到底是生成器bug、模型bug还是RTL bug，没有任何头绪。

5.2 一次FPGA比模型慢38%的排查

我想分享一次真实的排错过程，它几乎代表了这类联调问题的主流链路。某个单算子在性能模型里预估20k周期，上板后实测约32k周期，慢38%。第一反应当然是我自己生成的调度是不是有问题。

排查第一步，先确认DMA描述符的数量和搬运长度。比对命令流后发现，每个tile的搬运量都没问题。第二步检查bank冲突，把访问地址带入地址映射公式，发现偶发冲突只能带来大约5%的损失，远远不够解释38%。第三步才开始怀疑同步逻辑，一条条命令去看事件ID。结果发现问题很隐蔽：生成器在拼接卷积核和写回命令时，把sync_wait参数置成了“等待所有DMA完成”，而不是等待当前tile的计算完成。

也就是说，搬运下一块输入、计算当前块、写回上一块这三件事完全没有重叠，全部在串行排队。修复起来很简单，把sync_wait改成对应该tile的事件ID，但定位的过程花了几乎一整天。这也验证了一个结论：调度性能问题，第一嫌疑永远在同步事件描述符，而不在计算本身。

5.3 golden数据要管到算子级

联调过程中最高频的操作是“对结果”。我给每个算子维护一份从参考模型导出的golden tensor，只要跑一次指令流，就看输出和golden逐元素比对。这个流程看起来简单，但执行起来需要纪律：任何指令集的改动、任何硬件配置寄存器的改动，都要重新跑一遍算子级的回归。

最容易回归不到位的地方是类型转换和边界tile。宽卷积的右下角、无法整除的通道数、量化后饱和溢出，这些边界行为最容易在软硬件两边的实现里产生差异。所以我的建议是，除了常规的随机数据测试之外，一定要固定一批包含边界情况的碎测试，它们才是真正能暴露合同漏洞的那批用例。

6. 工程上几个我一直保留的硬习惯

前面几章讲了很多方法和踩坑过程，最后我想把一些“不那么技术、但特别管用”的工作习惯一起收在这里。这些东西没有哪本书会系统写，但都是我从返工和加班里换来的。

6.1 命令格式变更日志

软硬件交接的命令格式、寄存器位域、描述符字段，一定会有改动。我要求每改动一次，就用一个简单的表格记录：字段名、偏移、默认值、变更原因、涉及模块、生效版本。每周软硬件双方review一次，而不是等版本发布之后再看。

项目里有一半的“诡异问题”，最后的结论都是“某个寄存器位上周被改了，但编译器组不知道”。有了变更日志之后，这类问题变成了5分钟就能追到的已知记录。

6.2 性能模型和RTL的逐点签核

性能模型再精细，也要跟RTL对拍。我不建议等整颗芯片做好了才去对模型，而是每实现一个子模块，就挑几个有代表性的算子，在模型和周仿真之间对比周期数。如果偏差超过5%，一定得查清楚，哪怕最后只是模型里少算了一个DMA启动延迟，也要修正模型。

把这条变成硬性规则之后，性能模型在整个开发周期里一直维持了很高的可信度。后来计算阵列再改版，大家都敢直接先用模型估结果，因为知道它不会骗人。

6.3 给生成器留足够的可观测性

编译器生成的命令流，中间过程必须带有“意图信息”。每一条命令都应该能追溯到它来自哪个算子、哪个tile、代码生成器的哪一段逻辑。我在命令包里塞了一个调试字段，上板后可以从状态寄存器dump出来。这样一旦性能不符合预期，扫一眼命令流就知道生成器在干什么，是调度顺序错了还是tile尺寸设错了，而不是把成千上万条命令打印下来人肉对。

写到这里，这篇也已经足够长了。回看“AI 芯片的软硬件设计”这个系列，真正让芯片“能打”的往往不是某一个内核跑得有多快，而是软件栈在真实负载下能不能顺畅地把硬件喂饱。如果读完之后你能记住一件事，那就是选架构的时候，一定要把“编译器怎么想”放进同一个决策表里。软硬件之间的边界清楚一点，大家的日子就好过一点。