place后violation和fanout除了psynopt和增加weight还有什么办法【已解决】

jiazhang

（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违例如何修?

jiazhang

回复 1# jiazhang


   

icfbicfb

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的要求就行了

Alicezw

回复 1# jiazhang


    第一个问题我也遇到了，求更好的解决方法，谢谢！

jiazhang

回复 3# icfbicfb

恩 版主说的有道理！fanout不是硬性要求！

对于setup违例！我选了其中一条违例的，看了下，这里面工具已经将其全部优化成LVT了；而且从报告中看不出有


哪些cell异常! buffer的话 其中有10个，不知道算不算多呢，版主！请版主知道下如何优化

自己用写了个脚本，用usefulskew处理了下，修复了其中一些setup 违例；由于没有考虑用userful skew之后hold的问题，所以修复完之后又出现了一些hold违例！


不过hold违例在place阶段应该不用管！


  clock clk (rise edge)                                                                   0.00       0.00      
  clock network delay (ideal)                                                         0.00       0.00      
  rom1_u_sram0/CE (SRAM8x1024_1rw)                                       0.00       0.00 r    1.08
  rom1_u_sram0/O[0] (SRAM8x1024_1rw)                                    7.11       7.11 f    1.08
  icc_place2620/ZN (INVX4_LVT)                                                   0.07 *     7.19 r    1.08
  icc_place2621/ZN (INVX16_LVT)                                                 0.06 *     7.24 f    1.08
  icc_place2728/QN (NOR2X4_LVT)                                               0.09 *     7.33 r    1.08
  icc_place2823/QN (NOR2X4_LVT)                                               0.05 *     7.39 f    1.08
  icc_place2824/ZN (INVX8_LVT)                                                  0.06 *     7.45 r    1.08
  icc_place2770/ZN (INVX16_LVT)                                                0.05 *     7.50 f    1.08
  icc_place2734/ZN (INVX16_LVT)                                                0.05 *     7.55 r    1.08
  icc_place2818/QN (NAND2X4_LVT)                                             0.04 *     7.58 f    1.08
  icc_place2788/ZN (INVX4_LVT)                                                  0.04 *     7.62 r    1.08
  icc_place2819/QN (NAND2X4_LVT)                                             0.05 *     7.67 f    1.08
  icc_place2822/ZN (INVX8_LVT)                                                  0.04 *     7.71 r    1.08
  icc_place2503/QN (NOR2X4_LVT)                                               0.05 *     7.76 f    1.08
  U2225/QN (NAND2X4_LVT)                                                        0.04 *     7.80 r    1.08
  U2612/QN (NOR2X4_LVT)                                                          0.05 *     7.84 f    1.08
  U2482/QN (NAND2X4_LVT)                                                        0.05 *     7.90 r    1.08
  U2351/QN (NOR2X4_LVT)                                                          0.04 *     7.93 f    1.08
  U2347/QN (NAND2X4_LVT)                                                        0.05 *     7.98 r    1.08
  U2591/QN (NAND2X4_LVT)                                                        0.04 *     8.02 f    1.08
  U2266/QN (NAND2X4_LVT)                                                        0.06 *     8.08 r    1.08
  icc_place2761/ZN (INVX4_LVT)                                                  0.02 *     8.10 f    1.08
  icc_place2782/QN (NAND2X4_LVT)                                             0.04 *     8.14 r    1.08
  icc_place2784/QN (NOR2X4_LVT)                                               0.03 *     8.17 f    1.08
  U6906/QN (NOR2X4_LVT)                                                          0.04 *     8.21 r    1.08
  U6584/QN (NAND2X4_LVT)                                                        0.08 *     8.29 f    1.08
  icc_place2347/ZN (INVX8_LVT)                                                  0.07 *     8.36 r    1.08
  icc_place2337/ZN (INVX8_LVT)                                                  0.04 *     8.39 f    1.08
  U6368/Q (MUX21X1_LVT)                                                          0.11 *     8.50 f    1.08
  ram_top1_ram1_u_ram_wrap_DOA_reg_0_/D (SDFFX1_LVT)
                                                                                                 0.00 *     8.50 f    1.08
  data arrival time                                                                       8.50      

  clock clk (rise edge)                                                                   9.00       9.00      
  clock network delay (ideal)                                                         0.00       9.00      
  clock uncertainty                                                                       -0.36       8.64      
  ram_top1_ram1_u_ram_wrap_DOA_reg_0_/CLK (SDFFX1_LVT)
                                                                                                 0.00       8.64 r   
  library setup time                                                                      -0.18       8.46      
  data required time                                                                     8.46      
  ------------------------------------------------------------------------------------
  data required time                                                                     8.46      
  data arrival time                                                                        -8.50      
  ------------------------------------------------------------------------------------
  slack (VIOLATED)                                                                      -0.04

jiazhang

回复 4# Alicezw

看你是在哪个阶段，我是在place阶段；你可以写个脚本，用useful skew处理一下！

Timme

工具对fanout超过一定数值的net会降低延时计算精度，比如降到Elmore。对EDI，这个值默认是100，所以不修改这个默认值的前提下让fanout>100是肯定不行的...

jiazhang

回复 7# Timme
我的fanout 没有大于100啊 是77；

Timme

试试把reg2reg再细分几个group，时序最差的weight最小，时序次差的weight加大点，有时能收干净有时收不干净的weight设到最大（100？）. tips：group_path命令有先后顺序。

jiazhang

回复 9# Timme

恩 这个是个方法；问个问题 是不是执行过 place_opt之后 一般就不用place_opt了 而志勇psynopt来优化