This file describes the rules used by the mbk(1) to
rds translator. In the following file, symbolic layout objects are
refered as mbk(1) objects, mbk(1) being the internal data
structure that supports symbolic representation. On the other hand,
rds is a data structure describing mainly rectangles, and is
therefore used for real layout representation.
Some syntaxic remarques on the way to write the file follow. The
case of identifiers is not significant, so NDIF is equivalent to NdiF.
Comments are allowed anywhere in the file, using the sharp (#) as
start of comment, and newline as end of comment. A line begining with
a sharp will be ignored, and a line containing a sharp will be
read up to the character preeceding it. A newline can be escaped
using the backslash ( followed by the newline. If some
character, spaces or tabs for example, follow the backslash, chances
are that a syntax error will be issued.
First, some important process parameters are needed, the physical
grid step, that is the least common multiple of all the technologies values
in terms of layout distances, and the lambda, computed from a careful
observation of the process design rules.
Then, a set of tables is needed, to describe how to translate a symbolic
object, belonging to the mbk(1) world, and a set of layout
rectangles, in rds.
Each table has a special meaning, and its parametrization exend beeing not
full, some borders are to be evocated. Several type of table exists indeed.
Some are needed for object translation, others for post treatment
parametrization, others to define cif or gds identifiers regarding rds ones.
Many things seem to be parametrizable, but in fact, mostly, if not only,
numbers, names in cif and gds translation tables, and boolean value in post
treatement may be changed without problems.
For any table, if some layer is not applicable, it can simply be
omitted. The default action is `do nothing', or use a value of 0.0 for all
entries.
The following lines describe the file, entry by entry, specifying
what is expected.
- Physical
grid
- DEFINE PHYSICAL_GRID .5
This statement defines the minimum grid spacing enforced by the
foundry.
- Lambda
- DEFINE LAMBDA 1
This defines the value of the lambda in microns. This value, like any other
one in the rest of the file must be a multiple of the
PHYSICAL_GRID.
- Segment translation
table
- TABLE MBK_TO_RDS_SEGMENT
This table contains all the informations needed to translate a symbolic
segment of a given layer onto one, two or three real rectangles of
specified layers. An example of this table is given below, with values
needed for a technology where one lambda is equal to 1.05 μ and the
design grid is set to 0.15 microns.
TABLE MBK_TO_RDS_SEGMENT
NWELL RDS_NWELL VW 3.15 6.30 0.0 ALL
NDIF RDS_ACTIV VW 0.60 -0.90 0.0 ALL \
RDS_NIMP VW 2.10 2.10 0.0 ALL
PDIF RDS_ACTIV VW 0.60 -0.90 0.0 ALL \
RDS_PIMP VW 2.10 2.10 0.0 ALL
NTIE RDS_ACTIV VW 0.60 -0.90 0.0 ALL \
RDS_NIMP VW 1.20 0.30 0.0 ALL
PTIE RDS_ACTIV VW 0.60 -0.90 0.0 ALL \
RDS_PIMP VW 1.20 0.30 0.0 ALL
NTRANS RDS_GATE VW 0.00 0.15 0.0 ALL \
RDS_ACTIV VW -1.50 4.35 0.0 ALL \
RDS_NIMP VW 0.00 7.35 0.0 ALL
PTRANS RDS_GATE VW 0.00 0.15 0.0 ALL \
RDS_ACTIV VW -1.50 4.35 0.0 ALL \
RDS_PIMP VW 0.00 7.35 0.0 ALL
POLY RDS_POLY VW 0.60 0.15 0.0 ALL
ALU1 RDS_ALU1 VW 0.90 0.75 0.0 ALL
ALU2 RDS_ALU2 VW 0.90 -0.30 0.0 ALL
TPOLY RDS_TPOLY VW 0.60 0.15 0.0 ALL
TALU1 RDS_TALU1 VW 0.90 0.75 0.0 ALL
TALU2 RDS_TALU2 VW 0.90 -0.30 0.0 ALL
END
The first column is the
mbk(1) layer name to be
translated, then there one or more groups of 6 columns each. For each physical
rectangle, there are 3 parameters :
- rds layer name
- One of
VW,
LCW,
RCW that indicates the `type' of segment
to be generated
- physical length extension:
DLR
- physical width oversize:
DWR
- offset from symbolic axis:
OFFSET
- tools for which the generated rectangle is applicable:
ALL,
DRC
(for the symbolic design rule checker, see
druc(1)),
EXT (for
the symbolic extractor, see
lynx(1)) These parameters are meant
regarding the symbolic segment.
- Connectors
translation table
- TABLE MBK_TO_RDS_CONNECTOR
This table contains all the informations needed to translate a symbolic
connector of a given layer onto one single real rectangle.
An example of this table is given below, with values needed for a technology
where one lambda is equal to 1.05 μ and the design grid is set to
0.15 micron.
TABLE MBK_TO_RDS_CONNECTOR
POLY RDS_POLY 0.6 0.15
ALU1 RDS_ALU1 0.9 0.75
ALU2 RDS_ALU2 0.9 -0.3
END
One symbolic connector is translated into one physical
rectangle using 3 parameters :
- rds layer name
- physical width oversize:
DWR
- physical extension on each side of the abutment box:
DER
It is discouraged to use active or well layers as
connectors while designing.
- Vias translation
table
- TABLE MBK_TO_RDS_VIA
This table contains all the informations needed to translate a symbolic via
of a given layer onto one to four real rectangles of user specified
layers. An example of this table is given below, with values needed for a
technology where one lambda is equal to 1.05 μ and the design grid
is set to 0.15 micron.
TABLE MBK_TO_RDS_VIA
CONT_BODY_N RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_NIMP 4.5
CONT_BODY_P RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_PIMP 4.5
CONT_DIF_N RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_NIMP 6.3
CONT_DIF_P RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_PIMP 6.3
CONT_POLY RDS_ALU1 3 RDS_CONT 1.5 RDS_POLY 3
CONT_VIA RDS_ALU1 3 RDS_VIA1 1.5 RDS_ALU2 3
CONT_VIA2
C_X_N RDS_GATE 1.2 RDS_ACTIV 5.4 RDS_NIMP 8.4
C_X_P RDS_GATE 1.2 RDS_ACTIV 5.4 RDS_PIMP 8.4
END
This table describes how to translate one symbolic via,
to 2, 3 or 4 physical rectangles. The table is defined as follow : The first
column is the
mbk(1) via name to translate, then there are 4 groups of
2 columns each, which correspond to four potential targets
rds
rectangles of user specified layer. In one group the first column is the
rds layer name, the second one is the
rds layer width. The
rectangle is centered on the contact coordinates, and expands in the four
direction of half the given width value.
- Denotching
values table
- TABLE S2R_OVERSIZE_DENOTCH
This table contains the oversize value needed to erase notches. All the
rectangles of the same rds layer are oversized by this value and
then merged alltogether and undersized by the same value. An example of
this table is given below.
TABLE S2R_OVERSIZE_DENOTCH
RDS_NWELL 3.00
RDS_POLY 0.75
RDS_GATE 0.75
RDS_ALU1 0.75
RDS_ALU2 0.75
RDS_ACTIV 1.05
RDS_NIMP 2.55
RDS_PIMP 2.55
END
For some rds layers, like RDS_NWELL, RDS_NIMP and
RDS_PIMP, two rectangles distant from less or equal the minimun spacing design
rule must be merged in a single one. In this case, the oversize value is equal
to the minimum spacing rule between two edges of the same layer divided by 2.
Some other rds layers, like RDS_ALU1, ..., must not be merged. In this
case, the oversize value is equal to the minimum spacing rule between two
edges of the same layer divided by 2, minus the physical grid.
Some layers never create notch, such as RDS_VIA1 or RDS_CONT, so the oversize
value is null.
- Ring width
- TABLE S2R_BLOC_RING_WIDTH
s2r must merge segments to erase notches even if those segments are in two
different hierarchical level blocs, for example, two blocs abuted side to
side. So, it must be able to fetch segments inside blocs. It is not needed
to flatten the entire bloc, only a ring is necessary. The ring is computed
from the abutment box edges or from the envelop edges of the overlapping
blocs.
An example of this table is given below.
TABLE S2R_BLOC_RING_WIDTH
RDS_NWELL 6
RDS_POLY 1.8
RDS_GATE 1.8
RDS_ALU1 1.8
RDS_ALU2 1.8
RDS_ACTIV 2.4
RDS_NIMP 1.8
RDS_PIMP 1.8
END
The normal ring width is the minimum spacing design rule
between two segments of the same rds layer.
A zero means that no ring is wanted for that rds layer.
- Minimum real layer
width design rule
- TABLE S2R_MINIMUM_LAYER_WIDTH
This table contains the minimum width of each rds layer. It is used by s2r
to avoid creating rectangles below the minimum required, during the merge
operation.
TABLE S2R_MINIMUM_LAYER_WIDTH
RDS_NWELL 6
RDS_POLY 1.2
RDS_GATE 1.2
RDS_ALU1 1.8
RDS_ALU2 1.8
RDS_ACTIV 1.2
RDS_NIMP 2.7
RDS_PIMP 2.7
END
A zero can be specified, when it is sure that this layer
is not to be merged, because not treated by s2r.
- Post treatment
configuration table
- TABLE S2R_POST_TREAT
This table indicates to s2r which rds layers must be post-processed.
Precicely if a layer is only to be be translated, or translated and then
post-processed. Translated means translate and fit from symbolic to real,
and postreated that it should also be merged with its neighbours. For
example, it's not necesary to merge cut layers such as RDS_CONT.
TABLE S2R_POST_TREAT
RDS_NWELL TREAT NULL
RDS_PWELL NOTREAT NULL
RDS_NDIF NOTREAT NULL
RDS_PDIF NOTREAT NULL
RDS_NTIE NOTREAT NULL
RDS_PTIE NOTREAT NULL
RDS_POLY TREAT NULL
RDS_GATE TREAT NULL
RDS_TPOLY NOTREAT NULL
RDS_CONT NOTREAT NULL
RDS_ALU1 TREAT NULL
RDS_TALU1 NOTREAT NULL
RDS_VIA1 NOTREAT NULL
RDS_ALU2 TREAT NULL
RDS_TALU2 NOTREAT NULL
RDS_VIA2 NOTREAT NULL
RDS_ALU3 NOTREAT NULL
RDS_TALU3 NOTREAT NULL
RDS_ACTIV TREAT NULL
RDS_NIMP TREAT RDS_PIMP
RDS_PIMP TREAT RDS_NIMP
RDS_REF NOTREAT NULL
RDS_ABOX NOTREAT NULL
END
If set to NOTREAT, the first parameter indicates a
translation. If set to TREAT, then the layer is translated and then
post-treated
To post-process creates problems with the implantation layers. It is possible to
have a good symbolic layout (no symbolic design rule errors), and have a
resulting layout with DRC violations, created by a poor post-processing. It is
due to the fact that these layers do not exist in symbolic, so it is not
possible to apply them drc verifications. If two rectangles of these layers
are too close (less than a given value), they must be merged. Generally, there
is no problem, but when corners are too near it is impossible to merge with
the classical algorithm, expand, merge, then shrink.
Rectangles, known as scotches, are created to merge anyway, like this :
+--------+ +--------+ +-----+--+
|////////| |////////| |/////|//|
|//+--+//| |//+--+//| |//+--|//|
|//| |//| gives -> |//| |//| or -> |//| |//|
|//+--+//| +-----------+ |//+--|//|
|////////| |///////////| |/////|//|
+--------+ +--------+//| +-----|//|
^ +--------+ |//|-----+ |//+--------+
| |////////| |//|/////| |///////////|
o--->|//+--+//| |//|--+//| +-----------+
| |//| |//| |//| |//| |//| |//|
implant |//+--+//| |//|--+//| |//|--+//|
areas |////////| |//|/////| |//|/////|
+--------+ +--+-----+ +--+-----+
A N implantation layer should not overlap a P
implantation one. We say that P implantations and N implantations are
complementary. A scotch will not be created if it intersects with any of the
rectangles of the complementary layers.
If a record contains in the second field a rds layer different from NULL, it
indicates the complementary layer. This implies that if it is a layer that
might need scotches the algorithm will try not to intersect with it when
creating scotches.
- TABLE LYNX_GRAPH
This table gives the connexion graph between the rds layers. For each layer,
the list of the connectable layers is written. Up to now, the extractor
works only on translated symbolic layout.
TABLE LYNX_GRAPH
RDS_NDIF RDS_CONT RDS_NDIF
RDS_PDIF RDS_CONT RDS_PDIF
RDS_NTIE RDS_CONT RDS_NTIE
RDS_PTIE RDS_CONT RDS_PTIE
RDS_POLY RDS_CONT RDS_GATE RDS_POLY
RDS_GATE RDS_POLY RDS_GATE
RDS_CONT RDS_PDIF RDS_NDIF RDS_POLY RDS_PTIE RDS_NTIE RDS_ALU1 RDS_CONT
RDS_ALU1 RDS_CONT RDS_VIA1 RDS_ALU1 RDS_REF
RDS_REF RDS_CONT RDS_VIA1 RDS_ALU1 RDS_REF
RDS_VIA1 RDS_ALU1 RDS_ALU2 RDS_VIA1
RDS_ALU2 RDS_VIA1 RDS_VIA2 RDS_ALU2
RDS_VIA2 RDS_ALU2 RDS_ALU3 RDS_VIA2
RDS_ALU3 RDS_VIA2 RDS_ALU3
END
- TABLE LYNX_CAPA
This table gives the capacitance in picofarad per square lambda of each
layer. The extractor computes only substrat capacitances. The capacitances
associated with gate or drain or sources are not computed. On the other
hand the transistor sizes (area, perimeter) are computed. (This is to
ensure compatibility with Spice).
TABLE LYNX_CAPA
RDS_POLY 1.00e-04
RDS_ALU1 0.50e-04
RDS_ALU2 0.25e-04
END
- Cif translation
table
- TABLE CIF_LAYER
This table gives the equivalence between internal layers and their
representation in the cif file format. A table may look like that
(for MOSIS layers):
TABLE CIF_LAYER
RDS_NWELL CWN
RDS_PWELL CWP
RDS_ACTIV CAA
RDS_NIMP CSN
RDS_PIMP CSP
RDS_POLY CPG
RDS_GATE CPG
RDS_CONT CCA
RDS_ALU1 CMF
RDS_VIA1 CVA
RDS_ALU2 CMS
END
- Gds translation
table
- TABLE GDS_LAYER
This table gives the equivalence between internal layers and there
representation in the gds file. A table may look like that (for CMP
layers):
TABLE GDS_LAYER
RDS_NWELL 1
RDS_POLY 11
RDS_GATE 11
RDS_CONT 16
RDS_ALU1 17
RDS_VIA1 18
RDS_ALU2 19
RDS_ACTIV 2
RDS_NIMP 12
RDS_PIMP 14
RDS_CPAS 20
END