Assura LVS Parameter Mismatch Error

It's unlikely to be Assura's fault - it's probably the rule deck (or the rule deck not being used properly). This is something that you either need to take up with the foundry (TSMC) or maybe as a first step Cadence Customer Support - that way we can look at the exact situation  you have - and retrieve the rule deck for the specific document number you have (there are several 130nm processes, so we'd need to check the right one) and check what's going on.

Regards,

Andrew.

Tony,

When you say it only works when just 1 finger is used, do you mean just 1 finger in the layout?  If so, then have a look at the netlist on the schematic side. Since you said it was a generated pcell, I assume you are using XL and the schem device has fingers=5. If still so, then it sounds like your schematic is not netlisting correctly within Assura.  (assuming you are netlisting through Assura)  We are seeing something similar, using Assura in a completely different PDK, different process, different fab, and in 6.17.  Our netlists on the schematic side don't correctly reflect some of the parameters (such as numberOfFingers or multiplier) as defined in the schem, so we see similar parameter errors.  Not blaming Cadence for this, but we haven't figured it out yet.  If you can't get past this,  2 possible workarounds, until the real problem is determined, are:  1) try creating a CDL netlist first and reference that in your LVS run, or 2) consider requesting that the parameters of the schematic device be changed such that numberOfFingers is changed from 5 to 1, while either the multiplier is changed from 1 to 5, OR the instance is arrayed <5::0>.  When you (re) generate the layout device you will get 5 individual units rather than one 5-finger unit and will have to overlap the S/D's yourself - no big deal - and you might find better LVS results.  Good luck.

To clarify, I tend to agree with Andrew in that it is not likely Assura, but perhaps the deck, which points at the PDK and thus the foundry.  That is our suspicion for our own issues as well, but at this point that is only a guess.  In the meantime we look for workarounds so we can keep cranking.  The alternative methods I mentioned have been successful for that.

Maybe you could play with the auLvs simulation information in the CDF for the component in question to get it to netlist the right parameters, but that still assumes the LVS rules will be taking those parameters into account when combining them (if it works with auCdl, they probably are). Either way, I'd suggest you contact the foundry - potentially Cadence Customer Support could help too if we can see the setup and then give some advice on what to change to make it work.

Regards,

Andrew.

Hi Budlah and Andrew,

Thank you very much for your reply and suggestions.

Like Budlah said, "Just 1 finger" means only 1 finger in the layout.

I'm using ASSURA DFII. But I'm not very familiar with how ASSURA works, so I'm not sure if that means I'm netlisting through ASSURA.

I tried changing multiplier in the device properties in schematics, but somehow that didn't work, ASSURA still gives the same LVS error.

However, renaming the device name to <0:4>, basically like doing a manual multiplier in schematics, and then re-overlapping it in the layout, and it worked, on the exact same-looking layout!

That only solved part of my problem though, as I encountered a new LVS parameter mismatch error on a MiM cap. It says 

Schematic Instance: C0 mimcap
Layout Instance: avD90_1 mimcap_1p0_sin

c 4.99952e-12 vs 3.34349e-12 differs by 33.1238%
Layout Instance is the merged result of: avD90_1 avD90_2 avD90_3 avD90_4

While all I did is to route an auto-generated MiM cap cell in the layout.

Shall I open a new thread with this? Andrew Beckett

Many thanks again to both of you.

-Tony

Again, this new issue is specific to the technology you're using - and also might be related to what you've done in the layout. It's unlikely we can provide much help in the forums without being able to see more - so I'd suggest contacting the foundry or maybe customer support, as I suggested before.

Regards,

Andrew.

Thanks Andrew.  I'll suggest that to the parties looking into it.  I'm more of an end user waiting at the mercy of the tools guys to get stuff up and running, while wishing I had more ability in that area myself.  It feels like we need to (find, then) flip a switch to change the options on what I think is, as of yet, a rather primitive, barely locally developed, out of the box product.  As I am currently ignorant on the topic, can you describe briefly the diff between auLvs and auCdl?  I have a feeling I can guess that (type of netlisting?), based on your statement.

Another mystery 'we' are trying too chase down is (trying to find, and flip an options switch, probably) getting Assura LVS to not ignore dummy devices that are fully tied off.  Examples of such devices would be a simple N-channel with source/drain/gate/bulk all tied to ground (or VSS), or a P-channel that has all nodes tied high.  I move from place to place frequently, so I get to 'use' varying setups in terms of how teams have tailored their pdk interpretations and local runsets.  So, at one place, dummy resistors can be totally ignored in LVS (not my preference), while in another place ANY device in the layout or schem, whether their nodes are tied together or not, must be accounted for.  Some folks just don't care about that.  Where I'm currently working, these devices are being ignored but we would prefer they not be ignored, and verified instead.  Haven't figured out this one yet, though.  I'm fairly sure this is simple, but don't know the method with Assura.  (In the distant past, I've found and altered lines of code in (non-Cadence) decks where the option was switched.) 

-Jim

Jim,

auLvs and auCdl are two different netlisting approaches. auLvs was originally a netlister for Diva - for Assura it doesn't actually produce an "auLvs" netlist, but uses the same CDF information to control which parameters are read for LVS. auCdl produces a "CDL" (Component Description Language, a SPICE-like format which originated with Dracula and has been extended considerably by various LVS tools since). Both are means of providing the input to the schematic side of LVS.

For the second part, this is controlled by the filterDevice and filterOptions functions in the rules. Look in the Assura Physical Verification Command Reference  manual for more details.

Regards,

Andrew.

Hi Tony,

Did you solve your problem? If yes, how did you do it?

I am facing almost the same problem. I have an inductor in my design. While its spacing is 4 um both in schematic and layout, LVS report sees it as ~1um. When I go layout and measure its spacing manually, it is indeed 4 um. This problem had occurred once again for simple MOS transistors. While they had 4 fingers, LVS reported that they have 8 fingers. For the MOS case, I found a workaround by chainging the number of fingers of MOS in schematic keeping the total width/length. But for the inductor, the pdk does not allow me to give a spacing value less than 2 um.

Do you have any suggestion for me?

I am using Cadence Virtuoso 6.1.3 and Assura 6.1.3.. My netlist type is DFII and the pdk that I am using is HHNEC 0.18um.

Thank you for any kind of help in advance.

Kind regards,
M.Ali

Hi Ali,

It's been a while so I don't remember every detail of the problem. If I remembered correctly - it seemed to be an issue with the LVS schematic extraction, and I followed Budlah's advice, avoiding the use of multi-fingered instances and instead use <0:n> arrayed ones and it worked out fine.

Specific to the problem you're facing, does LVS work with a schematic & layout with only the inductor instance? If it's still problematic, then I would suggest either try using a different inductor option, or carefully simulate the physical layout, ensuring it connects to where it should connect to and works as it should work, then check off the error with the foundry (basically living with the error and waiving your rights to complain if the taped out chip didn't work, do allow for ample time to communicate!).

Good luck and best,

Tony