分析一个clock reconvergence pessimism的例子

xilinx_zhao

代码：
module ex1(in1,clk,cntl,f2);
  input in1,clk,cntl;
  output f2;
  reg f2;
  reg f1;
  reg clk_tmp;
  wire clk_dly;

  BUFFD2 buf_1 (clk,clk_dly);

  always @(clk,cntl)
    case (cntl)
       1'b1: clk_tmp=clk;
       1'b0: clk_tmp=clk_dly;
       default: clk_tmp=clk;
     endcase;
  always @(posedge clk_tmp)
    begin
      f1<=in1;
      f2<=f1;
    end
  endmodule



做了如下的约束：
set_operating_conditions WCCOM
create_clock [get_ports clk] -period 10.0 -name clk
set_propagated_clock clk
set_annotated_delay 1.0 -cell -from buf_1/I -to buf_1/Z
set_dont_touch_network clk
1.请问 timing report 里面的那个 “clock reconvergence pessimism”为0.99 是怎么计算出来的？
2.另外，可以看到，launch 时候走的是有buf_1的路径，而capture时候，走的是没有buf_1的路径，悲观。下面的图片，点击可以放大。

xilinx_zhao

回复 2# zhq415758192

annotate 是为了准确地告诉DC，这一段的delay就是这个数值，不要它自己算，这样的话，在报告里面，可以认出来。但是我的那个问题，怎么还没有高人指点？

xilinx_zhao

自己顶吧

jun_dahai

clock reconvergence pessimism是launching时钟路径和capturing时钟路径的延时差值，它发生在时钟切换的时候，是基于library通过查找LUT得到的
另外，你应该把timing_removal_clock_reconvergence_pessimism设置为true属性了

taoli_ic

你应该把cntl设置 set_case_analysis，不然timing engine就会找best path for launch clock, worst path for capture clock.

optihack

我比较同意楼上的说法

icfbicfb

crpr都是CTS之后的事情， 和dc没啥关系，

把timing_removal_clock_reconvergence_pessimism 设成false好了（default就是false） ，

matafeiye

crpr都是CTS之后的事情， 和dc没啥关系，

把timing_removal_clock_reconvergence_pessimism 设成false好 ...
icfbicfb 发表于 2012-1-31 07:51

                               
登录/注册后可看大图

    不知道这个参数在pt分析中的作用是什么？  我看pt报告的时候若将它设置成true，貌似更容易时序收敛。菜鸟求解答

chrisyl

是这样的，launch clock path取悲观路径，所以计算的是经过buf_1的路径；capture clock path 取乐观路径，所以按不经过buf_1的路径计算。这两条路径之后都要经过U5/Z，但是这一点不可能有两个到达时间，只能有一个。这两个到达时间之间的差值0.99ns，就是crpr值，是应该去掉的。

fanlianglove

Good！