min pulse width违例 如何修

cts之后出现 min pulse width的违例， 用命令检查transtion，没有错误
icc_shell> report_clock_tree -drc_violators
****************************************
Report : clock tree
Design : demo00_top
Scenario(s): func_wcl_cmax
Version: H-2013.03-ICC
Date: Tue Apr7 13:45:02 2015
****************************************
============================Report for scenario (func_wcl_cmax)=============================
Warning: Float pin scale factor is not set for the 'max' operating condition of scenario 'func_wcl_cmax'.Skews may be inaccurate. (CTS-376)
------------------------------------------------------
DRC violations on clock tree
Clock Tree Name: clk
Scenario Name: func_wcl_cmax
Clock Root Pin: clock
------------------------------------------------------
Number of MaxTran Violators: 0
Number of MaxCap Violators: 0
Number of MaxFanout Violators: 0

查看layout，看到之前设置的buf，inv也都在clock path上，
时钟周期是3ns
请问这个该如何解决呢?

通常不用修， 因为.lib 里面的min pulse是很小的一个值，即memory能工作的最小允许的clock period值，
比如1Ghz 或几百Mhz， 而设计里面通常不需要这么快

版大，lib里的是很小，但我这个跑完之后，需要的更小啊，要不应该就不会违例了吧！ 我的是3ns也有300MHz；
这个违例是不是说：比如我的库允许我只能跑100MHz，但我硬要跑300MHz，所以出现了违例；

我看PT guide上说，如果有这个违例，可能会允许逻辑错误的；这个就直接过去，不用修吗?

版大，我用report_min_pulse_width报了下，确实lib中stand cell的min pulse width都很小，但latch的比较大，而这里的违例也正是latch的；
RequiredActual
Pinpulse widthpulse widthSlackScenario
--------------------------------------------------------------------------------
clk_gate_DataOut_reg/latch/CLK(low)
2.411.99-0.42 (VIOLATED)
func_wc_cmax
MEM_Data_reg_13__0_/CLK(low)
0.411.981.57 (MET)func_wc_cmax
DataOut_reg_2_/CLK(low)
0.412.001.59 (MET)func_wc_cmax
DataOut_reg_3_/CLK(low)
0.412.001.59 (MET)func_wc_cmax
DataOut_reg_6_/CLK(low)
0.412.001.59 (MET)func_wc_cmax

latch是icg吧，自然有clock gating check来保证的
我印象中没有修过min pulse width的问题的

latch是icg吧，自然有clock gating check来保证的
我印象中没有修过min pulse width的问题的

恩 是icg；就是担心片子出来之后 不能工作

我觉得不会， 只要其他timing clean就行

如果min_pulse_width出现违反，low pulse 就会被latch滤掉，到时输出的波形只有高电平啦。
这种问题如果拿不定注意，可以对该latch用hspice仿真，如果真的滤掉了，到时硅片变砖头啦。

hspice啊? 还没用过呢。；
库中普通cell的 min pulse都很小，就latch的min pulse要求比较大；

这个出现违例了，也不知道该怎么修了！

请问在icc中该如何修复这种violation呢

怎么看到问题变成“已解决”了?
min_pulse_width 必须修的。这个不修芯片要死啊。
我查我用的TSMC的ICG 的cell ，基本min_pulse_width 都是100-200ps的范畴。没有过1ns的道理。
建议仔细查查这个ICG cell到底是怎么建造的，换一种ICG

我查我用的TSMC的ICG 的cell ，基本min_pulse_width 都是100-200ps的范畴
请问你这个是怎么查的，lib中关于cell的信息有描述min pulse width的吗?

我看了下我的库，关于ICG cell只有两种 一种是X8的 一种是X2的，我两个都试了下，可都是有这个违例！

timing_type : min_pulse_width;
rise_constraint (mpw_constraint_template_3x3) {
index_1 ("0.0031, 0.0704, 0.6085");
values ( \
"0.139609, 0.15361, 0.753174" \
);
}

我的icg的min pulse width都比较大！

查下逻辑吧

嗯，之前有
http://bbs.eetop.cn/thread-385058-1-1.html

这个不科学啊，应该是transition越大，min_pulse_width越大才对呀，你这怎么是反的?

不知道LZ解决这个问题了吗?貌似我也遇到这个violation，但不知道如何来修?或是不修?

如果有transition还没有修掉，会影响这个min_pulse_width的violation的！