怎么修复max_trans 。。

leadwellfine

20# 童黄
1）可以改。
2）工艺对transition的影响很大。你可以查看不同的工艺的.lib文件的default max transition. 0.18 standard cell的max transition可能达到4.5ns，而0.13 只有1.3ns。
3）注释掉set_max_transition，实际PR工具是按照cell lib库里的default max transition作为是否违例的条件，这不一定符合你的设计要求，比如说，频率比较高时，set_max_transition相对就要设小一点。
4）cts、route这些步骤有些fix hold 的优化选项，先做优化，应该大部分hold可以fix，少部分只能通过插入buffer手工修了。

童黄

21# leadwellfine
哇，受益匪浅啊。。真诚的谢谢你！
我试过手动插buffer，不知道是不是因为post place optimization时插得太多，导致route优化时，基本没动静，尝试过只修hold都没有变化，反倒transition violation更多了。
我重新做了一版，修改了sdc，希望能成功。
还有点问题，哎，这些问题真是层出不穷啊。。
1）之前是不是一定要所有的transiton 和capatiance 都ok
2）40M频率算大么，我用得是0.13工艺。需要设置max_transition 么，如果最后时序都满足了，没有cap 和tran violation了，是不是说明达到我所要求的了。
3）DFM后out put sdf 给做后仿，达到什么要求才行，一般由于时间问题，不可能我这边完全clear了才做后仿吧。
4）DRC和LVS修复，对时序影响大么。
拜托了~~~碰到你，我觉得很幸运。谢谢。。。

leadwellfine

22# 童黄
sdc设置是否合理对PR影响很大，希望你成功。
1)在CTS步骤fix完就行，PLACE时不需要。
2）40M用默认max transition应该问题不大，但为了保险最好设置一个比默认值稍小一点的值，报告的violation不一定要修。
3)可在DFM之前做后仿，为了看到后仿结果，最起码不要有setup violation，如果violation比clock的uncertainty小，写出SDF也行，仿真时用max delay选项。如果setup violation太多，在PT里fix,再写出SDF。这样可以及早发现netlist的问题。
4）先做个版本进行DRC，工具里repair&fix结果不一定能达到sign off要求，用calibre或其他物理验证工具报一下，有些问题必须在PR过程中规避，到最后是没办法fix的。除非改动比较大，要不然这些步骤对timing影响不大。

童黄

23# leadwellfine
偶崇拜你。。。
我换sdc后，CTS后很好修，基本不用改啥。可是route后，怎么修都没有动静，不管我用啥办法，post_route optimization包括修改参数，选择优化变量。或者astPostRT后，ECO，等都不行，有时候还越修越坏。为啥啊。。百思不得其解。您有什么建议么。。
另外我想问问，CTS之后的sdc和之前的sdc有什么不同么，是不是要改uncertainty。。
都快一年了，我觉得还在门外徘徊。。。惭愧！

leadwellfine

24# 童黄
CTS后使用propagated clock,uncertainty可以小一点。
如果Hold的优化参数打开了，hold还是存在,只能手工修复了。工具有时确实比较傻。
理解sdc constraints再做后端会比较顺畅一些。

童黄

25# leadwellfine
啊，终于route完了，而且时序满足了。改了sdc后，transition也没有violations了。
谢谢你了。
可是detail route有两个err metal1层有wrong wire on via。可是也看不出来有啥不对劲，不知道要不要修复 呢。
还有角落的pad和corner 不满足min spacing ，min width，我直接move了，没什么改善，您有什么建议么。。。

yale9301

检查驱动Buf与Pad之间的距离，如果距离比较远就手工添加buf，如果已经非常近就增大驱动。增大驱动后如果还有vio，那么就是pad有问题了，负载太大。

inspectb

不知道你说的是哪个的转换时间违规和用的什么工具。之前我的一个同事遇到过类似的问题。幸好她做的项目练习是我之前做过的项目，可以和正常的做对比。她的是芯片内部的电路转换时间特别大，经查是一个输出驱动多个负载时工具没加BUF,负载特别大，所以转换时间也特别长。查sdc文件，max_transition设的是1.5，不算大。和我做的时候设的一样。但是在P&R时和我做的步骤一样，就是结果不一样。后来回到DC阶段和我的DC脚本做对比，发现在是命名规则的问题。我的脚本在写出网表时，用了约束更严的命名规则。我们用的布线工具是encounter，估计是工具对verilog的命名规则有些不认同，所以没做插入BUF的优化。另外，各位能不能留下ＱＱ啊，这样更方便交流呀。我的ＱＱ３０９６７５５０。我们还可以建立一个群哦。

龙溪小泮

刚开始啊，不是很懂啊