HLS系列 – High Level Synthesis(HLS) 从一个最简单的fir滤波器开始4

在这个系列的前3篇文章“HighLevel Synthesis(HLS) 从一个最简单的fir滤波器开始1-3”中，我们从一个最简单的FIR滤波器，一步步优化，得到了一个比较理想的HLS综合结果，资源消耗很少。我们先回顾下：

我们做过的优化主要有：
在头文件定义中，把数据和系数的精度都改成了整形，用18bit来表示；
在fir.c的for loop里面，修改代码结构，只显性的出现一处乘法描述；
通过这2处改进，我们成功把DSP48E的消耗数量，从最开始的8个，降低到了1个。最新的资源消耗如下：

在这一章，让我们从别的角度，继续改进这个fir滤波器的性能。
仅从上述资源报告中DSP48E的消耗个数，我们就可以大致判断出来，fir滤波器其rtl的实现方式，大致采用的是串行的处理方式。这种结构虽然资源消耗较少，但是处理时间和延迟却比较长，这也可以从HLS的性能分析报告中得到印证：

从上面的报告中可以看出，其处理延迟Latency为33=2*16+1（一共16个循环，每个循环消耗2个clock cycle，所以一共是32个cycle，最后再+1表示最终输出的时候还要再寄存一拍，所以总的延迟latency是33个clock cycle）。其处理的流程大致如下：

这个Latency=33的延迟有些偏大的，有没有改进空间呢？其实是有的，让我们还是回到代码中，这里会给我们一些提示：

代码中每个循环里面，需要做4件事情：
第一个是读操作 read shift_reg[i-1]；
第二个是写操作 write shift_ref[i]；
第三个是乘操作；
第四个是加法操作；
熟悉rtl代码和硬件电路的童鞋应该可以分析，其实这3步操作，有可能可以包在一个大的组合逻辑电路里面，在1个时钟周期里面完成！也就意味着，其处理数据流可以变成下面这个样子，即每个for循环只需要消耗1个clock cycle即可：

那么如何才能实现上面的处理结构呢？
调整fir.c代码本身的结构，无法给HLS编译器传递这样的信息，此时只能通过特定的语法约束，在tcl脚本里面告诉HLS编译器，我需要把每个for循环的latency压缩，从2个clock cycle/per for loop压缩为1个clock cycle/perfor loop。此时我们会用到一个HLS PIPELINE II的约束，具体设置方法如下：

设置好后，我们点击综合按钮，很快综合结果就出来了，我们看下performance报告：

为什么latency仍然很大呢，不仅没有缩小，反而还从33变成了34，是我们约束设置的不多吗？不是的，我们约束设置的没有问题。从标红的地方可以看出来，我们的确告诉了HLS工具，把每个for loop的处理时间减小为1个clock cycle（target=1），只是HLS没有实现我们的设定目标，综合结果是2（achieved=2）。为什么HLS无法达成我们的设定目标呢，虽然从理论上分析它应该是可以的，一定有什么东西阻碍了这个优化过程。

这里留给读者思考3分钟……

接下来给出答案，其实问题出在shift_reg上，是它限制了latency的优化：

在综合资源报告里面，我们可以看到有一块用LUT实现的RAM（所谓的distributedRAM），它其实对应的c代码原型是shift_reg。而在for loop里面的这行代码里面：shift_reg[i]=shift_reg[i-1]; 我们分别对这块RAM先进行了一次读操作：readshift_reg[i-1]，然后又进行了一次写操作：write shirft_reg[i]，最重要的是写操作的值是前面读出的数据，这意味着读写操作之间有强相关性，所以没有办法Pipeline起来。因此，即使我们设置了约束让latency=1，工具也没有办法实现。

那么解决办法也很直接，我们把shirft_reg打散即可，用registers来构造shirft_reg数组：

重新综合后，我们可以看到performance报告，latency已经缩小了约50%，和我们预想的一致：

最后再让我们看下资源报告，Memory这项已经消失：