企业官网建设流程全解析

做AI芯片这行的人经常会遇到一种尴尬：芯片流片回来，跑分死活拉不上去，硬件团队说“设计没问题”，软件团队说“编译器已经尽力了”。两边都没撒谎，但整颗芯片就是发挥不出该有的性能。我在这个领域折腾了几年之后越来越确定，问题基本都出在软硬件接口的“语义”没有对齐上。这篇是这个系列的第三篇，前两篇分别讲了架构选型和数据流设计，这篇专门聊软硬件协同设计里最容易翻车、也最值得提前投入的部分——从指令集怎么定，到编译器怎么映射，再到真实项目里踩过的坑和完整的排查思路。适合正在做AI加速器、NPU软件栈、或者刚接触系统软件和体系结构交叉方向的工程师看，就算你现在只做应用层，里面的思路也可以帮你理解为什么某些算子在某些芯片上格外难优化。

1. 先想清楚一件事：软硬件接口不是“边界”而是“协议”

1.1 为什么CPU时代那套分工放到AI芯片上会失灵

传统CPU的世界里，软件和硬件的分工很清晰。指令集架构（ISA）是那条边界，软件通过编译器生成指令，硬件负责把指令执行掉，两者都遵守同一个ISA的约定，中间的微架构怎么折腾，软件不用操心。这套逻辑在x86、Arm上都跑了几十年，稳定，可靠，生态庞大。

但AI芯片不是这个玩法。AI芯片的架构迭代速度极快，算子形态又五花八门，从卷积、矩阵乘、激活函数到各类量化操作，每一种对硬件资源的要求都差得很远。而且很多AI芯片为了做极致能效，会选择相当激进的架构——二维脉动阵列、大容量的片上暂存器、多级DMA、异构多核，这些东西如果都像CPU那样通过通用ISA暴露给软件，编译器根本负担不起，生成的代码要么极其低效，要么根本没办法生成。

我个人的理解是，AI芯片的软硬件“边界”是一条宽宽的交界带，不是一条线。你必须在设计初期就把这条交界带里的内容想清楚，把它定义成一套稳定的、双向遵守的“协议”，而不是等RTL冻结了再去补。谁先把这个想清楚，谁的项目进度就会明显更顺。

1.2 我们最终定义的三层可见接口

在实际项目里，我们没有只定义一个ISA，而是把软硬件之间可见的内容拆成了三层，每一层面对不同的使用者。这样分层的最大好处是，每一层的变更可以由不同团队独立评审，不至于让一个小小的寄存器改动直接冲击编译器后端。

我举一个具体例子。某个算子里，输入张量的通道维度在内存里是连续排列的，但硬件的向量单元死活要求通道对齐到32字节。如果这个“对齐要求”只写在某个驱动函数的注释里，几乎必然出问题——编译器生成的DMA描述符没有做padding，硬件读出来的数据就不对，然后软件侧会怀疑是硬件BUG，硬件侧会怀疑是编译器BUG，两边扯皮好几天。

所以我们在做架构手册的时候，把数据接口层的约定写得比指令集手册还细致：包括每个算子的默认内存布局、对齐要求、每个DMA描述符字段的伪代码解析，甚至给了三个不同层级的“合法示例”和“非法示例”，让软件团队照着写。实践下来，这个投入的回报极其值。

1.3 一个反直觉的结论：接口要“窄”而不是“宽”

很多工程师——包括我自己早期——都觉得硬件很强大，那就多暴露一些控制能力给软件，这样编译器可以极尽优化。这个想法在理论上没错，工程上却是个陷阱。

接口一旦太宽，会带来两个实际问题。第一，软件栈的每一层都会有人“顺手”去碰硬件细节，今天运行时读一个寄存器，明天编译器复用一段保留内存，后天驱动又做了个特殊的中断处理。这些细节交织起来，任何一次小的架构调整都可能导致连锁崩溃。第二，验证和调试的维度爆炸式增长，窄接口的时候指令组合数量可能是几千种，宽接口直接变成几万种，功能验证和性能回归花的时间根本扛不住。

我们后期定的原则是：只暴露那些有明确语义、经过场景论证的控制能力，其余一律由硬件自洽完成。宁可软件侧多算两个周期，也不给一个模糊的硬件后门。历史经验告诉我，这种克制换来的项目节奏更稳，最终性能反而更容易调优。

2. 硬件侧最容易“拍脑袋”的三个设计点

2.1 计算阵列的拓扑：不是越大越好，而是要与编译器“可切分”的能力相配

