RING(1)

πŸ“¦ version 5.1.1-unstable-2025-02, in nixos 26.05, nixpkgs unstable

🌸 RING(1) β€” the pad ring router, bestie edition 🌸

okay so this is RING from the ALLIANCE USER COMMANDS section, and no cap it's the one that wraps ur little core in a whole ring of pads. it's giving ✨ full glam makeover ✨ for ur layout. let's get into it 🫢


✨ SYNOPSIS ✨

RING source result [ stat ]

three things: a source, a result, and maybe a stat if ur feeling data-y πŸ’…


🌈 ORIGIN 🌈

ok so 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 πŸ‡«πŸ‡· (yes that CURIE, main character energy fr).


πŸ’– DESCRIPTION πŸ’–

the source situation πŸŽ€

source defines two input files, and you need both, no skipping:

  • the file describing the input netlist β€” in MBK_IN_LO(1) format. example: source.al
  • the parameter file β€” source.rin

the parameter file has 5 sections: 4 for pad placement on the circuit sides, plus 1 to define the power supply 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 β€” so go off with ur formatting ig πŸ’…

the side sections πŸ¦‹

  • east(), north(), south(), west() define the relative pad order. they use the pad instance names.
  • for the north() and south() sections, the instance name declarations go from the left (first pad) to the right (last pad).
  • for the east() and west() sections, the instance name declarations go from the bottom (first pad) to the top (last pad).

any section may be missing β€” that means the relative side has no pad. however, at least one side must have at least one pad. (empty ring = not the vibe, it'll be mad 😭)

the width() section πŸ’€

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


what result even is πŸ‘‘

result defines the output filename. this file contains the layout of the routed circuit, in MBK_OUT_PH(1) format. example: result.ap

here's the tea on libraries β˜• β€” 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. not negotiable bestie 🚫

part of a catalog file:

a2_y  C
high_y  C
pck_sp C
piot_sp  C
pvssick_sp  C
pvdde_sp C
pvddi_sp  C

the optional stat parameter πŸ“Š

[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 also describes how many vias were placed. iconic, honestly πŸ’…

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 πŸ¦‹

these are the little guys running the show behind the scenes:

  • 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 the core of the circuit and the pad ring. and listen β€” RING is not a floor plan router, and it allows only one core. one core. that's the limit. periodt πŸ’…

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). yep, more than one pitch, don't push it 😀

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. same name, matching, cute, done πŸŽ€

RING performs an automatic placement of the pad ring and core. so you do not need to place pads β€” you only need to describe their relative position on each side, in the parameter file (source.rin). literally so low-effort of you, love that 🌸

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 is 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

ate. no crumbs. πŸ‘‘


πŸ’œ SEE ALSO πŸ’œ

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

go read those too, iykwim 🧚


😭 DIAGNOSTICS 😭

okay this is the part where we get real, bestie β€” read it, don't skim πŸ‘€

  • physical core must have at least one physical connector by side, otherwise it can't place pads correctly, and maybe dump a core file. so like… yeah. at least one per side πŸ™ˆ
  • whenever lots of core connectors (bus) are placed close ones from each others, RING may have problems connecting pad connectors placed just in front of them. in such a case, it's recommended to not have pad connectors at that place β€” so place an instance pad without connector (like pvdde_sp) or cut the bus into several parts to let space between connectors.
  • when core connectors are too close from corners, RING sometimes connects those ones to the supply rings. to solve this bug, move core connectors or change pad placement. and in any case, use druc(1) or lvx(1) to detect the problem.
  • supply vdd and vss pads (resp. pvddi_sp and pvssi_sp) must be placed as close as possible to the core side middle (i.e. not in the corners). otherwise, RING cannot link the supply pad connector to the ring supplies and exits with an error message. so. middle. not corner. got it? πŸ’€
  • supply tracks from pads and core are connected at the supply ring. there are sometimes a few problems when core and pad tracks are opposite. moving pads usually corrects the problem.

πŸŽ€ BUG REPORT πŸŽ€

this tool is under development at the ASIM department of the LIP6 laboratory. we need your feedback to improve documentation and tools 🫢 so like, tell them stuff, they're literally asking.


that's the whole page, bestie πŸ’– go route some rings and slay βœ¨πŸ’…πŸŒˆ

β€” with love from ASIM/LIP6, dated October 1, 1997 πŸŽ€ (yes it's an icon, it's been an icon since the 90s)

πŸ“¦ where this page comes from