AI芯片这几年热度一直居高不下从云端训练卡到手机里的NPU再到各种边缘计算盒子几乎每一家做芯片的公司都在抢这个赛道。但真正做过芯片研发的人都知道流片一次动辄几百万甚至上千万周期还长谁也不敢拍脑袋就把设计送去制造。所以建模与仿真就成了整个流程里最省钱、也最关键的环节——你可以在软件里把架构跑通、把性能瓶颈摸清楚、把软硬件接口对齐等确认没问题了再去考虑RTL和后端的事。这篇内容我想结合自己折腾NPU和AI加速器建模的经历聊聊怎么用gem5、SystemC这类工具搭一套能用的仿真环境以及联合仿真里那些文档不会写的坑。适合正在做AI芯片架构探索的工程师、想入门NPU设计的学生还有需要评估加速器性能的算法同学参考。1. 为什么AI芯片离不开建模与仿真1.1 流片成本倒逼的必然选择先算一笔账。一颗7nm的AI芯片光掩膜版费用就在千万美元级别加上IP授权、EDA工具、人力一次流片的总投入轻松过亿。如果架构设计有缺陷比如片上缓存带宽不够导致MAC阵列利用率只有30%那这颗芯片基本就废了。你不可能像写软件那样先上线再修bug硬件改一版的代价是重新走一遍完整流程时间成本至少半年起。建模与仿真解决的正是这个问题。它在RTL之前就建立一个可执行的性能模型让你能快速迭代架构参数MAC阵列是16x16还是32x32片上SRAM是分bank还是统一编址HBM的带宽给多少才不浪费这些决策如果靠拍脑袋风险极高靠仿真数据来支撑心里就有底了。我个人的经验是一个中等复杂度的NPU架构探索阶段至少要跑上百组配置的仿真才能收敛到一个相对合理的方案。这个阶段用高层模型比如SystemC的TLM比直接用RTL快几十倍甚至上百倍一天能跑完的配置组合用RTL可能要跑一个月。1.2 软硬件协同的刚需AI芯片和传统CPU最大的不同在于它的价值高度依赖软件栈。一个NPU算力再强如果编译器映射效率低、算子覆盖不全实际跑出来的性能可能只有峰值的20%。所以建模不能只建硬件还要把软件的行为也纳入进来。这就引出了软硬件联合仿真的概念。硬件侧用gem5或SystemC建模型软件侧跑真实的算子库或框架比如PyTorch导出的计算图两边通过接口对接。这样你不仅能看到硬件周期数还能看到具体哪个算子成了瓶颈、数据搬运占了多少时间。昇腾NPU的生态里就有类似的思路用仿真来验证算子在不同硬件配置下的表现。1.3 不同抽象层级的取舍建模不是越精细越好关键看你的目标。我一般把AI芯片的建模分成三个层级抽象层级典型工具建模速度精度适用阶段事务级TLMSystemC快中架构探索、参数扫描周期级CAgem5、SystemC-CA中高性能验证、瓶颈定位RTL级Verilog/VHDL慢最高功能验证、时序收敛架构探索阶段用TLM就够了你关心的是带宽、延迟、吞吐的大致关系不需要精确到每个时钟沿。等到架构基本定型再用gem5做周期级仿真把关键路径的时序抠清楚。RTL仿真一般只在最后验证阶段用因为太慢了跑一个完整的神经网络推理可能要几个小时甚至几天。提示不要一上来就追求最高精度。我见过不少团队在架构还没定型的时候就去抠RTL时序结果架构一改之前的工作全白费。先粗后细逐步收敛才是正确的节奏。2. 核心工具链选型与搭配逻辑2.1 gem5周期级仿真的主力gem5是目前学术界和工业界用得最多的周期级仿真器之一它支持多种CPU模型Atomic、Timing、O3、多种内存模型还能通过Ruby系统模拟缓存一致性协议。对于AI芯片建模gem5最大的价值在于它能给你精确的周期数和访存行为。不过gem5原生是面向CPU的要用来建NPU模型需要做不少定制。常见的做法是写一个自定义的SimObject把MAC阵列、片上缓存、DMA引擎都建模进去。gem5的Python配置脚本很灵活你可以通过参数快速切换不同的硬件配置。# gem5中定义一个简单的NPU加速器SimObject示例 from m5.params import * from m5.SimObject import SimObject class NPUAccelerator(SimObject): type NPUAccelerator cxx_header npu/accelerator.hh cxx_class gem5::NPUAccelerator # MAC阵列维度 array_width Param.Int(16, MAC array width) array_height Param.Int(16, MAC array height) # 片上缓存大小 sram_size Param.MemorySize(256kB, On-chip SRAM size) # 工作频率 clock Param.Clock(1GHz, Accelerator clock)这段代码定义了一个基本的NPU加速器参数框架。实际建模时你还需要在C侧实现recvTimingReq等接口处理来自CPU或DMA的请求。gem5的学习曲线比较陡但一旦跑通后续的配置扫描会非常方便。2.2 SystemC事务级建模的首选SystemC基于C天生适合做事务级建模。它的TLM-2.0接口标准让模块之间的通信变得很规范你可以把NPU拆成几个大模块指令调度器、数据搬运引擎、计算阵列、结果写回单元每个模块用b_transport或nb_transport接口通信。SystemC的优势在于仿真速度快和与软件栈的对接方便。因为本身就是C你可以直接把算子库编译进来在仿真过程中调用真实的计算函数。我做过一个项目用SystemC建了一个NPU的TLM模型同时把PyTorch的计算图通过ONNX导出后解析成指令流整个推理过程的仿真在几秒钟内就能跑完非常适合做设计空间的快速探索。// SystemC TLM中一个简单的计算模块示例 SC_MODULE(ComputeArray) { tlm_utils::simple_target_socketComputeArray socket; SC_CTOR(ComputeArray) : socket(socket) { socket.register_b_transport(this, ComputeArray::b_transport); } virtual void b_transport(tlm::tlm_generic_payload trans, sc_time delay) { // 解析事务执行MAC计算 // 根据数据量计算延迟 unsigned int data_len trans.get_data_length(); delay sc_time(data_len / 16, SC_NS); // 简化延迟模型 trans.set_response_status(tlm::TLM_OK_RESPONSE); } };这个例子展示了最基本的TLM建模方式。实际项目中你需要更精细地建模数据复用、流水线停顿、bank冲突等细节否则仿真结果会过于乐观。2.3 联合仿真的接口设计联合仿真的核心难点在于接口对齐。硬件模型和软件栈之间的数据格式、时序语义、同步机制都要约定清楚。常见的做法是定义一个中间层比如用共享内存或socket通信把软件侧的算子调用翻译成硬件侧的事务。我踩过的一个坑是软件侧假设数据是连续存放的硬件侧却按分块方式读取结果仿真出来的带宽利用率完全不对。后来我们在中间层加了一个地址映射模块把软件的逻辑地址转换成硬件的物理地址问题才解决。这个经验告诉我接口设计要尽早做而且要做得足够细不能等到两边都建好了再去对接。3. NPU建模的关键细节与实操要点3.1 MAC阵列的建模精度MAC阵列是NPU的核心建模时最容易犯的错误是把它当成一个理想的计算单元忽略了数据供给的限制。实际上MAC阵列的利用率高度依赖于数据复用策略和片上缓存的带宽。我一般会这样建模先确定阵列的维度比如16x16256个MAC然后计算每个周期需要从缓存读取多少数据。如果采用权重固定weight stationary的数据流权重可以常驻在寄存器里只需要读激活值如果采用输出固定output stationary则每个周期都要读权重和激活值。不同的数据流对带宽的需求差异很大。举个例子16x16的阵列如果每个MAC每个周期需要2个操作数一个权重、一个激活那么峰值带宽需求是256x2x4字节2KB/周期。在1GHz频率下就是2TB/s的片上带宽。这个数字非常夸张实际芯片根本做不到所以必须通过数据复用来降低带宽需求。仿真的时候如果你不建模这个约束算出来的性能会严重偏离实际。3.2 片上缓存的bank划分与冲突NPU的片上缓存通常会被划分成多个bank以支持并行访问。但bank划分不当会导致冲突反而降低有效带宽。建模时需要模拟bank的访问冲突。假设你有32个bank每个bank位宽是128字节工作频率1GHz。理论峰值带宽是32x128x1G4TB/s。但如果连续访问的地址都落在同一个bank上实际带宽就只有128GB/s差了32倍。所以在仿真中你需要根据访问地址计算bank索引统计冲突次数进而得到有效带宽。// 简化的bank冲突统计模型 int get_bank_id(uint64_t addr, int num_banks, int bank_width) { return (addr / bank_width) % num_banks; } // 在每次访问时记录bank使用情况 void access_memory(uint64_t addr) { int bank get_bank_id(addr, 32, 128); if (bank_busy[bank]) { bank_conflict_count; // 需要等待 } bank_busy[bank] true; }这个模型虽然简化但足以在架构探索阶段给出有意义的指导。实测下来加上bank冲突建模后仿真出的有效带宽比理想模型低了40%左右更接近真实芯片的表现。3.3 DMA引擎与数据搬运开销AI芯片的性能瓶颈往往不在计算而在数据搬运。一个典型的卷积层计算量可能是几百万次MAC但数据搬运量可能达到几MB。如果DMA引擎效率不高计算阵列就会经常饿着。建模DMA时我关注三个参数启动延迟、持续带宽、并发通道数。启动延迟是指DMA从收到指令到开始传输数据的时间通常在几十到几百个周期持续带宽取决于内存接口的位宽和频率并发通道数决定了能否同时搬运多块数据。在gem5里你可以用MemObject的子类来实现DMA模型通过recvFunctional或recvTimingReq接口接收请求然后根据数据量和带宽参数计算完成时间。我一般会把DMA的启动延迟设成50个周期持续带宽按内存控制器的80%来估算这样比较接近实际。注意DMA的建模精度对整体性能影响很大。我见过一个案例DMA启动延迟从50周期改成100周期后整个网络的推理时间增加了15%。所以这个参数不能随便拍最好有实测数据支撑。3.4 指令调度与流水线建模NPU通常有自己的指令集用来控制DMA、计算阵列、缓存等模块。指令调度器的建模决定了各模块能否并行工作。如果调度器设计得不好计算和搬运无法重叠性能就会大打折扣。我一般会建一个简单的流水线模型取指、译码、发射、执行、写回。每个阶段占用的周期数根据指令类型不同而不同。比如DMA指令的发射可能只需要1个周期但执行要等数据搬完MAC指令的发射需要检查操作数是否就绪如果没就绪就要插入气泡。在SystemC里可以用SC_THREAD或SC_METHOD来模拟流水线行为。关键是维护好各模块的状态和依赖关系确保仿真结果能反映真实的并行度。4. 联合仿真的完整实操流程4.1 环境搭建与依赖管理联合仿真的环境搭建是个体力活尤其是涉及多个工具的时候。我一般会用一个统一的Docker镜像来管理依赖避免不同工具之间的库版本冲突。以gem5SystemC的联合仿真为例你需要安装gem5的依赖sudo apt install build-essential scons python3-dev libprotobuf-dev protobuf-compiler libgoogle-perftools-dev编译gem5scons build/X86/gem5.opt -j$(nproc)安装SystemC下载SystemC 2.3.3源码./configure make sudo make install设置环境变量export SYSTEMC_HOME/usr/local/systemc-2.3.3和export LD_LIBRARY_PATH$SYSTEMC_HOME/lib-linux64:$LD_LIBRARY_PATH编译gem5的时候有个坑如果你要用Ruby内存模型需要额外安装libboost-all-dev和libcapstone-dev。另外gem5的编译很吃内存建议至少16GB否则链接阶段容易OOM。4.2 软件侧的计算图导出与解析软件侧我通常用PyTorch训练好模型后通过ONNX导出计算图然后用ONNX Runtime或自定义的解析器把图拆成算子序列。每个算子对应一组硬件指令比如卷积对应DMA加载MAC计算DMA写回。import torch import torch.onnx # 导出一个简单的卷积模型 class SimpleConv(torch.nn.Module): def __init__(self): super().__init__() self.conv torch.nn.Conv2d(3, 16, 3, padding1) self.relu torch.nn.ReLU() def forward(self, x): return self.relu(self.conv(x)) model SimpleConv() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export(model, dummy_input, simple_conv.onnx, input_names[input], output_names[output])导出ONNX后你需要一个解析器把图节点转换成硬件指令。这个解析器可以用Python写也可以用C写。我一般用Python写原型验证逻辑没问题后再移植到C里和SystemC模型对接。4.3 硬件侧的事务生成与注入硬件侧需要接收软件侧发来的指令生成对应的事务注入到仿真模型中。在SystemC里你可以用一个SC_THREAD来模拟指令队列从队列里取指令解析后调用相应的TLM接口。void instruction_thread() { while (true) { Instruction inst inst_queue.pop(); if (inst.type DMA_LOAD) { tlm::tlm_generic_payload trans; trans.set_command(tlm::TLM_READ_COMMAND); trans.set_address(inst.src_addr); trans.set_data_length(inst.size); sc_time delay SC_ZERO_TIME; dma_socket-b_transport(trans, delay); wait(delay); } else if (inst.type MAC_COMPUTE) { // 触发计算阵列 compute_event.notify(inst.latency, SC_NS); wait(inst.latency, SC_NS); } } }这段代码展示了指令线程的基本结构。实际项目中你需要处理指令之间的依赖关系比如MAC计算必须等DMA加载完成才能开始。这可以通过sc_event或sc_fifo来实现。4.4 仿真结果的对齐与验证联合仿真跑通后最重要的一步是结果对齐。你需要确认仿真出来的性能数据是否合理和理论分析或实测数据是否吻合。我一般会做三层验证功能验证仿真输出的结果和PyTorch的参考结果对比确保数值正确。性能验证仿真得到的周期数和理论计算对比偏差在合理范围内通常20%以内。瓶颈验证通过仿真找到的瓶颈和实际芯片的profiling数据对比确认方向一致。如果发现偏差过大就要回头检查模型参数。常见的偏差来源包括缓存命中率估计不准、DMA带宽设置过高、流水线气泡统计遗漏等。5. 常见问题与排查技巧实录5.1 仿真速度太慢怎么办这是最常被问到的问题。gem5跑一个完整的神经网络推理如果配置不当可能要跑好几天。我的经验是降低仿真精度架构探索阶段用Atomic CPU或简单的Timing CPU不要用O3。缩小问题规模先用小尺寸的输入比如32x32而不是224x224跑通流程再逐步放大。并行化gem5支持多线程仿真可以通过--num-threads参数开启。使用检查点gem5的checkpoint功能可以保存仿真状态避免每次从头开始。实测下来一个ResNet-18的推理用Timing CPU简化内存模型大概能在2小时内跑完。如果用O3 CPU时间会翻好几倍。5.2 联合仿真接口对不上这个问题我遇到过好几次典型表现是软件侧发来的事务硬件侧解析不了或者数据长度对不上。排查思路问题现象可能原因解决方法事务地址越界地址映射不一致检查软件侧的逻辑地址和硬件侧的物理地址映射数据长度不匹配数据类型或对齐方式不同统一数据格式确认字节序和对齐要求仿真卡死同步机制有问题检查event通知和wait的配对避免死锁结果错误计算逻辑不一致对比软件参考实现逐步缩小范围我一般会在接口层加日志把每个事务的地址、长度、命令都打印出来两边对比。虽然日志量大但定位问题很快。5.3 NPU部署环境中的torch_npu报错做昇腾NPU相关工作时经常会遇到NPU is selected as device, but torch_npu is not available这类报错。这个问题的根源通常是环境变量没设置对或者torch和torch_npu版本不匹配。解决步骤确认CANN工具包已正确安装source /usr/local/Ascend/ascend-toolkit/set_env.sh检查torch和torch_npu版本对应关系比如torch 2.1.0对应torch_npu 2.1.0用python -c import torch_npu; print(torch_npu.__version__)验证导入是否成功如果还是报错检查ASCEND_HOME_PATH环境变量是否指向正确的CANN路径这个坑我踩过不止一次后来养成了一个习惯每次新建环境后先跑一个最小的NPU测试用例确认环境没问题再开始正式工作。5.4 仿真结果和实测差距大仿真和实测有差距是正常的但如果差距超过50%就说明模型有问题。常见的偏差来源缓存模型过于理想假设100%命中率实际可能只有70%带宽估计过高忽略了bank冲突和刷新开销流水线气泡遗漏没有建模指令依赖导致的停顿频率和电压假设不符仿真用1GHz实际降频到800MHz我的做法是先用实测数据反推模型参数比如从实测带宽反推有效带宽系数从实测延迟反推启动开销。然后用这些校准过的参数去跑仿真结果会靠谱很多。5.5 多工具联合仿真的版本兼容SystemC、gem5、ONNX Runtime这些工具各有各的版本要求混在一起用很容易出问题。我的建议是用Docker固定版本不要用latest标签记录每个工具的版本号写在项目的README里升级某个工具前先在独立环境里验证兼容性尽量用长期支持版本LTS避免用刚发布的新版本有一次我升级了SystemC到2.3.4结果gem5的TLM接口编译不过折腾了一天才发现是API变了。从那以后我就坚持用Docker镜像锁定版本省了很多事。6. 从仿真到落地的经验总结6.1 模型校准比模型精度更重要很多人花大量时间追求模型的精细度却忽略了校准。一个经过校准的简单模型往往比一个未校准的复杂模型更准。我一般会先用理论公式算一个基线然后用实测数据校准关键参数最后再逐步增加模型细节。比如DMA带宽理论值是内存控制器的峰值带宽但实际有效带宽可能只有60%-70%。你把这个系数校准好了仿真结果的可信度就上来了。6.2 仿真不是目的决策才是仿真的价值在于支撑决策而不是产出漂亮的报告。每次跑仿真前我都会问自己这次仿真要回答什么问题是选16x16还是32x32的阵列是加一级缓存还是直接上HBM问题越具体仿真的设计就越有针对性。我见过一些团队仿真跑了很多数据攒了一堆但到了要做决策的时候还是拍脑袋。这就是典型的为了仿真而仿真浪费了大量时间。6.3 软硬件团队要尽早坐在一起AI芯片的建模与仿真从来不是硬件团队一个人的事。软件团队需要知道硬件的约束硬件团队需要知道软件的需求。如果两边各做各的最后对接的时候一定出问题。我的经验是在架构定义阶段就让软件团队参与进来一起确定指令集、数据格式、接口协议。这样后面做联合仿真的时候会顺畅很多。6.4 持续迭代小步快跑建模与仿真不是一次性的工作而是贯穿整个芯片研发周期的。架构阶段用TLMRTL阶段用周期级模型流片后还要用仿真做回归测试。每个阶段的模型精度和关注点都不同需要持续迭代。我一般会维护一个模型版本库每次架构调整都对应一个模型版本记录变更内容和仿真结果。这样回溯起来很方便也能看到架构演进的脉络。最后分享一个我个人的小技巧在跑大规模仿真之前先用一个极小的测试用例比如一个3x3的卷积把整个流程跑通确认软件侧、接口层、硬件侧都没问题再放大规模。这样能省下大量调试时间也能避免因为一个小bug导致几天的大规模仿真白跑。这个习惯我坚持了好几年实测下来至少帮我省了几百个小时的无效仿真时间。
