.\"   $Id: ring.1,v 1.4 2002/12/11 14:30:34 xtof Exp $
.\" @(#)Labo.l 0.0 90/22/08 UPMC;
.TH RING 1 "October 1, 1997" "ASIM/LIP6" "ALLIANCE USER COMMANDS"
.SH NAME
RING \- PAD RING router
.SH SYNOPSIS
RING \fIsource\fP \fIresult\fP \fB[ stat ]\fP
.so buster/alliance/alc_origin.1.en.gz
.SH DESCRIPTION
.IR source
defines two input files:
.RS
\-\- the file describing the input netlist (MBK_IN_LO(1) format).
.br
.RS
example: source.al
.br
.LP
.RE
\-\- the parameter file: source.rin
.br
This file consists in 5 sections: 4 for the pad placement on circuit
sides, one to define the power sypply width (in lambda units).
.LP
.br
.TP 10
example:
.RS
.IR east
() # none pad at east side.
.br
.IR north
(
.br
p_pck p_i0 p_i1
.br
p_i3)
.br
.IR south
(p_vssb p_vddb p_i2)
.br
.IR width
(vss 50 vdd 80)
.br
.RE
.LP
Separators (spaces, tabulations and new line) are allowed between instance names.
.LP
.br
\-\- east(), north(), south(), west() define the relative pad order.
They use the pad instance names.
.LP
.br
For the north() and south() sections, the instance name declaration
are from the 
.IR left
(first pad) to the
.IR right
(last pad).
.LP
.br
For the east() and west() sections, the instance name declaration
are from the 
.IR bottom
(first pad) to the
.IR top
(last pad).
.LP
.br
Any section may be missing. It means so the revalive side has no pad, 
however at least one side must has one pad.
.LP
.br
\-\- the width() section is optional and describes the
power (vdd), and ground (vss) track width.
.LP
.br
.RE
.IR \fIresult\fP 
defines the output filename.
.LP
.br
.RS
This file contains the layout of the routed circuit (MBK_OUT_PH(1) format).
.br
.RS
example: result.ap
.LP
.RE
.br
RING uses a pad library whose path directory is defined with the 
MBK_CATA_LIB(1) environment variable.
It also uses a catalog filename which is defined with the MBK_CATAL_NAME(1)
environment variable.
.br
The catalog must contain all the pad model names used in the
circuit. The core model-name must not be present in the catalog.
.br
.LP
Part of catalog file:
.RS
.br
a2_y  C
.br
high_y  C
.br
pck_sp C
.br
piot_sp  C
.br
pvssick_sp  C
.br
\.\.\.\.
.br
pvdde_sp C
.br
pvddi_sp C
.br
.LP
.RE
.br
.RE
.IR [stat]
(optional parameter) defines another output file:
.br
.LP
.RS
.br
\-\- the statistic file: result.stat
.br
.LP
It contains data about length (lambdas) and area (lambdas * lambdas) in ALU1 and ALU2, for each
equipotential. It describes how many vias were placed.
.br
.LP
.RS
example: *** STATISTIC FILE < result.stat > ***
.br
.LP
.RE
Equipotential list :
.br
.LP
.nf
.if t \{\
.ft CR \}
index|   name   |lgth A1|lgth A2|area A1|area A2| nb vias
.br
_________________________________________________________
.br
 60  |      vss | 9034  | 4408  | 614288| 454024| 1128
.br
_________________________________________________________
.br
 59  |      vdd | 7494  | 3968  | 574248| 408704| 1128
.br
_________________________________________________________
.br
 54  | b2_coeur | 2253  | 1899  |   2253|   3798|    4
