Open ports in special route summary

 Hi Kari

 After I enter setDelayCalMode -engine signalStorm and run verifyACLimit, I got the aclimit report something like below for clocks 

 NET clk_net (2)   Eff Freq: 50.000000
   PIN IOIN_clk.C
      Trise: 0.062375   Tfall:  0.034250   Vdd:    2.750000
          Irms      Limit          Width/CutArea       Cap     Layer      (x y)
       0.100246 $   1.597708           0.140000     0.024240        M3    (427.560 415.520)
       0.223936 $   1.575294           0.140000     0.054150        M4    (410.620 267.715)

 NET sclk_net (133)   Eff Freq: 25.000000
   PIN IOIN_sclk.C
      Trise: 0.259625   Tfall:  0.138375   Vdd:    2.750000
          Irms      Limit          Width/CutArea       Cap     Layer      (x y)
       0.007094 $   1.575294           0.140000     0.004901        M4    (446.180 419.720)
       0.006571 $   1.597708           0.140000     0.004541        M3    (447.440 418.320)
       0.002415 $   1.597708           0.140000     0.001669        M3    (448.980 418.320)
       0.003684 $   1.575294           0.140000     0.002545        M4    (448.700 414.540)
       0.010678 $   1.575294           0.140000     0.007378        M4    (441.700 422.100)
       0.010305 $   1.597708           0.140000     0.007120        M3    (443.940 421.120)
       0.013516 $   1.597708           0.140000     0.009339        M3    (440.300 423.080)
       0.013914 $   1.575294           0.140000     0.009614        M4    (438.900 421.960)
       0.003236 $   1.575294           0.140000     0.002236        M4    (424.340 408.100)

 I had a quick lookthrough the report, did not find any Irms over  the limit. Does it mean everything is fine and I can ignore the AC limit violation reported by reportClocktree.

Thanks a lot

 I didn't realize that reportClockTree was what reported the ac violations for your clock. Can you tell me what options you used for the reportClockTree command?

The detailed verifyACLimit report looks good - meaning, you are getting AC values for your nets, and they are below the limit. So you can go back to running without -detailed, and it will only report violations. From your previous runs, it seems like there are no violations, so I just want to try to figure out why reportClockTree thought there were.

 Hi Kari,

For reportClockTree, I use reportClockTree -clk clk -postRoute -report clocktree_clk_postRoute.rpt.  And I use setCTSMode -useLefACLimit true -powerAware true, before CTS. 

And just today, I found there is another issue for CTS, after CTS, there is unwanted clock input port called clk_net__L2_N1 has been generated for the core design module, like shown below. The clock is connected to many registers of our design, and It causes wrong post-layout simulation results, because the extra clock port is not connected with the outside stimulus. I can not image how and why the tool can create a new input port for a module. Could you please help me on that as well.

 module ptmac (
    instruction_i,
    data1,
    data2,
    rst,
    clk,
    data1_address,
    data2_address,
    inst_address,
    port_out,
    dce,
    dwe,
    port_in,
    pce,
    wake_input,
    sleep,
    pwe,
    acc_out,
    cs,
    sclk,
    si,
    so,
    instruction_o,
    data_o,
    clk_net__L2_N1);

Thank you very much for your help

Wei

 The strange clock input port was gone, after I modified Maxskew in clock specification file. The previous maxskew value was too tight. 

 If reportClockTree is showing ACLimit violations that verifyACLimit is NOT showing, then that sounds like you need to file a service request. I have never used reportClockTree to check AC limits; I always use verifyACLimit.

As for the clock ports, it's not unusual for CTS to add ports where it thinks it needs them. If you want to prevent that, and your modules are fences, you can use setCTSMode -honorFence. There may be some other ways to control it too, but it sounds like you already found the solution for your design.

 Hi Kari,

Thank you very much for your help