Normally, you should run lvs as follows: lvs -svDEd file.ext file.prs. The options mean the following:
-s : check that all state-holding nodes are staticized
-v : verbose error reporting
-d : digital checking only; don't look for charge-sharing problems.
-D : The extract file uses a slash as a subcircuit separator; this asks lvs to use "." instead (just like CAST)
-E : the input is an extract file.
Here's a simple scheme function that extracts the current edit cell,
calls cast2lvs cell.cast cell > cell.prs, followed by
lvs -vdDE cell.ext cell.prs where cell is the
name of the current edit cell (Note: this assumes a naming convention
for your CAST files as well as your CAST definitions).
We have some simple staticizers that you can use for your layout.
The files are ~rajit/stat/stat1.mag,
~rajit/stat/stat2.mag, and
~rajit/stat/stat3.mag. (The layout is not plugged.) Note
the sizes of the weak fets; make sure your opposing network
transistors are wide enough to overcome the weak inverter in the
staticizer.
If lvs complains about a "weak driver," make your
logic transistors wider (i.e. don't resize the staticizer if you are
using the ones provided). If lvs provides you with an
error message that you don't understand, read the lvs manual. There is a section of the manpage that
describes the error messages in more detail.
lvs might complain about certain types of
combinational logic requiring staticizers. For instance, this would
happen in the case of the restoring MUX in lecture 3. For the
restoring MUX production rules, both c and
_c are required. The problem is lvs cannot
prove that they are complementary (and technically, they are not!) so
it thinks the gate requires a staticizer. You can tell lvs to
assume that the c and _c are complementary
by adding the following before the prs {...} body in the
definition:
spec {
exclhi(c,_c)
excllo(c,_c)
}
which says that these two signals are both exclusively high and
exclusively low (which is the same as saying they are complementary).
lvs will now detect that the operator is combinational under
these assumptions.
Do not specify staticizers in your CAST file; lvs
will determine which nodes require one. Running lvs with
the -s option will check that dynamic nodes are
staticized.
Hierarchy
Namespace matching.lvs expects the namespaces
of your layout and CAST files to be consistent. This is not an issue
with simple subcells/defintions like NAND/NOR gates because the gates
themselves have no internal nodes. If you have a definition like
define foo() (node a, b)
{
node c;
prs {
a -> c-
~a -> c+
c -> b-
~c -> b+
}
}
then instantiating foo() (x,y); means that the internal
node c will have a name that is auto-generated by CAST;
this means that it won't match your layout. If the subcell
foo was instantiated in your .mag file with
cell id pqr, then you should replace foo() (x,y);
with foo pqr(x,y);. This will cause CAST to name the internal
node pqr.c, and it will match your layout since it knows
to match the production rules for pqr.c with layout in
cell pqr with a node in it labelled c.
Path/Filename Problems
If you are having problems with lvs finding extract files,
make sure you have a .magic file in your home directory with
the line addpath . in it.
