042、NPU的硬件抽象层（HAL）：跨平台移植的关键

042 NPU的硬件抽象层（HAL）：跨平台移植的关键

一个让我熬夜三天的bug

去年做某款AIoT芯片的NPU驱动移植，遇到了一个诡异现象：同样的模型，在A平台推理结果完全正确，换到B平台，分类结果全乱套了。更邪门的是，B平台跑官方SDK的demo没问题，跑我们自己写的推理框架就崩。

查了三天，最后定位到问题：两个平台的NPU寄存器地址映射方式不同——A平台用内存映射IO（MMIO），B平台用独立IO空间。我们的驱动代码里，直接硬编码了寄存器地址偏移量，没有通过HAL层做抽象。结果B平台读到的寄存器值全是错的，NPU根本没正确配置。

从那以后，我写NPU驱动第一件事：先把HAL层搭好，哪怕后面只用一个平台。

HAL到底在抽象什么

NPU的硬件抽象层，说白了就是给上层驱动和推理框架一个“统一的接口”，把不同芯片的寄存器布局、中断机制、DMA方式、电源管理这些硬件细节全部藏起来。

别小看这件事。我见过太多团队，项目初期图省事，直接在驱动里写*(volatile uint32_t*)(0x1A000000 + offset) = value，结果换芯片时欲哭无泪。

HAL层至少要抽象这几类东西：

寄存器访问：MMIO vs IO端口 vs 通过Mailbox间接访问。有些NPU的配置寄存器甚至要通过SPI或I2C写进去。

内存管理：NPU内部SRAM、DDR中NPU专用区域、一致性内存（c