Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
PROL(5)			       RDS FILE	FORMATS			       PROL(5)

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)  ob-
       jects,  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 representa-
       tion.

       Some syntaxic remarques on the way to write the file follow.  The  case
       of identifiers is not significant, so NDIF is equivalent	to NdiF.  Com-
       ments 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 exam-
       ple,  follow the	backslash, chances are that a syntax error will	be is-
       sued.

       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 sym-
       bolic object, belonging to the mbk(1) world, and	a set of  layout  rec-
       tangles,	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  ex-
       ists  indeed.   Some are	needed for object translation, others for post
       treatment parametrization, others to define cif or gds identifiers  re-
       garding 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 omit-
       ted.  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 representation	shall be known.
       Mbk layers

	    NWELL		minimum	width 4	; N-well.

	    PWELL		minimum	width 4	; P-well.

	    NTIE		minimum	width 2	; N  diffusion	for  polarisa-
				tion.

	    PTIE		minimum	 width	2  ; P diffusion for polarisa-
				tion.

	    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 (un-
				used).

	    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  (un-
				used).
       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 transis-
				tor

	    C_X_P		corner primitive for L or S shaped P  transis-
				tor
       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 polysilli-
				con 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 sym-
				bolic references

	    RDS_ABOX		virtual	layer needed to	indicate the  abutment
				box of a model.

	    RDS_DEFAULT		default	layer, shall never appear anywhere.

FILE DESCRIPTION
       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 en-
			   forced 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 lay-
			   ers.	 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 col-
			   umns	 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	appli-
			   cable: ALL,	DRC  (for  the	symbolic  design  rule
			   checker,  see  druc(1)),  EXT (for the symbolic ex-
			   tractor, 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 val-
			   ues 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 phys-
			   ical	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  val-
			   ues	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 coordi-
			   nates, 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  com-
			   puted  from	the abutment box edges or from the en-
			   velop 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 rectan-
			   gles	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-pro-
			   cessed.  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 implanta-
			   tion	 layers.   It  is possible to have a good sym-
			   bolic layout	(no symbolic design rule errors),  and
			   have	 a  resulting layout with DRC violations, cre-
			   ated	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  im-
			   plantation  one.  We	say that P implantations and N
			   implantations are complementary. A scotch will  not
			   be created if it intersects with any	of the rectan-
			   gles	of the complementary layers.
			   If a	record contains	in  the	 second	 field	a  rds
			   layer different from	NULL, it indicates the comple-
			   mentary 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
			   This	table gives the	connexion  graph  between  the
			   rds	layers.	  For each layer, the list of the con-
			   nectable layers is written.	Up to now, the extrac-
			   tor 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

       Extraction capacitance table
			   TABLE LYNX_CAPA
			   This	 table	gives the capacitance in picofarad per
			   square lambda of each layer.	  The  extractor  com-
			   putes 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 lay-
			   ers):

       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

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

ASIM/LIP6			October	1, 1997			       PROL(5)

NAME | DESCRIPTION | LAYERS AND PATTERNS | FILE DESCRIPTION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=prol&sektion=5&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help