脉动阵列或者乘法器阵列的规模和片上的存储系统是绑在一起的。很多人做架构选型的时候只看峰值算力——行了，256乘256个MAC单元，8TOPS，看起来很美。但等到软件侧开始做算子映射，问题马上来了：片上缓存只有2MB，一个常见的大卷积层，输入是224x224x256，输出带宽需求算下来，缓存根本放不下一个完整的tiling块。

这时候编译器被迫把通道维度拆小，比如原来可以一次把一个通道组整个算完，现在必须拆成4个分片。分片本身无所谓，但每个分片之间都要有DMA搬运。实测下来，这类情况下DMA搬运时间和计算时间的比例能到1：1，峰值算力再高也没用，整个沿路的有效吞吐打折超过一半。

后来我们的做法是，在项目早期就让编译器团队和架构团队坐下来一起建一个粗粒度的性能模型。架构团队提出一个候选拓扑，编译器团队用这个模型去跑几个代表性的模型——ResNet系列、一个小型Transformer、几个MLP变体——记录“如果硬件这么定，编译器能切出什么形状的loop结构、搬运量多大、利用率大概多少”。来回几轮，架构再定死。这比拍脑袋定阵列，然后软件硬扛要省几个月的时间。

2.2 指令语义要“聪明地傻”：计算指令的边界必须极其清晰

AI芯片的指令集设计容易走两个极端。一个极端是学VLIW，一条大指令塞了十几个并行槽位，粒度极细，编译器兴奋，硬件实现的人想哭。另一个极端是设一大坨高层指令，比如“执行一次完整卷积层”，硬件内部自己调度，编译器很轻松，但灵活性就没了，换个新算子只能干瞪眼。

我们中间平衡下来的做法，是定义一套“算子微码加数据流配置”的模式。核心计算单元执行相对细粒度的矢量运算指令——乘加、点积、向量加、激活函数，而数据流通过配置全局的DMA任务描述符和阵列的广播模式来确定。为什么要这么设计？因为编译器最需要的是把上层模型里的循环切得足够细、排得足够好，它需要指令级的表达空间。但我也承认，这种设计初期指令密度较低，后面为了降低取指开销，我们还是加了简单的循环缓存和无条件跳转指令。

这里有一条很重要的经验：算数指令的“语义边界”要靠周期精确的伪代码定义，不能只写几句自然语言。比如一条“点积16”指令，伪代码要明确写出16个周期内硬件每个cycle在做什么，哪些load结果可以forward到下一拍，哪些场景会stall。编译器工程师看了伪代码才能判断一条指令能不能在不违反数据依赖的情况下被调度到某个slot。自然语言写“与C代码行为一致”这句话，是后来无数对线时间的开始。

2.3 DMA与同步机制是隐藏的性能“刺客”

第二个坑来自DMA和同步。硬件团队如果不在设计主算力总线时考虑“数据什么时候准备好”这件事，软件侧的代价会非常大。

我见过一个项目，每颗NPU核心执行完一次计算以后，要给目标缓冲区发出一个完成事件，下一个核心需要等这个事件才来读数据。需求的逻辑非常简单，但硬件实现上只提供了一个“全局屏障”寄存器的同步方式——所有核心必须一起等，任何一颗卡住，整个系统全部停住。结果是，模型里稍微有一点不均衡的多核心负载，性能就塌方，延迟剧烈抖动。

正确的做法，是提供细粒度的、按缓冲区组进行同步的机制。比如DMA写入某个地址块完成，可以发出一个事件状态，消费者可以通过查询性地等待，而不是必须阻塞所有核心。这个机制在架构侧做起来不算复杂，但对编译器和运行时真是太关键了。编译器可以根据数据依赖关系精确插入等待，而不是每次在可能冲突的地方插入全同步屏障。全同步屏障的代价有多大？我们实测过一个典型案例，把每层之间的全同步改成细粒度事件后，端到端推理延迟直接缩短了18%。这18%没有增加任何算力，就是把同步开销打下来了。

3. 编译器侧如何向硬件“表白”：映射、分块与内存规划

3.1 从模型张量表达式到带循环结构的中间表示

编译器对接AI芯片，本质上要回答一个问题：上层模型里那些看起来很清爽的算子，怎么变成硬件能高效执行的、带循环和地址计算的指令流？

我们早期踩过一个理论坑，就是试图直接把框架的计算图转为指令序列，等于用“图调度器”干“编译器”的活儿。这种做法跑通简单模型可以，跑深一点的模型完全不行，因为缺了循环变换那一层，数据分块和内存复用根本做不出来。

