1. 指令集抽象层：软硬件之间第一份"工作合同"

1.1 指令集不是天经地义的——它是你自定义的设计决策

很多刚从通用处理器转向AI芯片设计的工程师，最容易犯的一个错误就是把指令集当成"理所当然"的东西——觉得芯片嘛，总得有指令，有指令就得有取指、译码、发射这些流程，于是按通用CPU的思路设计了一套细粒度的标量指令集，结果编译器后端越做越复杂，硬件利用率却始终上不去。

这里要先把一个概念掰开：AI芯片是领域专用架构（DSA），它不需要像通用CPU那样兼容几十年累积的软件生态，指令集完全是你可以自己定义的。这个定义的本质，是给硬件和软件之间签一份"工作合同"：硬件承诺"你给我这种指令，我就能用这个吞吐执行"，软件承诺"我按这套指令组织计算，不越界、不临时造新语义"。合同条款定得怎么样，直接决定后面编译器好不好写、硬件控制逻辑好不好做、算子能不能调到高利用率。

我在实际项目里的体会是，指令集抽象层级大概分三类：

大部分实际项目的选择不是"三选一"，而是"张量指令为主体 + 少量标量指令做控制"。原因是：卷积、矩阵乘这类算子占了AI负载的绝大部分算力消耗，用张量指令一次吃下一大块计算，能大幅减少取指和译码的次数；而像地址生成、循环边界判断这类控制逻辑，交给标量指令处理，灵活且不拖累主体计算。

1.2 张量指令集的"粗细粒度"之争：为什么粗了会硬，细了会软

张量指令的粒度设计，是我见过最多团队来回折腾的地方。粗到"整层一键执行"和细到"每次只能做一行点积"，是两个极端的失败案例。

把指令做得太粗，比如一条指令就把整个卷积层做完，听起来很美——软件侧几乎不用做什么调度。但硬件为了实现这个语义，内部要内置一个巨大的状态机，去处理padding、stride、channel扩张、甚至activation融合，所有细节都被焊死在RTL里。之后算法团队一旦提出新的融合需求或新的算子变体，硬件改起来伤筋动骨，软件还只能干等。

把指令做得太细，比如把load、compute、store完全拆开，每个都做成单元素行为，硬件实现倒是简单，但每条指令都有固定的发射开销和流水延迟，编译器要生成巨量的指令才能完成一个小算子，指令带宽和译码功耗成了新的瓶颈。更麻烦的是，数据搬运指令太碎，片上buffer的分配和生命周期管理全部压给编译器，后端优化工作量直接翻倍。

比较务实的选择，是把"块"作为指令的基本操作单位。具体来说，就是让一条张量指令执行一个二维或三维的分块计算，比如一次做8×8的矩阵外积、一次读入32×32的输入片、一次完成一个3×3卷积窗口在64个channel上的乘累加。粒度选择的原则也很朴素：让单条指令的执行时间落在几十到几百个周期，让一个算子由几条到几十条指令构成，既避免指令数爆炸，又保留编译器在算子层面做调度、融合和双缓冲的空间。

1.3 一个实操案例：从tensor级load/store到l2-hint的教训

我参与某模拟项目X时，早期为了让硬件控制最简单，把load和store也做成了张量级指令——一条tload负责把一整块feature map从外部DRAM搬到片上SRAM。RTL确实好写了，但编译器后端很快就发现一个尴尬问题：当某个数据块被复用多次时，编译器无法在指令层面表达"这个块接下来还要用，不要提前换出"。结果编译器为了保险，每次用完一个块就发出store换出，下次再重新load，DMA流量直接翻倍。

后来我们在load指令上加了两位hint字段，表示缓存优先级："0：用一次就走，1：用两三次，2：保持到整层结束"。这个改动很小，但恰恰是这两个bit，让编译器可以做跨算子的缓存保留策略，把一个常见残差结构的数据搬运量降了将近40%。

这个案例给我的教训是：指令集设计阶段就必须考虑到编译器需要什么样的"表达力"。硬件设计者不能只想着控制简单，还得反复问自己：如果我是编译器作者，这条指令语义允许我表达最优策略吗？最典型的一个检查方法，就是拿你计划支持的最重要的三五个算子，亲手写一遍指令序列，看有没有让你不舒服的地方。

