Provided by: alliance_5.1.1-1.1build1_amd64 bug

NAME

       RING - PAD RING router

SYNOPSIS

       RING source result [ stat ]

DESCRIPTION

       source defines two input files:
              -- the file describing the input netlist (MBK_IN_LO(1) format).
                     example: source.al

              -- the parameter file: source.rin
              This  file consists in 5 sections: 4 for the pad placement on circuit sides, one to
              define the power sypply width (in lambda units).

              example:
                        east () # none pad at east side.
                        north (
                        p_pck p_i0 p_i1
                        p_i3)
                        south (p_vssb p_vddb p_i2)
                        width (vss 50 vdd 80)

              Separators (spaces, tabulations and new line) are allowed between instance names.

              -- east(), north(), south(), west() define the relative pad order.   They  use  the
              pad instance names.

              For  the  north()  and south() sections, the instance name declaration are from the
              left (first pad) to the right (last pad).

              For the east() and west() sections, the instance  name  declaration  are  from  the
              bottom (first pad) to the top (last pad).

              Any  section  may  be missing. It means so the revalive side has no pad, however at
              least one side must has one pad.

              -- the width() section is optional and describes the power (vdd), and ground  (vss)
              track width.

       result defines the output filename.

              This file contains the layout of the routed circuit (MBK_OUT_PH(1) format).
                     example: result.ap

              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.
              The  catalog  must  contain  all  the pad model names used in the circuit. The core
              model-name must not be present in the catalog.

              Part of catalog file:
                     a2_y  C
                     high_y  C
                     pck_sp C
                     piot_sp  C
                     pvssick_sp  C
                     pvdde_sp C
                     pvddi_sp C

       [stat] (optional parameter) defines another output file:

              -- the statistic file: result.stat

              It contains data about length (lambdas) and area (lambdas * lambdas)  in  ALU1  and
              ALU2, for each equipotential. It describes how many vias were placed.

                     example: *** STATISTIC FILE < result.stat > ***

              Equipotential list :

              index|   name   |lgth A1|lgth A2|area A1|area A2| nb vias
              _________________________________________________________
               60  |      vss | 9034  | 4408  | 614288| 454024| 1128
              _________________________________________________________
               59  |      vdd | 7494  | 3968  | 574248| 408704| 1128
              _________________________________________________________
               54  | b2_coeur | 2253  | 1899  |   2253|   3798|    4
              _________________________________________________________
              Total length alu1  :        18781 (lambdas)
              Total length alu2  :        10275 (lambdas)
              Total area alu1    :      1190789 (lambdas * lambdas)
              Total area alu2    :       866526 (lambdas * lambdas)
              Total of vias      :         2260

ENVIRONMENT VARIABLES

       MBK_IN_LO(1) defines the input file format for the netlist.
       MBK_IN_PH(1) defines the input file format for the layout.
       MBK_OUT_PH(1) defines the output file format for the layout.
       MBK_CATAL_NAME(1) defines the catalog filename.
       MBK_CATA_LIB(1) defines the library pad cells directory.
       MBK_WORK_LIB(1) defines the work directory.

USAGE

       RING  performs  the  physical routing between core of circuit and pad ring.  RING is not a
       floor plan router and allows only one core.

       A core is designed, for example, with the standard cells placer ocp(1) and router nero(1),
       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).

       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.

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

       Distance between the first track and any instance (pad or core) is the pitch so 5 lambdas.

EXAMPLE

       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.

       chip.rin:

              # This is a comment: 1 comment per line
              north(p_a1 p_a2 p_a3 p_a4)
              south(
              p_i1 #another comment: the rest of the line
              p_i2
              p_i3
              p_i4)
              east(p_b4 p_b3 p_b2 p_b1)
              west(p_f1 p_f2 p_f3 p_f4)
              width(
              vdd 80
              vss 80
              )

              We want a ring of pads as follow:

                     +-------------------------------------------------+
                     |            |p_a1|p_a2|p_a3|p_a4|                |
                     |----+---------------------------------------+----|
                     |p_f4|                                       |p_b1|
                     |----|            +-------+                  |----|
                     |p_f3|            |       |                  |p_b2|
                     |----|            | CORE  |                  |----|
                     |p_f2|            |       |                  |p_b3|
                     |----|            +-------+                  |----|
                     |p_f1|                                       |p_b4|
                     |----+---------------------------------------+----|
                     |            |p_i1|p_i2|p_i3|p_i4|                |
                     +-------------------------------------------------+

              In order to obtain the routed circuit (chipr.ap):

              > ring chip chipr

SEE ALSO

       genlib(1) lvx(1) ocp(1) nero(1) druc(1)

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.

       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.

       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 druc(1) or lvx(1) to detect problem.

       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.

       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.