PAD延时太大怎么办

qxy1991

最近刚在做65nm的物理版图，发现时序违例总是出现在I2R或R2O路径上，IO口是由虚拟时钟控制的，看时序报告发现是因为PAD延时太大了（如下表红色所示）。Startpoint: TOP_Dip[1] (input port clocked by vir_clk_in)
  Endpoint: Core_Module/M/nonce_reg_28_
            (rising edge-triggered flip-flop clocked by clk_o1_200)
  Path Group: INPUTS
  Path Type: max

  Point                                       Fanout      Incr       Path      Voltage
  ------------------------------------------------------------------------------------
  clock vir_clk_in (rise edge)                            0.00       0.00      
  clock network delay (ideal)                             0.00       0.00      
  input external delay                                    0.50       0.50 r   
  TOP_Dip[1] (in)                                         0.00       0.50 r   
  TOP_Dip[1] (net)                              1         0.00       0.50 r   
PAD_TOP_Dip_1/C (PISR)                                  1.60 *     2.10 r    1.08
  Dip[1] (net)                                  1         0.00       2.10 r   
  Core_Module/Dip[1] (cs256h_top_cs256h_core_0)           0.00       2.10 r   
  Core_Module/Dip[1] (net)                                0.00       2.10 r   
  Core_Module/M/NonceStartSel[0] (cs256h_top_enc256_top_0)
                                                          0.00       2.10 r   
  Core_Module/M/NonceStartSel[0] (net)                    0.00       2.10 r   
  Core_Module/M/U120/ZN (INV40_HD1LVT)                    0.07 *     2.17 f    1.08
  Core_Module/M/n509 (net)                      1         0.00       2.17 f   
  Core_Module/M/U111/ZN (CLKNV40_HD1LVT)                  0.07 *     2.24 r    1.08
  Core_Module/M/n508 (net)                      1         0.00       2.24 r   
  Core_Module/M/U845/ZN (INV40_HD1LVT)                    0.06 *     2.30 f    1.08
  Core_Module/M/n679 (net)                      1         0.00       2.30 f   
  Core_Module/M/U841/ZN (INV40_HD1LVT)                    0.07 *     2.38 r    1.08
  Core_Module/M/n678 (net)                      3         0.00       2.38 r   
  Core_Module/M/U720/ZN (NAND2V16_HD1LVT)                 0.06 *     2.44 f    1.08
  Core_Module/M/n238 (net)                      4         0.00       2.44 f   
  Core_Module/M/U647/ZN (CLKNV12_HD1LVT)                  0.02 *     2.46 r    1.08
  Core_Module/M/n242 (net)                      1         0.00       2.46 r   
  Core_Module/M/U718/ZN (AOI32V4_HD1LVT)                  0.07 *     2.53 f    1.08
  Core_Module/M/n240 (net)                      1         0.00       2.53 f   
  Core_Module/M/U127/ZN (CLKNAND2V4_HD1LVT)               0.04 *     2.57 r    1.08
  Core_Module/M/n82 (net)                       1         0.00       2.57 r   
  Core_Module/M/nonce_reg_28_/D (DQV1_HD1LVT)             0.00 *     2.57 r    1.08
  data arrival time                                                  2.57      

  clock clk_o1_200 (rise edge)                            2.50       2.50      
  clock network delay (ideal)                             0.00       2.50      
  clock uncertainty                                      -0.60       1.90      
  Core_Module/M/nonce_reg_28_/CK (DQV1_HD1LVT)            0.00       1.90 r   
  library setup time                                     -0.05       1.85      
  data required time                                                 1.85      
  ------------------------------------------------------------------------------------
  data required time                                                 1.85      
  data arrival time                                                 -2.57      
  ------------------------------------------------------------------------------------
  slack (VIOLATED)                                                  -0.73      


查看IOlib库里的延时，发现这个数值是差不多的，现在又没办法找到另一个延时更小的库，求问还有没有什么办法可以解决？
师兄建议说可以设置clock_latency，给真实时钟都设置了一个1ns的clock_latency，发现I2R的时序问题的确是解决了，但是R2O的问题变得更严重，而且设置这个clock_latency不知道会不会给芯片造成不好的影响？