mcmm下的时序violation

Startpoint: u_flash_ctrl/xor_sig_reg_reg_17_
(rising edge-triggered flip-flop clocked by i_ps_clk)
Endpoint: u_flash_ctrl/xor_sig_reg_reg_17_
(rising edge-triggered flip-flop clocked by i_ps_clk)
Scenario: func_wcl_c
Path Group: i_ps_clk
Path Type: min
PointIncrPathVoltage
------------------------------------------------------------------------------------
clock i_ps_clk (rise edge)0.000.00
clock network delay (propagated)0.160.16
u_flash_ctrl/xor_sig_reg_reg_17_/CK (DFFRPQN_X0P5M_A9TR40)
0.000.16 r0.99
u_flash_ctrl/xor_sig_reg_reg_17_/QN (DFFRPQN_X0P5M_A9TR40)
0.100.26 r0.99
u_flash_ctrl/U641/Y (OAI22_X0P5M_A9TR40)0.02 &0.28 f0.99
u_flash_ctrl/U1720/Y (DLY4_X0P5M_A9TR40)0.12 &0.40 f0.99
u_flash_ctrl/U1426/Y (DLY4_X1M_A9TR40)0.12 &0.52 f0.99
u_flash_ctrl/xor_sig_reg_reg_17_/D (DFFRPQN_X0P5M_A9TR40)
0.00 &0.52 f0.99
data arrival time0.52
clock i_ps_clk (rise edge)0.000.00
clock network delay (propagated)0.460.46
clock uncertainty0.050.51
u_flash_ctrl/xor_sig_reg_reg_17_/CK (DFFRPQN_X0P5M_A9TR40)
0.000.51 r
library hold time0.030.54
data required time0.54
------------------------------------------------------------------------------------
data required time0.54
data arrival time-0.52
------------------------------------------------------------------------------------
slack (VIOLATED)-0.02

请问各位：40nm下做ICC后端设计，其余scenario均无violation，仅有func_wcl_c(worst case -40摄氏度)出现违反，原因应该与clock network delay相关，这个scenario下，skew 300ps，不太合理，请问如何解决呢?（注：该路径在pt无违反）谢谢

你这path有问题吧，startpoint和endpoint都是一个register。

path没问题的，下面是PT报的时序：
Startpoint: u_flash_ctrl/xor_sig_reg_reg_17_
(rising edge-triggered flip-flop clocked by i_ps_clk)
Endpoint: u_flash_ctrl/xor_sig_reg_reg_17_
(rising edge-triggered flip-flop clocked by i_ps_clk)
Path Group: i_ps_clk
Path Type: min
Scenario: func_wcl_c
PointIncrPath
------------------------------------------------------------------------------
clock i_ps_clk (rise edge)0.000.00
clock network delay (propagated)0.180.18
u_flash_ctrl/xor_sig_reg_reg_17_/CK (DFFRPQN_X0P5M_A9TR40)
0.000.18 r
u_flash_ctrl/xor_sig_reg_reg_17_/QN (DFFRPQN_X0P5M_A9TR40)
0.10 &0.28 r
u_flash_ctrl/U641/Y (OAI22_X0P5M_A9TR40)0.02 &0.30 f
u_flash_ctrl/U1498/Y (DLY4_X0P5M_A9TR40)0.13 &0.43 f
u_flash_ctrl/U1499/Y (DLY4_X1M_A9TR40)0.12 &0.55 f
u_flash_ctrl/U1497/Y (DLY2_X0P5M_A9TR40)0.05 &0.60 f
u_flash_ctrl/U1136/Y (BUF_X0P7B_A9TR40)0.03 &0.63 f
u_flash_ctrl/xor_sig_reg_reg_17_/D (DFFRPQN_X0P5M_A9TR40)
0.00 &0.63 f
data arrival time0.63
clock i_ps_clk (rise edge)0.000.00
clock network delay (propagated)0.190.19
clock uncertainty0.050.24
u_flash_ctrl/xor_sig_reg_reg_17_/CK (DFFRPQN_X0P5M_A9TR40)0.24 r
library hold time0.010.25
data required time0.25
------------------------------------------------------------------------------
data required time0.25
data arrival time-0.63
------------------------------------------------------------------------------
slack (MET)0.38

你ICC和PT的路径不一样，data path
最好是展开clock network看看，多半path不一样

你的时钟skew 在pt 和iCC 下表现的不一致，icc下 很大。建议你尝试用report_clock_timing -type latency -hold -to * 再检查一下proprageted clock latency 是否和你用report_timing中的报出的network latency一致。然后再在Primetime下做同样的操作，看到那个时钟的network latency 是多少，和icc有多大差异。

非常感谢您的建议。clk netlwork latency 是0.16ns。
PT也做了尝试，该scenario下，clk netlwork latency 是0.18ns，与icc相差无几。

我现在搞不懂的是为何时钟path clock network delay (propagated)0.46 ?
icc_shell> report_clock_timing -type latency -hold -to u_flash_ctrl/xor_sig_reg_reg_17_/CK
****************************************
Report : clock timing
-type latency
-launch
-nworst 1
-hold
Design : top
Scenario(s): func_wcl_c
Version: D-2010.03-ICC-SP2
Date: Thu Dec 19 14:42:56 2013
****************************************
Clock: i_ps_clk
--- Latency ---
Clock PinTransSourceNetworkTotal
----------------------------------------------------------------------------
u_flash_ctrl/xor_sig_reg_reg_17_/CK
0.030.000.160.16brp-+
----------------------------------------------------------------------------

不客气。共同探讨。
我猜测你的那个0.46ns 的network latency 是 针对setup 报出来的，你可以用report_clock_timing -type latency -setup -to * 这个命令查看一下，看看这时候报出来的network latency值是多少，如果是0.46上下，则我的猜测是对的。

就是说工具在做hold time时序检查的时候，clock network latecy 用了一个为setup做时序检查的network latency（最差路径），这就造成你的时序违反。这是猜测啊，你先做个试验看看具体的数据。

你的猜测是对的
icc_shell> report_clock_timing -type latency -setup -to u_flash_ctrl/xor_sig_reg_reg_17_/CK
****************************************
Report : clock timing
-type latency
-launch
-nworst 1
-setup
Design : top
Scenario(s): func_wcl_c
Version: D-2010.03-ICC-SP2
Date: Thu Dec 19 15:07:15 2013
****************************************
Clock: i_ps_clk
--- Latency ---
Clock PinTransSourceNetworkTotal
----------------------------------------------------------------------------
u_flash_ctrl/xor_sig_reg_reg_17_/CK
0.070.000.470.47wrp-+
----------------------------------------------------------------------------
1

你查看一下你当期使用的analyse_type.看看icc和primetime 的analyse_type是否一致，解释在：
http://www.eetop.cn/blog/967917/viewspace-39067.html

你把clock 展开看看吗 report_timing -path_type full_clock_expanded

非常感谢，很有帮助啊，我周一上班在仔细研究下！

我的pt和iccAnalysis Type 都是 on_chip_variation。

小编 问题后来解决了吗?

thank you for the reply