NAME

prol - define the rules for symbolic to real layout translation

DESCRIPTION

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.

FILEDESCRIPTION

The following lines describe the file, entry by entry, specifying what
is expected.
PhysicalgridDEFINEPHYSICAL_GRID.5
This statement defines the minimum grid spacing
enforced by the foundry.
LambdaDEFINELAMBDA1
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.
SegmenttranslationtableTABLEMBK_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.
TABLEMBK_TO_RDS_SEGMENTNWELLRDS_NWELLVW3.156.300.0ALLNDIFRDS_ACTIVVW0.60-0.900.0ALL\RDS_NIMPVW2.102.100.0ALLPDIFRDS_ACTIVVW0.60-0.900.0ALL\RDS_PIMPVW2.102.100.0ALLNTIERDS_ACTIVVW0.60-0.900.0ALL\RDS_NIMPVW1.200.300.0ALLPTIERDS_ACTIVVW0.60-0.900.0ALL\RDS_PIMPVW1.200.300.0ALLNTRANSRDS_GATEVW0.000.150.0ALL\RDS_ACTIVVW-1.504.350.0ALL\RDS_NIMPVW0.007.350.0ALLPTRANSRDS_GATEVW0.000.150.0ALL\RDS_ACTIVVW-1.504.350.0ALL\RDS_PIMPVW0.007.350.0ALLPOLYRDS_POLYVW0.600.150.0ALLALU1RDS_ALU1VW0.900.750.0ALLALU2RDS_ALU2VW0.90-0.300.0ALLTPOLYRDS_TPOLYVW0.600.150.0ALLTALU1RDS_TALU1VW0.900.750.0ALLTALU2RDS_TALU2VW0.90-0.300.0ALLEND
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.
ConnectorstranslationtableTABLEMBK_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.
TABLEMBK_TO_RDS_CONNECTORPOLYRDS_POLY0.60.15ALU1RDS_ALU10.90.75ALU2RDS_ALU20.9-0.3END
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.
ViastranslationtableTABLEMBK_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.
TABLEMBK_TO_RDS_VIACONT_BODY_NRDS_ALU13RDS_CONT1.5RDS_ACTIV3.3RDS_NIMP4.5CONT_BODY_PRDS_ALU13RDS_CONT1.5RDS_ACTIV3.3RDS_PIMP4.5CONT_DIF_NRDS_ALU13RDS_CONT1.5RDS_ACTIV3.3RDS_NIMP6.3CONT_DIF_PRDS_ALU13RDS_CONT1.5RDS_ACTIV3.3RDS_PIMP6.3CONT_POLYRDS_ALU13RDS_CONT1.5RDS_POLY3CONT_VIARDS_ALU13RDS_VIA11.5RDS_ALU23CONT_VIA2C_X_NRDS_GATE1.2RDS_ACTIV5.4RDS_NIMP8.4C_X_PRDS_GATE1.2RDS_ACTIV5.4RDS_PIMP8.4END
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.
DenotchingvaluestableTABLES2R_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.
TABLES2R_OVERSIZE_DENOTCHRDS_NWELL3.00RDS_POLY0.75RDS_GATE0.75RDS_ALU10.75RDS_ALU20.75RDS_ACTIV1.05RDS_NIMP2.55RDS_PIMP2.55END
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.
RingwidthTABLES2R_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.
TABLES2R_BLOC_RING_WIDTHRDS_NWELL6RDS_POLY1.8RDS_GATE1.8RDS_ALU11.8RDS_ALU21.8RDS_ACTIV2.4RDS_NIMP1.8RDS_PIMP1.8END
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.
MinimumreallayerwidthdesignruleTABLES2R_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.
TABLES2R_MINIMUM_LAYER_WIDTHRDS_NWELL6RDS_POLY1.2RDS_GATE1.2RDS_ALU11.8RDS_ALU21.8RDS_ACTIV1.2RDS_NIMP2.7RDS_PIMP2.7END
A zero can be specified, when it is sure that this
layer is not to be merged, because not treated by
s2r.
PosttreatmentconfigurationtableTABLES2R_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.
TABLES2R_POST_TREATRDS_NWELLTREATNULLRDS_PWELLNOTREATNULLRDS_NDIFNOTREATNULLRDS_PDIFNOTREATNULLRDS_NTIENOTREATNULLRDS_PTIENOTREATNULLRDS_POLYTREATNULLRDS_GATETREATNULLRDS_TPOLYNOTREATNULLRDS_CONTNOTREATNULLRDS_ALU1TREATNULLRDS_TALU1NOTREATNULLRDS_VIA1NOTREATNULLRDS_ALU2TREATNULLRDS_TALU2NOTREATNULLRDS_VIA2NOTREATNULLRDS_ALU3NOTREATNULLRDS_TALU3NOTREATNULLRDS_ACTIVTREATNULLRDS_NIMPTREATRDS_PIMPRDS_PIMPTREATRDS_NIMPRDS_REFNOTREATNULLRDS_ABOXNOTREATNULLEND
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.
ExtractiongraphtableTABLELYNX_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.
TABLELYNX_GRAPHRDS_NDIFRDS_CONTRDS_NDIFRDS_PDIFRDS_CONTRDS_PDIFRDS_NTIERDS_CONTRDS_NTIERDS_PTIERDS_CONTRDS_PTIERDS_POLYRDS_CONTRDS_GATERDS_POLYRDS_GATERDS_POLYRDS_GATERDS_CONTRDS_PDIFRDS_NDIFRDS_POLYRDS_PTIERDS_NTIERDS_ALU1RDS_CONTRDS_ALU1RDS_CONTRDS_VIA1RDS_ALU1RDS_REFRDS_REFRDS_CONTRDS_VIA1RDS_ALU1RDS_REFRDS_VIA1RDS_ALU1RDS_ALU2RDS_VIA1RDS_ALU2RDS_VIA1RDS_VIA2RDS_ALU2RDS_VIA2RDS_ALU2RDS_ALU3RDS_VIA2RDS_ALU3RDS_VIA2RDS_ALU3ENDExtractioncapacitancetableTABLELYNX_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).
TABLELYNX_CAPARDS_POLY1.00e-04RDS_ALU10.50e-04RDS_ALU20.25e-04ENDCiftranslationtableTABLECIF_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):
TABLECIF_LAYERRDS_NWELLCWNRDS_PWELLCWPRDS_ACTIVCAARDS_NIMPCSNRDS_PIMPCSPRDS_POLYCPGRDS_GATECPGRDS_CONTCCARDS_ALU1CMFRDS_VIA1CVARDS_ALU2CMSENDGdstranslationtableTABLEGDS_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):
TABLEGDS_LAYERRDS_NWELL1RDS_POLY11RDS_GATE11RDS_CONT16RDS_ALU117RDS_VIA118RDS_ALU219RDS_ACTIV2RDS_NIMP12RDS_PIMP14RDS_CPAS20END

SEEALSO

Insights on the symbolic to real translation process are available in
the file mapping.ps