Open ports in special route summary

 You can run Verify Connectivity on the SpecialNets and see if it will point you to the opens. Depending on your design, it may also show violations that are not an issue. (For example, the followpins on a block may show opens at the edge of the block, but you know when the block is placed in the top-level, this will be ok.)

Hi Kari,

After I run the command of verifyConnectivity -type special, it shows "Found no problems or warnings.". Do it mean everything? and can I ignore those open ports in sroute summary.

Thank you very much

 You should do a visual check of your design. Highlight all the pwr/gnd IO pads, and make sure they all connect into the pwr grid. Take a look at each macro and make sure there are pwr/gnd connections to each. The std cells should all be connected to the followpin rails, but you may want to make sure each rail vias up to a stripe. You can run verifyPowerVia to make sure you have no missing vias in your pwr/gnd grid. Make sure you run an IR-drop analysis as soon as you can to point out any weaknesses in the grid.

 Hi Kari,

I checked all the pwr/gnd IO pads and pwr/gnd pins of blocks. They are connected to the pwr/gnd nets. I run verifyPowerVia and got 4 missing vias. For IR-drops, they are very small, just 1 or 2 mV, and my design is not high speed. Do you think the power plan should be OK, after I fix the missing via issue.

Another issue is about EM, after CTS, I got some AC Irms Limit Violation on clocks. But after routing, when I run verifyACLimit, I did not get any violation. So can I ignore those AC violation for clock after CTS?

Thanks a lot 

 Your visual check sounds good. Definitely fix the 4 missing vias. For the IR Drop, 1 or 2 mV sounds small, but what percentage of your design voltage is that? (We typically aim for no more than a 5% drop across the chip, meaning 2.5% VDD and 2.5% VSS.)

When you ran the verifyACLimit after CTS, were the clocks routed with NanoRoute, or just trialRouted? Make sure that your tech LEF contains the ACCURRENTDENSITY RMS table to be sure the right values are being used.

 Hi Kari,

The voltage of our design is 1.2V, so I think 1 or 2 mv should be fine.

 And I use verifyACLimit after NanoRoute, the clock report is after nanoroute as well like below.

 ***** AC Irms Limit Violation *****
Pin Name                         (Actual)     (Required)   (Violation)  
-------------------------------------------------------------------
clk                              2.99717(mA)  1.57529(mA)  1.42188(mA)

I checked the tech file. There is ACCURRENTDENSITY RMS table for each metal like below.

ACCURRENTDENSITY RMS
        FREQUENCY    500 ;
        WIDTH        0.14 0.28 0.56 1 5 12 ;
        TABLEENTRIES 11.1679 8.4415 6.3908 5.1654 3.4313 3.0917 ;

 So I can not tell whether the right one be used for AC limit check

Thank you very much

 But you're saying that when you run verifyACLimit after routing the rest of the design, you don't see any violations? The LEF numbers look correct, so I would think that that's a real clock AC Limit violation, but you should see it anytime you run verifyACLimit. Do you use large buffers/inverters in your tree, and do you route the clocks with a nondefault rule that's twice the default width?

 Hi Kari,

I run the verifyAClimit again after nanoroute, the result is below

 encounter 9> verifyACLimit

******** Start: verifyACLimit ********
Start Time: Thu Jun 17 21:24:10 2010

Irms Scale Factor: 1
Report File: top.aclimit.rpt
Timing Analysis Mode: CTE
Verifying all signal nets.

Num Violations: 0

The reportclocktree command can know the frequency from clock spec file. I am wondering whether verifyACLimit can know the frequency of my design, since the default frequency is 500 in ACCURRENTDENSITY RMS table. But my design has one clock at 50MHz and the other is 25MHz. I use verifyACLimitSetFreq before verifyACLimit, but the result is same. I did not use any special setting for routing clock during nanoroute and how can I know how many buffers/inverters have been inserted in clock tree?

Thank you very much again

 I think you're doing everything right, but just to double-check, try running:

verifyACLimit -detailed -report aclimit.rpt

Also try running without verifyACLimitSetFreq - then a toggle rate of 1 (100%) is assumed, which is pessimistic, but may give us some more info to look at. (You can also set the toggle rate with the -toggle parameter.) If you want the data from verifyACLimitSetFreq to be used, then you have to run verifyACLimit with the -use_db_freq parameter.

The frequency number in the ACCURRENTDENSITY table is not used anywhere in the calculations, so you can ignore that. In fact, it's often listed as just "1". 

To see how many clock buf/inv were added, look at the clock.report file that was generated during CTS. You can also use the Clock Tree Browser or the Clock Tree Analyst in the GUI.

Finally, if the design is finished and you want to run everything in signoff mode, do the ac limit check after entering:

setDelayCalMode -engine signalStorm 

This will be more accurate.

Let me know how the clock nets look in the detailed report.

- Kari

 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