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

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

我们做过的优化主要有：
在头文件定义中，把数据和系数的精度都改成了整形，用18bit来表示；
在fir.c的for loop里面，修改代码结构，只显性的出现一处乘法描述；
把fir.c中的shift_reg，在HLS中约束只用reg来实现
约束Shift_accum_Lopp的Pipeline属性II=1
通过这4处改进，我们成滤波器资源消耗，和Latency数据如下：

在这一章，让我们再尝试从另外一个角度，继续改进这个fir滤波器。

从上述资源报告中DSP48E的消耗个数，以及Latency，我们知道现在的滤波器采用的是串行的处理方式。这和我们在数字信号处理课程中，常见的FIR滤波器结构是不太一样的。有经验的读者，肯定会回忆起，我们在课本里常见的滤波器长得大概是下面这个样子：

这是一种并行的处理结构。一个11阶的滤波器，就需要消耗11个乘法器，和多个加法器。所有的这些运算都可以并行的执行，并在一个周期内完成。这样的处理在速度上当然是最好的，虽然它意味着消耗更多的资源。那么我们如何才能综合处上述结构的滤波器呢？

HLS提供了一条专门的约束语法，HLSUNROLL，用以约束loop循环展开，也就是并行执行。下面我们来试试这条约束，添加完成后如下所示：

那我们综合一下，看看结果如何：

我们可以看到，把for loop展开后，总的latency确实减小了很多，从上篇文章中的18减小到了9。而且DSP消耗也从1个变成了8个。

效果还不错！但是请稍等等，这个是最好的结果了吗？稍微留一下，我们会发现1个问题
如果是全部展开的操作模式，那么理论上，所有的这些计算应该在1个clock cycle之内就可以完成，而现在却消耗了9个clock cycle；
那么是什么地方的限制，导致了无法达到我们理想的目标呢？

问题出在接口的优化上。在下图中，我们可以看到，fir函数的系数参数C被映射成了一个双端口RAM，这意味着我每个时钟周期仅能取2个系数进行运算，总共16个系数一共需要8个时钟周期才能提取完毕。看来就是不恰当的C端口，影响了我们HLS工具的进一步优化。

明确问题后，解决办法也很简单。我们可以通过约束，设置把C[N]端口完全打散，让它在rtl顶层，变成一组信号输入，这样就可以做到1个时钟周期把所有的系数都提取进来进行运算。操作方式非常类似于之前的把shirft_reg打散的步骤：

经过这个优化后，我们再来看下资源和Latency，效果很不错：

接口上也有很大的变化：

至此，这个fir滤波器的优化工作基本可以告一段落了。我们通过修改代码，添加HLS约束等手段，成功实现了一个不论是效率，还是资源使用，都比较合理的fir滤波器。