_________________________________________________________
.br
Total length alu1  :        18781 (lambdas)
.br
Total length alu2  :        10275 (lambdas)
.br
Total area alu1    :      1190789 (lambdas * lambdas)
.br
Total area alu2    :       866526 (lambdas * lambdas)
.br
Total of vias      :         2260
.br
.ft R
.fi
.LP
.RE
.br
.LP
.SH ENVIRONMENT VARIABLES
.LP
.br
\fBMBK_IN_LO(1)\fP defines the input file format for the netlist.
.br
\fBMBK_IN_PH(1)\fP defines the input file format for the layout.
.br
\fBMBK_OUT_PH(1)\fP defines the output file format for the layout.
.br
\fBMBK_CATAL_NAME(1)\fP defines the catalog filename.
.br
\fBMBK_CATA_LIB(1)\fP defines the library pad cells directory.
.br
\fBMBK_WORK_LIB(1)\fP defines the work directory.
.br
.LP
.SH USAGE
.LP
.br
RING performs the physical routing between core of
circuit and pad ring. 
RING is not a floor plan router and allows only one core.
.LP
.br
A core is designed, for example, with the standard
cells placer \fBocp(1)\fP and router \fBnero(1)\fP, which places the input and output connectors on 
the abutment box. The physical core connectors must be
separated by more than one pitch in any metal (in ALU1 or ALU2).
.LP
.br
Netlist and layout views relative to the same figure must have
the same name. For example, the netlist core name and the routed core name.	
.LP
.br
RING performs an automatic placement of the pad ring
and core. It is not necessary to place pads, but only
to describe their relative position on each side, in the parameter file
(source.rin).
.LP
.br
Distance between the first track and any instance (pad or core) is the pitch
so 5 lambdas.
.FF 
.br
.SH EXAMPLE
.LP
.br
Let chip.al be the circuit netlist and core.ap the routed core.
80 lambdas for supply track width and the pad placement are described as follows.
.LP
.RE
.br
.br
.TP 10
.IR chip.rin:
.LP
.RS
# This is a comment: 1 comment per line
.br
north(p_a1 p_a2 p_a3 p_a4)
.br
south(
.br
p_i1 #another comment: the rest of the line
.br
p_i2
.br
p_i3
.br
p_i4)
.br
east(p_b4 p_b3 p_b2 p_b1)
.br
west(p_f1 p_f2 p_f3 p_f4)
.br
width(
.br
vdd 80
.br
vss 80
.br
)
.br
.TP 10
We want a ring of pads as follow:
.LP
.br
.RS
.nf
.if t \{\
.ft CR \}
+-------------------------------------------------+
.br
|            |p_a1|p_a2|p_a3|p_a4|                |
.br
|----+---------------------------------------+----|
.br
|p_f4|                                       |p_b1|
.br
|----|            +-------+                  |----|
.br
|p_f3|            |       |                  |p_b2|
.br
|----|            | CORE  |                  |----|
.br
|p_f2|            |       |                  |p_b3|
.br
|----|            +-------+                  |----|
.br
|p_f1|                                       |p_b4|
.br
|----+---------------------------------------+----|
.br
|            |p_i1|p_i2|p_i3|p_i4|                |
.br
+-------------------------------------------------+
.ft R
.fi
.LP
.RE
.br
.br
In order to obtain the routed circuit (chipr.ap):
.LP
.br
>
.IR ring
.IR chip
.IR chipr
.LP
.br
.SH "SEE ALSO"
genlib(1)
lvx(1)
ocp(1)
nero(1)
druc(1)


.SH DIAGNOSTICS
Physical core must have at least one physical connector by side,
otherwise it can't place pads correctly, and maybe dump a core file.
.LP
.br
Whenever lots of core connectors (bus) are placed close ones from each others, 
RING may have problems to connect pad connectors placed just in front of them.
In such a case, it is recommended to not have pad connectors at that place and 
thus to place an instance pad without connector (as pvdde_sp)
or to cut the bus into several parts to let space between connectors.
.LP
.br
When core connectors are to close from corners, RING sometimes connects those
one to supply rings, to solve this bug, move core connectors or change pad 
placement. In any case, use \fBdruc(1)\fP or \fBlvx(1)\fP to detect problem.
.br
.LP
Supply vdd and vss pads (resp. pvddi_sp and pvssi_sp) 
must be placed as close as possible of the core side middle
(i.e. not in the corners). 
Otherwise, RING cannot link supply pad connector to ring supplies and
exits with a error message.
.br
.LP
Supply tracks from pads and core are connected at the supply ring.
There is sometimes few problems when core and pad tracks are opposite.
Move pads usually corrects problem.
.br
.LP

.so buster/alliance/alc_bug_report.1.en.gz