1. 项目概述1.1 核心需求解析AI 芯片的软硬件协同设计这个话题在业内聊了很多年但真正愿意把它掰开揉碎讲清楚的并不多。你看到“AI 芯片的软硬件设计 1”这个标题大概率是正在接触相关项目或者准备进入这个方向想知道从哪下手、怎么搭框架、软硬件之间到底怎么配合。这个标题的潜台词其实很明确不打算只讲芯片架构理论也不打算只写驱动代码而是要把两者放在一起讲清楚一个 AI 加速器从需求定义到落地验证的完整链路。所谓“1”通常意味着系列内容的第一篇重点应该放在总体设计思路、软硬件接口划分、工具链基础框架这些打地基的事情上。我个人的理解是这个系列适合三类人一类是刚转到 AI 芯片方向的学生或工程师需要建立全局视角一类是做算法或模型的开发者想知道自己的模型到底怎么跑到硬件上的还有一类是做嵌入式或传统 SoC 设计的工程师想了解 AI 加速和以往通用计算的差异到底在哪。这篇文章我打算沿着一条主线展开先说明软硬件协同设计的工作流程和关键决策点再拆解指令集与数据通路、编译器工具链、算子映射策略、量化方案选择这些核心模块最后补充验证、调试和性能分析的实际做法。内容会比较重但我尽量用通俗的语言和真实项目经验来说不堆概念。1.2 我从这个项目里看到的几个关键点先说结论AI 芯片和传统芯片最大的区别不在于“算得快”而在于“算得巧”。这个“巧”体现在架构设计之初就要把算法、编译器、运行时、驱动全链路一起考虑而不是像传统 SoC 那样先有硬件规格再把软件往上堆。从项目实操角度看有四个点最容易决定项目成败。第一个是软硬件接口的稳定性。接口一旦定了改一次的成本极高。指令集架构ISA也好寄存器映射也好DMA 描述符格式也好一定要在动手写 RTL 之前反复评审。第二个是算子覆盖率的定义。做张量加速器不是把所有算子都做进硬件而是把通用、高频、计算密集的算子硬件化其余用软件组合实现。这个“硬件化”和“软件化”的比例怎么定直接决定芯片面积、功耗和性能。第三个是编译器和硬件的同步开发节奏。编译器不是等芯片流片后才开始写的而是在架构探索阶段就要和硬件团队共用一个性能模型边评估边优化。否则等你芯片回来了编译器还没调好整个项目就卡在那里。第四个是片外存储带宽的瓶颈。我们做 AI 加速器时经常发现计算阵列的处理能力其实够用真正卡脖子的是数据搬运速度。LPDDR 带宽、片上 SRAM 容量、数据复用策略这些在体系结构设计阶段就要算清楚。这四点我会在后面的章节逐一展开尤其是第四点很多人第一次做加速器都会栽在带宽这个坑里。2. 软硬件协同设计的整体框架2.1 为什么要“协同”而不是“并行”很多第一次接触 AI 芯片设计的同学会误以为软硬件协同设计就是软件团队和硬件团队同时开工各干各的最后再整合。这个想法放在传统 SoC 开发里还能勉强凑合放在 AI 芯片上基本行不通。原因其实不复杂。AI 加速器的每个关键设计决策几乎都同时影响软硬件两端的实现复杂度。举几个最典型的场景。处理器的指令集设计。如果硬件上提供一条“矩阵乘加”指令编译器端就要能识别计算图中的矩阵乘子图并匹配到这条指令。反过来如果编译器团队评估后认为频繁执行“整块搬运逐元素运算”效率更高硬件就得考虑加宽存储总线或增加直接内存访问通道。指令集不是硬件单方面定的它是两边协商的结果。存储层级的设计。片上 SRAM 分几级、每级多大、是否支持多块并行读写这些决定编译器怎么排调度策略。硬件如果把缓冲区划分为多个 Bank编译器就可以把不同张量分配到不同 Bank 并做并行搬运如果只有一个连续地址空间编译器就要做复杂的地址冲突规避。前者性能上限高但面积功耗大后者简单但容易卡访存。算子切分策略。比如卷积怎么拆分成 GEMM通用矩阵乘法这个决定如果放在软件层做硬件只需要提供矩阵乘引擎和激活函数单元如果硬件把卷积直接做成专用电路比如为 3x3 卷积定制数据通路编译器就相对省事但芯片灵活性下降将来算法变了很难适应。类似这样的互相制约关系在整个 AI 芯片设计里到处都是。所以协同设计的本质是让软件团队在硬件方案还没定型前就介入用性能模型、仿真平台、虚拟原型去评估算法映射效果反过来给硬件提需求。硬件团队也不是闭门造车而是在需求驱动的约束下做架构探索双方在同一个“可执行的设计规格”下持续迭代。我实际项目中踩过的一个坑是软件团队等硬件服务模型通常用 SystemC 或 Python 写的周期级模拟器做好后才开工做编译器结果发现硬件方案有几个不合理的地方但 RTL 已经写了一点改动成本很高。后来我们调整流程把“架构探索阶段”和“软硬件需求冻结”之间加了至少两轮联合评审才把这类问题压下来。2.2 设计流程分哪几个阶段一个典型的 AI 芯片软硬件协同设计项目大致分六个阶段。每个阶段要产出的文档或代码我在后面加注释说明。阶段一需求定义。这部分首先是明确目标场景跑哪些模型ResNet、YOLO、BERT、Stable Diffusion 等等目标帧率或吞吐量功耗和面积预算成本约束量产时间和工具链成熟度。需求定义最忌讳模糊像“跑主流模型”这种描述后期一定会扯皮。阶段二架构探索。算法团队提供算子统计特征各算子的计算量占比、内存占用、数据复用度硬件团队据此搭建架构模板软件团队在性能模型上跑 benchmark陆续暴露瓶颈。这个阶段通常会产出一个 Excel 表或数据库列出几十个候选架构配置与对应的性能、面积、功耗预测。阶段三软硬件接口冻结。这是全项目最关键的里程碑。指令集、寄存器映射、中断机制、DMA 描述符、存储地址映射、同步机制全部冻结然后形成正式的接口文档接口控制文档简称 ICD。ICD 一旦发布任何修改都要走变更评审流程。阶段四并行开发。硬件团队做 RTL 设计、验证、综合软件团队做编译器后端、算子库、运行时、驱动。两边靠仿真环境和硬件加速验证平台FPGA 原型或 emulator对接。并行开发阶段最大的挑战是保持“参考模型”和 RTL 的同步更新不然软件调完了发现硬件行为对不上。阶段五软硬件集成。芯片回来或 FPGA 原型跑起来后做 bring-up。一般顺序是先跑自检程序再跑小的算子测试例再跑小模型比如 MNIST 或 MobileNet最后跑完整目标模型。这个阶段也是编译器 bug、驱动 bug、硬件 bug 的高发期。阶段六优化和量产。性能不达标就一层层查瓶颈算子核函数效率、数据搬运策略、内存分配、线程调度。这个阶段会有大量 profiling 工作软件侧要做的优化远比想象的多。我建议每家公司都把“软硬件接口冻结”这个阶段单独拿出来评审不要和架构探索混在一起。以一个真实案例来说我们曾在一个加速器项目里因为对“卷积计算完成信号”的定义不一致导致软件等待中断但硬件早已触发完成标志最终排查了两天原因是硬件团队理解的是“写回完成”软件团队理解的是“可重新开始计算”。ICD 里用一句话就能避免这种问题明确信号语义和时序关系。2.3 接口设计的要点和实践接口设计在传统芯片设计里通常指引脚定义或总线协议但在 AI 芯片语境下它更多指软件可编程视图programmer-visible view。这部分我会稍微展开因为它是软硬件协同设计的核心交汇点。指令集设计。AI 加速器的指令集一般不是通用 CPU 那种复杂指令集而是一种领域特定指令集DSAs指令通常分为几类计算指令矩阵乘、向量运算、激活函数、池化、数据搬运指令DMA 读/写、片上 Buffer 搬移、控制指令循环控制、同步、跳转、以及配置指令设置寄存器、配置维度参数。每类指令的关键是“显式并行步”的设计。比如一条矩阵乘指令是否支持多核并行支持的话计算结果的写回地址如何编排中断如何产生这些都是硬件和软件双边协议的事。寄存器映射。通常有两类寄存器一类是状态寄存器软件读它来获取硬件执行状态一类是控制寄存器软件写它来配置计算模式、数据路径、中断使能。保守的做法是为每个算子定义一组独立的配置寄存器灵活性和可编程性高但软件驱动代码量大激进的基因是全局共享一组配置寄存器节省面积但配置切换耗时多算子流水时容易产生冲突。我们的经验是寄存器定义一定要有全局编号并且和驱动代码中的结构体定义严格对应最好由工具自动生成头文件避免手写不一致。DMA 描述符设计。AI 芯片内部数据的搬运基本由 DMA 完成。DMA 描述符描述一次搬运任务比如搬运类型连续搬、二维搬、三维搬、源地址、目的地址、长度、步长、完成标志。描述符看似简单但设计时要把“多级描述符链”考虑进去。为什么需要链式描述符因为编译器排出来的数据搬运任务往往是序列化的不能让 CPU 等每个搬运完成后才去配下一个描述符。链式描述符让 DMA 自动执行后续任务CPU 只在全部完成时被中断一次极大降低软件开销。地址映射与内存管理。AI 芯片通常有多块存储片外 DDR、片内 SRAM、寄存器文件、以及各计算单元自带的 Accumulator Buffer。软件侧需要明确看到这些存储的地址映射并设计内存管理模块来分配地址。难点在于不同硬件模块的地址空间可能不连续、不对齐编译器分配张量地址时必须遵守对齐规则否则性能骤降甚至触发硬件行为未定义。接口评审的方法。我们项目里常用的方式叫“三表评审”指令计费表每条指令的周期数和功耗预估、寄存器配置表每个功能域可编程点的层级和复位值、错误处理表各种异常和回滚策略。三张表做成电子表格硬件团队维护每一列软件团队标注使用场景最终形成冻结版本。三表联审最大的价值在于让两边都看到“对方的边界”。3. 核心模块拆解硬件视角3.1 数据通路怎么算出来的AI 加速器的硬件核心是计算阵列。常见的架构有三种脉动阵列Systolic Array、SIMD 向量单元、以及可重构的异构计算引擎。脉动阵列的代表是谷歌的 TPUSIMD 向量单元在 GPU 和部分 NPU 中使用可重构异构引擎比如一些采用众核架构的公司灵活性更好。这里我把“怎么定规模”这件事重点讲因为大多数人做架构探索时都会卡在这里。先算一下“需要多少算力”。假设目标场景是跑 ResNet-50输入分辨率 224x224批量大小为 1希望在 10W 功耗下达到 100fps。ResNet-50 在 224x224 下的浮点运算量约为 4.1 GFLOPs乘加算两次浮点操作4.1 GFLOPs 已经包含乘加转换。100fps 的算力需求就是 410 GFLOPs。考虑实际利用率通常只有 30%~50%原因是数据搬运、算子切换、负载不均衡等我们要设计的算力约为 1 TFLOPs 到 1.4 TFLOPs 之间。再定“数据精度”。训练用 FP32 或 BF16推理通常是 FP16 或 INT8。如果 INT8TOPs每秒整数运算次数计算只需要 FLOPs 的一半因为一个 INT8 乘加只算一次操作但实际硬件一般仍把 INT8 乘加操作计数为 1 MAC即 2 次操作。为了让例子简单我用 MAC乘加操作来算目标 700 GMAC/s约 1.4 TFLOPs 的 INT8。接着算“计算阵列规模”。假设循环频率为 1GHz每周期每 MAC 单元完成 1 次乘加则需要 700 个 MAC。要留余量考虑利用率 50%则约 1400 个 MAC。配置成 16x16 的脉动阵列就是 256 MAC32x32 就是 1024 MAC还可以通过 double-pump两次复用增加吞吐。架构探索时你可以写一个参数化模板把阵列的行数、列数、片上存储容量、带宽约束作为参数统一跑一遍性能模型。我见过不少团队直接拍脑袋选 16x16 或 32x32这没有错但缺少计算依据。最好把各种尺寸放在同一个调度器下做评估脉动阵列单位周期吞吐、累加器缓冲Accumulator BufferAB容量、激活/权重 Buffer 容量、DMA 搬运带宽四个变量互为约束最终选出一组平衡配置。3.2 存储层级与片上缓存设计AI 芯片的存储层级几乎决定性能上限。有个共识是“数据搬运比计算更贵”片外 DDR 的访问功耗和延迟远高于片上 SRAM。所以设计存储架构的核心目标是尽量把数据留在片上反复复用减少 DDR 访问次数。这里引入“数据复用”的概念它是整块设计里最关键的推理依据。举例说明。卷积层的权重数据在一个 batch 的多次推理中是完全复用的权重应该常驻片上。偏置、BatchNorm 参数也属于这类数据。输入特征图在多个输出通道做卷积时同一块输入数据会被多次使用输入复用。输出特征图在后续层作为输入时还会被继续消费输出复用。架构设计时我们通常把激活值缓存Activation Buffer和数据缓存Weight BufferWB分开设计让它们可以并行读写。有一个经典的经验比例片上总存储大小和目标模型“峰值工作集”匹配。比如跑 YOLOv5s输入 640x640中间特征图加权重总需求约 8MB如果片上只有 2MB SRAM编译器就得分块调度复杂度暴涨。为了决策我们把“片上缓存容量”和“DDR 带宽”做成一对互选参数用性能模型跑出带宽利用率曲线。通常曲线有一个“拐点”超过某个容量后带宽利用率增长放缓那就没有必要扩大缓存。我最近做过的项目里最终选择片上 4MB SRAM 配合 LPDDR4x 4266MT/s 的带宽跑 YOLOv5s 达到约 70fps瓶颈已经从计算转移到带宽的边界。这个例子想说明存储架构的参数贴近实际模型而不是追求最大容量。面积太贵容量够用就行。3.3 专用计算单元的选择除了矩阵乘主阵列AI 芯片通常还要挂几个专用的功能单元比如激活单元、池化单元、Softmax 单元、归一化单元。这里经常有一个争议到底哪些算子值得专用硬件化我的判断依据很简单算子占整个模型计算时间超过 5%且控制简单、没有复杂的可变数据依赖就值得硬件化。Softmax 虽然计算量占比不高通常小于 2%但实现方式是指数运算除法累加用软件循环处理器执行会占用很多指令周期。专用的一小块指数查找表和除法器在功耗和面积上都很划算。激活函数又是另一个典型。ReLU 是纯硬件友好的既简单又高效不需要专用单元。GELU、SiLU 等非线性激活函数就需要查表或多项式逼近。如果你打算支持大语言模型还会出现 RMSNorm、LayerNorm、RoPE 等算子这些用软件实现还是硬件实现要在架构探索阶段一并决策。经验法则模型权重占比高的算子优先硬件化控制流复杂的算子留给软件。4. 核心模块拆解软件视角与工具链4.1 编程模型和运行时设计软件侧第一件要做的事是定义“程序员怎么使用这块芯片”。这听起来像 API 设计实际比 API 更深一层它决定了人和硬件的契约。目前 AI 芯片的编程模型大致有两类。第一类是类 PyTorch 风格程序员写 Python框架前端负责计算图解析后端生成算子调用运行调度由编译器完成。这一类的优点是开发效率高缺点是性能优化空间有限因为迭代式编程Python 不断调用小算子很容易造成大量设备端同步开销。第二类是类 Kernel 风格程序员写 SPM/CUDA 风格的 kernel显式管理数据搬运性能天花板高但门槛高调试困难。很多面向推理的 AI 芯片会选第一类为主第二类为辅。商用推理引擎像 TensorRT 或 OpenVINO实际走的思路是离线编译出一个封装引擎运行时不再解析模型结构而是加载已生成的指令序列。这种思路让运行时保持轻量甚至支持“裸机部署”不带操作系统。做 AI 芯片时软件团队应该把“图优化”和“内核生成”放在离线编译阶段运行时只负责加载、调度、同步。这些设计决策都会影响硬件侧的协处理器接口定义。假如运行时和硬件握手太频繁中断占满 CPU执行效率就崩了。4.2 编译器后端核心工作流编译器后端是软硬件连接的枢纽。大致分四个步骤。第一步计算图解析和优化。前端把 ONNX、PyTorch 或 TensorFlow 模型转成内部中间表示IR在这个层次我们做算子融合、内存规划、布局转换、常量折叠。算子融合是效率关键。比如 ConvBNReLU 这种三段融合如果三步都在 GPU 或 CPU 上运行数据必须写回全局内存再读回在 AI 芯片上因为缓冲区就在片上硬件可以把整个卷积、归一化、激活的流水线一气呵成。融合的目标就是减少中间张量在片外 DDR 和片上 SRAM 之间的搬运。第二步算子分解和硬件映射。这是编译器的核心。每个算子会先被分解为一个或多个底层模板比如卷积分解为 Im2ColGEMM偏置矩阵乘分解为分块矩阵乘和累加大矩阵分解为和应外部分块循环。这一步要依赖硬件后端提供“算子语义说明”包含各种数据布局约束和指令限制。没有这一步编译器生成的代码很可能在硬件上跑不了或性能崩塌。第三步内存分配和调度。我们有一个内部叫“地址业务”的阶段把所有中间张量的生命周期放在一个调度图里做图着色式寄存器分配或类启发式分配。关键约束包括计算单元并行性、Bank 冲突、DMA 描述符链长度限制、同步 barrier 的粒度。这一步直接决定能否充分发挥硬件性能。写过程序分配地址的人都懂看似只是“找块内存”实际是一个类似整体调度的问题。第四步代码生成。最后端把调度结果翻译成芯片指令序列同时生成对应的描述符和配置数据。这个阶段经常出现“硬件不支持 32 位对齐地址”或者“DMA 长传需按 16B 对齐”这类约束冲突所以代码生成器通常要内嵌一组对齐和合法性检查逻辑。这里我需要提醒的一点是不要幻想一步到位写一个完整的高性能编译器。AI 芯片编译器是一个持续演进的项目第一版只要能跑通几个目标模型并发性能铺路后面才能逐步加入更多优化 pass。如果一开始就被“把编译器做完美”的计划束缚住项目很容易陷进死循环。4.3 算子的端到端实现路径在真实项目里算子不是一个静态的概念而是一套从模型到硬件的映射流水线。以卷积为例。模型侧通常只需要一句torch.nn.Conv2d。软件栈先把它转成 ONNX Conv 节点然后进入编译器。编译器第一步要识别这个节点将其拆分为权重重排、Im2Col或直接使用硬件支持的隐式 GEMM 模式、矩阵乘、偏置加、激活融合几个子任务。硬件侧则分成几个功能模块执行权重重排由主机侧预排版Im2Col/GEMM 由计算阵列执行偏置和激活在专用单元执行。如果是直接实现隐式 GEMM很多 NPU 都这么干编译器里需要生成一个外层循环按输出通道分块每个循环体内调用“GEMM 微内核”。微内核封装了脉动阵列或 SIMD 单元的指令序列。每次微内核执行硬件会把激活 Buffer 中的一块数据和权重 Buffer 中的一块数据送入计算阵列循环累加后写回累加器缓冲。完成后再通过 DMA 把累加结果搬回主存。这条路径几乎每一步都有分布式的决策。输出通道如何分块取决于存储容量权重是否保持常驻取决于复用次数累加缓冲的大小决定一次能算多少个通道。所以编译器后端工程师需要定期看“硬件架构变更说明”否则你排的调度在新型号上就不 work。5. 模型部署与优化实践5.1 量化方案的关键细节AI 芯片上常用的推理精度有两种主路线INT8 和 FP16。INT8 能带来 2~4 倍性能提升但一定会引入量化误差尤其是对大语言模型的敏感层。我的经验是不要一上来就所有层无脑 INT8要先做“逐层敏感度分析”。做法很简单用一小批校准数据把每一层单独换成 INT8 做推理记录输出偏移或下游精度变化。找出最敏感的几层把这几层保留 FP16 或使用混合精度其余用 INT8误差降到可接受范围性能和精度的平衡点就抓到了。具体到量化部署还有三个细节容易被忽略。输入校准方式影响巨大。使用 1000 张样本的分布做校准和用 10 张代表性图片做校准对 INT8 最终精度的影响通常大于 0.5%对于分类任务影响可能不大对于检测任务影响就明显了。所以“选择什么校准集”也是在设计量化流程时必须明确的环节。权重和激活是否使用相同的量化范围。建议分开权重量化为对称 INT8因为权重分布近似对称激活量为非对称或使用零点因为激活分布通常偏在正区间。性能模型里可以看到分别处理能显著增加有效动态范围只损失极少换算成本。量化在硬件侧是否“免费”。部分 NPU 的 INT8 算力是 FP16 的两倍但也会有额外缓冲区开销。编译器排调度时要把输入类型转换节点作为独立算子插入计算图。这个“插入转换节点”看似琐碎但带着它去安排 DMA 搬运经常导致数据在片上被来回转置性能隐性损失很大。5.2 运行时调度与内存复用AI 芯片的运行时调度是一门“指针艺术”。关键不在于操作系统任务调度而在于张量生命周期管理。推理时多分支结构如 ResNet 的残差连接会让中间张量的生命周期重叠。编译器或运行时尽量复用缓冲区地址这种复用策略要整合到整个推理图。很多人觉得这就是给每个张量分配一块内存真正做起来后会发现指令序和 DMA 描述符执行顺序稍有变化缓冲区被覆盖的风险就可能出现。我推荐一种做法在编译器内部用“张量分片分配器”先对公司内部所有模型跑一遍调试级验证即在模拟器里执行指令序列并监控地址读写碰撞。每一步调度都必须经过分配器的合法性检查。内存安全不是等芯片跑起来才验证而是要在编译期就发现。这个思路和普通软件开发的 sanitizer 类似但它针对的是硬件的地址空间。另外多线程调度也不可忽略。推理端一般用少量核比如 CPU 侧的 4~8 个核做前端控制主要任务是下发任务、同步中断、超时处理。这个控制流模型不适合给每个算子都发起一次异步调用因为频繁的同步会压垮系统。更好的方式是采用“两层调度”第一层是模型级的图调度第二层是算子内部的指令队列调度。两层调度分离后软件复杂度也会大幅下降调试也会容易很多。5.3 全链路追踪和性能调优做软硬件协同的高性能系统第一步永远是“有没有性能数据”没有数据就谈不上调优。我强烈建议在软件栈的最底层做全链路 trace 插桩不是说你可以把所有中间事件都打印出来而是设计成“环形缓冲 时间戳”。用硬件计数器记录指令发射、DMA 完成、计算单元空闲、等待锁存等关键事件。把这些事件映射到模型计算图上就可以知道这个算子为何这么慢。实际调优过程中最常出现的性能问题主要有三类。搬运瓶颈。表现为指令周期快到内存搬运用不完。数据量明明很小但由于通道冲突DMA 被拆成过多小段增加描述符开销造成整体搬运周期显著超过理论时间。这时要做“描述符合并”或者调整 Bank 分配。计算负载不均衡。多核并行时某些核心负载过重另一些核心闲置。典型原因是输出通道划分得太细或者依赖同步点过多。解决办法是在调度器里改进“分块循环”让每个核拿到的子任务数量和尺寸均匀降低 barrier 次数。同步开销过重。如果每个算子之间都有同步等待流水线的重叠几乎为零。解决方案是把算子组成“融合组”在组内用双缓冲或软件流水让计算和数据搬运并行。这通常要求硬件侧提供“多个 DMA 通道 多个计算指令队列”的能力这也是我之前强调性能和架构要一起设计的核心原因。6. 两大关键支撑验证与性能评估6.1 多层验证体系搭建软硬件协同项目的验证比单一硬件验证或单一软件验证要复杂得多。理想情况下有四个层次。第一层算子级仿真验证。软件团队在自己设计的参考模型上跑算子对比标准数值结果。这里要覆盖边界数据零矩阵、饱和值、极端负值和异常尺寸比如偶数和奇数通道。第二层RTL 级仿真验证。硬件团队在仿真器上跑同一组测试用例对比软件参考模型。由于 RTL 仿真速度慢通常会抽取一部分用例做“差异测试”即随机生成输入并用差分比较。第三层FPGA 原型验证。多数 AI 芯片项目会做 FPGA 原型直接在真实时钟频率下跑算子速度虽然比模拟器快很多但频率通常只有真实芯片的 1/10。FPGA 原型的好处是能跑真实模型一个小的 YOLOv5 也可能要跑几分钟以及让软件团队提前写驱动和编译器后端。第四层硅前验证和硅后验证。硅前主要做功耗分析、时序收敛和静态检查硅后则是流片后的 bring-up。硅后 bring-up 不要一上来就跑大模型我建议按“自检 → 简单算子 → 单算子复杂测试 → 小模型 → 目标模型”循序渐进每一步都检查输出比对和性能计数避免把问题混在一起。我见过很多团队在 FPGA 原型上直接跑完整 YOLOv5s拿到错了几个框的结果就一头雾水。如果你把一个算子一个算子地验证都通过了再全链跑出现问题时定位就容易得多。6.2 性能模型的建模策略性能模型这个词在项目里被滥用得很厉害。我这里的定义是能在软件架构探索阶段以周期级或近似周期级精度估算出每条指令实际执行时间的程序模型。建模策略的核心是“细节分层”。不必一开始就把 RTL 级 pipeline 周期在意那是 RTL 团队的事。软硬件协同的性能模型重在反映行为事件和资源竞争。举个例子一条 DMA 描述符执行时需要知道搬运大小、Bus 带宽、Bank 冲突率、是否和计算指令并行这些信息可以从接口定义和系统架构描述里得到。周期数就是这几个因素的函数而不是精确到每个 cycle 的仲裁细节。为什么我不推荐一上来就写精确的 SystemC 时间模型因为 SystemC 建模写得越精确维护成本越高每次架构改动都要同步更新通常会让项目失去灵活性。合理的做法是先用一个 Excel 或简单 Python 脚本快速估算确定一个大致方向再去写或者重写一轮精确模型专门用于软硬件冻结前验证。性能模型的产出物至少包括三类统计量各算子周期占比、各存储带宽利用率、各功能单元的利用率。其中最有价值的是“结构瓶颈定位”比如看到某一层的 GEMM 周期已经远高于理论值说明调度有问题而不是算力不够编译器团队可以据此介入优化。6.3 硬件性能计数器设计硬件性能计数器是软硬件项目里经常被忽略但特别重要的部分。没有它优化就像闭眼开车。AI 加速器的计数器应该覆盖四类事件计算事件比如 MAC 单元有效工作周期数、空转周期数、单指令多数据SIMD利用率、存储事件比如 DMA 读写完成次数、缓冲命中率、片上缓存 Miss 次数、流水线事件比如指令队列满、同步等待周期、写冲突次数、以及外部接口事件比如 DDR 带宽利用率、ISP 或 PCIe 传输计数。这些计数器的定义最好在 ICD 阶段就一起定下因为设计到位需要占用寄存器空间和硬件逻辑。硅后调试时我的经验是先从“指令队列等待周期”和“DMA 等待周期”这两个计数值下手。它们会直接告诉你瓶颈是在计算、存储还是同步。之前做加速器时遇到过花了一周优化计算流水线但性能没有变化的情况原因其实是 DMA 通道冲突太严重。加上计数器后一眼就看出 DMA 通道的占用率一直高于 95%而计算单元还有 40% 时间空转。7. 常见问题与排查技巧实录7.1 算子行为与参考模型不一致这类问题最常见通常出现在硅后集成的头几天。先确认是不是数值精度问题把所有中间结果转成 FP32 打印和软件仿真模型对比看偏差是逐渐放大还是突然跳变。如果突然跳变大概率是某个算子的实现路径走错了如果逐渐放大大概率是量化或舍入误差的累积。还有一种隐蔽情况芯片端做了一条 fuse 路径但参考模型里没有加对应逻辑。比如你在芯片上把卷积和 BatchNorm 融合了但参考模型还是分步计算导致数值不同。这种问题在融合优化时非常容易踩坑建议在编译器生成的“算子融合日志”里把融合决策记录下来配套打印每个输入输出张量的数值摘要后续排查会轻松很多。7.2 指令队列耗尽和死锁指令队列泛满导致硬件死等通常要检查三个方面。第一硬件端是否有足够深的指令队列尤其在多路 DMA 同时下发时第二软件端是否在还未满足前一个指令同步条件时就提交了新指令第三中断丢失时驱动和硬件是否还能自恢复。排查死锁时我最喜欢用“二分法判断”。先把计算功能全部禁用只跑 DMA 搬运看是否死锁。然后把 DMA 禁用只跑计算看是否死锁。最后只跑同步指令看两个模块同步的握手信号和中断是否正确。用这个顺序基本能在半小时内定位是搬运端、计算端还是同步协议本身的问题。7.3 性能指标与模型预估差距大常见原因有两类一类是调度器生成的指令顺序没有充分利用并行另一类是量化或精度影响导致某些算子走了精度较低或效率低的 path。如果模型预估的周期是 1000 周期实际执行是 1500 周期不要急着改硬件先把性能计数器的数据打印出来对照计算周期、搬运周期和等待周期三个数值占比。这个占比会告诉你哪个部件拖后腿然后再针对优化。7.4 工具链版本错位问题凡是软硬件项目都会遇到“硬件 RTL 版本、驱动版本、编译器版本”三者之间不匹配。比如驱动增加了新寄存器特性但 RTL 没实现或者编译器生成的新指令不受旧驱动支持。最笨但最有效的办法是建立一套正式的版本基线软件和硬件团队共同维护一个“变更日志”每次接口变更必须同步到对应分支。集成时统一用带版本号的镜像而不是随手拉最新代码。这个细节虽然无聊但能避免大量低级集成错误。7.5 附高频问题速查表现象可能原因首要排查动作算子输出异常但非零量化参数未加载或加载错误检查量化配置表是否一致单算子对照测试性能远低于预期DMA 通道冲突严重查 DMA 等待计数和搬运描述符合并情况偶发死锁中断丢失或同步条件未满足加中断超时机制备份关键状态寄存器多核结果不一致输出维度划分规则有误核对调度器分块参数与硬件地址映射表编译时间异常长算子分解后路径过多检查是否在 IR 层遗漏了算子融合 pass8. 实现一个最小可运行示例8.1 目标与任务界定为了说明软硬件怎么配合这里给一个最小示例设计一个 4x4 脉动阵列加速器完成两个 4x4 矩阵的乘法并在仿真环境中验证软件指令序列。这不是一个完整的 AI 芯片但它能让你看清指令集、DMA、计算阵列和同步机制是如何串起来的。假设硬件参数如下4x4 MAC 阵列10MHz 仿真时钟每个 MAC 单元支持 8 位乘累加片上有一个 64B 的输入激活缓冲区AB和一个 64B 权重缓冲区WB一个 DMA 通道可搬运 64B 连续数据支持一条MAC_MATRIX指令完成两个 4x4 矩阵的乘累加完成后写回一个累加结果寄存器堆。模型是简单的矩阵乘法无偏置无激活。这个示例的核心意义不是性能而是展示软硬件分工硬件提供执行机制软件提供数据编排和指令序列。8.2 指令集和寄存器定义定义以下寄存器CTRL启动计算、STATUS忙/空闲标志、AB_BASE和AB_SIZE激活缓冲区地址、WB_BASE和WB_SIZE权重缓冲区地址、ACC_BASE累加结果地址、DMA_SRC等DMA 描述符字段。为简化我们用固定地址映射AB 地址从 0x0000 开始WB 地址从 0x0040 开始累加器从 0x0080 开始。指令只有一条MAC_MATRIX表示将 AB 中的 4x4 矩阵与 WB 中的 4x4 矩阵乘累加结果存入 ACC。软件要做的流程是(1) DMA 把两个矩阵分别搬运到 AB 和 WB(2) 写AB_BASE、WB_BASE、ACC_BASE(3) 写CTRL发起计算(4) 轮询STATUS直到空闲(5) DMA 把 ACC 结果搬回主存。这个流程虽然简陋但已经体现了软硬件交互的基本模式。8.3 Python 仿真器实现我来写一个简化版仿真器便于你理解行为。不用完整代码但核心逻辑展示如下。class NPU: def __init__(self): self.ab [[0]*4 for _ in range(4)] self.wb [[0]*4 for _ in range(4)] self.acc [[0]*4 for _ in range(4)] self.status 0 # 0 idle, 1 busy self.ctrl 0 def load_ab(self, data): for r in range(4): for c in range(4): self.ab[r][c] data[r][c] def load_wb(self, data): for r in range(4): for c in range(4): self.wb[r][c] data[r][c] def run_mac(self): self.status 1 for i in range(4): for j in range(4): s 0 for k in range(4): s self.ab[i][k] * self.wb[k][j] self.acc[i][j] s self.status 0 def read_acc(self): return [row[:] for row in self.acc] def step(self): if self.ctrl 0x01: self.run_mac() self.ctrl 0这段代码对应硬件 RTL 里的状态机和计算单元。软件侧的驱动只需要写寄存器、轮询状态、搬运数据。放到真实项目中这个仿真器还可以加入周期计数、DMA 通道模拟和中断事件形成周期级模型的基础版本。8.4 软件侧驱动示例下面是一段驱动伪代码的核心逻辑展示软硬件如何交互。这里我故意不使用真实硬件寄存器地址避免误导。// 软件控制 4x4 矩阵乘 void matrix_mul_on_npu(int16_t* A, int16_t* B, int16_t* C) { // 步骤1: 搬运数据到片上缓冲区 dma_transfer(A, AB_BASE, sizeof(A)); dma_transfer(B, WB_BASE, sizeof(B)); // 步骤2: 配置并启动计算 write_reg(AB_BASE, addr_A_value); write_reg(WB_BASE, addr_B_value); write_reg(ACC_BASE, addr_C_value); write_reg(CTRL, 0x01); // 步骤3: 等待计算完成 while (read_reg(STATUS) ! 0) { // 可以在此处加入超时处理 } // 步骤4: 搬回结果 dma_transfer_from_onchip(ACC_BASE, C, sizeof(C)); }这个驱动看起来简单实际硬件上还有地址对齐、DMA 描述符链和中断处理但“搬运 → 配置 → 计算 → 等待 → 搬回”这个模式是所有 AI 芯片软件栈的基础循环。这里有一个重要的设计短语驱动层不要直接暴露寄存器操作给上层。上层应该是整数张量语义的算子 API比如matrix_mul(A, B, C, rows, cols, depth)驱动完成寄存器配置和 DMA 描述符编排。这套层次结构让编译器后端可以复用驱动接口也方便在仿真器和真实芯片之间切换。9. 工具链与开发环境建议9.1 常用的开源与商业工具软硬件协同设计并不需要从零造轮子。我按用途分类整理了一些常用工具你可以根据自己的项目阶段选择。用途工具/框架说明模型训练与导出PyTorch / TensorFlow / ONNX只做部署时用它们做格式转换即可编译器前端ONNX Runtime / TVM / MLIRTVM 的 TE 和 AutoTVM 适合做算子自动调优编译器中间表示MLIR / LLVMMLIR 对自定义算子下降更友好硬件建模SystemC / Gem5加扩展/ 自定义 Python 模拟器早期用 Python精确建模再上 SystemC硬件验证Verilator / Synopsys VCS / Cadence XceliumVerilator 开源且速度极快FPGA 验证Xilinx Vitis / Intel Quartus快速原型和软件驱动预验证性能分析Perfetto / Trace Compass 自定义 trace schema结合硬件计数器使用最有效如果你公司没有充足预算完全可以用 TVM 和 MLIR 搭第一版编译器框架。它们虽然不像商用工具那么“开箱即用”但社区活跃算子编写和硬件后端插入都比较自由。很多国产 NPU 的第一版工具链就是从 TVM 的 BYOCBring Your Own Codegen或者 Halide 思路起步的。9.2 开发流程和管理建议再好的工具缺少流程也很难落地。我建议所有 AI 芯片软硬件协同项目至少建立三个环节。定期软硬件联调例会。频率可以是一周一次每次不超过一小时。会议的核心不是汇报进度而是同步“接口变更”和“性能模型变化”。例会记录直接成为 ICD 的变更记录后续追溯问题时会非常有用。统一的 problem tracker。无论是硬件 bug、编译器 bug还是工具链集成 bug都用一个追踪系统管理。每个 bug 要关联硬件模块、软件模块和复现用例。这个听起来像软件工程常识但在芯片团队中往往做得不够因为硬件团队习惯于“本地验证”很少和别人共享问题列表。benchmark 回归机制。每周跑一次全量基准测试包含至少 3 个典型模型和 10 个核心算子。测试结果自动归档并与上周对比。性能回归或精度回归要立即引起注意。这个机制运行一段时间后它的价值会远超你的预期。9.3 与开源社区的协作模式如果团队有足够能力建议和开源社区建立协作关系。比如用 TVM 时把新的硬件后端回馈到上游这样后续新版框架更新时你这些自动降级逻辑还能平滑兼容。但是回馈代码也要谨慎不要因为开源版本更新而打乱内部稳定版本节奏。我的建议是两个分支内部基线分支和上游协作分支定期同步不做大重构。10. 一些我个人的实操体会10.1 踩过的坑和教训这部分我想写点实话都是项目里实际遇到的不是从教科书里看的。最大的坑是“过早性能优化”。软硬件协同设计阶段很容易陷入对计算单元数量的过度优化把编译器还没验证的调度方案当作既定事实。结果是花大量时间调整硬件微架构最后编译器实现后发现调度方式完全不同架构只能推倒重来。我现在会先让编译器团队快速实现一个最简单的可用后端哪怕性能只有目标的 30%先把端到端跑通再逐层优化。跑通全链路比单点性能重要得多。第二个坑是“低估了数据搬运的作用”。很多第一次做 NPU 的同事会把算力当作唯一指标直到调试才发现DDR 带宽和片上缓冲容量才是真正的性能天花板。如果你设计的计算阵列理论峰值很高但片外带宽不足实际有效算力可能只有峰值的五分之一。任何一个 AI 芯片架构决策都应当把“数据搬运”和“计算”放在同一张表格里评估。第三个坑是“版本管理混乱”。这不是单一工具层面的问题而是流程问题。尤其当 FPGA 原型和 RTL 仿真各自的软件栈不一致时问题会爆炸式增长。后来我们规定每次 tap-out 或原型发布时必须配套一个可重复构建的软件 SDK 版本该版本能通过完整测试集。这听起来麻烦但为调试省下的时间是十倍以上。10.2 一点建议复现我的最小示例如果你是完全的新手我建议你今天就用 Python 把 4x4 矩阵乘跑的仿真器跑通然后试着改几个参数比如把矩阵改成 8x8或者增加一条ACC_CLEAR指令。你也可以尝试在仿真器里统计周期数看看不同的 DMA 调度对运行时间的影响。一旦你能通过寄存器配置和指令下发控制硬件仿真器你对“软硬件协同”这个概念的理解就会完全不同。最后想说的是AI 芯片这块领域看起来高深但拆开看无非是“如何把大量计算安全、高效、可控地组织起来”。软硬件协同设计扮演的正是让这一切成立的黏合剂。无论你是从硬件进入还是从软件进入只要把握住接口、数据流、性能模型、验证体系这几根主线方向就不会走偏。 
长河君 · 2026/10/6 6:02:46 · 阅读 1.2k AI芯片软硬件协同设计：接口、编译器与性能优化全解析
1. 项目概述1.1 核心需求解析AI 芯片的软硬件协同设计这个话题在业内聊了很多年但真正愿意把它掰开揉碎讲清楚的并不多。你看到“AI 芯片的软硬件设计 1”这个标题大概率是正在接触相关项目或者准备进入这个方向想知道从哪下手、怎么搭框架、软硬件之间到底怎么配合。这个标题的潜台词其实很明确不打算只讲芯片架构理论也不打算只写驱动代码而是要把两者放在一起讲清楚一个 AI 加速器从需求定义到落地验证的完整链路。所谓“1”通常意味着系列内容的第一篇重点应该放在总体设计思路、软硬件接口划分、工具链基础框架这些打地基的事情上。我个人的理解是这个系列适合三类人一类是刚转到 AI 芯片方向的学生或工程师需要建立全局视角一类是做算法或模型的开发者想知道自己的模型到底怎么跑到硬件上的还有一类是做嵌入式或传统 SoC 设计的工程师想了解 AI 加速和以往通用计算的差异到底在哪。这篇文章我打算沿着一条主线展开先说明软硬件协同设计的工作流程和关键决策点再拆解指令集与数据通路、编译器工具链、算子映射策略、量化方案选择这些核心模块最后补充验证、调试和性能分析的实际做法。内容会比较重但我尽量用通俗的语言和真实项目经验来说不堆概念。1.2 我从这个项目里看到的几个关键点先说结论AI 芯片和传统芯片最大的区别不在于“算得快”而在于“算得巧”。这个“巧”体现在架构设计之初就要把算法、编译器、运行时、驱动全链路一起考虑而不是像传统 SoC 那样先有硬件规格再把软件往上堆。从项目实操角度看有四个点最容易决定项目成败。第一个是软硬件接口的稳定性。接口一旦定了改一次的成本极高。指令集架构ISA也好寄存器映射也好DMA 描述符格式也好一定要在动手写 RTL 之前反复评审。第二个是算子覆盖率的定义。做张量加速器不是把所有算子都做进硬件而是把通用、高频、计算密集的算子硬件化其余用软件组合实现。这个“硬件化”和“软件化”的比例怎么定直接决定芯片面积、功耗和性能。第三个是编译器和硬件的同步开发节奏。编译器不是等芯片流片后才开始写的而是在架构探索阶段就要和硬件团队共用一个性能模型边评估边优化。否则等你芯片回来了编译器还没调好整个项目就卡在那里。第四个是片外存储带宽的瓶颈。我们做 AI 加速器时经常发现计算阵列的处理能力其实够用真正卡脖子的是数据搬运速度。LPDDR 带宽、片上 SRAM 容量、数据复用策略这些在体系结构设计阶段就要算清楚。这四点我会在后面的章节逐一展开尤其是第四点很多人第一次做加速器都会栽在带宽这个坑里。2. 软硬件协同设计的整体框架2.1 为什么要“协同”而不是“并行”很多第一次接触 AI 芯片设计的同学会误以为软硬件协同设计就是软件团队和硬件团队同时开工各干各的最后再整合。这个想法放在传统 SoC 开发里还能勉强凑合放在 AI 芯片上基本行不通。原因其实不复杂。AI 加速器的每个关键设计决策几乎都同时影响软硬件两端的实现复杂度。举几个最典型的场景。处理器的指令集设计。如果硬件上提供一条“矩阵乘加”指令编译器端就要能识别计算图中的矩阵乘子图并匹配到这条指令。反过来如果编译器团队评估后认为频繁执行“整块搬运逐元素运算”效率更高硬件就得考虑加宽存储总线或增加直接内存访问通道。指令集不是硬件单方面定的它是两边协商的结果。存储层级的设计。片上 SRAM 分几级、每级多大、是否支持多块并行读写这些决定编译器怎么排调度策略。硬件如果把缓冲区划分为多个 Bank编译器就可以把不同张量分配到不同 Bank 并做并行搬运如果只有一个连续地址空间编译器就要做复杂的地址冲突规避。前者性能上限高但面积功耗大后者简单但容易卡访存。算子切分策略。比如卷积怎么拆分成 GEMM通用矩阵乘法这个决定如果放在软件层做硬件只需要提供矩阵乘引擎和激活函数单元如果硬件把卷积直接做成专用电路比如为 3x3 卷积定制数据通路编译器就相对省事但芯片灵活性下降将来算法变了很难适应。类似这样的互相制约关系在整个 AI 芯片设计里到处都是。所以协同设计的本质是让软件团队在硬件方案还没定型前就介入用性能模型、仿真平台、虚拟原型去评估算法映射效果反过来给硬件提需求。硬件团队也不是闭门造车而是在需求驱动的约束下做架构探索双方在同一个“可执行的设计规格”下持续迭代。我实际项目中踩过的一个坑是软件团队等硬件服务模型通常用 SystemC 或 Python 写的周期级模拟器做好后才开工做编译器结果发现硬件方案有几个不合理的地方但 RTL 已经写了一点改动成本很高。后来我们调整流程把“架构探索阶段”和“软硬件需求冻结”之间加了至少两轮联合评审才把这类问题压下来。2.2 设计流程分哪几个阶段一个典型的 AI 芯片软硬件协同设计项目大致分六个阶段。每个阶段要产出的文档或代码我在后面加注释说明。阶段一需求定义。这部分首先是明确目标场景跑哪些模型ResNet、YOLO、BERT、Stable Diffusion 等等目标帧率或吞吐量功耗和面积预算成本约束量产时间和工具链成熟度。需求定义最忌讳模糊像“跑主流模型”这种描述后期一定会扯皮。阶段二架构探索。算法团队提供算子统计特征各算子的计算量占比、内存占用、数据复用度硬件团队据此搭建架构模板软件团队在性能模型上跑 benchmark陆续暴露瓶颈。这个阶段通常会产出一个 Excel 表或数据库列出几十个候选架构配置与对应的性能、面积、功耗预测。阶段三软硬件接口冻结。这是全项目最关键的里程碑。指令集、寄存器映射、中断机制、DMA 描述符、存储地址映射、同步机制全部冻结然后形成正式的接口文档接口控制文档简称 ICD。ICD 一旦发布任何修改都要走变更评审流程。阶段四并行开发。硬件团队做 RTL 设计、验证、综合软件团队做编译器后端、算子库、运行时、驱动。两边靠仿真环境和硬件加速验证平台FPGA 原型或 emulator对接。并行开发阶段最大的挑战是保持“参考模型”和 RTL 的同步更新不然软件调完了发现硬件行为对不上。阶段五软硬件集成。芯片回来或 FPGA 原型跑起来后做 bring-up。一般顺序是先跑自检程序再跑小的算子测试例再跑小模型比如 MNIST 或 MobileNet最后跑完整目标模型。这个阶段也是编译器 bug、驱动 bug、硬件 bug 的高发期。阶段六优化和量产。性能不达标就一层层查瓶颈算子核函数效率、数据搬运策略、内存分配、线程调度。这个阶段会有大量 profiling 工作软件侧要做的优化远比想象的多。我建议每家公司都把“软硬件接口冻结”这个阶段单独拿出来评审不要和架构探索混在一起。以一个真实案例来说我们曾在一个加速器项目里因为对“卷积计算完成信号”的定义不一致导致软件等待中断但硬件早已触发完成标志最终排查了两天原因是硬件团队理解的是“写回完成”软件团队理解的是“可重新开始计算”。ICD 里用一句话就能避免这种问题明确信号语义和时序关系。2.3 接口设计的要点和实践接口设计在传统芯片设计里通常指引脚定义或总线协议但在 AI 芯片语境下它更多指软件可编程视图programmer-visible view。这部分我会稍微展开因为它是软硬件协同设计的核心交汇点。指令集设计。AI 加速器的指令集一般不是通用 CPU 那种复杂指令集而是一种领域特定指令集DSAs指令通常分为几类计算指令矩阵乘、向量运算、激活函数、池化、数据搬运指令DMA 读/写、片上 Buffer 搬移、控制指令循环控制、同步、跳转、以及配置指令设置寄存器、配置维度参数。每类指令的关键是“显式并行步”的设计。比如一条矩阵乘指令是否支持多核并行支持的话计算结果的写回地址如何编排中断如何产生这些都是硬件和软件双边协议的事。寄存器映射。通常有两类寄存器一类是状态寄存器软件读它来获取硬件执行状态一类是控制寄存器软件写它来配置计算模式、数据路径、中断使能。保守的做法是为每个算子定义一组独立的配置寄存器灵活性和可编程性高但软件驱动代码量大激进的基因是全局共享一组配置寄存器节省面积但配置切换耗时多算子流水时容易产生冲突。我们的经验是寄存器定义一定要有全局编号并且和驱动代码中的结构体定义严格对应最好由工具自动生成头文件避免手写不一致。DMA 描述符设计。AI 芯片内部数据的搬运基本由 DMA 完成。DMA 描述符描述一次搬运任务比如搬运类型连续搬、二维搬、三维搬、源地址、目的地址、长度、步长、完成标志。描述符看似简单但设计时要把“多级描述符链”考虑进去。为什么需要链式描述符因为编译器排出来的数据搬运任务往往是序列化的不能让 CPU 等每个搬运完成后才去配下一个描述符。链式描述符让 DMA 自动执行后续任务CPU 只在全部完成时被中断一次极大降低软件开销。地址映射与内存管理。AI 芯片通常有多块存储片外 DDR、片内 SRAM、寄存器文件、以及各计算单元自带的 Accumulator Buffer。软件侧需要明确看到这些存储的地址映射并设计内存管理模块来分配地址。难点在于不同硬件模块的地址空间可能不连续、不对齐编译器分配张量地址时必须遵守对齐规则否则性能骤降甚至触发硬件行为未定义。接口评审的方法。我们项目里常用的方式叫“三表评审”指令计费表每条指令的周期数和功耗预估、寄存器配置表每个功能域可编程点的层级和复位值、错误处理表各种异常和回滚策略。三张表做成电子表格硬件团队维护每一列软件团队标注使用场景最终形成冻结版本。三表联审最大的价值在于让两边都看到“对方的边界”。3. 核心模块拆解硬件视角3.1 数据通路怎么算出来的AI 加速器的硬件核心是计算阵列。常见的架构有三种脉动阵列Systolic Array、SIMD 向量单元、以及可重构的异构计算引擎。脉动阵列的代表是谷歌的 TPUSIMD 向量单元在 GPU 和部分 NPU 中使用可重构异构引擎比如一些采用众核架构的公司灵活性更好。这里我把“怎么定规模”这件事重点讲因为大多数人做架构探索时都会卡在这里。先算一下“需要多少算力”。假设目标场景是跑 ResNet-50输入分辨率 224x224批量大小为 1希望在 10W 功耗下达到 100fps。ResNet-50 在 224x224 下的浮点运算量约为 4.1 GFLOPs乘加算两次浮点操作4.1 GFLOPs 已经包含乘加转换。100fps 的算力需求就是 410 GFLOPs。考虑实际利用率通常只有 30%~50%原因是数据搬运、算子切换、负载不均衡等我们要设计的算力约为 1 TFLOPs 到 1.4 TFLOPs 之间。再定“数据精度”。训练用 FP32 或 BF16推理通常是 FP16 或 INT8。如果 INT8TOPs每秒整数运算次数计算只需要 FLOPs 的一半因为一个 INT8 乘加只算一次操作但实际硬件一般仍把 INT8 乘加操作计数为 1 MAC即 2 次操作。为了让例子简单我用 MAC乘加操作来算目标 700 GMAC/s约 1.4 TFLOPs 的 INT8。接着算“计算阵列规模”。假设循环频率为 1GHz每周期每 MAC 单元完成 1 次乘加则需要 700 个 MAC。要留余量考虑利用率 50%则约 1400 个 MAC。配置成 16x16 的脉动阵列就是 256 MAC32x32 就是 1024 MAC还可以通过 double-pump两次复用增加吞吐。架构探索时你可以写一个参数化模板把阵列的行数、列数、片上存储容量、带宽约束作为参数统一跑一遍性能模型。我见过不少团队直接拍脑袋选 16x16 或 32x32这没有错但缺少计算依据。最好把各种尺寸放在同一个调度器下做评估脉动阵列单位周期吞吐、累加器缓冲Accumulator BufferAB容量、激活/权重 Buffer 容量、DMA 搬运带宽四个变量互为约束最终选出一组平衡配置。3.2 存储层级与片上缓存设计AI 芯片的存储层级几乎决定性能上限。有个共识是“数据搬运比计算更贵”片外 DDR 的访问功耗和延迟远高于片上 SRAM。所以设计存储架构的核心目标是尽量把数据留在片上反复复用减少 DDR 访问次数。这里引入“数据复用”的概念它是整块设计里最关键的推理依据。举例说明。卷积层的权重数据在一个 batch 的多次推理中是完全复用的权重应该常驻片上。偏置、BatchNorm 参数也属于这类数据。输入特征图在多个输出通道做卷积时同一块输入数据会被多次使用输入复用。输出特征图在后续层作为输入时还会被继续消费输出复用。架构设计时我们通常把激活值缓存Activation Buffer和数据缓存Weight BufferWB分开设计让它们可以并行读写。有一个经典的经验比例片上总存储大小和目标模型“峰值工作集”匹配。比如跑 YOLOv5s输入 640x640中间特征图加权重总需求约 8MB如果片上只有 2MB SRAM编译器就得分块调度复杂度暴涨。为了决策我们把“片上缓存容量”和“DDR 带宽”做成一对互选参数用性能模型跑出带宽利用率曲线。通常曲线有一个“拐点”超过某个容量后带宽利用率增长放缓那就没有必要扩大缓存。我最近做过的项目里最终选择片上 4MB SRAM 配合 LPDDR4x 4266MT/s 的带宽跑 YOLOv5s 达到约 70fps瓶颈已经从计算转移到带宽的边界。这个例子想说明存储架构的参数贴近实际模型而不是追求最大容量。面积太贵容量够用就行。3.3 专用计算单元的选择除了矩阵乘主阵列AI 芯片通常还要挂几个专用的功能单元比如激活单元、池化单元、Softmax 单元、归一化单元。这里经常有一个争议到底哪些算子值得专用硬件化我的判断依据很简单算子占整个模型计算时间超过 5%且控制简单、没有复杂的可变数据依赖就值得硬件化。Softmax 虽然计算量占比不高通常小于 2%但实现方式是指数运算除法累加用软件循环处理器执行会占用很多指令周期。专用的一小块指数查找表和除法器在功耗和面积上都很划算。激活函数又是另一个典型。ReLU 是纯硬件友好的既简单又高效不需要专用单元。GELU、SiLU 等非线性激活函数就需要查表或多项式逼近。如果你打算支持大语言模型还会出现 RMSNorm、LayerNorm、RoPE 等算子这些用软件实现还是硬件实现要在架构探索阶段一并决策。经验法则模型权重占比高的算子优先硬件化控制流复杂的算子留给软件。4. 核心模块拆解软件视角与工具链4.1 编程模型和运行时设计软件侧第一件要做的事是定义“程序员怎么使用这块芯片”。这听起来像 API 设计实际比 API 更深一层它决定了人和硬件的契约。目前 AI 芯片的编程模型大致有两类。第一类是类 PyTorch 风格程序员写 Python框架前端负责计算图解析后端生成算子调用运行调度由编译器完成。这一类的优点是开发效率高缺点是性能优化空间有限因为迭代式编程Python 不断调用小算子很容易造成大量设备端同步开销。第二类是类 Kernel 风格程序员写 SPM/CUDA 风格的 kernel显式管理数据搬运性能天花板高但门槛高调试困难。很多面向推理的 AI 芯片会选第一类为主第二类为辅。商用推理引擎像 TensorRT 或 OpenVINO实际走的思路是离线编译出一个封装引擎运行时不再解析模型结构而是加载已生成的指令序列。这种思路让运行时保持轻量甚至支持“裸机部署”不带操作系统。做 AI 芯片时软件团队应该把“图优化”和“内核生成”放在离线编译阶段运行时只负责加载、调度、同步。这些设计决策都会影响硬件侧的协处理器接口定义。假如运行时和硬件握手太频繁中断占满 CPU执行效率就崩了。4.2 编译器后端核心工作流编译器后端是软硬件连接的枢纽。大致分四个步骤。第一步计算图解析和优化。前端把 ONNX、PyTorch 或 TensorFlow 模型转成内部中间表示IR在这个层次我们做算子融合、内存规划、布局转换、常量折叠。算子融合是效率关键。比如 ConvBNReLU 这种三段融合如果三步都在 GPU 或 CPU 上运行数据必须写回全局内存再读回在 AI 芯片上因为缓冲区就在片上硬件可以把整个卷积、归一化、激活的流水线一气呵成。融合的目标就是减少中间张量在片外 DDR 和片上 SRAM 之间的搬运。第二步算子分解和硬件映射。这是编译器的核心。每个算子会先被分解为一个或多个底层模板比如卷积分解为 Im2ColGEMM偏置矩阵乘分解为分块矩阵乘和累加大矩阵分解为和应外部分块循环。这一步要依赖硬件后端提供“算子语义说明”包含各种数据布局约束和指令限制。没有这一步编译器生成的代码很可能在硬件上跑不了或性能崩塌。第三步内存分配和调度。我们有一个内部叫“地址业务”的阶段把所有中间张量的生命周期放在一个调度图里做图着色式寄存器分配或类启发式分配。关键约束包括计算单元并行性、Bank 冲突、DMA 描述符链长度限制、同步 barrier 的粒度。这一步直接决定能否充分发挥硬件性能。写过程序分配地址的人都懂看似只是“找块内存”实际是一个类似整体调度的问题。第四步代码生成。最后端把调度结果翻译成芯片指令序列同时生成对应的描述符和配置数据。这个阶段经常出现“硬件不支持 32 位对齐地址”或者“DMA 长传需按 16B 对齐”这类约束冲突所以代码生成器通常要内嵌一组对齐和合法性检查逻辑。这里我需要提醒的一点是不要幻想一步到位写一个完整的高性能编译器。AI 芯片编译器是一个持续演进的项目第一版只要能跑通几个目标模型并发性能铺路后面才能逐步加入更多优化 pass。如果一开始就被“把编译器做完美”的计划束缚住项目很容易陷进死循环。4.3 算子的端到端实现路径在真实项目里算子不是一个静态的概念而是一套从模型到硬件的映射流水线。以卷积为例。模型侧通常只需要一句torch.nn.Conv2d。软件栈先把它转成 ONNX Conv 节点然后进入编译器。编译器第一步要识别这个节点将其拆分为权重重排、Im2Col或直接使用硬件支持的隐式 GEMM 模式、矩阵乘、偏置加、激活融合几个子任务。硬件侧则分成几个功能模块执行权重重排由主机侧预排版Im2Col/GEMM 由计算阵列执行偏置和激活在专用单元执行。如果是直接实现隐式 GEMM很多 NPU 都这么干编译器里需要生成一个外层循环按输出通道分块每个循环体内调用“GEMM 微内核”。微内核封装了脉动阵列或 SIMD 单元的指令序列。每次微内核执行硬件会把激活 Buffer 中的一块数据和权重 Buffer 中的一块数据送入计算阵列循环累加后写回累加器缓冲。完成后再通过 DMA 把累加结果搬回主存。这条路径几乎每一步都有分布式的决策。输出通道如何分块取决于存储容量权重是否保持常驻取决于复用次数累加缓冲的大小决定一次能算多少个通道。所以编译器后端工程师需要定期看“硬件架构变更说明”否则你排的调度在新型号上就不 work。5. 模型部署与优化实践5.1 量化方案的关键细节AI 芯片上常用的推理精度有两种主路线INT8 和 FP16。INT8 能带来 2~4 倍性能提升但一定会引入量化误差尤其是对大语言模型的敏感层。我的经验是不要一上来就所有层无脑 INT8要先做“逐层敏感度分析”。做法很简单用一小批校准数据把每一层单独换成 INT8 做推理记录输出偏移或下游精度变化。找出最敏感的几层把这几层保留 FP16 或使用混合精度其余用 INT8误差降到可接受范围性能和精度的平衡点就抓到了。具体到量化部署还有三个细节容易被忽略。输入校准方式影响巨大。使用 1000 张样本的分布做校准和用 10 张代表性图片做校准对 INT8 最终精度的影响通常大于 0.5%对于分类任务影响可能不大对于检测任务影响就明显了。所以“选择什么校准集”也是在设计量化流程时必须明确的环节。权重和激活是否使用相同的量化范围。建议分开权重量化为对称 INT8因为权重分布近似对称激活量为非对称或使用零点因为激活分布通常偏在正区间。性能模型里可以看到分别处理能显著增加有效动态范围只损失极少换算成本。量化在硬件侧是否“免费”。部分 NPU 的 INT8 算力是 FP16 的两倍但也会有额外缓冲区开销。编译器排调度时要把输入类型转换节点作为独立算子插入计算图。这个“插入转换节点”看似琐碎但带着它去安排 DMA 搬运经常导致数据在片上被来回转置性能隐性损失很大。5.2 运行时调度与内存复用AI 芯片的运行时调度是一门“指针艺术”。关键不在于操作系统任务调度而在于张量生命周期管理。推理时多分支结构如 ResNet 的残差连接会让中间张量的生命周期重叠。编译器或运行时尽量复用缓冲区地址这种复用策略要整合到整个推理图。很多人觉得这就是给每个张量分配一块内存真正做起来后会发现指令序和 DMA 描述符执行顺序稍有变化缓冲区被覆盖的风险就可能出现。我推荐一种做法在编译器内部用“张量分片分配器”先对公司内部所有模型跑一遍调试级验证即在模拟器里执行指令序列并监控地址读写碰撞。每一步调度都必须经过分配器的合法性检查。内存安全不是等芯片跑起来才验证而是要在编译期就发现。这个思路和普通软件开发的 sanitizer 类似但它针对的是硬件的地址空间。另外多线程调度也不可忽略。推理端一般用少量核比如 CPU 侧的 4~8 个核做前端控制主要任务是下发任务、同步中断、超时处理。这个控制流模型不适合给每个算子都发起一次异步调用因为频繁的同步会压垮系统。更好的方式是采用“两层调度”第一层是模型级的图调度第二层是算子内部的指令队列调度。两层调度分离后软件复杂度也会大幅下降调试也会容易很多。5.3 全链路追踪和性能调优做软硬件协同的高性能系统第一步永远是“有没有性能数据”没有数据就谈不上调优。我强烈建议在软件栈的最底层做全链路 trace 插桩不是说你可以把所有中间事件都打印出来而是设计成“环形缓冲 时间戳”。用硬件计数器记录指令发射、DMA 完成、计算单元空闲、等待锁存等关键事件。把这些事件映射到模型计算图上就可以知道这个算子为何这么慢。实际调优过程中最常出现的性能问题主要有三类。搬运瓶颈。表现为指令周期快到内存搬运用不完。数据量明明很小但由于通道冲突DMA 被拆成过多小段增加描述符开销造成整体搬运周期显著超过理论时间。这时要做“描述符合并”或者调整 Bank 分配。计算负载不均衡。多核并行时某些核心负载过重另一些核心闲置。典型原因是输出通道划分得太细或者依赖同步点过多。解决办法是在调度器里改进“分块循环”让每个核拿到的子任务数量和尺寸均匀降低 barrier 次数。同步开销过重。如果每个算子之间都有同步等待流水线的重叠几乎为零。解决方案是把算子组成“融合组”在组内用双缓冲或软件流水让计算和数据搬运并行。这通常要求硬件侧提供“多个 DMA 通道 多个计算指令队列”的能力这也是我之前强调性能和架构要一起设计的核心原因。6. 两大关键支撑验证与性能评估6.1 多层验证体系搭建软硬件协同项目的验证比单一硬件验证或单一软件验证要复杂得多。理想情况下有四个层次。第一层算子级仿真验证。软件团队在自己设计的参考模型上跑算子对比标准数值结果。这里要覆盖边界数据零矩阵、饱和值、极端负值和异常尺寸比如偶数和奇数通道。第二层RTL 级仿真验证。硬件团队在仿真器上跑同一组测试用例对比软件参考模型。由于 RTL 仿真速度慢通常会抽取一部分用例做“差异测试”即随机生成输入并用差分比较。第三层FPGA 原型验证。多数 AI 芯片项目会做 FPGA 原型直接在真实时钟频率下跑算子速度虽然比模拟器快很多但频率通常只有真实芯片的 1/10。FPGA 原型的好处是能跑真实模型一个小的 YOLOv5 也可能要跑几分钟以及让软件团队提前写驱动和编译器后端。第四层硅前验证和硅后验证。硅前主要做功耗分析、时序收敛和静态检查硅后则是流片后的 bring-up。硅后 bring-up 不要一上来就跑大模型我建议按“自检 → 简单算子 → 单算子复杂测试 → 小模型 → 目标模型”循序渐进每一步都检查输出比对和性能计数避免把问题混在一起。我见过很多团队在 FPGA 原型上直接跑完整 YOLOv5s拿到错了几个框的结果就一头雾水。如果你把一个算子一个算子地验证都通过了再全链跑出现问题时定位就容易得多。6.2 性能模型的建模策略性能模型这个词在项目里被滥用得很厉害。我这里的定义是能在软件架构探索阶段以周期级或近似周期级精度估算出每条指令实际执行时间的程序模型。建模策略的核心是“细节分层”。不必一开始就把 RTL 级 pipeline 周期在意那是 RTL 团队的事。软硬件协同的性能模型重在反映行为事件和资源竞争。举个例子一条 DMA 描述符执行时需要知道搬运大小、Bus 带宽、Bank 冲突率、是否和计算指令并行这些信息可以从接口定义和系统架构描述里得到。周期数就是这几个因素的函数而不是精确到每个 cycle 的仲裁细节。为什么我不推荐一上来就写精确的 SystemC 时间模型因为 SystemC 建模写得越精确维护成本越高每次架构改动都要同步更新通常会让项目失去灵活性。合理的做法是先用一个 Excel 或简单 Python 脚本快速估算确定一个大致方向再去写或者重写一轮精确模型专门用于软硬件冻结前验证。性能模型的产出物至少包括三类统计量各算子周期占比、各存储带宽利用率、各功能单元的利用率。其中最有价值的是“结构瓶颈定位”比如看到某一层的 GEMM 周期已经远高于理论值说明调度有问题而不是算力不够编译器团队可以据此介入优化。6.3 硬件性能计数器设计硬件性能计数器是软硬件项目里经常被忽略但特别重要的部分。没有它优化就像闭眼开车。AI 加速器的计数器应该覆盖四类事件计算事件比如 MAC 单元有效工作周期数、空转周期数、单指令多数据SIMD利用率、存储事件比如 DMA 读写完成次数、缓冲命中率、片上缓存 Miss 次数、流水线事件比如指令队列满、同步等待周期、写冲突次数、以及外部接口事件比如 DDR 带宽利用率、ISP 或 PCIe 传输计数。这些计数器的定义最好在 ICD 阶段就一起定下因为设计到位需要占用寄存器空间和硬件逻辑。硅后调试时我的经验是先从“指令队列等待周期”和“DMA 等待周期”这两个计数值下手。它们会直接告诉你瓶颈是在计算、存储还是同步。之前做加速器时遇到过花了一周优化计算流水线但性能没有变化的情况原因其实是 DMA 通道冲突太严重。加上计数器后一眼就看出 DMA 通道的占用率一直高于 95%而计算单元还有 40% 时间空转。7. 常见问题与排查技巧实录7.1 算子行为与参考模型不一致这类问题最常见通常出现在硅后集成的头几天。先确认是不是数值精度问题把所有中间结果转成 FP32 打印和软件仿真模型对比看偏差是逐渐放大还是突然跳变。如果突然跳变大概率是某个算子的实现路径走错了如果逐渐放大大概率是量化或舍入误差的累积。还有一种隐蔽情况芯片端做了一条 fuse 路径但参考模型里没有加对应逻辑。比如你在芯片上把卷积和 BatchNorm 融合了但参考模型还是分步计算导致数值不同。这种问题在融合优化时非常容易踩坑建议在编译器生成的“算子融合日志”里把融合决策记录下来配套打印每个输入输出张量的数值摘要后续排查会轻松很多。7.2 指令队列耗尽和死锁指令队列泛满导致硬件死等通常要检查三个方面。第一硬件端是否有足够深的指令队列尤其在多路 DMA 同时下发时第二软件端是否在还未满足前一个指令同步条件时就提交了新指令第三中断丢失时驱动和硬件是否还能自恢复。排查死锁时我最喜欢用“二分法判断”。先把计算功能全部禁用只跑 DMA 搬运看是否死锁。然后把 DMA 禁用只跑计算看是否死锁。最后只跑同步指令看两个模块同步的握手信号和中断是否正确。用这个顺序基本能在半小时内定位是搬运端、计算端还是同步协议本身的问题。7.3 性能指标与模型预估差距大常见原因有两类一类是调度器生成的指令顺序没有充分利用并行另一类是量化或精度影响导致某些算子走了精度较低或效率低的 path。如果模型预估的周期是 1000 周期实际执行是 1500 周期不要急着改硬件先把性能计数器的数据打印出来对照计算周期、搬运周期和等待周期三个数值占比。这个占比会告诉你哪个部件拖后腿然后再针对优化。7.4 工具链版本错位问题凡是软硬件项目都会遇到“硬件 RTL 版本、驱动版本、编译器版本”三者之间不匹配。比如驱动增加了新寄存器特性但 RTL 没实现或者编译器生成的新指令不受旧驱动支持。最笨但最有效的办法是建立一套正式的版本基线软件和硬件团队共同维护一个“变更日志”每次接口变更必须同步到对应分支。集成时统一用带版本号的镜像而不是随手拉最新代码。这个细节虽然无聊但能避免大量低级集成错误。7.5 附高频问题速查表现象可能原因首要排查动作算子输出异常但非零量化参数未加载或加载错误检查量化配置表是否一致单算子对照测试性能远低于预期DMA 通道冲突严重查 DMA 等待计数和搬运描述符合并情况偶发死锁中断丢失或同步条件未满足加中断超时机制备份关键状态寄存器多核结果不一致输出维度划分规则有误核对调度器分块参数与硬件地址映射表编译时间异常长算子分解后路径过多检查是否在 IR 层遗漏了算子融合 pass8. 实现一个最小可运行示例8.1 目标与任务界定为了说明软硬件怎么配合这里给一个最小示例设计一个 4x4 脉动阵列加速器完成两个 4x4 矩阵的乘法并在仿真环境中验证软件指令序列。这不是一个完整的 AI 芯片但它能让你看清指令集、DMA、计算阵列和同步机制是如何串起来的。假设硬件参数如下4x4 MAC 阵列10MHz 仿真时钟每个 MAC 单元支持 8 位乘累加片上有一个 64B 的输入激活缓冲区AB和一个 64B 权重缓冲区WB一个 DMA 通道可搬运 64B 连续数据支持一条MAC_MATRIX指令完成两个 4x4 矩阵的乘累加完成后写回一个累加结果寄存器堆。模型是简单的矩阵乘法无偏置无激活。这个示例的核心意义不是性能而是展示软硬件分工硬件提供执行机制软件提供数据编排和指令序列。8.2 指令集和寄存器定义定义以下寄存器CTRL启动计算、STATUS忙/空闲标志、AB_BASE和AB_SIZE激活缓冲区地址、WB_BASE和WB_SIZE权重缓冲区地址、ACC_BASE累加结果地址、DMA_SRC等DMA 描述符字段。为简化我们用固定地址映射AB 地址从 0x0000 开始WB 地址从 0x0040 开始累加器从 0x0080 开始。指令只有一条MAC_MATRIX表示将 AB 中的 4x4 矩阵与 WB 中的 4x4 矩阵乘累加结果存入 ACC。软件要做的流程是(1) DMA 把两个矩阵分别搬运到 AB 和 WB(2) 写AB_BASE、WB_BASE、ACC_BASE(3) 写CTRL发起计算(4) 轮询STATUS直到空闲(5) DMA 把 ACC 结果搬回主存。这个流程虽然简陋但已经体现了软硬件交互的基本模式。8.3 Python 仿真器实现我来写一个简化版仿真器便于你理解行为。不用完整代码但核心逻辑展示如下。class NPU: def __init__(self): self.ab [[0]*4 for _ in range(4)] self.wb [[0]*4 for _ in range(4)] self.acc [[0]*4 for _ in range(4)] self.status 0 # 0 idle, 1 busy self.ctrl 0 def load_ab(self, data): for r in range(4): for c in range(4): self.ab[r][c] data[r][c] def load_wb(self, data): for r in range(4): for c in range(4): self.wb[r][c] data[r][c] def run_mac(self): self.status 1 for i in range(4): for j in range(4): s 0 for k in range(4): s self.ab[i][k] * self.wb[k][j] self.acc[i][j] s self.status 0 def read_acc(self): return [row[:] for row in self.acc] def step(self): if self.ctrl 0x01: self.run_mac() self.ctrl 0这段代码对应硬件 RTL 里的状态机和计算单元。软件侧的驱动只需要写寄存器、轮询状态、搬运数据。放到真实项目中这个仿真器还可以加入周期计数、DMA 通道模拟和中断事件形成周期级模型的基础版本。8.4 软件侧驱动示例下面是一段驱动伪代码的核心逻辑展示软硬件如何交互。这里我故意不使用真实硬件寄存器地址避免误导。// 软件控制 4x4 矩阵乘 void matrix_mul_on_npu(int16_t* A, int16_t* B, int16_t* C) { // 步骤1: 搬运数据到片上缓冲区 dma_transfer(A, AB_BASE, sizeof(A)); dma_transfer(B, WB_BASE, sizeof(B)); // 步骤2: 配置并启动计算 write_reg(AB_BASE, addr_A_value); write_reg(WB_BASE, addr_B_value); write_reg(ACC_BASE, addr_C_value); write_reg(CTRL, 0x01); // 步骤3: 等待计算完成 while (read_reg(STATUS) ! 0) { // 可以在此处加入超时处理 } // 步骤4: 搬回结果 dma_transfer_from_onchip(ACC_BASE, C, sizeof(C)); }这个驱动看起来简单实际硬件上还有地址对齐、DMA 描述符链和中断处理但“搬运 → 配置 → 计算 → 等待 → 搬回”这个模式是所有 AI 芯片软件栈的基础循环。这里有一个重要的设计短语驱动层不要直接暴露寄存器操作给上层。上层应该是整数张量语义的算子 API比如matrix_mul(A, B, C, rows, cols, depth)驱动完成寄存器配置和 DMA 描述符编排。这套层次结构让编译器后端可以复用驱动接口也方便在仿真器和真实芯片之间切换。9. 工具链与开发环境建议9.1 常用的开源与商业工具软硬件协同设计并不需要从零造轮子。我按用途分类整理了一些常用工具你可以根据自己的项目阶段选择。用途工具/框架说明模型训练与导出PyTorch / TensorFlow / ONNX只做部署时用它们做格式转换即可编译器前端ONNX Runtime / TVM / MLIRTVM 的 TE 和 AutoTVM 适合做算子自动调优编译器中间表示MLIR / LLVMMLIR 对自定义算子下降更友好硬件建模SystemC / Gem5加扩展/ 自定义 Python 模拟器早期用 Python精确建模再上 SystemC硬件验证Verilator / Synopsys VCS / Cadence XceliumVerilator 开源且速度极快FPGA 验证Xilinx Vitis / Intel Quartus快速原型和软件驱动预验证性能分析Perfetto / Trace Compass 自定义 trace schema结合硬件计数器使用最有效如果你公司没有充足预算完全可以用 TVM 和 MLIR 搭第一版编译器框架。它们虽然不像商用工具那么“开箱即用”但社区活跃算子编写和硬件后端插入都比较自由。很多国产 NPU 的第一版工具链就是从 TVM 的 BYOCBring Your Own Codegen或者 Halide 思路起步的。9.2 开发流程和管理建议再好的工具缺少流程也很难落地。我建议所有 AI 芯片软硬件协同项目至少建立三个环节。定期软硬件联调例会。频率可以是一周一次每次不超过一小时。会议的核心不是汇报进度而是同步“接口变更”和“性能模型变化”。例会记录直接成为 ICD 的变更记录后续追溯问题时会非常有用。统一的 problem tracker。无论是硬件 bug、编译器 bug还是工具链集成 bug都用一个追踪系统管理。每个 bug 要关联硬件模块、软件模块和复现用例。这个听起来像软件工程常识但在芯片团队中往往做得不够因为硬件团队习惯于“本地验证”很少和别人共享问题列表。benchmark 回归机制。每周跑一次全量基准测试包含至少 3 个典型模型和 10 个核心算子。测试结果自动归档并与上周对比。性能回归或精度回归要立即引起注意。这个机制运行一段时间后它的价值会远超你的预期。9.3 与开源社区的协作模式如果团队有足够能力建议和开源社区建立协作关系。比如用 TVM 时把新的硬件后端回馈到上游这样后续新版框架更新时你这些自动降级逻辑还能平滑兼容。但是回馈代码也要谨慎不要因为开源版本更新而打乱内部稳定版本节奏。我的建议是两个分支内部基线分支和上游协作分支定期同步不做大重构。10. 一些我个人的实操体会10.1 踩过的坑和教训这部分我想写点实话都是项目里实际遇到的不是从教科书里看的。最大的坑是“过早性能优化”。软硬件协同设计阶段很容易陷入对计算单元数量的过度优化把编译器还没验证的调度方案当作既定事实。结果是花大量时间调整硬件微架构最后编译器实现后发现调度方式完全不同架构只能推倒重来。我现在会先让编译器团队快速实现一个最简单的可用后端哪怕性能只有目标的 30%先把端到端跑通再逐层优化。跑通全链路比单点性能重要得多。第二个坑是“低估了数据搬运的作用”。很多第一次做 NPU 的同事会把算力当作唯一指标直到调试才发现DDR 带宽和片上缓冲容量才是真正的性能天花板。如果你设计的计算阵列理论峰值很高但片外带宽不足实际有效算力可能只有峰值的五分之一。任何一个 AI 芯片架构决策都应当把“数据搬运”和“计算”放在同一张表格里评估。第三个坑是“版本管理混乱”。这不是单一工具层面的问题而是流程问题。尤其当 FPGA 原型和 RTL 仿真各自的软件栈不一致时问题会爆炸式增长。后来我们规定每次 tap-out 或原型发布时必须配套一个可重复构建的软件 SDK 版本该版本能通过完整测试集。这听起来麻烦但为调试省下的时间是十倍以上。10.2 一点建议复现我的最小示例如果你是完全的新手我建议你今天就用 Python 把 4x4 矩阵乘跑的仿真器跑通然后试着改几个参数比如把矩阵改成 8x8或者增加一条ACC_CLEAR指令。你也可以尝试在仿真器里统计周期数看看不同的 DMA 调度对运行时间的影响。一旦你能通过寄存器配置和指令下发控制硬件仿真器你对“软硬件协同”这个概念的理解就会完全不同。最后想说的是AI 芯片这块领域看起来高深但拆开看无非是“如何把大量计算安全、高效、可控地组织起来”。软硬件协同设计扮演的正是让这一切成立的黏合剂。无论你是从硬件进入还是从软件进入只要把握住接口、数据流、性能模型、验证体系这几根主线方向就不会走偏。