2. 数据排布与片上调度：真正决定算力利用率的地方

2.1 外部带宽的残酷现实：算力是买来的，带宽是借来的

做AI芯片设计，有一句话我特别认同：算力是晶体管堆出来的，带宽是功耗和引脚买回来的。两者成本完全不同——你要提高一倍的MAC阵列规模，大概就是多堆一倍乘法器；但你要提高一倍的外部DRAM带宽，意味着更多接口、更多功耗、更高封装成本。在实际系统里，把数据从DRAM搬到片上SRAM再搬到寄存器，这一路上的能量开销和延迟，往往比真正做一次乘加要贵得多。

所以，AI芯片的软硬件协同设计，核心战场从来不是乘法器排成什么形状，而是数据怎么流动、在哪个存储层次驻留、复用多少次。硬件工程师在设计片上存储层次时，脑子里应该时刻有一张"数据复用账"：每个从DRAM读进来的字节，到底被计算单元用了多少次？这个次数如果太接近1，说明你的存储系统在空转，无论算力标称多大，真实利用率都会很难看。

有个简单的量化工具叫计算强度（算术强度），定义为运算量除以访存量，单位是FLOPs/Byte。它本质上描述的是"每从外部读一个字节，你能做多少次运算"。如果这个值低于你硬件的峰值算力除以峰值带宽，那这个算子就是带宽受限的，加再多乘法器也没用。这个判断思路后面讲性能模型时还要细说，现在先记住：软硬件协同的第一步，是让每个算子都尽量匹配存储系统的节奏，而不是让数据疯狂来回跑。

2.2 矩阵乘分块计算：自己在纸上推一遍

分块（tiling）是整个数据调度体系里最基础也最核心的技术，尤其是矩阵乘和卷积，几乎全靠分块把数据复用和片上容量平衡好。我用矩阵乘来做一个完整的推导，这个例子搞懂了，卷积的分块思路自然就通了。

假设我们要计算 C[M][N] = A[M][K] × B[K][N]，全部数据在外部DRAM。如果直接按照 i、j、k 的原始循环顺序去乘，每计算一个 C[i][j]，需要读一次 A[i][:]，一次 B[:][j]，那么总的DRAM访存量大概是 M×N×(K+K)，也就是 M×N×2K，而运算量是 M×N×2K FLOPs。算一下计算强度，正好是1——每读一个字节做一次运算。这个效率是非常差的。

现在引入分块：把 A、B、C 分别切成大小为 Bi×Bk、Bk×Bj、Bi×Bj 的块，循环在块级别外移。那么每个小块的计算过程中，A块需要从DRAM读一次 Bi×Bk 个元素，B块读一次 Bk×Bj 个元素，C块写一次 Bi×Bj 个元素。一个块内产生的运算量是 2×Bi×Bk×Bj FLOPs，访存量大约是 Bi×Bk + Bk×Bj + Bi×Bj 个元素（按字节算要乘以数据类型大小）。

比如用 fp16，取 Bi=Bj=64，Bk=8，每个块的访存量 = (64×8 + 8×64 + 64×64)×2 = (512+512+4096)×2 = 10240字节，运算量 = 2×64×8×64 = 65536 FLOPs，计算强度大约是6.4 FLOPs/Byte，比不分块提升了6倍多。如果你把 Bi=Bj 再放大到128，Bk保持8，计算强度能直接拉到接近25。

这里有个很直观的结论：Bi 和 Bj 越大，数据复用越好；Bk 只影响一个块能贡献多少运算，它越大，片上需要的缓冲空间越大但循环次数越少。最终 Bi、Bj、Bk 的选择，就是在片上SRAM容量、复用率和循环开销之间找一个平衡点。我自己做项目时，会直接用一段小脚本把这三种取值扫一遍，然后把结果画在roofline图上看瓶颈点，再决定哪组参数最值得让编译器做默认tile shape。不夸张地说，这个脚本写起来花不了半天，但每次都帮我省下了大量在RTL仿真里瞎试的时间。

2.3 数据布局格式：NHWC、NCHW与四通道对齐的取舍

