提高FMAX的时序优化方法

提高FMAX的时序优化方法

转载请注明出处：http://blog.csdn.net/kevin_hee/article/details/78087600

一、FMAX介绍

FMAX代表了设计中一个时钟从源寄存器到目的寄存器所能跑的最高速率，它的大小受两个寄存器间最大的走线延迟决定。

以Altera Quartus16.1为例，在时序分析完成后，打开Fmax报告：

Compilation Report/TimeQuest Timing Analyzer/Slow 1200mV 85C Model/Fmax Summary

可以看到各个时钟在设计中能跑的最高频率(Slow 1200mV 85C Model是最糟糕的模型，这里以提高最坏情况下的FMAX为例来说明)。

 

Restricted Fmax表示受限制的Fmax，如果是内部逻辑使用的时钟，则Restricted Fmax一般和Fmax相等。如果时钟是作为和IO口连接的输入输出时钟，则其大小受到IO口的翻转速率限制，当时钟频率较大时可能两个值不相等。

 

二、限制FMAX的原因

一般仿真完成后的设计是一个未经优化的设计，上板编译后的时钟频率一般不能达到理想速度。

下面详细分析限制FMAX的可能原因。

 

1. 两个寄存器间过多的组合逻辑。

将一条待优化的时钟线路的时钟频率大小调到理想大小，在时序分析完成后打开TimeQuest软件。找到一条Timing Failing路径，并用Technology Map Viewer定位查看。

 

对此，可能会观测到一条如下的路径。

 

如上图所示，两个寄存器间的组合逻辑太长，造成了寄存器间的走线延迟太大。

进一步用TimeQuest查看详细报告。

 

如上图所示，IC(即走线延迟)占据了Path Delay的67%。由此判定，这条时钟路径的建立时间违例主要是寄存器间组合逻辑过多造成的。

 

另外判断组合逻辑过多也可以通过设计代码看出来。如下代码：

reg [8:0] result_c,in_a,in_b,in_c; always@(posedge clk or negedge rst_n) begin     if(!rst_n)begin       result_c <= 9'd0;     end     else begin      //组合逻辑过多       result_c <= ((in_a+in_b+in_c)>>2)&{2'd0,9'h1FF};     end end

为了得到result_c，在一个时钟周期内需要完成两个加法操作、一个移位操作和一个按位与操作。这些操作都属于组合逻辑，必定为增加延迟，降低FMAX。

 

2. Fan-Out即扇出太大

扇出即一个寄存器向下驱动的逻辑数量。

 

一个寄存器的扇出太大，带来的问题就是布局布线的时候设计工具无法满足寄存器和下级驱动逻辑之间的走线达到速度和公平性的平衡。

例如如果要满足逻辑C到C1的走线延迟短，可能就会使得C到C2、C3的走线延迟变大，而时序问题就出在C到C2、C3的走线延迟上。

同样使用TimeQuest软件查看一条Timing Failing的详细报告，可能会看到如下的结果。

 

如上图所示，inst1|regout的Fanout达到了4108，IC延迟占总延迟的82%。可以判定，这条时钟路径的建立时间违例主要是逻辑扇出太大造成的。

 

3. 冲突的物理分配

A.如果一个设计较大，则布局布线工具无法满足所有相关的内部逻辑器件例如两个寄存器之间布局布得很近。

B. 一个和外部IO口相连的内部寄存器会因为设计复杂的原因无法保证和IO Buffer离得很近。

C. 一个设计如果使用了片内的DSP、RAM等等其它硬核资源，这些硬核的位置是固定的，如果逻辑器件如寄存器布局后离他们很远，也会造成走线延迟过大。

 

如果使用TimeQuest查看一条Timing Failing路径，将其定位到Chip Planner:

 

可能看到如下的走线:

 

如上图所示，两个寄存器的布局布线使得走线横穿了整个器件，这样的走线延时必然是无法接受的。

有如下DDR布局布线的例子(抽象的图例)：

 

