Assura LVS Parameter Mismatch Error

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.

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.

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.