FPGA 17最佳论文导读 ESE: Efficient Speech Recognition Engine with Compressed LSTM on FPGA

欢迎转载，转载请注明：本文出自Bin的专栏blog.csdn.net/xbinworld。
技术交流QQ群：433250724，欢迎对算法、机器学习技术感兴趣的同窗加入。

---

后面陆续写一些关于神经网络加速芯片设计的paper，前面已经写了ISSCC2017，固然，由于只有利用不加班的下班时间来看和写，可能周期会比较长…不过呢，多学习一些老是好的。最近有点忙，没有保持写的节奏，后面加油吧!）。下一篇会开始写ISCA 2017的论文。

---

做者与单位：

国内知名的深鉴科技的几位初创写的一篇，拿了今年FPGA会议的best paper，今天来看一看到底有些什么内容。文章围绕在FPGA下设计LSTM执行引擎，主要考虑的点是稀疏的计算架构。说实话，稀疏计算已经说的快熟（lan）了，关键仍是这样的架构要在牺牲通用性下，获得足够强劲的收益；在一些专用的计算场景下，确实能够作到很好的效果，但也并非一个免费的午饭。

背景介绍

先介绍一下语音识别和LSTM的简单背景。本文关注的应用场景是语音识别，当前一个基本的语音识别模型的流程是：

其中，如今很是经常使用的用于建模声学模型的是LSTM网络模型，它用于获得acoustic output probabilities（音节的输出几率），并且颇有可能会占据整个系统中的90%以上的执行时间。因此做者认为要加速LSTM计算。

LSTM的结构以下图所示：

一个LSTM层里面，其实是对一个序列x_1 … x_T的递归计算，其中最重要的是有i，f，o三个门控单元，分别叫作input，forget，output gate；一种比较流行的计算模式以下公式所示，也就是Figure 4所表明的含义。更详细的介绍本篇不写了，若是读者有兴趣能够看下[1]，我后面也打算在深度学习系列中写一篇RNN/LSRM的博文。

模型压缩

主要是Pruning和Conpression几步，具体下面会讲。

1. 剪枝pruning与负载均衡Load Balance
   基本的剪枝方法和Deep Compression [2]方法是一致的——将最小数值的Weight稀疏掉，而后再用retraining的方法保持原来的模型精度；retraining的时候胡保持已经被稀疏掉的参数不更新（一直是0）。可是做者提出，若是只是这样简单的稀疏，会有严重的负载不均衡现象，尤为是在硬件计算中，若是须要一个批次的计算所有完成，就会由于非零参数严重不均匀，出现快的计算单元等待慢的计算单元执行的状况，形成性能的浪费。

方法很简单，就是将分组了的参数按照一致的比例去稀疏，而不是原来那样全局稀疏；并经过retraining把损失的精度补回来。这样就作到了负载均衡的稀疏参数了。

1. 量化Quantizaiton
   参数和数据最低能够作到12bit量化；参数和数据的动态区间不一样：
   
   

2. 编码Encoding
   属于CSC的编码，由于DDR位宽是512bit，因此须要512b对齐，PCIE接口位宽是128bit，因此有128bit对齐的要求。一个weight包含了12bit数据自己+4bit offset，offset表示距离上一个非0值的中间有几个0；

下面这张图是想表示在本文的设计中，一个input data读一次会被计算屡次（吐槽一下，做者在画图以及后面文字解释的时候对于column的使用很是随意，有的时候是图上的一行，有的时候又是一列，看起来很费劲。FPGA会议的最佳论文…建议再严谨易读一点比较好。固然，也有多是我没理解…）

下面是整个系统的架构图，能够看到，有多个channel，每一个channel独立计算一个voice vector；在一个channel内部，见右图，有不少个PE，每一个PE独立占有一个数据FIFO，而PE的数据来源都是共享的。大概的执行流程以下：参数会经过指针buffer和weight buffer先把参数连续存在片上RAM中，在解码中，由于知道了某个参数的位置index（经过offset，就能够知道它要和哪一个数据相乘），就把须要的数据按序取到FIFO中，在计算的时候就不须要管序号了，只要FIFO和weight buffer中取出来的数据对的上；临时sum结果存在act buffer中，而后每一次乘完后再由Accu累加器把以前的结果和当前结果累加起来；这里有一点，由于一个PE可能须要处理参数矩阵中的多列，因此我猜想act buffer是能够存多个临时结果的。另外剩下的部分就是向量点乘，而后是加法，激活函数这些，完成LSTM整个过程，就不说了。整个ESE有32个channel，每一个channel有32个PE。

这样看来，处理一个voice数据只有32个PE，也就是32个MAC，须要同时处理32个voice数据才能用满引擎。其实也折射了另一个问题，sparse计算架构，单个数据处理时很难把并行的PE数量作大（为何呢？由于目前看到的方案，在sparse计算中，要么就是用参数索引数据，要么用数据索引参数，索引取数据开销比较大；还有一个问题是，一个weight column能够作local reduction，以减小中间计算结果，可是data利用率低，要想data利用率高，中间计算结果就很大，这也是一个矛盾。），仍是须要批处理才能提升总的性能。若是有更好的sparse计算架构，但愿能够推荐给我学习。

OK，本篇就记录到此，后面会写一下今年ISCA的paper学习笔记。

参考资料

[1] http://www.jianshu.com/p/9dc9f41f0b29 [2] Deep Compression: Compressing Deep Neural Networks with Pruning, Trained Quantization and Huffman Coding [3] ESE: Efficient Speech Recognition Engine with Compressed LSTM on FPGA