place后violation和fanout除了psynopt和增加weight还有什么办法
（1）place之后 reg2reg 有setup 违例，用psynopt优化了两次，然后将reg2reg的path的weight增大66，
再一次psynopt，setup违例减小了一些，但还是没有干净；还有什么优化方法吗?
（2）setup之后 有一条net的fanout违例，设的64，实际为77，这条net是在macro内的，
用psynopt -only_design_rule搞不掉；请问在macro内的fanout违例如何修?
1）增加range ，set_critical_range 100 [current_design]
-weight超过20的数字几乎多没差别了， icc已经很重视了，只能是尽力修复
然后看timing path的情况，如果都是纯粹的comb logic（buffer很少），那就很难修了，
只能到cts 的时候useful skew调整下， 如果buffer很多，说明floorplan可以改善修复
2）这个应该是连到各个macro的net吧， 不是macro内吧，
再说了，我反复强调： fanout不是hard rule， 在timing不紧张的时候，fanout >100也是允许的
只要max trans/cap 不违反lib的要求就行了
第一个问题我也遇到了，求更好的解决方法，谢谢！
恩 小编说的有道理！fanout不是硬性要求！
对于setup违例！我选了其中一条违例的，看了下，这里面工具已经将其全部优化成LVT了；而且从报告中看不出有
哪些cell异常！ buffer的话 其中有10个，不知道算不算多呢，小编！请小编知道下如何优化
自己用写了个脚本，用usefulskew处理了下，修复了其中一些setup 违例；由于没有考虑用userful skew之后hold的问题，所以修复完之后又出现了一些hold违例！
不过hold违例在place阶段应该不用管！
clock clk (rise edge)0.000.00
clock network delay (ideal)0.000.00
rom1_u_sram0/CE (SRAM8x1024_1rw)0.000.00 r1.08
rom1_u_sram0/O[0] (SRAM8x1024_1rw)7.117.11 f1.08
icc_place2620/ZN (INVX4_LVT)0.07 *7.19 r1.08
icc_place2621/ZN (INVX16_LVT)0.06 *7.24 f1.08
icc_place2728/QN (NOR2X4_LVT)0.09 *7.33 r1.08
icc_place2823/QN (NOR2X4_LVT)0.05 *7.39 f1.08
icc_place2824/ZN (INVX8_LVT)0.06 *7.45 r1.08
icc_place2770/ZN (INVX16_LVT)0.05 *7.50 f1.08
icc_place2734/ZN (INVX16_LVT) 0.05 *7.55 r1.08
icc_place2818/QN (NAND2X4_LVT)0.04 *7.58 f1.08
icc_place2788/ZN (INVX4_LVT)0.04 *7.62 r1.08
icc_place2819/QN (NAND2X4_LVT)0.05 *7.67 f1.08
icc_place2822/ZN (INVX8_LVT) 0.04 *7.71 r1.08
icc_place2503/QN (NOR2X4_LVT)0.05 *7.76 f1.08
U2225/QN (NAND2X4_LVT)0.04 *7.80 r1.08
U2612/QN (NOR2X4_LVT)0.05 *7.84 f1.08
U2482/QN (NAND2X4_LVT)0.05 *7.90 r1.08
U2351/QN (NOR2X4_LVT)0.04 *7.93 f1.08
U2347/QN (NAND2X4_LVT)0.05 *7.98 r1.08
U2591/QN (NAND2X4_LVT)0.04 *8.02 f1.08
U2266/QN (NAND2X4_LVT)0.06 *8.08 r1.08
icc_place2761/ZN (INVX4_LVT) 0.02 *8.10 f1.08
icc_place2782/QN (NAND2X4_LVT)0.04 *8.14 r1.08
icc_place2784/QN (NOR2X4_LVT)0.03 *8.17 f1.08
U6906/QN (NOR2X4_LVT)0.04 *8.21 r1.08
U6584/QN (NAND2X4_LVT)0.08 *8.29 f1.08
icc_place2347/ZN (INVX8_LVT)0.07 *8.36 r1.08
icc_place2337/ZN (INVX8_LVT)0.04 *8.39 f1.08
U6368/Q (MUX21X1_LVT)0.11 *8.50 f1.08
ram_top1_ram1_u_ram_wrap_DOA_reg_0_/D (SDFFX1_LVT)
0.00 *8.50 f1.08
data arrival time8.50
clock clk (rise edge)9.009.00
clock network delay (ideal)0.009.00
clock uncertainty-0.368.64
ram_top1_ram1_u_ram_wrap_DOA_reg_0_/CLK (SDFFX1_LVT)
0.008.64 r
library setup time-0.188.46
data required time8.46
------------------------------------------------------------------------------------
data required time8.46
data arrival time-8.50
------------------------------------------------------------------------------------
slack (VIOLATED)-0.04
看你是在哪个阶段，我是在place阶段；你可以写个脚本，用useful skew处理一下！
工具对fanout超过一定数值的net会降低延时计算精度，比如降到Elmore。对EDI，这个值默认是100，所以不修改这个默认值的前提下让fanout>100是肯定不行的...
我的fanout 没有大于100啊 是77；
试试把reg2reg再细分几个group，时序最差的weight最小，时序次差的weight加大点，有时能收干净有时收不干净的weight设到最大（100?）. tips：group_path命令有先后顺序。
恩 这个是个方法；问个问题 是不是执行过 place_opt之后 一般就不用place_opt了 而志勇psynopt来优化
place阶段，谢谢！
为什么时序最差的weight最小?
他的意思应该是权衡这些path吧，因为cost=slack*weight，最差的slack比较大，所以weight设置小一些，这样工具可以平衡地对待这些path
当然你的理解应该也可以，对slack比较大的weight设置再大一些，那么工具就会下大力度来修复这些slack比较大的path！
我这里的uncertianty可能约束太严格了，可以稍微放松些；在者，这里的违例也不是很大，可以放到cts和route阶段去修复；应该没问题的！还有从时序报告中可以看出，有一些inverter，如果非要在此阶段修，可以写个脚本删除一些inverter，这样此阶段的违例就会被修干净，可能会新出现drc错误，可以到cts阶段修；
额，好吧，谢谢您的解释
学习了