% 
% Add your name  to the authors' list
% All the sections are in alphabetical order. 
% 
\documentstyle{report}

\title{MOSAICO: User's manual}
\author{ M. Beardslee, J. Burns, A. Casotto, M. Igusa,\\ F. Romeo, A. Sangiovanni-Vincentelli \
\\ \\ Department of Electrical  \
Engineering and Computer Sciences, \
\\ University of California, Berkeley }

% 
% Define some new commands
%
\newcommand{\osp}{{\em OCT Symbolic Policy}}
\newcommand{\mosaico}{{\tt MOSAICO}}
\newcommand{\padplace}{{\tt padplace}}
\newcommand{\puppy}{{\tt PUPPY}}
\newenvironment{intro}{\em}{}
\begin{document}
\maketitle
\tableofcontents
\chapter{The MOSAICO system}
\section{Introduction}
This manual describes features and use of \mosaico, a complete set of tools
for floorplanning, placement, and
routing of macro-cells.  Macro-cells are functional blocks that are created
by module generators, manual layout, or any number of other means. Since
\mosaico\ is tightly coupled to  Berkeley's logic synthesis system
\cite{BerkSyn} macro-cell functionality can be optimized 
with the characteristics of the target implementation style in
mind.  The \mosaico\ floorplanner can then be used to produce specifications
for the aspect ratios and pin positions of each macro-cell.  The combination
of the optimized logic equations and the geometric information from
the floorplanner comprise the input to module generators; the
macro-cells output are then used in the placement phase of \mosaico.

To achieve
design-rule independence the entire \mosaico\ system operates at the
symbolic-layout level, rather than at the physical-layout level.  A
spacing step is carried out prior to mask generation to ensure that
the layout is design-rule correct.

\section{Pipeline Structure}

\mosaico\ consists of
five basic steps executed in sequence as a
{\it pipeline}.  The pipeline is represented in Figure \ref{pipeline} together with
the sequence of symbolic views that are stored at each step in the OCT
data manager \cite{Har86}.  Each step is described in detail in the
following sections.

\begin{figure}
\begin{center}
%
% File: pipe
% xlaped version 1.1
%
\setlength{\unitlength}{0.008in}
\begin{picture}(432,338)(0,0)
\put(341,325){\makebox(0,0)[l]{unplanned}}
\put(341,269){\makebox(0,0)[l]{placed}}
\put(335,325){\vector(-4,-1){96}}
\put(239,293){\vector(4,-1){96}}
\put(335,261){\vector(-4,-1){96}}
\put(239,229){\vector(4,-1){96}}
\put(335,197){\vector(-4,-1){96}}
\put(239,165){\vector(4,-1){96}}
\put(335,133){\vector(-4,-1){96}}
\put(239,101){\vector(4,-1){96}}
\put(335,69){\vector(-4,-1){96}}
\put(239,37){\vector(4,-1){96}}
\put(341,205){\makebox(0,0)[l]{cd}}
\put(341,141){\makebox(0,0)[l]{cd\_after\_gr}}
\put(341,77){\makebox(0,0)[l]{routed}}
\put(341,13){\makebox(0,0)[l]{spaced}}
\put(150,301){\makebox(0,0){Floorp. \& Placement}}
\put(150,237){\makebox(0,0){Channel definition}}
\put(150,173){\makebox(0,0){Global routing}}
\put(150,109){\makebox(0,0){Detailed routing}}
\put(150,45){\makebox(0,0){Compacting \& Spacing}}
\put(5,45){\vector(0,1){240}}
\put(5,285){\vector(1,1){16}}
\put(21,301){\vector(1,0){48}}
\put(69,173){\vector(-1,0){64}}
\put(69,109){\vector(-1,0){64}}
\put(69,45){\vector(-1,0){64}}
\end{picture}
\caption{The MOSAICO pipeline}
\label{pipeline}
\end{center}
\end{figure}

Figure \ref{pipeline} illustrates one of the most important features of
\mosaico: its modularity.  Modularity is achieved by ensureing
that all the information produced at each stage of the pipeline
is stored in the OCT data base.  Each of the tools in the
pipeline reads its input data from an OCT view in the data manager and
produces as its output another view which contains the previous data
updated with the information added by the tool.  Of course, new views
need not be created; the original view can be annotated in place by
each tool if desired.

\section{Floorplanning and Placement}

\begin{intro}
In the \mosaico\ environment, the activity of floorplanning and
placement (F\&P) is handled in a unified framework; in fact there is
no distinction between floorplanning and placement at the algorithmic
level.  At the floorplanning stage some of the parameters of the
macro-cells (aspect ratio, pin positions) may be varied; at the
placement level all the macro-cell parameters are fixed and the only
remaining degrees of freedom are the positions and orientations of the
cells.  The F\&P phase maintains a global view of the chip and directs
the interactions with the module generators and the timing verifiers.

The F\&P iterations are started by an initial floorplanning operation
in which the most detailed description available for each cell is
retrieved from OCT.  For some macro-cells the complete layout may be
known.  For others only a set of constraints, such as requirements on
pin positions or aspect ratio, may exist.  Other cells may be
described at the logical or behavioral level.  For such cells, called
{\it soft cells}, an area estimation is performed, based on the
complexity of the cell and on the features of the module generator
that will be used to produce it.  The terminals of a soft cell are
free to move about the border of the cell. We call them {\it floating
terminals}.

After each iteration the floorplanner produces as output the position
and orientation of each cell and also the shape and pin positions for
those cells that were not completely specified.  This information is
passed to the module generators (e.g.  Gem, Topogen \cite{ada86}, Wolfe \cite{wolfe}).

The input to the module generators comes from two sources, one being
the floorplanner which specifies geometric constraints as described
above.  The other data is the logic description produced by the logic
optimization tool Mis \cite{mis86}.

If a module generator is unable to satisfy all the constraints imposed
on a particular cell, the actual shape of the generated cell is fed
back to F\&P and a new iteration is started.

The F\&P module also interacts with the timing analyzer Hummingbird
\cite{humm}.  The purpose of the timing analyzer is to critique the
floorplan.  It performs two tasks: first it checks the arrival times
of signals required for the correct functioning of the circuit, then
it marks each net with information about the maximum and minimum delay
through that net.  If the requirements are not met, a new iteration of
the floorplanner is necessary.  The timing information is used to
update the constraints imposed by F\&P on the maximum or minimum
length of the nets.

As the F\&P task is repeatedly executed, more and more refined
representations of the chip are generated.  As the macro-cells gain
their physical implementations, the information available to the F\&P
tool increases, and the floorplanning task becomes a placement task.
\end{intro}

\subsection{The FLOORPLAN bag}
\label{flp}
To indicate the fact that a cell is soft, a bag named ``FLOORPLAN''
must be attached to the interface facet of the cell.
The FLOORPLAN bag contains constraints for floorplanner and module generators.
The bag is always and only in the interface facet. It contains the
following objects and properties: 
\begin{description}
\item[A box] This box has two meanings.
For the floorplanner, the area of the box represents the area of the
soft cell and its shape represents the desired aspect ratio of the
cell. The aspect ratio can vary in the range specified by two
properties {\bf MIN\_Y\_OVER\_X} and {\bf MAX\_Y\_OVER\_X} (see
below). The box may be attached to a layer (for example layer PLACE) so that it can be
seen in VEM, but such attachment is optional.

For a module generator, the box represents the area suggested by the
floorplanner for the implementation of the cell.  \mosaico\
itself can be considered a module generator, and the box in the
FLOORPLAN bag in the interface of the chip to be placed
specifies the area available  for floorplanning and placement.


\item[MODULE\_GENERATOR] is a string property, naming the module
generator which is supposed to implement the cell. This property is
used by the floorplanner and by {\tt alba}.
Examples: ``'', ``wolfe'', ``gem'', ``mosaico''.
\item[MIN\_Y\_OVER\_X] Minimum aspect ratio for a soft cell.
\item[MAX\_Y\_OVER\_X] Maximum aspect ratio for a soft cell.
\item[FORBIDDEN\_EDGES] (\puppy\ only) Easy way to put edge constraints on the
floating pins of the cell. Example = ``LEFT TOP''.
\end{description}

\subsection{Tools}
\begin{description}
\item[puppy] does not consider soft cells with variable aspect ratio yet.
See also ``Puppy User's Manual''.
\item[alba] is a program that performs a number of checks before and
after floorplanning, allowing the user to change some of the
information contained in the FLOORPLAN bag.
\item[makeSoft] is a program that creates the
information necessary to consider a cell as a soft cell. 
\end{description}

\section{Channel Definition and Ordering}
\label{chdef}

\begin{intro}
The {\it channel definition} task is to partition the available routing area
into smaller regions for the subsequent global and detailed-routing phases.
Once the regions are determined they have to be {\it ordered} so that
each region can be routed in a sequence such that its width can be adjusted
independently of all previously-routed regions.

Otten \cite{Otten82} presented a channel definition algorithm which
produces a feasible routing order on a restricted class of
placements called {\it rectilinear slicing structures}.
The advantage of the slicing method is that it induces a simple hierarchical
decomposition of the routing problem into independent subproblems.
The chip is divided by the first slice into two blocks; the slicing
procedure is then recursively repeated on the sub-blocks. 
Each slice represents a single routing area and the order in which the slices are found
is the reverse of the routing order.
\end{intro}

\vspace{0.5cm}
Given a placed macrocell layout, the channel definition program {\tt atlas}
will figure out where the routing channels are located and the order in which
to route them.  Channel definition is executed prior to global routing.
Formal terminals (IO's) are expected to reside on the outer perimeter 
(in a rectangle) of the macroblock or chip.  For each side, top, bottom,
left and right, the formal terminals are merged together into one instance
consisting of a strip of terminals.
{\tt Atlas} will try to use a slicing tree for the channel definition.
When a slicing tree is impossible to create, {\tt atlas} will use irregular
channels, i.e.   ``Z'' shaped channels.
Currently, ``Z'' shaped channels are allowed when using the -Z option in mosaico.
We suggest that the user use {\tt atlasRpc} to visually inspect the channel definition
and ordering. If the channel definition is not what is desired, then the user can
interactively change the placement and redo the channel definition within the rpc
applicaion.

The input channel definition program is a placed view.
Polygons of the instance's master's PLACE layer are used to abstract the outline of
the instances.  These polygons are used by the channel definition to see where the
routing channels reside.
If the PLACE layer does not exist, then the bounding box is used as the outline of
the instance.  If the outlines of the instances overlap, then atlas will automatically
move (all) instances apart to resolve the overlap.

See also Appendix \ref{chdefpol}.


\subsection{Tools}
\begin{description}
\item[atlas] is the channel definition program.
\item[atlasRpc] is the RPC version of {\tt atlas}.  This program is
useful for visually inspecting the channel definition using vem.
\end{description}

\subsection{Properties}
\begin{description}
\item[CDChanDef] is a program defined bag which is the symbolic representation
of a channel.
\item[CDChanOrder] is a program defined property attached to the CDChanDef
bag whose value is the order in which the channel should be routed.
\item[CDCorners] is a program defined bag attached to each instance to tell
the global router which boundaries of the instance lie on which channel.
\item[CDCorner] is a program defined property attached in a ``linked'' list
with the CDCornerEdge bag whose value is the index into the PLACE polygon
of the instance to denote the part of the instance polygon which is bordering
the channel the CDCorner property is attached to.  Hopefully no one should
need to understand this property except the global router.
\item[CDCornerEdge] - see CDCorner propery.
\item[CDOuterChannel] is a property attached to the external channels.
\end{description}


\section{Global Routing}

\begin{intro}
After the channel definition and ordering step described in the
previous section, the data must be prepared for the global router.
The channel graph, with the positions of the terminals on its edges,
and a net list, are the inputs necessary for global routing.  In the
channel graph, nodes represent intersections between channels while
edges represent channels or sections of them.  Each edge in the graph
is assigned a weight that represents the maximum number of tracks that
can be accommodated in the channel.  Once the channel graph is built,
all the connected terminals of each macro-cell instance are projected
to the closest edge in the graph.  The weights on the edges are
interpreted as {\it capacity constraints}.  It is important to note
that the input to the global router is completely symbolic and
therefore totally independent of the layout style.

When the global router finishes, each net is represented by of a
sequence of subnets, each of which is assigned to one of the edges of
the channel graph.  When a net exits one channel to enter another one
a {\it pseudo-terminal} is created.

\end{intro}

\subsection{Tools}
\begin{description}
\item[cds] is the program that interfaces the Channel Definition System (CDS)
to the global router.
\end{description}

{\tt cds} consists of two phases: The first phase prepares the 
data in the format 
suitable for the used global router, presently {\tt TimberWolfMC}.
In the second phase, {\tt cds} reads the results produced by the global router
and stores them back into
OCT so that they can be used to complete the detailed routing by Spider.

\subsection{OCT structure}

After the global routing, each net
consists of a number of segments, each of
which is assigned to a channel. The connectivity among nets is obtained with 
pseudo-terminals located at the intersection of channels. These pseudo-terminals
can be considered as place holders for the actual connectors that will be
introduced by spider in the detailed routing phase. 
Niether the pseudo-terminals nor the subnets have, at this stage of the
pipeline, any geometry attached to them.
Their purpose is to combine the connectivity information with the path on
the channel graph that has been selected by the global router for each net. 
This information is stored in the database as follows:
\begin{description}
\item[CDSubnet] an OCT object of type net. It is contained by the relative
net. Each subnet contains exactly two pseudo-terminals and
actual-terminals.
\item[CDPseudoTerm] an OCT object of type bag. It is contained by exactly
two CDSubnets. It doesn't contain any OCT object. 
\end{description}

\section{Detailed Routing}

\begin{intro}
The channel server {\tt Cprep} analyzes information from the global router
and the channel definition
and ordering phase and produces channel specifications
for the router server {\tt Spider}.  {\tt Spider} performs the detailed 
routing of each channel using this information and the design rules for the 
fabrication technology.
{\tt Spider} can handle routing regions with irregular edges, and
wires with different widths, which is necessary to route
special nets like power and ground in the same channel with standard
signal nets.

{\tt Spider} serves as a data translator from OCT to a format usable by 
a channel router in the \mosaico\ library ({\tt yacr}, {\tt mighty}) and then back to OCT.
From the OCT channel description {\tt Spider} extracts a non-uniform symbolic
grid in which the grid lines are placed to 
obtain the best possible alignment with the actual locations of the pins.
If the general-area router {\tt mighty} is used,  an estimate of the 
space necessary to complete the routing must first be computed.
\end{intro}
\subsection{Tools}
\begin{description}
\item[Cprep] Pulls each channel out of the database in proper order and sets
up routing information.
\item[spider] Interfaces non-OCT based routers to and from OCT.
\item[YACR] General two layer channel router (fastest and powerful, YACR
almost always routes channels in the minimum number of wiring tracks).
\item[mighty] Maze routing based channel and switch box router (usually routes
a channel in the minimum number of tracks but is slower that YACR)
\end{description}

\section{Power and Ground Routing} 
\label{PGsec}
\begin{intro}
The routing of the power and ground nets is more involved than the
routing of signal nets because of problems related to voltage drops and
maximum allowable current densities.
As a consequence,
power and ground nets may have variable wire-segment widths.

In modern technologies the presence of two layers of metal makes it unnecessary
to require planar routing techniques for power and ground connections.
The policy used in \mosaico\ is to use the same set of tools to route both the
standard signals and power and ground. 
However, power and ground connections require some additional processing. 

Mosaico assumes that the amount of current that can flow through a
macro-cell without damaging its internal power (ground) connection is unknown.
Thus, none of the power(ground) nets are routed through any macro-cell.

After the global routing stage the current requirements of the power nets
are found at the boundaries of the channels. This information is passed to the
channel server {\tt spider}. After {\tt spider} performs the symbolic
routing of each channel, 
the segments of the power and ground nets in the channel are correctly sized.
\end{intro}

The nets with type ``SUPPLY'' or ``GROUND'' are treated specially by
\mosaico. The terminals on those nets are searched for the property
PEAKCURRENT, and the width of the nets is computed in order to
accomodate such current. The value of the maximum current density  for
each layer is currently stored in the {\tt MOSAICOrules} file in the
technology directory. 
The width of the power and ground wires in Lambda is quantized to the closest 
of the values in the sequence:
\[ 2,3,4,5,6,8,10,12,14,17,20,25,30,35,40, \ldots \]

\subsection{Properties}
\begin{description}
\item[NETTYPE]: string valued property (\osp). Legal values are: {\tt SIGNAL,SUPPLY,GROUND,CLOCK}.
\item[TERMTYPE]: string valued property (\osp). Legal values are: {\tt SIGNAL,SUPPLY,GROUND,CLOCK}.
\item[PEAKCURRENT]: real valued property (\osp), expressing the peak current through the terminal in amperes. Example: {\tt 0.005}
\end{description}
\subsection{Tools}
\begin{description}
\item[PGcurrent] must be run after global routing. Each P\&G net must
have only one source for PGcurrent to work properly. Power nets with
more than one source must be partitioned before running PGcurrent.
No tool will allow you to do this partitioning yet.
\item[spider] routes power and ground as signal nets initially, then uses
information from PGcurrent to correctly size the wires.
\end{description}



\section{Flattening}

\mosaico\ creates the routed view in a hierarchical way, one channel at
a time. The hierarchy is then flattened using {\tt octflatten}.

\subsection{Tools}
\begin{description}
\item[octflatten] a program for flattening instasnce hierarchies.
\item[nle] a library of routines that allow flattening and merging of
instances. Used by {\tt octflatten}.
\item[nleRpc] RPC version of {\tt nle}.
\end{description}


\section{Via minimization}
\begin{intro}
The input to the via minimizer {\tt mizer} is the flattened layout containing
macro-cells and wiring. At this point, all horizontal wires are on one metal 
layer
and all vertical wires are on the other metal layer. By reassigning some wire
segments to the opposite layer, the via minimizer reduces the total number of
vias. Note that the locations of the segments are not changed, only their
layer assignment. The terminals of a macro-cell are usually implemented in one
or more layer. These implementation layers determine which layers {\tt mizer} 
may use to connect to that terminal. {\tt mizer} does not
check the actual geometrys of the macro-cell to determine this information.
Because of this {\tt mizer} can not handle over-the-cell routing (yet).
\end{intro}

\section{Layout Spacing}

\begin{intro}
All steps in the \mosaico\ pipeline are carried out at the
symbolic-layout level.
Symbolic layout spacing (or compaction) is thus an essential part of
the system for several reasons.
First, all designs must be spaced to ensure that they are design-rule correct;
this has the advantageous effect of eliminating design-rule checking, since
the layouts are correct-by-construction.
Second, the use of generalized symbolic layout provides a mechanism for
producing technology-independent designs.
The spacing techniques used in \mosaico\ are capable of updating the symbolic
layout primitives themselves (e.g., transistors, contacts), as well as the
spacings between them.
Also, by the use of a variety of spacing techniques, various optimizations
of the layout can be performed over a range of area/cpu-time trade-offs.
{\bf Sparcs }
\cite{Jlb86} is the spacer presently used in \mosaico.
\end{intro}

\subsection{Tools}
\begin{description}
\item[sparcs] a symbolic-layout compactor.
\item[padplace] with the -S option, \padplace\ puts the proper constraints for
the pads.
\end{description}


\section{Verification and evaluation}

\subsection{mosaicoRC}
{\tt  mosaicoRC}
performs 4 different checks to asses the 
correctness of the routing process.
It checks the consistency, from a net-list point of view, of two facets;
it checks for disconnected terminals, disconnected paths, and
possible violations of the symbolic policy with respect to the
routing procedures.

The consistency check is performed in two steps. 
In the first step, the first facet is selected and 
all the nets attached to it are generated. 
For each one of the nets, all the terminals are generated. 
Every terminal is matched by name with a corresponding 
terminal on the second facet.
If the matching fails, an error is recorded. 
The procedure is then repeated with the facets exchanged.

To check for disconnected terminals, mosaicoRC proceeds as follows: For
each net, generate the first terminal attached to it and start to
follow the path originating from it.  The path is followed until
either it ends on a terminal or it branches to two or more other
paths.  Each one of these is then followed.  The procedure is repeated
recursively.  All the terminals are marked as soon as they are reached
by one of the paths starting from the first terminal.  When, for the
net under consideration, all paths have been examined, all
terminals attached to it must be marked.  For each one of the
terminals that is not marked, an error is detected and recorded.

The checking for disconnected paths is accomplished by generating all
paths attached to the layers used to perform the routing.  For each of
the paths it is checked that connects to exactly two between
terminals and connectors.

The checking for violations of the routing policies comes for free
while the other checks are being performed.

The inconsistencies eventually determined are reported in two
different formats: a textual one and a graphical one.  For the textual
messages a file named {\tt {\em circuitName}\_mosaicoRC.out} is
created and all the violations discovered are reported in it in an
textual format.  The violations that are related to geometric entities
are collected into a bag which is stored in OCT.

Once the execution of {\tt mosaicoRC} is completed, 
the errors can be displayed graphically by
means of Vem by the following sequence of operations:
\begin{description}
    \item run Vem;
    \item open the contents view of the facet on which {\tt mosaicoRC} has been run;
    \item select the bag named ROUTING\_ERRORS;
\end{description}
At this point the location where errors occurred will be highlighted.
Each of the object that is 
highlighted will have a property named ROUTING\_ERRORS
attached to it. 
The value of the property is a string that describes 
the type of the error detected.
Some of the errors, like for example differences between two facets,
cannot be represented graphically. In this case the error is
reported in the textual format only.
As a consequence, the most complete report of the inconsistencies
detected by {\tt mosaicoRC} is contained in the file
{\tt {\em circuitName}\_mosaicoRC.out}.

\subsubsection{OCT Structure}

ROUTING\_ERRORS an OCT object of type bag. 
It is contained by the facet and contains the
objects for which an error has been detected. 

ROUTING\_ERROR an OCT object of type property. 
It is contained by the bag ROUTING\_ERRORS
and by the object for which an error has been detected. 
It does not contain any object.
The property is of type string.
Its value is a short message describing the type of error detected.


\subsection{chipstats}

{\tt chipstats} computes various statistics on an OCT view. It can
be run on the routed view as well as on any other symbolic view. It
computes the length of each net (or its bounding box, if there is no
routing), the area of the chip, and the number of vias.

\input{use}


\chapter{Alphabetical Glossary}
\section{Floating terminals}


To specify a floating terminal, attach the property
``TERM\_FLOATING\_EDGES'' to it in the interface facet. This is a string valued property
consisting of a list of the edges in which the terminal is allowed to
float. For example: ``LEFT TOP''. The empty string ``'' means that all
edges are legal.

You  can use the program {\tt makeSoft} to make all terminals of a
cell floating. If you want to be more detailed, use \padplace\ with
the {\tt -l} and the {\tt -D} options (see the man page for \padplace\
for more details).

A cell with floating terminals is a SOFT cell.
See also Sec.\ref{flp}.


\section{Formal Terminals}

Each formal terminal MUST HAVE A DISTINCT NAME.

All formal terminals in the masters must have an implementation, with the exception of 
floating terminals. No connection can be made to terminals without an implementation.
Non-floating terminals without an implementation cause a fatal error for the routing system,
although the placement tools can get away with that. 

\noindent
{\bf Minimum separation requirement:} The terminals of the cells must
be at least 11 lambdas apart when working with ``scmos'' technology.
If they are closer than that, \mosaico\ might not be able to connect to them.
 
Formal terminals of chip should be implemented, because they help defining the pads, and because
that is the right way to do things anyway. The program  \padplace\ 
can help you give an implementation to formal terminals which lack
one. See the manual page for \padplace\ and in particular the option
{\tt -u}. See alsp Sec.\ref{netlist} and Sec.\ref{padfamily}

\subsection{Properties}
\begin{description}
\item[DIRECTION]: string valued property: one of {\tt INPUT, OUTPUT} or
{\tt INOUT} (\osp). This property is extremely important for 
power and ground terminals. 
\item[PEAKCURRENT]: real valued property, expressing the peak current
expected through the terminal in amperes for power and ground terminals
only (\osp).
\item[TERMTYPE]: one of {\tt SIGNAL, CLOCK, SUPPLY, GROUND} (\osp).
\item[TERM\_FLOATING\_EDGES]: list of edges on which a floating terminal is
allowed to be placed. The empty string is the default, meaning that
all edges are legal. Examples: {\tt "LEFT", "LEFT RIGHT", "TOP
BOTTOM", "LEFT RIGHT BOTTOM" }.
\item[TERM\_EDGE]: one of {\tt LEFT, RIGHT, TOP, BOTTOM}. This is the
edge where the floorplanner recommends
the terminal should be placed.  
\item[TERM\_RELATIVE\_POSITION] is a real valued property in the
range [0.0,1.0] representing the position of the terminal on the edge
specified by ``TERM\_EDGE''. For example, a value of 0.75 means that
the terminal should be placed in a position corresponding to 75\% of
the edge, computed from left to right and from bottom to top.
\item[TERM\_ROW] In the case in which you need more than 1 row of
pads, this property specifies the row in which the pad should go. Row
0 is the outermost row, row 1 is the next row, and so on.
\end{description}


\section{Instances}

A chip has a number of instances. Every instance which is not a connector must have a
distinct name. Every connector that implements a formal terminal should also have a distinct name.
\begin{description}
\item[MOBILITY] (\osp) FIXED means that the cell's coordinates cannot be
changed by \mosaico. Default is ``MOVABLE''.
\item[PLACEMENT\_CLASS] Used especially to recognize the pads.  See section\ref{pads}.
\item[LEGAL\_TRANSFORMATIONS] is a string valued property. The string
is a list of words from the following vocabulary:
\begin{itemize} 
\item ``ALL'' , the default value, means that all the transformations are
legal;
\item Any OCT transformation, without the prefix ``OCT\_'': ``NO\_TRANSFORM'', ``MIRROR\_X'',
``MIRROR\_Y'', ``ROT180'', ``ROT90'', ``ROT270'', ``MX\_ROT90'',
MY\_ROT90'';
\item ``THIS\_ASPECT\_RATIO'' is a short hand for the list of 4
transformations which maintain the aspect ratio of the cell:
``NO\_TRANSFORM MIRROR\_X MIRROR\_Y ROT180'';
\item ``NOT'' means that all the following transformations are not
legal.
\end{itemize}
Examples: ``NOT THIS\_ASPECT\_RATIO'', ``ROT90 ROT270 NO\_TRANSFORM''.

The property can be attached to the interface of the master. If it is
attached both to the instance and to its master, the instance property overrides.
\end{description}

\subsection{Pads}
\label{pads}

Pads are special instances which want to be placed along the periphery
of the chip. In general, pads are flagged by a special property, but
in other cases pads are implicitly defined by the fact that they
provide the implentation for the formal terminals of the chip.

\begin{description}
\item[PLACEMENT\_CLASS] This property is attached either to the
instance or to the interface of the master. In both cases it has value ``PAD''.
\end{description}

\subsection{Pad families}
\label{padfamily}
This section applies to version 3 of \padplace\ and all later versions.

Pads are often designed in families, each containing a Vdd pad, a Gnd
pad, an input pad, an output pad, and maybe others. Pads of the same
family can abut and can create power and ground rings. In this section
it is explained how a pad family can be described so that \padplace\ can use
the family to give a correct implementation to all the formal
terminals of a chip.

Each pad in the family must be assigned a type and a direction. 
\padplace\ will match type and direction of the formal terminal, to find the
pad which is the proper implementation.
\padplace\ also will take into account power consumption of the pads to determine how many 
power and ground terminal to add to the  chip bejond those already present in the chip.

A pad family can be of two types: instances (the ``normal'' type) or connectors.



A facet decribing the family must be of type SYMBOLIC and contain:
\begin{itemize}
\item
One instance of each pad. The instances should be attached to
INSTANCES bag or to the CONNECTORS bag according to the type of the family.

 The instances should be rotated so that they
can be placed on the top of the chip (inner edge facing down).
Each instance should be annotated with the property DIRECTION (INPUT,
OUTPUT, INOUT) and TERMTYPE (SUPPLY, GROUND, CLOCK , SIGNAL).
Also each instance must have the real valued property
PAD\_VDD\_GND\_REQUIRED, expressing the amount of power required by
the pin. For example: Suppose that the for a particular family, one
should put one vdd/gnd pair for each 4 output pads. This will be
expressed by attaching to the output pad the property
PAD\_VDD\_GND\_REQUIRED with value 0.25 = 1/4.

\item
One net called PAD\_BONDING\_PINS containing all the bonding pins
which will give the implementation to the formal terminals.
\item
One net called PAD\_INTERNAL\_PINS containing all the bonding pins
which will give the implementation to the formal terminals.
\item
One net called PAD\_SUPPLY\_RING containing all the terminals that
must be connected to form the supply ring for the pads. The net should
also contain a path of the right width on the correct layer for the
ring.
\item
One net called PAD\_GROUND\_RING containing all the terminals that
must be connected to form the ground ring for the pads. The net should
also contain a path of the right width on the correct layer for the
ring.
\item
One property called PAD\_MINIMUM\_SEPARATION to specify the minimum
distance between the pads. A separation of 0 means that the pads can
be abutted.
\end{itemize}

\noindent
{\bf Current limitations: }
Only 1 power voltage is supported. Tristate outputs are not supported yet.

\subsection{Tools}

\begin{description}
\item[padplace] is the tool for pad placement. It understands which cells
are pads, which side should face towards the inside of the chip, and
can place the pads according to a number of different schemes.
An instance is a pad if one of the following three conditions is satisfied:
\begin{enumerate}
\item The instance has the property PLACEMENT\_CLASS with value PAD;
\item The master has the property PLACEMENT\_CLASS with value PAD;
\item An actual terminal of the instance is attached to a formal terminal of the cell.
\end{enumerate}
\end{description}

\section{Layer PLACE}

The layer ``PLACE'' is a dummy layer used by \mosaico. Currently, the routing phase of \mosaico\ 
(see \ref{chdef}) requires the layer to be present in the interface facet of the master
of each instances. The geometry on the layer PLACE is used to define
the shape of the cells.  

{\em The layer PLACE is now generated automatically by {\bf vulcan}.
However, there are good reasons to change {\bf vulcan} so that it does
no longer generate the layer PLACE. We are currently changing \mosaico\ 
so that it does not require the layer PLACE in the input facet. The
layer PLACE will still be used internally by \mosaico.}

The layer PLACE is also used to give shape and implementation to 
soft cells (see \ref{flp}).

See also \ref{chdef}, \ref{flp}.



\section{Nets}

Unique names for nets are NECESSARY.

\begin{description}
\item[NETTYPE] one of {\tt SIGNAL, CLOCK , SUPPLY, GROUND} (\osp).
\item[NET\_CRITICALITY] integer valued property in the range
[-1000,1000] (\osp). Criticality 0 is the default. The higher the
criticality, the shorter the net should be.
\item[NET\_MAX\_LENGTH] integer valued property (\puppy\ only) for
the placement tools, this property suggests the maximum length of the
net (in lambdas).
\end{description}

\chapter{RPC applications}

Fig.\ref{fRPC} shows how you can modify the {\tt vem.bindings} file in order to
include those RPC applications that have been developed with the \mosaico\ system.
Each application is briefly described in this chapter.
\begin{figure}
\begin{verbatim}
REMOTE  nleRpc          localhost       ~octtools/bin/rpc/nleRpc
REMOTE  atlas           localhost       ~octtools/bin/rpc/atlas
REMOTE  mosaicoDemo     localhost       ~octtools/bin/rpc/mosaicoDemo
INCLUDESTD
symbolic        nleRpc          MENU MOSAICO    1       ALIAS
symbolic        atlas           MENU MOSAICO    2       ALIAS
symbolic        mosaicoDemo     MENU MOSAICO    5       ALIAS
\end{verbatim}
\caption{Example vem bindings file to include the \mosaico\ RPC applications}
\label{fRPC}
\end{figure}

\section{atlas: channel definition}
The enables the user to visually check the channel definition and ordering.
If the channel definition is not what is desired, then the user can alter the placement
of instances using vem drag instance (don't use vem move instance) and do another
channel definition.

\section{nleRpc: net list editing}
This RPC application gives direct access to the routines in the {\tt
nle} library. See Sec.\ref{nle} for more detail.

\section{mosaicoDemo: monitoring of \mosaico}
This application makes a great demo, but it can also be useful to
check the behavior of \mosaico\ in each phase of the pipeline, as well
as in each channel. See the man page for more details.

\chapter{Miscellaneous libraries}

\section{adm:}
The scope of the adm library is to provide a mechanism to record
on an OCT facet the
sequence of tools that have been used to generate the 
data that is presently stored in the facet.
Furthermore,
adm routines provide a way to check that dependency
order among tools is satisfied.

Presently the adm library consists of 4 routines, namely
\begin{itemize}
    \item admToolName( toolName, argc, argv )
    \begin{description}
	\item char *toolName; 
	\item char *argv[];
	\item int  argc;
    \end{description}
    \item admLogInTool( OutFacet )
    \begin{description}
	\item octObject	*OutFacet; 
    \end{description}
    \item admLogOutTool( OutFacet )
    \begin{description}
	\item octObject	*OutFacet; 
    \end{description}
    \item int admCheckInput( InFacet)
    \begin{description}
	\item octObject	*InFacet; 
    \end{description}
\end{itemize}

\subsection{Routine Description}

\begin{description}
\item[admToolName]
records the name of the tool, the command line used to run the tool.
admToolName initializes also the procedure necessary 
to collect statistics on the OCT utilization.
For this reason
the routine must be called before the first call to an OCT routine.
In any case it cannot be called after any other routine in the adm library. 
If this constraint is violated, the program calling any of the adm routines 
will terminate and an error message will be printed on
stderr.

\item[admLogInTool]
put a signature of the tool on the output facet. 
If any errors occur, a message is printed on stderr and the execution is terminated.

\item[admLogOutTool]
completes a signature of the tool created 
on the output facet by admLogInTool with the
information that the tool has successfully completed its job.
The routine call must be the last thing before the facet is closed.
If any errors occur, a message is printed on stderr and the execution is terminated.

\item[admCheckInput]
checks that the precedence relations are satisfied before the tool is run.
The routine call must follow immediately routine admLogInTool.
It returns ADM\_GO if the data in the input facet contains all the 
information required by
to toolName. If not it retuns ADM\_NO\_GO.
The relations used to check consistency are, in the present version, as follows:
\begin{itemize}
    \item padplace: NO PRECEDENCE IS REQUIRED;
    \item puppy: NO PRECEDENCE IS REQUIRED;
    \item atlas: NO PRECEDENCE IS REQUIRED;
    \item cds: DEPENDS ON atlas;
    \item PGcurrent: DEPENDS ON cds;
    \item cprep: DEPENDS ON (cds OR PGcurrent);
    \item octflatten: DEPENDS ON cprep;
    \item mosaicoRC: NO PRECEDENCE IS REQUIRED;
    \item sparcs: DEPENDS ON octflatten;
\end{itemize}

\end{description}

\subsection{OCT Structure}

The data is stored in the facet in the following format.

MOSAICO\_HISTORY octObject of type bag. Contains any number of octObjects of type bag,
one for each of the tools that have been run on the facet.
It is contained by the facet.

ToolName octObject of type bag. Contains 4 octObjects of type property. It is contained
by the bag MOSAICO\_HISTORY.

COMMAND\_LINE octObject of type property. 
It does not contain anything. 
It is contained by the ToolName bag. 
The property is of type string.
Its value is the command line that has been used to run ToolName.

TIME\_LAST\_CALL octObject of type property. 
It does not contain anything. 
It is contained by the ToolName bag. 
The property is of type string.
Its value is the time and date in which ToolName was started.

TIME\_LAST\_CALL\_SECS octObject of type property. 
It does not contain anything. 
It is contained by the ToolName bag. 
The property is of type integer.
Its value is the time and date, expressed in seconds, in which ToolName was started.

COMPLETION octObject of type property. 
It does not contain anything. 
It is contained by the ToolName bag. 
The property is of type integer.
Its value is 1 if ToolName completed successfully and is 0 if some error has been
detected.

\section{nle: net list editing}
\label{nle}
The {\tt nle} library provides a set of routines for flattening,
merging, and substitution  of instances. The most difficult thing to
understand is the concept of the ``type'' of a flattening or of a merging.
\begin{itemize}
\item HARD flattening means that any existing routing of the nets is
preserved. HARD merging means that all the actual
terminals of the instances to be merged are promoted to formal
terminals if they are attached to a net that crosses the boundary of
the partition.  (clear ?) HARD merging is not well defined when
routing is present. In any case, the routing will not be preserved.
HARD merging and HARD
flattening are the inverse operations of each other only if no routing
is involved.
\item SOFT flattening means that all the routing inside the instance to
be flattened is ignored. SOFT merging means that the  new cell are one
for each of the nets that cross the boundary of the partition. Each of
these terminals has no implementation. SOFT merging and SOFT
flattening are the inverse operations of each other.
\end{itemize}

\appendix
\chapter{Appendix: Channel definition policy}
\label{chdefpol}
{\small\hsize=6in
\begin{verbatim}
Channels:

Channels are grouped in a binary tree as follows:

Each channel represents a submodule and a generalized partition of itself.
The partition represents the "channel" subdividing the submodule.

channel name = "CDChanDef" (type==OCT_BAG)
contains:
    if a real channel:
        channel order property
        sub channels
        sub nets
        instance corner edges
    if a leaf channel (no partition):
        cell instance
        surrounding global wire graph description
containers:
    channel (if not root channel)
    contents facet (if root channel)

Channels have a order property.  This property designates the order in which 
the channels are to be routed.

channel order name = "CDChanOrder"   (type==OCT_BAG, prop.type==OCT_INTEGER) 
    prop.value = order which the channels are to be routed (0 = 1st channel
                 to be routed, n = (n+1)th channel to be routed).



e.g.

The macro cell below is represented by the tree on the right:

      +----------+.....+--------+                 ************
      |          |     |        |                 * contents *
      |          |     | Inst 2 |                 *   facet  *
      |          |     |        |                 ************
      |          |  C  +--------+                       |
      |          |  h  .        .                  .....V.....
      |  Inst 1  |  a  . Chan B .                  . Chan  A .
      |          |  n  .        .                  ...........
      |          |     +--------+                   |       |
      |          |  A  |        |         ..........V..   ..V........
      |          |     | Inst 3 |         . Leaf Chan .   . Chan  B .
      |          |     |        |         .............   ...........
      +----------+.....+--------+            |              |     |
                                       +-----V--+ ..........V.. ..V..........
                                       | Inst 1 | . Leaf Chan . . Leaf Chan .
                                       +--------+ ............. .............
                                                        |             |
                                                    +---V----+  +-----V--+
                                                    | Inst 3 |  | Inst 2 |
                                                    +--------+  +--------+


Global route subnets:

Nets are grouped into channels as follows:

1) A subnet corresponding to channel is attached under the net
2) All aTerms in the net/channel are attached under the subnet.
   The original net - aterm attachments are untouched.
3) Pseudo terminals (terminals of the subnet representing net channel to
   channel interfaces) are created and attached to both the original
   net and the subnet.
4) Subnets are then attached under its corresponding channel.

channel subnet name  = "CDSubNet"     (type==OCT_NET)

subnet contains:
    actual terminals    (real terminals)
    psuedo terminals    (channel to channel terminals)
subnet containers:
    original net
    channel subnet traverses

psuedo terminal name = "CDPseudoTerm" (type==OCT_BAG)

psuedo terminal contains:
    net width property
psuedo terminal containers:
    subnet
    original net

The net pin width is attach to pseudo terminals and actual terminals of special
net pins that are not to be routed by a standard minimum width wire.

net terminal width name = "PorGWidth" (type==OCT_PROPERTY,
                                       prop.type==OCT_INTEGER)


e.g.

A global wire net below is represented by the tree on the right:

                                                            ..........
                                                            . Chan A .----+
                                                            ..........    |
                                                                          |
                                                            ..........    |
        .      .                                            . Chan B .    |
        .      .                                            ..........    |
        .Chan B.                         *************             |      |
        .      .                         *  Net      *----------+  |      |
  ATerm 3--+   .                         *************-------+  |  |      |
        .  |   .                          |  |  |  |         |  |  |      |
        .  |PTerm      ATerm     *********V* |  |  |         | .V..V..... |
     ......4.............2..     * ATerm 3 <-|--|--|---------|-. SubNet . |
           |             |       *********** |  |  |  +------|-.......... |
  Chan A   +-+-----------+                   |  |  |  |      |            |
             |                      .........V. |  |  |      |            |
     ........1..............        . PTerm 4 <-|--|--+      |            |
           ATerm                    ..........<-|--|----+    |            |
                                                |  |    |    |            |
                                       *********V* |    +---.V........    |
                                       * ATerm 1 <-|--------. SubNet <----+
                                       *********** |    +---..........
                                                   |    |
                                          *********V*   |
                                          * ATerm 2 <---+
                                          ***********

Global wire graph:

Surrounding global wire graph description

graph description name = "CDGraph" (type==OCT_BAG)
contains:
    1st point of surrounding polygon
containers:
    leaf channel

Surrounding polygon is an ordered list of vertices
that are connected together
with bags representing the graph edges.

The vertices are OCT points and the edges are OCT bags.

The graph edges represent global wiring channels.
The graph edges have an edge width property representing the width of the
global wiring channel.  The graph edges are attached to its corresponding
routing channel.

graph edge name = "CDGraphEdge" (type==OCT_BAG)
contains:
    points  (representing end points - last/closing endpoint is assumed to
             be the first point attached to the graph description bag and is not
             attached to that point).
    global wire channel width property
containers:
    channel (routing channel corresponding to global wiring channel - a 
             many to 1 surjective mapping)

global wire channel width name = "CDEdgeWidth" (type==OCT_PROPERTY,
                                                prop.type==OCT_INTEGER)
    prop.value = average width of global wiring channel in database units


Corners:

Corners of instance boundaries designate each instance boundary segment to
a routing channel.  The boundaries of an instance are assumed to be either
clockwise or counterclockwise (i.e. the instance boundary
does not cross itself).
A boundary path delineating part of the routing channel defined by a bordering
instance is defined by two corners and a corner edge attached to the
routing channel.
Each corner is an index into an array of points (representing the boundary of
an instance).

corner bag name = "CDCorners" (type==OCT_BAG)
contains:
    1st corner of instance boundary
containers:
    instance

corner name = "CDCorner" (type==OCT_PROPERTY, prop.type==OCT_INTEGER)
    prop.value = index into oct point array of instance master "place" layer
                 polygon.  However if instance master "place" layer bounding
                 polygon is a box then:
                 0 represents the lower left corner of the master box,
                 1 represents the lower right corner of the master box,
                 2 represents the upper right corner of the master box,
                 3 represents the upper left corner of the master box.

corner edge = "CDCornerEdge" (type==OCT_BAG)
contains:
    corner property
containers:
    channel

\end{verbatim}
}
\bibliographystyle{plain}
\bibliography{mosaico}
\end{document}