指令和分块策略定下来之后，还有一个看似不起眼、实际能毁掉整个性能预算的问题——feature map在内存里的排布格式。同样一个卷积层，数据按NCHW排还是按NHWC排，DMA的搬运效率可能差出一大截。

先说两个极端。NCHW在数学上最直观，channel是连续维，对按channel方向做累加的权重非常友好；但卷积滑动窗口在空间维移动时，每次取一个相邻像素要跨越整个channel平面，地址跨度很大，DMA如果按行搬运会搬进来大量无用数据。NHWC反过来，w/h方向连续，对空间局部性好，但channel维被拆散成碎片，一旦硬件向量单元需要一次性处理多个channel，就得做很多的拼接和裁剪。

实践中更常用的折中方案，是类似NC1HWc4这种"channel切成4个一组、组内连续"的布局。原因很实际：现在的张量计算单元通常一次处理4个或8个channel，用这种格式，DMA可以连续读入对齐好的数据块，计算单元也能直接消费，几乎不需要额外的reorder缓冲。代价是如果某层channel数不是4或8的整数倍，需要padding一些浪费空间，但这部分开销通常远小于跨步访存带来的性能损失。

我在项目里吃过亏的地方是：硬件设计初期没有明确规定feature map格式，RTL里DMA按64字节对齐优化，软件团队却按NCHW先写了一个快速版本，结果跑到实测带宽只有理论的一半，一看trace，几乎每次搬运都有大量冗余字节。后来把格式统一成group-channel布局，性能立刻正常。这件事说明：数据布局格式不能等软件栈写完了再定，你在RTL设计DMA和片上buffer地址映射时，就必须同步确定编译器要生成的布局，这个决定要写到接口文档里，作为硬性约束。

3. 性能模型要建在RTL冻结之前，越简单越有效

3.1 Roofline：先判断你是算力受限还是带宽受限

很多团队做AI芯片，RTL都开始写了才想起做性能分析，而且一上来就要求搞一个全系统周期精确模拟器，结果建模本身要半年，RTL都快freeze了还没跑出几个用例。我的经验恰恰相反：性能模型的精度应该分阶段逐步逼近，最开始一个roofline模型就够用了，很多架构决策根本不需要周期级仿真就能判断。

Roofline模型的核心逻辑特别朴素。你的硬件有两个上限：一个是峰值算力P（FLOPs/s），一个是峰值带宽B（Bytes/s）。对于任何一段计算，如果它的计算强度是I（FLOPs/Byte），那么理论上它最乐观的执行效率不会超过 min(P, I×B)。如果 I×B < P，说明它被带宽卡住，就算你把MAC阵列扩大一倍也没用；只有当 I 大于 P/B 这个阈值，算力才可能被喂饱。

我通常把每一层的计算强度和硬件阈值线画在同一张图上，问题一目了然。举一个我自己推导过的例子：一个3×3卷积层，输入分辨率32×32，输入channel64，输出channel64。它的运算量约等于 3×3×64×64×32×32×2 ≈ 75.5 MFLOPs。访存量呢？如果不做任何数据复用，输入输出都要从DRAM来回搬，算下来需要读约2.6 MB、写约2.6 MB，计算强度大概只有14 FLOPs/Byte；如果我把同一块输入在片上保留复用，等所有输出channel都算完再换出，访存量能降到原来的十分之一，计算强度升到140以上。

如果你的硬件阈值线是50 FLOPs/Byte，那不做复用时这层就是带宽受限；做了简单复用，马上就变成算力受限。这种判断只要半小时就能完成，但能帮你避开"盲目堆算力"这个大坑——很多看起来是算力不够的问题，本质上都是数据搬运策略的问题。建议所有做AI芯片的团队，在架构设计启动会上花一次会的时间，把计划支持的所有主力算子画一遍roofline，这张图以后会成为你和编译器团队吵架时最重要的裁判。

3.2 周期级模型的建立步骤，以及为什么不建议一步到位

当roofline确认了算力/带宽边界后，第二步才是建立周期级性能模型。但这里我要特别强调"渐进式建模"：先做一个粗略的分析模型，公式算一算，再逐步加上队列、流水、bank冲突这些细节，最后才谈得上周期级模拟。

我推荐的最小可用建模步骤是这样的：

