一个典型的流水线设计

流水线设计通常可以在一定程度上提升系统的时钟频率，因此常常作为时序性能优化的一种常用技巧。如果某个原本单个时钟周期完成的逻辑功能块可以进一步细分为若干个更小的步骤进行处理，而且整个数据处理过程是单向的，即没有反馈运算或者迭代运算，前一个步骤的输出是下一个步骤的输入，那么就可以考虑采用流水线设计的方法来提高工作的时钟频率。

如图3.23所示，典型的流水线设计是将原本一个时钟周期完成的较大的组合逻辑（上图）通过合理的分割后由多个时钟周期分别完成n个较小的组合逻辑（下图）。原本1个时钟周期完成的逻辑功能拆分为n个时钟周期以流水线方式实现，虽然该设计的时钟频率会有所提升，但是需要额外付出n-1个时钟周期的初始延时。

图3.23 流水线设计的寄存器模型

如图3.24所示，假设一个流水线设计需要四个步骤完成一个数据处理过程，那么从有数据输入（in1）的第1个时钟周期（1clk）开始，直到第4个时钟周期（4clk）才处理第1个输入数据；如果输出时再用寄存器打一拍，通常是第5个时钟周期才会输出第1个数据的处理结果；但在以后的每个时钟周期内都会有处理完成的数据持续输出。也就是说，流水线设计在提高工作的时钟频率的情况下，只在开始处理时需要一定的延时时间（和流水线级数正相关），以后就会不间断的输出数据，从而提高处理速度。如果该设计不采用流水线设计，那么该实例处理一个数据就需要4个时钟周期，而流水线设计则能够提高最多4倍的处理速度（取决于设计的整体性能水平，通常情况下是提升不了4倍的）。

图3.24 流水线设计实现

这里我们来看一个除法器IP核进行流水线优化的例子。如图3.25所示，在Xilinx提供的除法器IP核的配置页面中，有一个时延选项（Latency Options），这个时延其实就是我们刚刚提到的数据从输入到输出，经过内部的流水线处理逻辑，所需要的初始延时时钟周期数。可想而知，这个延时设置得越大，对应的流水线级数越高，可以达到的时序性能应该是会约好的；但这个延时值如果设置的较小，对应的流水线级数就越低，那么势必会影响它的时序性能。以笔者的经验，在一些算法实现中，经常会涉及除法器IP核的使用，虽然流水线级数设置得高一些能够带来更好的时序性能，但是往往也会涉及与该除法器计算结果相关的中间结果也需要用寄存器进行较多的延时缓存，有时这也是一笔不小的资源开销，所以就比较矛盾，因此通常会选择一个比较折中的时延参数，而不是单纯的“越大越好”。

图3.25 除法器IP的配置页面

在工程note10_prj002中，使用了Latency=2的一个较小的时延和流水线级数。在编译后，查看时序结果，如图3.26，对于50MHz这样较低频率下的时钟（20.0ns时钟周期），竟然也有3条和除法器（uut_div_gen_1）相关的3条路径出现了时序违规（Slack为负）。

图3.26 2级流水线的时序结果

在工程note10_prj003中，当我们尝试修改Latency=4，将除法器的流水线数增加1倍后再做编译。如图3.27，此时已经不存在时序违规路径了，并且最小的时序余量也高达4.022ns，性能提升明显。

图3.27 4级流水线的时序结果

对于流水线设计是否能够实际的提升设计工程的时钟频率，并不能仅从局部的优化去考虑，而需要从整体的设计去考量。在时序性能的优化中，通常是先找到时序的关键路径，即时钟频率的瓶颈所在，从关键路径下手进行必要的流水线优化，如此才有可能提升性能。

审核编辑：汤梓红