090、NPU的NoC(片上网络):多核NPU的通信架构

📅 2026/6/18 13:52:49
090、NPU的NoC(片上网络):多核NPU的通信架构
NPU的NoC(片上网络):多核NPU的通信架构去年调一个8核NPU的AI推理任务,跑ResNet-50死活上不去吞吐量。单核跑得好好的,一开多核,延迟直接翻倍。用逻辑分析仪抓片上总线,发现四个NPU核在抢DDR带宽,另外四个核在等数据,整个系统像早高峰的十字路口——谁也别想快。后来把NoC拓扑从Mesh改成Ring,配合优先级仲裁,吞吐量直接拉回理论值的92%。那次之后我明白一件事:NPU的算力是核给的,但性能是NoC给的。为什么NPU需要NoC传统SoC用总线(如AXI)连接主从设备,一个master发请求,slave响应。这套机制在CPU场景下够用,因为CPU核少、数据量小、对延迟不敏感。但NPU不一样——一个NPU集群可能有8个、16个甚至32个计算核,每个核每秒要吞吐几百GB的激活值和权重数据。如果用共享总线,所有核挤在一条道上,仲裁器会成为瓶颈,带宽利用率直线下降。NoC(Network-on-Chip)本质上是在芯片内部建一个微型网络。每个计算核、存储控制器、DMA引擎都挂在一个“路由器”上,数据以包的形式在网络中路由。好处是:多个通信可以并行发生,不会互相阻塞;扩展性好,加核只需加路由节点;功耗可控,因为数据只在需要传输的路径上翻转。从一次死锁调试说起有次写NPU的DMA驱动,多核同时向共享SRAM写数据。代码逻辑很简单:每个核计算完一部分结果,通过DMA写到SRAM的指定偏移。结果跑起来就卡死,JTAG挂上去一看,四个DMA引擎全部挂在“等待写完成”状态,SRAM控制器那边显示写请求队列满了,但没有任何读请求。