1. 把每个算子拆成操作序列：比如一个卷积层，拆成"加载输入tile、加载权重tile、执行乘累加、写回输出tile、下一块"这样的事件序列。
2. 为每个事件估算cycle成本：tensor指令执行时间 = 数据块尺寸 / 吞吐率；DMA搬运时间 = 搬运字节数 / 有效带宽；同步等待按最坏情况估。
3. 考虑最基本的overlap：先假设DMA和计算能完全重叠，只算总理想周期，再逐步扣除重叠失效的部分。
4. 和RTL仿真校准误差：拿一到两个典型层，先用RTL或更精确的模拟器跑出实际cycle数，对比你的模型，把误差来源一一修正。

有一个建模心态必须摆正：模型不是越复杂越好。一个只能覆盖三个主力算子、但每个算子都能在十分钟内算完的分析模型，比一个号称覆盖所有边界情况、但跑一个算子要调试一周的全模拟器，对架构决策的帮助大得多。我在某模拟项目X里，早期就用了一个Excel表格，把各层的tile配置、访存量、计算cycle列出来，然后按流水线重叠因子简单乘一下，就已经能把整网性能估到误差15%以内，足够用来决定片上SRAM容量要不要加。等真正需要评估bank冲突和DMA调度时序时，才去写周期级模型。

3.3 一个真实的瓶颈发现过程：从"以为算力不够"到"其实是数据搬运问题"

这套建模方法真正打动我的，是一次几乎让人绝望的性能排查。当时某模拟项目X的某个版本跑一个检测网络，预期要达到的算力利用率是60%，实际只有25%。团队第一反应是MAC阵列有瓶颈，想把tensor core的利用率再往上压。我坚持先用建好的perf模型跑了一遍，结果模型预测利用率约26%，说明模型的假设和实现是吻合的——问题不在实现细节没调好，而是这个算子结构本身就不合理。

进一步看模型的访存分解发现，整个网络的DRAM流量里，有超过一半来自Elementwise层的输入输出搬运，比如残差相加、激活、归一化这些看着不起眼的算子。它们在模型里每个都单独完成一次"读输入、算、写输出"的完整DRAM周期，而真正的卷积层反而是片上复用做得不错的。

原因找到了：调度器没有考虑Elementwise算子与卷积算子的融合。理论上，这些Elementwise操作完全可以附着在卷积的写回阶段，输出tile还在片上SRAM时就直接做完加法和激活，只写一次DRAM。但当时的指令集和调度规则没有给这种融合提供任何表达手段，编译器只能保守地逐算子执行。

后续改动分为两路：硬件侧在卷积写回数据通路上加了可选的激活/加偏置单元；软件侧在调度器里增加了一个"相邻算子融合检测"的pass。改动完成后，同样的网络在perf模型里的DRAM流量下降了近一半，实测利用率从25%提升到53%。整个过程中，我几乎没有碰乘法器阵列的设计——这恰好印证了那句话：AI芯片的瓶颈经常在软件能看见的数据路径上，而不是算力本身。

4. 精度与数据格式：算法团队和硬件团队最容易被忽略的契约

4.1 混合精度数据格式的现状与代价

精度这个话题在软硬件协同设计里的地位，比很多工程师想象的高得多。原因很简单：不同数据格式，直接决定你的芯片在同样面积和功耗下能塞进多少MAC、能跑多快。

主流AI芯片现在基本都会原生支持FP16、BF16和INT8这几种格式。FP16精度尚可、动态范围一般，BF16牺牲尾数换指数范围，适合训练和大范围波动数据，INT8则是推理性价比之王——同样一片面积，INT8乘法器的数量可以达到FP16的两倍，也就是说，如果算法能接受INT8量化，芯片的峰值算力标称可以直接翻番。这不是软件优化能追回来的差距。

但硬件支持某种格式，不代表软件真的能用好它。最常见的坑是：硬件datapath支持INT8，但编译器生成算子时，为了保证精度统一把所有中间结果都保持为FP32，只在输入输出端做了一次量化。这样做确实保险，却让INT8的算力优势荡然无存——因为你实际在跑的数学操作几乎全是FP32的。软硬协同的正解是：从一开始就明确每个算子应该以什么格式计算、什么格式存中间结果、什么时候需要发生格式转换，并把这个决策固化到编译器的IR（中间表示）里，而不是让每个算子的实现各自临场发挥。

