168、NPU的编译器开发：异常处理与错误恢复

嵌入式NPU原理基础：从零开始理解神经网络处理器

第168章 NPU的编译器开发：异常处理与错误恢复

从一次凌晨三点的崩溃说起

凌晨三点，我盯着屏幕上那行冰冷的错误码发呆：

NPU_ERR: IRQ_HANDLER_TIMEOUT at tile[2], core[3], cycle[4523891]

这是某款车规级NPU芯片的现场。客户反馈说，在连续运行12小时后，模型推理突然“卡死”——没有输出，没有中断，只有一颗冷冰冰的芯片在散热片上烤着。更诡异的是，同样的模型在仿真环境里跑了三天三夜都没事。

后来定位到原因：NPU编译器在生成指令序列时，对某个特定形状的卷积层做了激进的流水线优化，导致在硬件资源紧张时，DMA传输和计算单元之间产生了死锁。而编译器生成的异常处理代码，恰好没有覆盖这种边界情况。

从那天起，我意识到：NPU编译器开发中，异常处理不是“锦上添花”，而是“保命符”。今天这篇笔记，就聊聊这个容易被忽视但极其重要的领域。

异常分类：别把硬件错误当软件bug

NPU的异常，和CPU的异常有本质区别。CPU异常通常是“指令执行异常”（除零、缺页），而NPU异常更多是“资源调度异常”和“数据流异常”。我习惯把它们分成三类：

第一类：可恢复的运行时异常

• DMA传输超时（常见于带宽争抢）
• 计算单元流水线stall（比如某个tile