PROL(5)

📦 version 5.1.1, in fedora 43, fedora 44

🎀 PROL — the RDS FILE FORMATS tea 🎀

okay so welcome to prol(5), bestie 💖 this is the page about the prol file format, and it's literally the rulebook for how symbolic stuff gets translated into real layout. buckle up, it's a long one, we're doing it in parts, stay with me 🫶

✨ NAME ✨

prol — define the rules for symbolic to real layout translation. that's it, that's the whole vibe. 💅

🌈 ORIGIN 🌈

this software belongs to the ALLIANCE CAD SYSTEM, developed by the ASIM team at the LIP6 laboratory of Université Pierre et Marie CURIE, in Paris, France. iconic honestly 🇫🇷✨

💫 DESCRIPTION 💫

so this file describes the rules used by the mbk(1) to rds translator. quick vocab check bestie, don't skip this:

  • In this file, symbolic layout objects are referred to as mbk(1) objects — mbk(1) being the internal data structure that supports the symbolic representation.
  • On the other hand, rds is a data structure describing mainly rectangles, and is therefore used for the real layout representation.

ngl there are a few syntax notes about how to actually write the file, so let's get into it:

  • The case of identifiers is not significant, so NDIF is equivalent to NdiF. periodt, do not stress about your caps lock.
  • Comments are allowed anywhere in the file, using the sharp (#) as start of comment, and newline as end of comment.
  • A line beginning with a sharp will be ignored, and a line containing a sharp will be read up to the character preceding 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. so like… don't do that 🙈

first things first, you need some important process parameters, bestie:

  • 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 you need a set of tables, to describe how to translate a symbolic object, belonging to the mbk(1) world, and a set of layout rectangles, in rds.

every table has a special meaning, and its parametrization extent being not full, some borders are to be evocated. several types of table exist 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. lowkey freeing 🦋

💡 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.

🧚 LAYERS AND PATTERNS 🧚

since the goal of this file is to allow translation from mbk(1) to rds, the meaning of the layers in both representations shall be known. so here's the whole dictionary, no skips 💜

🌸 Mbk layers 🌸

  • NWELL — minimum width 4 ; N-well.
  • PWELL — minimum width 4 ; P-well.
  • NTIE — minimum width 2 ; N diffusion for polarisation.
  • PTIE — minimum width 2 ; P diffusion for polarisation.
  • NDIF — minimum width 2 ; N diffusion for transistor.
  • PDIF — minimum width 2 ; P diffusion for transistor.
  • NTRANS — minimum width 1 (gate width) ; N transistor.
  • PTRANS — minimum width 1 (gate width) ; P transistor.
  • POLY — minimum width 1 ; polysilicon, not transistor gate.
  • ALU1 — minimum width 1 ; first level of metal.
  • ALU2 — minimum width 2 ; second level of metal.
  • ALU3 — minimum width 3 ; third level of metal (unused).
  • TPOLY — minimum width 1 ; through route for POLY.
  • TALU1 — minimum width 1 ; through route for ALU1.
  • TALU2 — minimum width 2 ; through route for ALU2.
  • TALU3 — minimum width 3 ; through route for ALU3 (unused).

🦋 Mbk patterns 🦋

  • CONT_POLY — cut pattern from ALU1 to POLY
  • CONT_VIA — cut pattern from ALU1 to ALU2
  • CONT_VIA2 — cut pattern from ALU2 to ALU3
  • CONT_DIF_N — cut pattern from ALU1 to NDIF
  • CONT_DIF_P — cut pattern from ALU1 to PDIF
  • CONT_BODY_N — cut pattern from ALU1 to NTIE
  • CONT_BODY_P — cut pattern from ALU1 to PTIE
  • C_X_N — corner primitive for L or S shaped N transistor
  • C_X_P — corner primitive for L or S shaped P transistor

🍓 Rds layers 🍓

  • RDS_NWELL — N-well (or N-tub), bulk for P transistors.
  • RDS_PWELL — P-well (or P-tub), bulk for N transistors.
  • RDS_NDIF — use for symbolic extractor as equivalent of NDIF.
  • RDS_PDIF — use for symbolic extractor as equivalent of PDIF.
  • RDS_NTIE — use for symbolic extractor as equivalent of NTIE.
  • RDS_PTIE — use for symbolic extractor as equivalent of PTIE.
  • RDS_POLY — polysillicon run, for cell internal wirering.
  • RDS_GATE — transistor polysillicon, for gate.
  • RDS_TPOLY — polysillicon feed through. Indicate to a router that a track is free of polysillicon.
  • RDS_CONT — hole in the isolating layer between polysillicon or active area and first metal level.
  • RDS_ALU1 — first metal level run.
  • RDS_TALU1 — first metal level feed through. Indicates to a router that a track is free of first metal level.
  • RDS_VIA1 — hole in the isolating layer between first metal level and second metal level.
  • RDS_ALU2 — second metal level run.
  • RDS_TALU2 — second metal level feed through. Indicate to a router that a track is free of second metal level.
  • RDS_VIA2 — hole in the isolating layer between second metal level and third metal level.
  • RDS_ALU3 — third metal level run.
  • RDS_TALU3 — third metal level feed through. Indicate to a router that a track is free of third metal level.
  • RDS_ALU4 — fourth metal. (Used only for GaAs designs.)
  • RDS_VIA3 — hole in the isolating layer between third metal level and fourth metal level. (Used only for GaAs designs.)
  • RDS_ACTIV — active area dropped in N or P implant to build transistors.
  • RDS_NIMP — implant area, (sometime known as N select), for N transistors.
  • RDS_PIMP — implant area, (sometime known as P select), for P transistors.
  • RDS_CPAS — passivation, used in pads.
  • RDS_USER0 — user defined purpose layer. (May be used for DRC logical operations.)
  • RDS_USER1 — user defined purpose layer. (May be used for DRC logical operations.)
  • RDS_USER2 — user defined purpose layer. (May be used for DRC logical operations.)
  • RDS_REF — virtual layer for the representation of symbolic references
  • RDS_ABOX — virtual layer needed to indicate the abutment box of a model.
  • RDS_DEFAULT — default layer, shall never appear anywhere. 💀 fr fr, never.

👑 FILE DESCRIPTION 👑

the following lines describe the file, entry by entry, specifying what is expected. get cozy, we're going line by line bestie 🫶

⭐ Physical grid ⭐

DEFINE PHYSICAL_GRID  .5

this statement defines the minimum grid spacing enforced by the foundry. that's the floor, no going under it 💅

⭐ 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. no cap, that's a hard requirement 🔥

⭐ Segment translation table ⭐

TABLE MBK_TO_RDS_SEGMENT

this table contains all the information 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

so the first column is the mbk(1) layer name to be translated, and then there are 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 ✨

Okay bestie, this one is TABLE MBK_TO_RDS_CONNECTOR, and it's literally the cheat sheet for turning a symbolic connector of a given layer into one single real rectangle. One symbolic thing in, one real rectangle out. Periodt.

Here's the example, with the values you'd need 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

So one symbolic connector gets translated into one physical rectangle using 3 parameters:

  • the rds layer name
  • physical width oversize: DWR
  • physical extension on each side of the abutment box: DER
🫶 Heads up though: it is discouraged to use active or well layers as connectors while designing. Like, don't. That's the note, I'm just passing it along.

✨ Vias translation table ✨

Now TABLE MBK_TO_RDS_VIA — this is the glow-up for vias. It holds all the information needed to translate a symbolic via of a given layer onto one to four real rectangles of user specified layers. Yes, up to four, she's flexible.

Example time, same tech energy — 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

So what is this table actually doing? It describes how to translate one symbolic via into 2, 3 or 4 physical rectangles. And here's the structure, fr fr:

  • 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, and 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.

That's the whole vibe. Slay.

✨ Denotching values table ✨

Okay so TABLE S2R_OVERSIZE_DENOTCH is where we keep the oversize value needed to erase notches. The tea: all the rectangles of the same rds layer get oversized by this value, then merged altogether, and then undersized by the same value. Oversize → merge → undersize. Iconic little move honestly.

Example:

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

Now the rules behind those numbers, bestie, because they are not random:

  • 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.
  • And some layers never create notch, such as RDS_VIA1 or RDS_CONT, so the oversize value is null. Nothing to erase, nothing to do. 💅

✨ Ring width ✨

TABLE S2R_BLOC_RING_WIDTH — okay, situation: s2r must merge segments to erase notches even if those segments are in two different hierarchical level blocs, for example two blocs abutted side by side. So it has to be able to fetch segments inside blocs. But no, it does not need 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.

Example:

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 0 means that no ring is wanted for that rds layer. Simple as that.

✨ Minimum real layer width design rule ✨

TABLE S2R_MINIMUM_LAYER_WIDTH contains the minimum width of each rds layer. It's used by s2r to avoid creating rectangles below the minimum required, during the merge operation. Basically the "don't you dare go smaller than this" table. 👑

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 0 can be specified when it is sure that this layer is not to be merged, because it's not treated by s2r. iykyk.

✨ Post treatment configuration table ✨

TABLE S2R_POST_TREAT tells s2r which rds layers must be post-processed. Precicely: whether a layer is only to be translated, or translated and then post-processed. "Translated" means translate and fit from symbolic to real. "Post-treated" means it should also be merged with its neighbours. For example, it's not necessary 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

How to read it, bestie:

  • If set to NOTREAT, the first parameter indicates a translation.
  • If set to TREAT, then the layer is translated and then post-treated.

Now here's the drama, and I need you to really hear me on this one:

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. The reason? These layers do not exist in symbolic, so it is not possible to apply them drc verifications.

So 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. So 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.

And one more thing: 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. 🧚

✨ Extraction graph table ✨

TABLE LYNX_GRAPH 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

kay so that's the tail end of that table, and END is the lil "we're done here" that closes it out. slay ✨

🧮 Extraction capacitance table 🧮

So this next one is TABLE LYNX_CAPA, and bestie, listen: it hands you the capacitance in picofarad per square lambda for each layer. That's the whole vibe of it. 💅

Important deets tho: the extractor only computes substrat capacitances. (Yes the page says "substrat", we don't make the rules 💀 — you know what it means.) The capacitances that come along with gate, drain, or sources are not computed. Not a thing. Nope. 🙈

But — and this is the plot twist — the transistor sizes (area, perimeter) are computed. And why, you ask? To ensure compatibility with Spice. That's the reason, no cap. 🌶️

TABLE LYNX_CAPA

RDS_POLY    1.00e-04
RDS_ALU1    0.50e-04
RDS_ALU2    0.25e-04

END

🧚 Cif translation table 🧚

Next up: TABLE CIF_LAYER, and this one is giving translator energy — it maps the equivalence between the internal layers and how they show up in the cif file format. 🦋

A table may look like that (for MOSIS layers), and honestly? She's cute:

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 🌈

And then we have TABLE GDS_LAYER — same idea, different format, bestie. This one gives the equivalence between the internal layers and their 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

lowkey obsessed with how tidy that is ✨

👀 SEE ALSO 👀

  • If you want the tea on how the symbolic to real translation process actually goes down, there are insights available in the file mapping.ps. Go read it, bestie, it's right there. 🫶

💌 BUG REPORT 💌

Okay so real talk: this tool is under development at the ASIM department of the LIP6 laboratory. 🛠️

They need your feedback to improve the documentation and the tools. Like, actually need it. So if something's weird or a doc is missing a lil something, say it — you'd be doing main character work. 👑

and that's the whole page, bestie — every last table, every last layer name, no crumbs left behind 💅✨

this lil masterpiece is brought to you by ASIM/LIP6, dated October 1, 1997, and it lives at PROL(5) 🎀🦋⭐

📦 where this page comes from