怎么修复max_trans 。
做完CTS，优化后，setup和hold都没有错误，怎么也修复不了maxtrans错误。不知道有什么办法啊。请各位用经验指点下迷途的我。在此谢过了。
自己检查了下，发现那violations在做完place之后就存在。想办法修啊修，也没有搞定。希望大家帮帮忙哈。谢谢了。
贴个violation path出来看看嘛
先让工具自己optimize, 每个工具都有cts以后的place optimization command
如果工具没办法处理，需要你手工干预
一般是增大驱动或者加buffer
不关我的事,我是逗大家开心的,“不忍心”
谢谢建议，我试过了，violation的值减少了，但还是没解决问题。
因为report在服务器上，权限问题使我不能导出来，哎。
我可以描述一下，有三个是跟pad的violation，10.5左右，
还有两个和其相连的INVX的violation，也是10左右，挺大的了，用插入buffer能使值稍小点，但是没有解决。
很可能是pad的lib做的不够好，比如pad的inputcap，你们自己做的还是别人的库?
或者你们的sdc set_load?
还有一种可能，约束有问题，需要检查一下路径，实在不行就手工修改吧。
是smic库，SP013D3库。其实还有个是SP013W的pad库，但是pad的VSS有drc问题，所以就用这个D3的库，不知道你有没有听过。
不知道您说的sdc set_load是什么意思，请详细说明，再次谢过了。
10# devopetent 在TIMING SETUP里把MAX TRANSITION 设的小小的,
这个一般设置为0吧。
我查了下，一个是pll信号，还有事power_good信号，reset信号，本身变化不多，基本是个常量，但它后边跟的路径挺多，所以驱动需求就大了。不知道有没有办法，可以在sdc中设置不检查这个路径，或者有什么办法先布置相关的这个信号。请指导。
能不能把你的几个约束写上来看看，感觉应该是约束不合理造成的，不然不应该违背这么大。
说起来，惭愧不已啊，本人对于怎么设置约束，一直懵懵懂懂，是前端做完DC后生成给我的，稍微改了点。
INST_Ppll_lock和其相连的invx U1violation，U1接的是port Ppll_lock
sdc中set_false_path -from [get_ports {Ppll_lock}]
set_drive rise min 20 [get_ports {Ppll_lock}]
set_drive fall min 20 [get_ports {Ppll_lock}]
set_drive rise max 20 [get_ports {Ppll_lock}]
set_drive fall max 20 [get_ports {Ppll_lock}]
其他两个类似
INST_Ppower_good
和其相连的invx U2 violation，U2接的是port Ppower_good
sdc中set_false_path -from [get_ports {Ppower_good}]
set_drive rise min 20 [get_ports {Ppower_good}]
set_drive fall min 20 [get_ports {Ppower_good}]
set_drive rise max 20 [get_ports {Ppower_good}]
set_drive fall max 20 [get_ports {Ppower_good}]
INST_Prst_n_in
怎么只有驱动的设置，没有负载和其他DRC的设置吗?
这两个pad直接相关的就这些了
在sdc中需要设置DRC?
18# 童黄
1）常量就不要设置set_drive或set_input_transition，必要时设置set_case_analysis;
2）输入定义在chip level的IO PAD上最好不要用set_drive和set_driving_cell，太抽象了，直接指定set_input_transition。输出定义在chip level的IO PAD上用set_load就可以了。cell的延时、output transition本来就是通过input transition和load两个参数查表得到。
3）report里面的与input IO相关的PAD和pin上的transition可以不关注,它是由输入transition和你选择的IO cell的性能决定的.与output IO相关的PAD和pin上的transition是一定要修的，但也要查看一下IO cell的性能，它的output transition可能达不到你规定的要求。
4）set_max_transition 0 current_design要求太严，设置一个稍微比符合实际的值严一点的值就可以了，要不然PR过程中会插入很多buffer去修transition。
谢谢，受教了。还有几个问题，想请教下。
1）如果由DC写出来的sdc，后面版图布局布线的时候，修改这个sdc，应该没有关系吧。
2）另外工艺不同，transition是直接最受影响的参数么。
3）如果在sdc中我注释掉了set_max_transition，会影响布的效果么，或者更难修复?
4）用astro时，在post_place修复好了，route效果很差，而且hold怎么也修不过来，可以手动修复么，不知道您有什么建议。
再次谢过。
19# 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修复，对时序影响大么。
拜托了~碰到你，我觉得很幸运。谢谢。
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。
都快一年了，我觉得还在门外徘徊。惭愧！
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了，没什么改善，您有什么建议么。
检查驱动Buf与Pad之间的距离，如果距离比较远就手工添加buf，如果已经非常近就增大驱动。增大驱动后如果还有vio，那么就是pad有问题了，负载太大。
不知道你说的是哪个的转换时间违规和用的什么工具。之前我的一个同事遇到过类似的问题。幸好她做的项目练习是我之前做过的项目，可以和正常的做对比。她的是芯片内部的电路转换时间特别大，经查是一个输出驱动多个负载时工具没加BUF,负载特别大，所以转换时间也特别长。查sdc文件，max_transition设的是1.5，不算大。和我做的时候设的一样。但是在P&R时和我做的步骤一样，就是结果不一样。后来回到DC阶段和我的DC脚本做对比，发现在是命名规则的问题。我的脚本在写出网表时，用了约束更严的命名规则。我们用的布线工具是encounter，估计是工具对verilog的命名规则有些不认同，所以没做插入BUF的优化。另外，各位能不能留下ＱＱ啊，这样更方便交流呀。我的ＱＱ３０９６７５５０。我们还可以建立一个群哦。
刚开始啊，不是很懂啊