TimeQuest中的recovery/removal检查是对工程中的各种异步控制信号（包括异步复位 信号、异步使能信号等）的时序进行分析。recovery时间是指在有效时钟沿到来之前异步控制信 号必须保持稳定的一段时间，和数据的建立时间概念是相似的；removal时间是指在有效时钟沿到 来之后异步控制信号必须保持不变的一段时间，和数据的保持时间概念是相似的。它们的时序余量计算公式也和建立时间、保持时间相似。

如图1所示，查看TimeQuest中的recovery检查报告，它对该实例工程的3个异步清 除信号（sysrst_nr2、sdwrad_clr和vga_validr）进行检查。sysrst_nr2是 该工程的系统复位信号，而sdwrad_clr和vga_validr是 由内部逻辑产生的，它们既作为内部逻辑的同步清除信号（不进行recovery/removal检 查），也分别作为内部两个FIFO的异步复位信号（这部分路径将进行recovery/removal检查）。

图1

    由于数据setup time/hold time检查和控制信号的recovery/removal检 查都是对信号与时钟沿关系的时序分析，而且它们的分析计算公式都是类似的，所以一般信号的路径进行setup time/hold time检查，而异步控制信号的路径将进行recovery/removal检 查。TimeQuest不会同时对信号既进行setup time/hold time检查，又进行recovery/removal检查， 只是二者取一。

    在该工程中，sdwrad_clr的产生是由5.4s定时器cnt5s控制。当状态机sdinit_nstate处 于SD_DELAY状态时，cnt5s开始 计数，值为28'hffffff0时sdwrad_clr将 产生一个时钟周期宽度的高脉冲，这个高脉冲将作为FIFO的异步清除信号。下述代码即sdwrad_clr信号的产生逻辑。

reg[27:0] cnt5s;    //5.4s定时计数器

    //5.4s计数

always @(posedge clk or negedge rst_n)

    if(!rst_n) cnt5s <= 28'd0;

    else if(sdinit_nstate == SD_DELAY) cnt5s <= cnt5s+1'b1;

    else cnt5s <= 28'd0;

//SDRAM写控制相关信号清零复位信 号，高有效

wire sdwrad_clr = (cnt5s == 28'hffffff0);  

    下面来看看时序分析报告中异步清除信号sdwrad_clr的recovery检查。如图2所示。由于时序分析的起 点和终点都是以寄存器为基础的，所以作为wire的sdwrad_clr不 会出现在recovery检查的“From Node” 中，取而代之的是直接控制sdwrad_clr输出的计数器cnt5s的 全部28位寄存器。很显然，这里需要进行recovery检 查的路径会比我们的预想多得多。这里最坏recovery检查slack=11.453ns（远远满足我们的要求了）。

图2

    如图3和图4所示，分别是从Chip Planner中查看到cnt5s[27:0]在器件中的布局（右侧深蓝色部分）以及扇出路径。

图3

图4

    单从功能和时序上，上述代码已经满足了要求，只是最后的布局布线上让人有些不满意。显然，它可以进 一步的优化，办法很简单，只要把异步复位信号sdwrad_clr的输出用一个寄存器锁存一拍后再 输出即可。下面是优化后的代码。

reg[27:0] cnt5s;    //5.4s定时计数器

    //5.4s计数

always @(posedge clk or negedge rst_n)

    if(!rst_n) cnt5s <= 28'd0;

    else if(sdinit_nstate == SD_DELAY) cnt5s <= cnt5s+1'b1;

    else cnt5s <= 28'd0;

reg sdwrad_clr;     //SDRAM写控制相关信号清零复位信号，高有效

always @(posedge clk or negedge rst_n)

    if(!rst_n) sdwrad_clr <= 1'b0;

    else if(cnt5s == 28'hffffff0) sdwrad_clr <= 1'b1;

    else sdwrad_clr <= 1'b0;

    如图5所示，优化后的recovery检查的路径大大减 少，只有原来的1/28。现在的“From Node” 是寄存器sdwrad_clr。最坏的recovery检 查slack=14.077ns，相比之前有了大幅度的提高。

图5

    下面来看看代码 优化后布局布线的变化，如图6和图7所示， 分别为代码优化后从Chip Planner中查看到的cnt5s[27:0]在 器件中的布局（右侧深蓝色部分）以及扇出路径。很明显，计数器cnt5s[27:0]的布局布线较 之前有了很大的改观。

图6

图7

    从这个实例中， 我们可以很深刻的体会到使用一些简单的代码优化技巧后给系统时序性能的改善带来的变化。尤其是FPGA内 部产生的控制信号（不论是要作为后续电路的同步还是异步控制的信号），该信号在输出前应尽可能的减少组合逻辑数量，如果有可能，可以像我们的实例中那样先 用寄存器锁存一拍再输出，尽量让控制信号“干干净净”的驱动后级电路。