如上图所示，因为FPGA上下都有DDR Interface，中间的寄存器必须驱动上下两级逻辑，这样会造成冲突。如果将中间的寄存器布局离interface1近些，则与interface2间的走线延迟将可能达不到要求，反之亦然。

 

三、时序优化方法

时序优化应该首先从设计的源代码入手，在通过手动更改源代码使得时序违例时间Slack达到足够下的情况下，再尝试综合与布局布线优化选项。

 

1. 确定引起时序问题的原因。

A. 在前面的分析中可以看到，首先不借助工具就能找到的原因是寄存器间过多的组合逻辑。体现在源代码中就如前面示例代码的形式---一个时钟周期内需要完成多次组合逻辑运算。

 

B. 对于不那么明显的组合逻辑，在时序违例后通过TimeQuest查看详细的分析报告，特别关注Data Arrival Path中data path，查看是否有比较长的组合逻辑及比较大的延迟。

 

如上图所示(上图只是示例，上图违例并不是组合逻辑过多造成的)，这里需要关注LCCOMB等组合逻辑是否过多。

同样，也可以通过Technology Map Viewer(如前面所描述的)来看两个寄存器间的组合逻辑数量的多少。

 

C. 对于确定组合逻辑不是影响时序问题的原因后，查看Data Arrival Path中data path的IC即走线延迟，如果发现某个中间逻辑节点走线延迟太大，进一步如前面所展示的，用Chip Planner来查看走线延迟，以确定是否是冲突的物理分配导致的时序违例。

 

D. 同样确定组合逻辑不是影响时序问题的原因后，查看Data Arrival Path中data path的Fanout数，过大的扇出必然会导致IC走线延迟增加。

 

2. 优化时序

A. 对于过多的组合逻辑，合适的方法是在组合逻辑中间插入寄存器，分断组合逻辑，做流水操作。

 

流水线操作增加了latency，但是加大了FMAX。

 

B. 尽量用case语句代替if else语句。

如下代码：

always@(*) begin     if(A)       sig_out <= 1;     else if(B)       sig_out <= 2;     else if(C)       sig_out <= 3;     else if(D)       sig_out <= 4;     else if(E)       sig_out <= 5;     else if(F)       sig_out <= 6;     else if(G)       sig_out <= 7;     else if(H)       sig_out <= 8;     else         sig_out <= 9; end

因为if else语句带有优先级，很大可能会被综合工具翻译为下面的情况：

 

这种带有级联结构的组合逻辑，比起不带有级联结构的case并行逻辑，延迟必然会增大。

 

C. 对于高扇出的信号，常用的做法是做逻辑复制，即Duplication。

原理是将源寄存器复制一份，用复制的寄存器来驱动一部分源寄存器扇出的下级逻辑，即分担了源寄存器的扇出负担。

还有一种方法是让高扇出的信号走全局时钟网络，但是一般高扇出的信号在综合的时候会自动走全局网络，而且对于有限的全局走线资源，一般会留给时钟，所以对于不是时钟的信号，建议做逻辑复制。

 

D. 对于冲突的物理分配，本质原因是寄存器的布局无法使得所有与之相连接的逻辑器件如寄存器、DSP的走线延迟满足要求，满足了A的走线延迟要求，就无法满足B的走线延迟要求。

对此通常的做法是做流水线和逻辑复制，这样做的原理是增加了寄存器使得布局布线能够让相关的逻辑器件与这些寄存器之间走线延迟达到要求。

 

E. 在尝试了以上所有方法后，如果已经将Slack降低到了一定程度，通常在-1ns以下。就可以尝试更改综合和布局布线优化选项。

在Quartus的Advanced Settings(Fitter)优化选项中，打开如下四项的效果是不错的，而且这四项优化不会显著增加编译时间，也不会显著增加逻辑资源的使用量：

 

更改优化选项physical synthesis effort level会显著增加编译时间。

其它更多的优化选项也可以进行尝试，关于优化的更多信息参考Altera Quartus Handbook Volumn 2 Chapter 16 <<Netlist Optimizations and Physical Synthesis>>一章。