分析一个clock reconvergence pessimism的例子

代码：
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的路径，悲观。下面的图片，点击可以放大。

这应该是dc的报告吧，为何要annotate?dc应该是ideal的clk ，既latency为o。

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

自己顶吧

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

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

我比较同意楼上的说法

crpr都是CTS之后的事情， 和dc没啥关系，
把timing_removal_clock_reconvergence_pessimism 设成false好了（default就是false） ，

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

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

Good！

学习了

好像不对吧。crpr是计算common path由于不同的corner下的差异。