4.2 量化信息要写进指令集和IR，而不是临时抱佛脚

我给一个实际建议：在定义张量指令时，就必须把数据格式作为指令语义的一部分。比如一条gmma指令，不仅要写清楚操作数A、B、C的shape，还要写明它们的元素类型、scale因子如何传递、累加器精度是什么。为什么scale必须进指令语义？因为量化推理的数学本质是"整数运算+定点缩放"，如果scale在指令里没有位置，编译器就只能把一次缩放拆成一个独立的元素级算子，多一次完整的数据往返。

一个好的IR里，量化信息应该自然附着在张量类型上，我见过一个相对好用的定义方式，大概是这样的：

op gmma { operand A: tensor<16x32xfp16> operand B: tensor<32x16xfp16> operand C: tensor<16x16xfp32> attr accumulate_precision: fp32 attr quantization: { input_scale: per_tensor(0.0078125) output_scale: per_channel([...]) } }

关键是quantization这个属性不是额外挂在边上的注释，而是指令合法性的组成部分——如果输入的数值范围超过了scale允许的范围，调度器需要在前面自动插入一个精度调整节点，而不是让硬件在运行时静默溢出。这种机制一旦在软硬件接口层定死，后面做量化感知训练时，算法团队只需要按这个格式产出模型配置，编译器就能毫无歧义地生成对应的硬件指令。

顺便提一下量化感知训练配合硬件的一个细节：很多量化感知训练框架假设硬件的量化行为是"四舍五入到最近整数"，但某些为了省面积设计的量化器是"截断"或者带偏置的舍入。这两者在低bit（如INT4）下产生的精度差异非常明显。我在某模拟项目X中就被这个问题坑过一次，算法团队在软件仿真里跑了很久的量化模型，精度看起来很好，但一烧到FPGA原型上就掉点，最后发现是硬件量化器的舍入模式和训练时假设的不一致。从那以后，我们做任何量化配置，第一件事就是确认硬件RTL里的舍入实现，并把它写进精度仿真模型里。

4.3 累加器宽度带来的惨痛教训：RTL快做完才改datapath

还有一件印象极深的事，关于累加器宽度。当时某模拟项目X的规格说明书上写的是"支持FP16输入、FP32累加"。但团队里做量化训练的同事后来发现，某些归一化层的统计量在FP32累加时依然存在较大误差，最好能用FP32输入+FP32累加，或者至少BF16输入+FP32累加。硬件团队一听就头大——tensor core的乘法器输入宽度和累加器通路在RTL里已经基本定型，从FP16输入改成支持FP32输入，不仅仅是把乘法器换宽，还涉及输入寄存器堆、片上buffer的带宽、甚至DMA搬运粒度全部要重算。

最后只好做了一个折中：保留原始FP16乘法路径，额外加了一条并行的FP32向量路径来处理少数精度敏感的算子。这条路径的利用率很低，却额外占了约20%的面积和不少验证时间，纯粹是为了弥补接口层设计时没有对齐需求的代价。

如果早点在接口文档里明确"哪些层必须支持高精度计算、哪些层允许低精度"，硬件设计完全可以只给那几层准备单独的高精度数据路径，其余主流层用紧凑的低精度乘法器。这个教训让我对"精度是软件问题还是硬件问题"有了新的认识——它其实是接口问题，必须在软硬件设计启动时由两边共同确认，而不是等到RTL快冻结才去解决。

5. 软硬件协同验证：流片前必须做满的功课

5.1 软件就绪度管理：别让芯片等软件

流片回来那天，硬件团队最怕听到的一句话是："芯片都回来了，但软件栈还没调通。"AI芯片和传统ASIC最大的不同在于，它的价值几乎完全依赖上层的编译器、运行时和算子库，芯片本身只是算力原料。所以软硬件协同验证，必须在RTL阶段就开始，而不是等芯片回来再联调。

我的做法是，尽量在RTL还在功能仿真阶段时，就把软件栈跑在一个统一的虚拟平台上。具体来说有几种方案：