后来我们建立了三个层次的IR。第一层是从推理框架接到的计算图及张量表达式，这一层不做任何硬件相关的事情，只做数学性质的分析——shape推导、广播消除、常量折叠。第二层是带循环结构的逻辑IR，在这一层，编译器拿到张量表达式以后，根据目标硬件的片上容量推导出循环分块方式——比如把通道维拆成多块、把空间维切成分片——并附着预计的访存信息。第三层是带物理资源约束的IR，此时每个循环块被分配到具体的PE组、缓冲区地址和DMA通道上，最后从这个IR发成指令流。

这套分层看似增加了工程量，但每一层的边界都对应着一种独立测试方式。IR1可以用纯CPU参考核做数值对比，IR2可以用一个独立的循环变换工具做simulate，IR3才真正依赖我们自己的硬件模型。软件栈的排错效率因此提高了很多。

3.2 内存规划是一道“算术题”，不是经验题

片上SRAM怎么分配，堪称整个软件栈里最有数学美感的工作。每个算子的输入、输出、权重、偏置、中间结果，都要在某几块SRAM里来回倒腾。倒腾得好，DMA可以提前搬运下一块的数据，计算几乎不停止；倒腾得不好，所有单元都在干等内存就绪——也就是俗称的“stall”。

内存规划的第一步是生命周期分析。每个张量从被生产出来开始，到最后一个消费者读完它为止，它需要占用的SRAM区间是可以计算的。然后把多个算子的生命周期叠起来看，就可以判断哪些张量可以复用同一块内存。这一步用到的工具和通用编译器里的寄存器分配没有本质区别，只是寄存器的名字换成了“SRAM分页”。

第二步是双缓冲策略。给定一个循环分块之后，我们会把SRAM分成A、B两组，当前计算块用A组数据就地计算时，DMA提前把下一个块的数据搬到B组。交替使用。关键是要算出让两组缓冲“恰好”交替的边界条件：搬运时间小于计算时间，否则还是会暴露空闲。我习惯的做法是：计算一下预计搬运时间，再和计算周期模型做比较，如果搬运时间超出计算时间，就调整分块形状，让每一块的粒度变大，把搬运次数降到计算时间罩得住的范围。

第三步是留buffer余量。不要把所有SRAM都填满到极致，必须留一块“碎片区域”用于满足对齐和padding。我们之前定过一个约束：编译器规划的内存占用不得超过片上容量的85%，剩下15%是预留空间。这个约束看着浪费，但它救了很多次命，尤其是遇到非典型输入尺寸的时候，预留空间能兜底住编译器因为形状推理不精确而产生的额外临时需求。

3.3 代码生成：把依赖关系翻译成同步指令

定位“谁等谁”是代码生成阶段最耗神的一件事。每个DMA写回缓冲区之后，哪些PE可以从这个缓冲区读？PE写完一块结果之后，在它被覆盖之前要不要通知后续的DMA？这些依赖如果表达不当，轻则性能下降，重则数据被覆盖产生随机错误。

我们实际用的是“先算后插”的保守策略：先在IR3里构建每个内存对象的生产者和消费者表，然后把内存访问排序一遍，检查有没有跨缓冲区、跨PE组的访问冲突。再在这个排序基础上插入等待与同步指令，而不是在指令发射过程中边走边看。因为边走边看只能做局部判断，极易漏掉跨层依赖。

生成指令的调度顺序也有讲究。常规的做法是先安排数据搬运，再安排计算指令，最后安排同步。但我们的经验是，NEI（Non-Essential Interleave）阶段需要一个相对“智能”的启发式调度器：DMA的启动指令可以被放在更早的空闲slot里，计算指令尽量和一次DMA的等待期重叠。这种排序优化对整体延迟的改进，实测数据可以到10%到15%。

4. 一次真实的性能回退：完整排查链路

4.1 现象与观察：一个算子家族利用率腰斩

某个型号的数据准备基本完毕、开始做端到端性能回归期间，我发现一个很别扭的现象。从某个版本开始，一连串针对特定模型族的算子——包括几个深度可分离卷积、逐通道卷积和一组类似的矩阵分解操作——有效利用率普遍从75%到80%掉到了45%左右。其他算子不受影响，整个模型端到端的延迟也因此上涨了接近30%。

第一反应是代码提交里谁改坏了调度。我翻了改版日志，发现确实有几个提交动到了内存分配和布局转换的部分，但代码审查时都觉得不影响。于是开始了多日排查。

4.2 第一步：用数据测试排除精度问题

