block初始的时候是42%的cell uti,place后是52%, 这个增长是正常的吗？

quanqiutong

   

xingyun666666 发表于 2021-7-6 10:52
您好，想请教下，有时综合的timing满足，在pr时发现timing critical，我没有做过综合，这种timing path是 ...

综合用了wc corner，pr时 wc，wcl corner都跑，结果wcl中的timing 非常critical。
即使只使用wc corner跑pr，有些路径的timing 也变的很差，这些路径中cell 没法放的很近。

xingyun666666

   

quanqiutong 发表于 2021-7-6 12:16
综合用了wc corner，pr时 wc，wcl corner都跑，结果wcl中的timing 非常critical。
即使只使用wc corner跑 ...

我的理解，这种是不是就是DC综合和PR的corr不是特别好？有些path在DC时看着timing是没问题的，但是后端实际layout中，受到FP以及place cell位置的影响，就出现了新的timing violation？
那这种情况，貌似只能后端来修，前段或者综合有什么好办法吗？我想可以加大margin，但是可能会通杀，过优很多不必要的path

xingyun666666

   

jake 发表于 2021-7-6 12:15
init: 0%
floorplan: small increase due to physical cells such as tap cells, endcap cells
place: sm ...

第一，如果综合不能做到meet setup并有一点裕量，后端不能接受，但是，我看到有两种情况：
  (1)  有些path在综合时是meet的，但是在后端是violation的，这种比较好理解
（2）有些path在综合时是violation的，但是在后端是meet的，我看到其中一种好像是综合用的cell驱动比较小，PR时用的大一些，其实不太理解这种，是怎么回事？还有其他类型的timing path也是前端meet，后端不meet的吗？我可能经验比较少


第二，在CTS之前timing optimization是没有意义的，CTS之前主要是优化data path，我的理解其实是不是也算是优化了timing？只是此时tree是ideal的，timing不是很精准的优化，有点脱离最终的实际情况

第三，一直困扰我的问题，就是当PR发现有timing violation时，哪种情况适合设置group path去优化，哪种不适合，我发现，有些timing path我设置了group path优化的很好，有些设置了完全没用，感觉现在就是盲设，不太理解group path这种method优化的实质

jake

   

xingyun666666 发表于 2021-7-6 07:36
第一，如果综合不能做到meet setup并有一点裕量，后端不能接受，但是，我看到有两种情况：
  (1)  有些p ...

第二CTS之前不动data path，不做任何timing optimization。
CTS之前会考虑drv fixing，max_fanout, max_transition, max_cap，通常不涉及critical data path。
CTS之后才开始考虑修setup, hold。

第三
不是很明白你的group_path怎么用的。我的理解是group_path命令只影响report_timing。
我通常在综合的时候会仔细分析关键部分的data path，尤其是reg2reg。我的准则是综合时这些data path必须满足setup。其实这一步也是验证我的架构是否合理。如果综合达不到timing，我会重新做架构，重写RTL。 高速设计RTL架构直接影响后端timing，自己掌控RTL十分必要。  
P&R CTS之后，我会仔细分析每个skew group。如果有data path不能满足setup，我会看是在哪个skew group，看clock tree debugger里sink相对位置，考虑是否需要改这个skew group ccopt property。 CTS通常会跑几次，直到post CTS没有setup violation。

有些时候setup violation是SDC没写对，这种情况会回到综合再走flow。
可能讲得太笼统了。唉，timing closure是比较复杂的，几句话是讲不清的，而且跟设计本身有关。

xingyun666666

   

jake 发表于 2021-7-7 10:40
第二CTS之前不动data path，不做任何timing optimization。
CTS之前会考虑drv fixing，max_fanout, max_ ...

第二，Place时（preCTS）其实工具优化的不是timing meet的？而是在fix drv这些？
第三，inn中可以设置group path然后设置weight，加大权重去更好的优化timing path，好像不只是针对report_timing有用
不知道我的理解对不对哦

xingyun666666

   

jake 发表于 2021-7-6 12:15
init: 0%
floorplan: small increase due to physical cells such as tap cells, endcap cells
place: sm ...

place: small increase due to DRV fixing
不知道jake哥有没有遇到过place后uti增长十几个点的时候，好像之前做DDR会这样

jake

   

xingyun666666 发表于 2021-7-7 01:41
第二，Place时（preCTS）其实工具优化的不是timing meet的？而是在fix drv这些？
第三，inn中可以设置gro ...

第二
在-preCTS模式，Innovus是有能力做drv fixing，WNS, TNS optimization的。根据设计需求，可以选择只做drv fixing。

如果综合后没有setup violation，Innovus preCTS也没有setup violation，WNS，TNS都为正，Innovus不需要做WNS，TNS optimization，可以跑类似下面的flow。
setPlaceMode ...
setOptMode ...
place_opt_design
place_opt_design -incremental

如果综合后有setup violation, Innovus preCTS 有负的 WNS，TNS, 可以选择暂时不理会timing，只做drv fixing。
setPlaceMode ...
setOptMode ...
place_design
optDesign -drv
这里optDesign -drv告诉工具只做drv fixing。

我个人是不喜欢在placement阶段做timing optimization的。

想了想，可能因为我的flow严格要求综合必须meet setup，掩盖了一些问题。如果综合后勉强满足setup，WNS为0。Innovus place时两个模块距离较远，place时是有可能出现WNS为负的。这时跑上面第一个flow, place_opt_design可能会首先在critical path上upsize cell，如果还不能meet setup，place_opt_design可能会“发疯”的。 也许这是place后utilization增加好多的原因。 也许可以试一下第二个flow，只做place_design，观察utilization，再做optDesign -drv，观察utilization，再做optDesign -preCTS ...  还有，usefulskew全程关掉，减少不必要的变数。


第三
我明白你的做法了。