我的建议是三管齐下：RTL仿真负责验证指令行为细节，软件模拟器负责性能和算子行为，FPGA原型负责端到端整网验证。尤其重要的是，在流片前必须把"从模型到编译到运行的完整工具链"在FPGA上跑通一个真实模型，而且要用预期的最终部署配置去跑，而不是用简化Demo。很多硬件bug在单算子测试里根本暴露不了，只有整网运行时，DMA并发、多核同步、功耗管理这些跨模块交互才会现出原形。

5.2 接口冻结与变更管理：ICD版本双签制度

软硬件接口的变更管理，是我见过最容易被忽视、后果也最惨烈的环节。AI芯片因为迭代快，指令集、寄存器映射、数据格式这些接口经常在开发中途调整。如果没有一个严格的变更流程，你会遇到的情况是：硬件RTL按v3版本实现了某个行为，编译器已经按v4版本改了生成规则，两边都觉得自己没错，但合在一起就是跑不出正确结果。

我在项目中推过一个"接口控制文档（ICD）版本双签制度"，原则很简单：

• 所有涉及软硬件约定的内容，统一写进一份ICD，包括指令编码、寄存器偏移、数据布局、中断与同步语义、精度要求。
• 任何一方要修改ICD里的条款，必须先改文档、升版本号、写清楚变更影响，然后交给另一方指定的接口负责人评审签署，签完才允许动代码。
• 每次RTL或编译器的重要版本发布，都必须锁定它对应的ICD版本号，发布记录里要能追溯到"这版RTL是根据ICD v3实现的"。

听起来很像是流程管理，但实际发生的好处是：它逼着双方在改动前先想清楚对侧会受什么影响，避免"顺手改一下"导致的隐性不兼容。有一次编译器团队想优化一个矩阵指令的排布，把它挪到了另一组寄存器编号上，按照制度他们先提出了ICD变更，硬件团队反馈这对DMA通道分配有冲突，于是双方花了半天设计了一个兼容方案，而不是等芯片回来再花两周查为什么寄存器被踩了。

5.3 端到端模型验证：单算子通过不等于整体能用

最后聊聊端到端验证的重要性和具体做法。在AI芯片上，单个算子的单元测试全绿，是整个验证工作中最简单的一关；真正的问题往往出现在多个算子串起来之后。一个调好的卷积算子本身没有问题，但和它相邻的归一化算子如果复用了同一块片上buffer，且没有正确的同步等待，就可能出现计算结果被覆盖的隐形错误。

我的教训来自某模拟项目X的一次经典事故。单个算子的RTL仿真和FPGA测试都通过了，但把整个网络接起来跑，精度一直不符合参考值。前前后后查了三天，最后在波形里发现，某个残差相加算子在DMA还没有搬完输入数据时就开始计算了，原因是调度器在融合两个算子时省略了它认为"多余"的同步点。这个bug在单算子测试里完全不可能暴露，因为单算子测试的场景是"输入已经就绪"。

为了避免这类问题，我在项目里定了两条规矩：

1. 端到端对比要建立"黄金数值"：在固定随机种子下，用参考实现跑一遍完整模型，存下每一层的输出张量。硬件和软件栈每完成一个里程碑，就跑一次完整模型，逐层对比输出，误差超出容差即报警。
2. 错误不能只看到一个现象就修：任何端到端精度的异常，必须给出一个能够稳定复现的最简用例，并且把它转化成新增的回归测试。每修一个这样的bug，就把用例留在回归集里，防止未来改调度器时旧问题复发。

这套实践看起来费时费力，但实际执行起来后，流片回来后的bring-up时间被大幅压缩。我们不慌不忙地跑完回归集，大部分问题在虚拟平台阶段就已经清理干净，芯片本身的定位和调试变得非常从容。我后来把这种思路总结成一句话给新同事：芯片验证的尽头不是"所有测试通过"，而是"软件在硬件上运行的行为，和参考模型完全一致"。达到这个状态，软硬件协同设计才算真正闭环。

我自己经手过几个AI芯片项目后最大的体会是：把硬件算力堆高从来不是最难的环节，难的是让编译器、算子库、指令集、存储层次和验证流程作为一个整体高效运转。工具链上的每一个"约定"，都是这个整体里最容易被忽略、也最值得认真对待的接口。设计阶段多一次决策上的沟通，后面就能省下数周的联调和排查时间。