AnsweredAssumed Answered

LVS error in IO pads with multiple power rails

Question asked by gopakumarg on Sep 23, 2013
Latest reply on Sep 30, 2013 by dan_liddell

Like • Show 0 Likes0
Comment • 3

In my full chip design I have multiple IO pad groups, one regular IO, 2 pairs of Oscillator IO with their corresponding supplies, A pair of analog VD, VS Pad. The VSSIO ring is common to all these pads for ESD purpose. The VDDIO, VDD, VSS power rail for each group were given different names ( like VDD1, VDD2, VDDIO1 etc). In LVS the connectivity is not matched. The FX mismatch says that the particualr power nets of each IO pads are connected to some nets with different numbers ( 3456 etc) instead of VDD1 or VDDIO1 or VSSIO). I can see that both the layout and source has the nets, but the layout names corrsponds to some numbers rather than the net name. How can I solve this?

Also there are ESD diodes for all these Pads which is being reported as unmatched instance. Please help me solve the issue.

thanks

Gopakumar

No one else has this question

Outcomes

3 Replies

dan_liddell Sep 27, 2013 4:54 PM
Mark Correct
Correct Answer
Hi Gopakumar,

Is the circuit extraction report (.ext file) clean? Any shorts, opens, or bad devices?

As far as the instance mismatches go, it sounds like you have devices not being recognized in the layout. If the circuit extraction report shows BAD DEVICE errors, that may show the problem directly. If not, I would check the DEVICE statements in the rule file to ensure they cover the devices you need. Pay particular attention to the pin and seed layers. Ensure they are derived correctly and that the pin layers have connectivity in the CONNECT set and the layer derivation tree.

The rule file analyzer (calibre -svrf rules) can sometimes help with CONNECT and DEVICE issues. Use the HELP command to see a list of interface commands.

The unmatched diode instances might have something to do with the LVS errors you mention. You may not be getting the connectivity you expect across the diodes if they are not recognized.

If your connectivity text (TEXT LAYER) has been properly specified and attached, you should see your top-level nets get extracted with names. If that's not happening, check your TEXT LAYER statements and the method you use to attach those lables to nets.

dan
Like • Show 0 Likes0
Actions
gopakumarg @ dan_liddell on Sep 28, 2013 8:33 AM
Mark Correct
Correct Answer
Hi Dan,

thank you very much for the reply.
Actually my .ext file is not clean. It do have open and short , it says stamping conflict on all the ground pins of the IO cells, means VSS, VSSIO, VSSIO1, VSS1 all says shorted even though they are not in real. I have checked this manually, there is no chance that there can be a short, because the IO ring is completed by abutting the IO cells.

I do have a bad component , but the bad component is still the Diode inside the PAD. I haven't checked the TEXT layer, can you tell me how I can check it? Do you mean to say like whether I can see the top level ground and power as labels in the layout? If that is the case, my answer is NO, I cant see the power and ground names I gave. Please tell me how I can make sure the labels are there or not.

If I don't have the proper labels in the top lvel layout, please tell me how to assign them. ( In the layout I can see the VDD, VDDIO, VSSIO net names for each IO cell which ic inside the instance, but I cant see the power netname I assigned).

Sadly I have already asked for support from Metor for two times, both AE can't help me n sorting out. If some one can help I'm really thankful.

Thanks
Gopakumar
Like • Show 0 Likes0
Actions
dan_liddell @ gopakumarg on Sep 30, 2013 11:05 AM
Mark Correct
Correct Answer
You’re welcome.

The shorts in your connectivity extraction report are text shorts. This means there are conflicting text objects on the same net. The shorted net may be fine from a physical standpoint, but there are conflicting text objects present. When this occurs, Calibre has to choose which net label is correct and reject the superfluous ones. But, if a rejected one is, in fact, the correct label, then you could have problems during comparison.

I would turn on LVS ISOLATE SHORTS YES BY LAYER (BY CELL can also help) and track down these text shorts to eliminate them (use the .shorts database in RVE). Otherwise, you are asking for problems in LVS.

The open circuits almost certainly are errors. Those need to be fixed before going to LVS. It’s possible that the opens are due to omissions in the rule file. The CONNECT/SCONNECT set has to be complete for all the layers in the intended connectivity set. It’s also possible that text objects are incorrectly placed. The opens must be fixed before doing comparison.

The bad device situation must be fixed, otherwise the diode will never get recognized. The BAD DEVICE report will indicate which device is bad. Look at the rule file DEVICE definition. Are the pins derived correctly? Are they all present on the instances that are bad? The SVRF Analyzer (calibre –svrf) can assist with this. Look in the Calibre Verification User’s Manual for the documentation. The DEV, CONN, and LAYER commands can be particularly helpful.

Top-level ports are typically labeled. If not, you might be able to get all your nets extracted properly by changing the TEXT DEPTH statement. But, it’s probably better to label the pads. Look in your rule file for the TEXT LAYER statement. Those are the layers where connectivity text can be used. Use those layers to label your top-level ports. If your connectivity text layers are all in CONNECT statements, you should be fine. If not, check for ATTACH statements to get labels onto the proper layers.

dan
Like • Show 0 Likes0
Actions

LVS error in IO pads with multiple power rails

Outcomes

Related Content

Recommended Content