( ESNUG 356 Item 2 ) --------------------------------------------- [8/03/00]
Subject: Cadence Diva LVS Tricks For Differentiating Identical Devices
> I have a little problem, I made a layout of a circuit which is symetrical
> in architecture but not in parameters: A differential input with 2
> resistors load. The only difference is transistor width.
>
> When I do a LVS, the netlists don't match, the netlister would want me to
> invert my 2 transistors. When I add an output pin, the problem is solved
> (the circuit becoming non-symetrical).
>
> Anybody know how to do to solve this problem without adding a new pin??
>
> - Sami Aissa
> Matra Nortel
From: Jay Lessert <jdl@teleport.com>
Since you haven't told us what tool you're using, the tool-independent way
is: Simply label (not pin) one of the internal nodes in both the schematic
and layout.
- Jay Lessert Portland, OR
---- ---- ---- ---- ---- ---- ----
From: Jim Thompson <Jim_T@analog-innovations.com>
Yep, that's the way I do it. Although sometimes even that doesn't work, so
the layout guy and I work in concert and add dummy resistors (metal) to
trick the LVS software into looking from the right direction.
- Jim Thompson
Analog Innovations, Inc. Phoenix, AZ
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
I'll assume were talking about a Cadence LVS run with Diva here, and add one
more possibility. Using Diva LVS, you can attach a "signature" property to
extracted devices when running Diva EXT.
(You should be able to find exact syntax on Cadence Openbook or SourceLink.)
This assigns a unique integer to each instance. In theory, if all the
parameters match for two instances of the same device, the devices are
identical anyway, and you aren't worried about it.
You could set it up by saying some variable "X" is your integer, and given
"w" (width) & l(length), you can do something like X=int(w*1e6 + l). Make
sure, just in case, you don't set this up so that different values of w & l
can yield the same "X". The more CDF variables you can use, the more you
can rely on a unique result, and for practical purposes you should probably
try to incorporate any variables you would normally netlist. In practice,
if you set this up in a test case with all your process devices and a good
amount of symmetry, and add the signature rountines this way for devices
getting confused until it seems to clear up, you can probably eliminate LVS
confusion without needing to add labels.
Having said this, there are still two catches:
(1) Somewhere in the int() function or the Diva extractor, (maybe the
signature routine itself,) there is usually some roundoff error... you
can explore this further by just adding some printf's in your EXT file
if you need. You'll want to round *up* the total value before
truncating to an integer type. Round-off error occurs after 8 decimal
places, and if you're setting up your code to require a match within a
tight tolerance, it won't help you if your Diva decks tell you
"1+1=0". (Of course, Cadence says this isn't a big enough problem to
fix anytime soon, and doesn't see the urgency in having its multi-
million-dollar toolset *not* giving you "1+1=0" from roundoff... but
that's another story.)
(2) The signature routine will cause LVS error reporting to be changed,
and it will be less informative. At this point, for the "altered"
devices, LVS is comparing the device and its signature, not the device
and separate parameters...still you should quickly be able to find and
figure out what's the matter, and the goal of an accurate LVS run
that's easier to use to debug seems to me to be worth the sacrifice.
If you set up the signature routine correctly, all the parameter info is
there anyway, ready to use... you just have to look at it.
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
The LVS rule parameterMatchType can be used to differentiate between
otherwise identical devices. It works by allowing the user to generate an
integer value which becomes a device subtype, incorporated into the
signature of the device instance. The main problem with using this rule is
that it does not work very well in the following case.
Two resistors are in the layout and two are in the schematic. There is no
visible difference based on how they are wired. In the layout, one has a
value of 99 while the other has a value of 199. The schematic resistors
have the value 105 and 190.
Looking at this, you would say (being able to deal with fuzzy logic as
you are) the 99 goes with 105 and 199 does with 190. LVS, not being very
bright about things like fuzzy logic, does not use the parameters to
help it along. So you use parameterMatchType to help.
The formula chosen in the required SKILL function is fix(R/100.0) since
most of your resistors are under one thousand ohms. 99 become 0. 105,
190 and 199 all become 1. Now we have a resistor with subtype 0 and
three resistors with subtype 1.
LVS now guesses that the one layout subtype 1 resistors matches to one
of the two schematic subtype 1 resistors. It then sees that there are no
subtype 0 resistors in the schematic and never manages to match the
remaining layout resistor to anything. And, by random chance, it matched
the wrong schematic resistor when it made the guess.
Not very helpful.
Enter parameterMatchDegree. A rule which allows LVS to ask the user
SKILL function how well every possible pair of layout to schematic
devices match. Since the set on each side is relatively small, this does
not take long, and it does not change the device type. Sounds very
useful, sort of does that fuzzy logic thing, too bad it has not been
coded into LVS.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
Pretty much, I agree with your analysis, and it points up *exactly* why you
need to be careful with signatures.
First, you can have two different resistors with identical R... which is one
reason I mentioned (and suggested) both "w" & "l" in my earlier letter.
Yes, it seems like overkill to some, but it's easy enough to add the 2-4
lines of extra code and make your LVS run more reliable.
Second, I wouldn't be truncating any part of the value of a netlisted
parameter used in the signature... I'd be more inclined to make it R*1 or
R*(10^(+int)) if I was going to use "R" at all. To make this scheme work,
you need to use all the precision on each netlisted variable that you can
get. If your grid is DSM, maybe you want to multiply W & l each by another
100 for the purpose of the signature routine... over and above the factors I
suggested earlier, that is.
Third, especially as you remove significant digits, you add to the
possibility of roundoff error. What you did was essentially reproduce the
issue I had with "1+1=0" in a different circumstance. (Actually, you give
1=1 and 1=0, which is a variation of the problem, but a more common version
that programmers run into with "int" or "fix" functions in many languages.
This should also tell you how cautious you have to be about this particular
problem.)
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
Unless you can get your resistors to be drawn to the exactly correct
value to match the schematic, you pretty much have to trim the low order
digits away or you won't get any match at all. That's part of the
problem with parameterMatchType, it actually changes the device type so
different subtypes cannot be matched.
Your proposal makes each resistor value into a separate subtype so there
is no possibility of slightly different values being matched. In most
rule decks I have seen, there is a tolerance built into the property
comparison routines to allow for small differences in the value between
the layout and the schematic.
By adding L and W, you actually restrict the designer even further. Not
only does the resistance have to be exactly correct, you also require
that the W and L be the same. No longer can the designer have any leeway
to make the device a little shorter and thinner or longer and wider to
accommodate the environment the resistor is drawn in. Bends in the
device are almost impossible since they change the final resistor value
for a given L and W. Perhaps you are not including the bend factors,
which reduces the accuracy of your extraction, especially for the
smaller valued devices.
Personally, I'd like to see more people asking for better algorithms in
LVS. Except for runtime issues, there is no reason LVS cannot try each
of the possible matches and use the one that results in the least number
of unmatched devices. Kind of like a chess program set to "annihilate
the human" does to find the best possible move. Couple that with helpful
hints like my suggested parameterMatchDegree rule and it may be able to
find the correct match every single time there is one, with tolerable
runtimes.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
Again, there's a lot to agree with here, partly based on what you're trying
to do.
Still, using pcells and a fixed sheet rho, if you were to use "R" or
"Rtotal" for a resistor, calculating an exact value might be valuable. You
could actually use LVS as a tool to identify versions before and after
process changes, for example, and make sure you replaced obsolete devices.
My slant on this is to make the tool as accurate as you can make it, and
make sure the user doesn't get "false positives". (And why would you want a
different equation or different constants between layout and schematic,
anyway? You *should* be able to get exact matches.) My own concern
centers around this: allowing a match where none should exist.
I'll also say my experience is *not* writing Diva code for bleeding-edge,
hundred-million-transistor chips, where, if it runs at all, speed has to be
a priority, and you're probably talking about hierarchical over flat
netlisting.
As for defining "slightly different" resistor values, you can build a
tolerance into the code after getting as exact a match as you can in the
signature routine. As you pointed out, you've got to be careful about how
much precision you use, because you can get false matches or false
mismatches if precision and tolerance aren't set right. Also, because of
roundoff within Cadence tools, you have to have *some* tolerance in the
code. Period. I just prefer a small tolerance when I can get away with it.
I'd also agree entirely that bends make Diva extraction more
difficult...though not entirely impossible...but even if you consider this,
there are places out there that don't use snaking resistors or snaking
MOS's, and probably don't calculate metal resistances except for some
parasitic analysis that doesn't touch Diva. Or, you could have a (hidden?)
parameter in your schematic-side CDF that would let you backannotate R (or
other parameters) when you find out you have to add bends in a device being
extracted. (Obviously, that's not the ideal solution, but I think it may be
better than dummy components to force a match.) Regardless, there should be
an equation somewhere that tells you how to handle bends in calculations if
you use them, and, again, there are lots of different directions you can
take from there.
Ultimately, it's figuring out the best tools and methodology to do what you
need. And I think we've proved this is a fairly complex topic by how much
we've been writing on a side-topic to the original message.
And I will have to try your suggestion of parameterMatchDegree when I get a
chance...sounds like an interesting solution!
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
I wish you *could* try using parameterMatchDegree, but it is not in LVS.
It is a feature that I feel should be added as a replacement for the
almost totally useless parameterMatchType, which should be deleted.
- Ed Kalenda
|
|
