348 lines
7.1 KiB
Groff
348 lines
7.1 KiB
Groff
.\" $Id: ring.1,v 1.1 1999/05/31 17:30:14 alliance 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 man1/alc_origin.1
|
|
.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 router SCR, 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)
|
|
scr(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 man1/alc_bug_report.1
|
|
|