因为算子涉及量化操作，我们最初怀疑是量化系数在数据重排时被错误搬运，导致计算没有错误，但多了一些奇怪的“保护性”路径，最终影响了性能。为了验证，我把这些算子的输入导入到同一芯片的纯数值模式下面，用一个全局关闭DMA优化的配置跑一遍，数值结果与基准版本完全一致。这就把“数据算错”和“精度出问题”这两类原因基本排除了，可以放心把注意力全部放到调度与访存上。

这一步很重要：性能问题排查前，优先确认数值正确性。数值不对，后面一切分析都是空中楼阁。

4.3 第二步：用单算子仿真环境定位到指令序列

接下来，我用仿真器对这些算子做了单算子trace。仿真器里会记录每个指令槽发射情况、PE空闲cycle计数、DMA队列深度等信息。从trace结果一眼看到一个异常特征：几乎所有相关算子的空闲时间都集中在“等待局部缓冲数据”的信号上，而且等待的地址段高度集中在某个buffer的低地址部分。

按照成本从低到高的原则，我先在仿真器里尝试把该buffer的起始地址偏移加上若干字节padding，结果有效等待周期数立刻下降了不少。到这一步，怀疑对象基本锁定了“bank冲突”方向。

4.4 第三步：定位到bank访问冲突与DMA burst边界

芯片的片上SRAM通常被物理划分为多个bank，每个bank只允许有限数量的访问并发。如果编译器生成的DMA描述符目标地址对齐到32字节边界，但buffer首地址由于上一轮分配的差异落在了某个bank的固定偏移上，DMA burst的数据宽度就会跨多个bank，导致某个bank在某段时间内承受过密访问，其他bank却闲置。

更具体的原因是：这几个算子都是小通道数、低空间分片的形态，地址在低区域集中，而编译器在将上一轮输出数据布局转换为下一轮输入布局的时候，给地址分配的“间隔步长”刚好踩中了网络上地址交织的“陷阱”——DMA burst 长度是固定的，但地址步长让它无法均匀分配到多个bank，引发反复冲突。这部分实现上其实没有坏，但“恰好碰上”就成了性能黑洞。

4.5 修复与验证：既改编译器也改一个硬件参数

修复分成两层。编译器侧修改了这些算子的内存分配策略，在数据布局转换时主动插入至少一个地址偏移，避免所有缓冲区起始地址落进同一bank组；同时把该算子族的DMA burst长度调整为与bank宽度匹配的数值。硬件侧做了一点小调整，把“典型场景下网络的最小交错间隔”暴露为一个可配置的内部参数，让编译器可以查询，而不是靠启发式去猜。

修改后，仿真器里该算子家族的有效利用率恢复到了73%左右，再加上把我的padding策略继续打磨，最终稳定在78%。端到端推理延迟回到了正常水平，还略有一丁点提升。这个案例给我最大的教训是：软硬件协同设计里的“性能回归”，很可能不是某一行代码错了，而是两个模块各自“正确”地运作，却互相踩到了隐含的物理约束。只有把bank布局、burst长度、地址对齐这些纳入软件侧的知识库，才能从根上避免同类问题。

5. 在出片之前，靠什么来验证软硬件协同是否正确

5.1 搭建一个“可信的指令语义仿真器”比想象中更重要

很多项目在硬件RTL还没ready时，软件栈就已经开工了。如果没有一个可以信任的仿真器，软件侧就只能写“凭感觉”的代码，等RTL回来再逐个调整。我的建议是，指令集定义完成后，立刻投入一到两个月去搭一个周期较准的指令仿真器。

仿真器的准确度分两个级别。第一个级别是指令功能级仿真，能逐指令产生正确结果，跑通算子的数值是否和CPU对齐。第二个级别才是周期级仿真，能真实反映每个指令的cycle、DMA和PE的并发情况、bank冲突等。我们实践下来，第一个级别是必须的，第二个级别在性能调优前也是必须的。

仿真器的build做得好，整个软件栈就可以在“真实硬件”还没出来之前完成大部分开发，登基的时候问题数量会少很多。做仿真器最无聊的部分是维护与RTL语义的一致性。每次RTL修改了某个指令的时序，仿真器就要同步更新。如果不做这个同步，等到仿真器和RTL出现偏差，所有人的分析都很痛苦。因此，我们把“软件仿真器语义与RTL验证case的一致”写进了交付流程，每周跑一遍指令语义一致性回归。

5.2 周期模型：一块白板和一个电子表格就够起步

