摘录自：HiSVP开发指南
NNIE介绍
NNIE 是 Neural Network Inference Engine 的简称，是海思媒体 SoC 中专门针对神经网络特别是深度学习卷积神经网络进行加速处理的硬件单元
开发流程
以 Caffe 框架上训练的模型为例，NNIE 的开发流程如图 3-1 所示。在 Caffe 上训练、
使用 NNIE 的 mapper 工具转化都是离线的。通过设置不同的模式，mapper 将
*.caffemodel 转化成在仿真器、仿真库或板端上可加载执行的数据指令文件。一般在开
发前期，用户可使用仿真器对训练出来的模型进行精度、性能、带宽进行初步评估， 符合用户预期后再使用仿真库进行完整功能的仿真，最后将程序移植到板端。
工具链介绍
- mapper，将caffe model转成wk文件
- 仿真库，在pc上仿真，模拟硬件执行，
- 调试工具，Ruyi Studio，集成了转换和仿真库
网络层的分类
- 标准层
- 拓展层：NNIE支持，但非caffe标准层
- Non-support层：NNIE不支持的层。比如 Caffe 中专用于 Tranning 的层、其他非
Caffe 框架中的一些层或者用户自定义的私有层等。
就是：caffe的标准层+一些层（具体看下面网络层例子）是NNIE支持的。
拓展层
原始Caffe中没有定义的层结构，为了使mapper能支持这些网络，需要对原始的Caffe进行拓展
解决方案
- 按照 3.1.4 节扩展 Caffe 的 caffe.proto 以及扩展层代码实现，并以此基础来进行训
练，对应部署的 deploy.prototxt 满足 mapper 要求。 - 使用开源的扩展 caffe 框架来训练（比如 rbgirshick/py-faster-rcnn 等），不需要扩展
caffe.proto 以及扩展层代码实现，但是需检查对应的扩展层规格是满足要求，且最
后输入给 mapper 的 deploy.prototxt 必须满足 3.1.4.3 中要求以便 nnie_mapper 识别。
具体细节
- 拓展Caffe proto文件
- 拓展层代码实现
- 拓展层在prototxt中的定义
网络层例子
- CReLU
- PassThrough
- DepthwiseConv
- RReLU
- MatMul
- Permute
- ROIPooling
- PSROIPooling
- Upsample
- Normallize
Non-support层处理方式
拓展层和Non-support层之间的区别是？？？
当网络中存在 Non-support 层时，需要将网络进行切分，不支持的部分由用户使用 CPU
或者 DSP 等方式实现，统称为非 NNIE 方式。由此整个网络会出现 NNIE->非 NNIE-
NNIE… 的分段执行方式。
其他特性
- 支持任意中间层上报：除了网络的输出层，用户若还关心网络的某个中间层输出
时可指定该层上报输出，中间层输出不影响后续隐藏层继续运算； - 支持任意层高精度（16bit）计算模式：某些网络层对精度要求高时可以指定这些
层为高精度模式，但是注意高精度模式的计算能力会比低精度要弱； - 支持任意切分：用户有自定义私有层或者 NNIE 不支持的层时，需要对网络进行
切分，同时也支持用户对支持的层进行切分，但是建议用户尽量减少分段段数，
减少硬件执行过程中的软件交互开销，以期获得更高的性能； - 支持 binary/ternary/sparse 参数的高压缩比定制压缩，用户提供的参数只有三种值
且正负对称时，mapper 会自动进入 Ternary 模式；用户提供的参数只有两种值且
包含 0 时，mapper 会自动进入 Binary 模式；用户提供的参数稀疏比在 80%以上时
自动进入 sparse 模式；这三种模式相对 normal 模式能提供更高的压缩比，以达到
更高的带宽提升； - 硬件预处理支持 YUV 转换成 RGB：从海思媒体 SOC 的其他模块中，比如 VI、
VPSS、VGS（参考《HiMPP V4.0 媒体处理软件开发参考》）等模块中获取的均是
YUV 数据，而用户训练网络模型使用的一般是 RGB 数据。NNIE 硬件支持 YUV
输入转到 RGB，因此用户在实际使用场景中可以把 YUV 转为 RGB 交给 NNIE 硬
件实现； - 支持高效模式完成 in-place 激活运算：类似 Conv+ReLu 计算，使用 3.6 章节中的
in-place 描述方案，硬件执行效率更高； - 支持多输入、多输出：支持多输入、多输出（包含任意上报的输出）的网络配
置； - 支持网络结构的自动优化：例如同轴 Concat 级联时将被优化成一层以提升处理效
率； - 支持自动识别片上 Cache 以提升处理性能：数据在隐藏层内传递时，如果数据足
够小，可以完整的存入片内 RAM，mapper 将实现片上数据传递以提升处理性
能；
提高硬件资源利用率建议
-
总体原则：
− 一般情况下，相同计算量场景，尽量增加单层的计算量，减少网络层数，以减
少层之间切换造成的利用率损失，提高端到端的利用率。
− 尽量使用卷积、反卷积、Pooling、FC 层，提高硬件资源利用率，减少 LRN、
MVN、Normalize、Softmax 层的使用。
− 建议使用 RELU、Sigmod、Tanh、PRELU、RRELU 激活函数并使用 in-place 的
的配置方式（与前一层共享 blob），以便硬件高效完成计算； -
特别地针对卷积、反卷积、Pooling、DepthwiseConv 层运算：
− 输出特征数据尺寸在 16*16 时，读参数的 DDR 带宽与卷积计算基本匹配；特
征数据尺寸更小时，计算单元受限于 DDR 带宽会无法全部利用。
− 硬件进行卷积计算时，数据按 16 组并行计算，输入的 C 维度是 16 倍数，输出
的维度 C 是 4 的倍数，输出的 W 维度是 16 的倍数时，可以充分利用 MAC 的
计算性能
Prototxt要求
- 学习Caffe框架
Linux 版 NNIE mapper 安装
mapper是做模型转换的，将caffe model转换成NNIE硬件能识别的wk文件
仿真库使用说明
NNIE PC 端仿真库分为功能仿真(nniefc*.lib)、指令仿真(nnieit*.lib)和性能仿真：
- 功能仿真仅从功能一致性的角度去模拟硬件，有 CUDA 加速功能，速度较快；
- 指令仿真从指令一致性的角度去模拟硬件，速度较慢；
- 性能仿真输出各层的带宽、cycle 数仿真结果；性能仿真默认配置下跟指令仿一并
执行。
功能仿真、指令仿真、硬件三者的结果保持完全一致。
功能仿真 CUDA 加速配置
NNIE问题解决
reference
- HiSVP 开发指南