不少团队在等RTL的阶段会陷入“什么都不好干”的局面。其实最简单的周期模型用一张电子表格就能起步。把架构图简化成几个数值参数：MAC阵列规模、SRAM容量、DMA带宽、bank数、burst宽度，再配合一个按算子形状拆分的公式，就能够估算一个候选算子的理论最优周期。

这种白板级模型，主要是用来约束上下限的。比如上面提到的那次bank冲突，半个小时的Excel模型就能把“理想利用率上限”和“当前策略的理论下限”算出来，排错方向会更聚焦。虽然简陋，但在出片前它是定位性能问题的最快工具。

5.3 “最小端到端”要尽早跑通：喂进一颗小模型

出片前最兴奋的时刻，往往是把一个足够简单的端到端模型——比如单层卷积加GAP加一个全连接——完整跑通的时候。我强烈建议，在规划软件栈的时候，把“第一个最小模型跑通”的目标定义成里程碑，而不是默认结果。

“最小端到端”并不是只在演示版里跑个加法，它需要把完整的处理链路都打通：模型解析、图优化、算子lowering、内存分配、DMA调度、指令发射、运行时资源管理，甚至包括模型加载的文件格式。这一条链路看起来很多余，实际却是暴露软硬件接口“协议”里各种隐含假设的低成本手段。我们很多设计缺陷，都是在最小端到端阶段被发现的，那时候改动任何一侧都还不算伤筋动骨。

6. 踩过这些坑之后，我对协同设计的几条心得

6.1 软硬件接口文档要像“法律条文”一样写

接口文档最大的敌人是“每个人读起来都觉得自己理解了，但各自理解的不一样”。解决方案很简单：语言不够，伪代码来凑；伪代码还不够，给波形图或者表格示意。所有关于“时机”和“顺序”的描述，都要有明确的周期语义。比如一条“DMA完成”描述，要确认从哪个信号有效到哪个时刻数据可读，中间隔了多少个周期。当前面忠实依照该文档做实现的编译器，和硬件侧参考模型连跑三天不出冲突，才算文档合格。

6.2 性能优化要按“先访存、再循环、最后指令”的顺序推进

软件调优最大的浪费来自过早优化。很多团队一上来就想搞算子融合、想搞指令级并行，结果基线都没起，分不清瓶颈在哪。我的顺序是：第一步把数据布局和DMA调度理顺，确保访存不见拖延；第二步调整循环分块与多核调度，确保计算主体被有效占用；最后再考虑给指令做更精密的排布。

有些优化，比如算子融合，看着是软件层赢了一截，实际上会让内存生命周期变长，本来可以提前DMA搬运的块反而等得更久。不动基线就做这类大刀阔斧的优化，我觉得是纸上谈兵。

6.3 架构变更必须带着软件栈一起Review

很多项目的架构评审会，只有硬件团队在讲寄存器级设计。我后来坚持一个规矩：任何架构改动，哪怕只是加一个指令，也要让编译器团队和驱动团队到场，回答三个问题——新指令对我们支持的算子家族有什么帮助？现有指令序列是否需要全部重排？软件栈的测试用例是否需要新增？如果三个问题里有两个答案是“不太清楚”，那这个架构改动就先pass掉，留到软件侧消化完了再上。

看起来这条准则让评审周期变长，实际上它消灭了大量返工。我自己见过的最贵的一次返工，就是一条看似无害的、为了峰值性能加的“组合计算指令”，结果编译器因为不知道时机，每次都让它串行执行，最后改版本把整套调度器推翻重来。

6.4 心态上要接受“没有完美的接口，只有逐步逼近的协议”

写到后面越来越觉得，软硬件协同设计本质上是在不确定里做折中。你不可能一次设计出永不改动的接口，但可以通过仿真器、周期模型、代码评审和最小端到端来逐步逼近一个稳定形态。重要的是，这个过程必须在芯片回来之前走完大部分，而不是等真机出来以后，用一次次的流片迭代去填坑。正式版本的流片成本高，迭代周期长，能在软件侧和仿真环境里解决的问题，绝对不要留到真机阶段。

最后分享一个实际体验吧。在我们某个项目里，真正让整个软件性能出现一次大跃进的，不是某一版编译器优化，而是大家终于统一了“数据布局这件事由编译器说了算，驱动只负责搬运、不负责理解数据”的规范。这个规范立下去之后，之前很多“明明功能正常但性能总是不对劲”的问题自动消失了。类似这样的“分界共识”，比任何单个算法技巧都值钱。希望这篇能给你一些参考，让你们的芯片和软件在第一次碰面的夜晚，少一些互相干瞪眼的时光。