\chapter{How to run \mosaico}

This chapter gives a brief introduction on how one can use \mosaico\ to 
place and route a chip.

\section{Get a correct net list}
\label{netlist}
The input for \mosaico\ is a net list, that is, a description of the
cells that constitute the chip with all the nets that interconnect
terminals of the cells. This net list must be stored in the OCT
database in a facet obeying all the rules of the \osp. Once you have
a correct net list \mosaico\ will do the
placement, routing and compaction.

In order to get a net list you can use one of the following tools:
\begin{description}
\item[bdnet] is a net list translator distributed with the
octtools. See relevant man page. 

Some special rules should be used when you set up a bdnet file to
describe a chip for \mosaico.
\begin{itemize}
\item Remember to attach the NETTYPE ({\tt SUPPLY} or {\tt GROUND}) property to your supply and
ground nets;
\item Remember to attach the TERMTYPE  ({\tt SUPPLY} or {\tt GROUND}) 
property to all the supply and ground formal terminals in the
interface facet of the chip.
\item Do not worry about pads. Just provide one formal terminal for
each pad. You can use \padplace to implement the pads and to place them
around the chip;
\item You can use the bdnet file to add special constraints for the
placement, like the FLOORPLAN bag (see section \ref{flp}), or the
LEGAL\_TRANSFORMATIONS property for the instances.
\end{itemize}
\item[tw2] provides an interface between the TimberWolfMC input
format and OCT. See the man page for {\tt tw2} for more details.
\end{description}

\subsection{Editing the net list, merging and flattening}

{\tt NOTE: you can skip this section on your first reading.}

Suppose that you have a {\em correct} net list and that you would like
to edit it. For example, you might want to partition your design into
two or more smaller pieces. The basic tool to do this is the {\tt nle}
library. You can either use {\tt nleRpc} to work interactively or {\tt
alba} to work in batch mode.

In order to define a partition with {\tt alba}, you need to create the
following structure  in
the contents facet of your chip:
\begin{itemize}
\item A bag whose name begins with the letters ``{\tt PARTITION}''.
The name can be longer. For example ``{\tt PARTITION\_my\_subchip}'' is
a legal name. The bag must contain all of the following:
\item All instances that belong to the partition;
\item property {\tt PARTITION\_NAME} whose value is a string which is the name of the new cell to be created;
\item property {\tt PARTITION\_TYPE} with value {\tt HARD} or {\tt SOFT},
according to the type of merging that you want to perform (see man
page for {\tt nle});
\item optional property {\tt MODULE\_GENERATOR}, with value the name of the
program that you want to use to process the partition. For example,
this could be ``wolfe'' or ``mosaico''.
\end{itemize}
This structure is used by \padplace to specify how the pads should be
merged into pad blocks in order to simplify the job of the router.

\section{Implement and place pads}

Suppose you have your chip correctly described in the OCT view {\tt
chip:unplaced}.
The next thing to do is to implement the pads. First of all, get a list
of all the formal terminals and of their properties using \padplace.

\begin{verbatim}
    padplace -l chip:unplaced > chip.pads
\end{verbatim}

The file {\tt chip.pads} contains the list of all the terminals. The
format of this file is such that it can be fed back into \padplace. You can
edit the file to add placement information like TERM\_EDGE and
TERM\_RELATIVE\_POSITION, TERM\_ROW (Fig.\ref{padplacefile}).

Then you can ask \padplace to implement all the
pads. Normally \padplace comes with the following pad families in the {\em scmos} technology:
\begin{description}
\item{\_2uFamily}
\item{\_msuFamily}
\item{\_cFamily}
\end{description}
Suppose that for your chip you want to use the 
{\tt \_2uFamily}, and that you want \padplace to use  the information
contained in {\tt chip.pads} to decide where each pad should go.
Then you can type:

\begin{verbatim}
    padplace -u _2uFamily -D chip.pads -o chip:with_pads chip:unplaced
\end{verbatim}

If you do not have a clear idea on where to place the pads, you can use
the {\tt -n} option of \padplace to obtain a pad placement that attempts
to minimize the length of the nets connected to the pads. This is
especially useful with the {\tt \_cFamily}. Try:

\begin{verbatim}
    padplace -u _cFamily -o chip:with_pads chip:unplaced
\end{verbatim}

Use {\tt vem} to check that everything is like you want it. Then go on to
the next section.

\begin{figure}
\begin{center}
\begin{verbatim}

#
# Formal Terminal description for ram:flat
# padplace recognizes the following keywords:
# TERMTYPE DIRECTION
# TERM_FLOATING_EDGES TERM_EDGE 
# TERM_RELATIVE_POSITION TERM_RELATIVE_POSITION_STEP 

# This file uses a 'REVERSE' logic: 
# First you specify the properties
# then the terminal for which the props apply
	TERMTYPE SIGNAL
	DIRECTION INPUT
	TERM_EDGE LEFT
FORMAL_TERMINAL shr
FORMAL_TERMINAL shl
FORMAL_TERMINAL clk
FORMAL_TERMINAL clear
	TERM_EDGE RIGHT
FORMAL_TERMINAL data<2>
FORMAL_TERMINAL data<1>
FORMAL_TERMINAL data<0>
	DIRECTION OUTPUT
	TERM_EDGE TOP
FORMAL_TERMINAL char2_out<3>
FORMAL_TERMINAL char2_out<2>
FORMAL_TERMINAL char2_out<1>
FORMAL_TERMINAL char2_out<0>
	TERM_EDGE BOTTOM
FORMAL_TERMINAL char4_out<3>
FORMAL_TERMINAL char4_out<2>
FORMAL_TERMINAL char4_out<1>
FORMAL_TERMINAL char4_out<0>
\end{verbatim}
\end{center}
\caption{Example of a file created by \padplace and edited}
\label{padplacefile}
\end{figure}

\section{Place the chip}


First, it is useful to run {\tt symclean} on
your design.  {\tt symclean} checks an Oct facet for conformity to Oct
symbolic policy and can try to clean up problems. 

\begin{verbatim}
    symclean [-duv] chip:placed
\end{verbatim}

By default, {\tt symclean} will not modify the cell.  The {\tt -d} flag allows {\tt symclean} to
make the necessary modifications.  If the {\tt -u} flag is specified,
unimplemented
formal terminals will not be deleted (formal terminals from MIS and BDNET do
not have implementations). {\tt Vulcan} will be run if any changes have been
made. The {\tt -v} flag turns off the use of {\tt vulcan}.

Now, you can either run \mosaico\ with the {\tt -P}
option, which will invoke \puppy\ as a placement tool and then go on to
the routing, or you can invoke \puppy\ directly with:

{\tt puppy -o chip:placed chip:with\_pads }

\section{Run \mosaico}

\subsection{Easy to use}
You now have a placed chip in {\tt chip:placed}. To route the chip type:

\noindent
{\tt mosaico chip:placed}

\noindent
Done! The output view is {\tt chip:placed.spaced}, but you can specify
another output view with the {\tt -o } option.
Many intermediate files and directories are created by \mosaico, 
these will deleted after they are no longer needed if you run \mosaico\ with 
the addition of the  {\tt -c} option. 


\begin{verbatim}
    mosaico -c chip:placed
\end{verbatim}

\noindent
If you
have already run \mosaico\ without the {\tt -c} option, you can clean
the unnecessary files using the {\tt -C} (capital C) option:

\begin{verbatim}
    mosaico -C chip:placed
\end{verbatim}


\subsection{Time and space requirements}

The whole process might take anywhere from 5 minutes for a small chip
with less than 10 cells and about 20 nets, to a few hours for large
chips with a few tens of cells and hundreds of nets. The two standard
benchmarks ({\tt ami33} and {\tt xerox}) take about 30 CPU minutes each on
a VAX 8800.

\mosaico\ creates a number of intermediate files, directories and
facets. The {\tt RTstuff} directory contains all the channels before
and after routing. It also contains the log files generated by spider.
These files can be useful to the expert user for debugging, but under
normal conditions they contain no useful information.
Typically, each channel requires about 20 to 200 kBytes of disk
storage, depending on the amount of routing. Large channels (hundreds
of nets, 50 or more tracks) can grow up to half a MByte or more.

OCT cells with name of the form {\tt <chip>.ioleft, <chip>.ioright,
<chip>.iotop, <chip>.iobottom} contain the I/O pads, which are merged
together in order to reduce the number of channels to be routed.

The file {\tt mosaicoDemoRpc.seq} can be used together with the RPC
application {\tt mosaicoDemo} (see manual).

The file {\tt <chip>\_mosaicoRC.out} contains the output from {\tt
mosaicoRC} and it is created only if any error is detected in the routing.

The following views of the chip are also created:
\begin{description}
\item[{\tt placed.cd}]: containing the channel definition;
\item[{\tt placed.cd\_after\_gr}]: containing the global routing information;
\item[{\tt placed.hier}]: containing the complete hierarchy of channels;
\item[{\tt placed.flat}]: which is the flattened version of {\tt
placed.hier};
\end{description}

\subsection{If something goes wrong}

To be realistic, sometimes something goes wrong, often due to 
some misunderstanding or some missing property. To find out where the problem is,
it is always convenient to redirect the output from {\tt mosaico} to a file:

{\tt mosaico <chip>:placed >\& mout \&}

Study this file ({\tt mout}) to discover all the errors that have occurred. Then
refer to the documentation relative to the appropriate tool to
solve the problem. 

\subsection{Common problems}
\begin{description}
\item[Overlapping instances:] If there are overlapping cells, the
definition of channels impossible. If the 
ovelapping is minor, \mosaico\ will first try to expand the placement
by a fixed factor of 1.1. If overlap persists after the expansion, the
run will be aborted. It is up to you to solve the problem. If you used
\puppy\ for the placement, you can try to rerun it using a slightly
higher weight for the overlap cost. Also, you could just try to rerun
\puppy\ keeping the same parameters. \puppy\ uses a
probabilistic algorithm and it will generally produce different
placements in each run (however the cost of the final placement will
be about the same).
\item[Dropped nets:]
\item[Terminals too close:] Terminals must be separated by a minimum amount
that is dependent on the technology being used regardless of the layer(s) the
terminals are on.  \mosaico\ ({\tt spider} in particular) will complain
somewhat like this: 
\begin{verbatim}
ERROR - pins too close
        PIN VDD at loc 40620, 63300 width 400
        PIN HandXHS1 at loc 40450, 63760 width 60
\end{verbatim}

This indicates that terminals VDD and HandXHS1 are too close and their
locations and widths. This situation must be fixed because one of these
terminals will be left unconnected.
\item[Terminals on a wrong layer:] known layers for standard scmos technology
are: {\tt MET1, MET2, POLY}. Terminals on other layers cannot be used.
\item[Other routing errors:] \mosaico\ performs double checking of the
routing using the program {\tt mosaicoRC}. If an error is detected,
you should check the file {\tt <cellname>\_mosaicoRC.out} for a textual
description of the error. In the file you will also find instructions
on how to use {\tt vem} to see the location of the error. 
\item[Power and ground nets are not proper size:] this is generally due
to lack of properties in the right places. See section \ref{PGsec} for
more details.
\end{description}


\subsection{Known problems}
\begin{description}
\item[Placement with overlapping instances:] The algorithm used by
\puppy\ (Simulated Annealing) performs a minimization of a cost
function, and it does not guarantee an overlap free placement. It is
generally easy to obtain an overlap free placement by properly tuning
the annealing parameters using the interactive graphical interface
provided by \puppy. See the {\em Puppy Users Guide} for more details.
\item[Inefficient use of empty rooms:] \mosaico\ performs at its best
on dense placements, with no empty rooms (large empty areas). If your
placement has empty rooms, they might stay empty.
\end{description}

\section{Floorplanning}

Suppose that your chip has one cell which is not yet implemented.
Suppose also  that the module generator that you are going to use to
implement the cell gives you some flexibility on the shape of the cell
as well as on the position of its terminals. The \mosaico\ system 
provides some support to decide which constraints to set for the
implementation of the cell. This will be illustrated by an example.


The floorplanning tool in \mosaico\ is \puppy\ which cannot
handle cells with variable aspect ratio (at least for the time being).
Thus you  have to decide the shape of the cell. Suppose that you want
this shape to be a rectangle 100 by 300. Type the following command:

\begin{verbatim}
    makeSoft -w 100 -h 300 MYSOFTCELL:someview
\end{verbatim}

And this is all we can do for the aspect ratio of the cell. 

\puppy\ does handle floating pins on soft cells. Some terminals
are only allowed to be floating on some of the edges of the cell,
others can float anywhere. 
One easy way to tell \puppy\ that the terminals are
floating is to use {\tt makeSoft}. For example:

\begin{verbatim}
    makeSoft -F LR MYSOFTCELL:someview
\end{verbatim}

specifies that all the terminals of the cell can float but only on the
left or on the right edge ({\tt -F LR}).

A more detailed representation of the constraints on the floating pins
can be expressed using \padplace:

\begin{verbatim}
    padplace -l  MYSOFTCELL:someview > someFile
\end{verbatim}

to get a list of all the terminals of the cell. Then you can edit the
file {\tt someFile} which might look something like Fig.\ref{padplace.file}.
The file says that the 3 input terminals can float only on top and
left edges, while the output terminals can float only on the right edge.
Give this information to \padplace again:

\begin{verbatim}
    padplace -D someFile  MYSOFTCELL:someview
\end{verbatim}


\begin{figure}
\begin{center}
\begin{verbatim}
# comments begin with a \# and end with newline

       TERM_FLOATING_EDGES TOP LEFT
FORMAL_TERMINAL in.1
FORMAL_TERMINAL in.2
FORMAL_TERMINAL in.3
       TERM_FLOATING_EDGES RIGHT
FORMAL_TERMINAL out.1
FORMAL_TERMINAL out.2
       TERM_FLOATING_EDGES RIGHT TOP
FORMAL_TERMINAL clock
\end{verbatim}
\end{center}
\caption{Example of file to describe floating terminals. Indentation
is used only for clarity. You can use
this file also to specify other properties of the terminals, like
DIRECTION and TERM\_TYPE}
\label{padplace.file}
\end{figure}


\subsection{Important note on floating pins}

Floating terminals are very hard to deal
with, especially if there are many (hundreds) of them. \puppy\ finds 
it hard to decide on an orientation for a cell whose terminals
are all floating because at high temperature almost all the
orientations are equivalent. This means that for reasonable running
times, the resulting placement
might not be very good (it might even be unfeasible).

It is always
better to constrain the floating terminals as much as possible.
The possibility to do this depends, of course, on the specific
problem. In some cases it makes sense to constrain the input
terminals all on one side, while letting the output terminals float on the
opposite side. 

Depending on the structure of your chip, there might be some pad
arrangements that make more sense than others. Although it would be
desirable that the tools themselves automatically detect this
condition, this is not yet the case. Locally, for each soft cell,
\padplace with its option {\tt -n} can generally do a good job.

\subsection{Wolfe and \mosaico}

If a chip contains standard cells like those in the MSU library,
you should use {\tt wolfe} to obtain a dense layout of these cells.

You should determine an  optimal partitioning of all the standard
cells in your chip. Then place and route each partition using {\tt wolfe},
then use \mosaico\ to wire all the pieces together.
The process of determining  an optimal  partition is currently not
supported by any tool (i.e. it must be done by hand, trying to be a little
smart about it). 

Please consider the following ideas:
\begin{itemize}
\item You can control the aspect ratio of a {\tt wolfe} cell using the {\tt
-r} option (specifying the number of rows). Alternatively, you can use
{\tt makeSoft} to specify a target bounding box for the cell.
\item You can control the position of each terminal in a wolfe cell
using the {\tt TERM\_EDGE} and {\tt TERM\_RELATIVE\_POSITION}
properties. \padplace provides an easy ASCII interface to enter such
properties, and \puppy\ can choose the optimal value for those
properties based on its own floorplanning criteria.
\item It is not a good idea to have a partition containing only one standard
cell, but it is disastrous to have many such partitions. You can merge
standard cells into the same partition using {\tt nle} or {\tt alba
-p} (please refer to the appropriate manuals). 
\end{itemize}

\subsection{Hand layout and \mosaico}

Some rules should be followed to allow a painless integration of hand layout in
a chip which has to be routed by \mosaico. The rules
are listed here ordered by importance:
\begin{itemize}
\item Do not allow terminals to overlap.
\item Keep the terminals at least 7 lambdas apart (for scmos) \footnote{The
recommended spacing between terminals is the minimum center to center distance
of two MET1-MET2 vias}. One easy way to guarantee this result even
after compaction is to implement all the terminals using MET1-MET2 vias.
\item The layers  connected to are MET1, MET2, and POLY.
A terminal must contain at least one geometry on these layers or it
cannot be connected by \mosaico.
\item Place all the formal terminals along the periphery of the cell so that
they can be easily accessed from outside the cell.	
\item Try to use the same layer to implement all the terminals that appear on the same
side of a cell. Example: make all the terminals on the TOP of the cell
in MET1 and all the terminals coming out form the LEFT edge of the
cell in MET2. The effect of applying this rule is that of producing ``better looking'' routing.
This is by far the least important of all the rules.
\end{itemize}

The restrictive rules mentioned above make it easier for
\mosaico. However, \mosaico\ has been designed to handle much more complicated
situations, like irregularly shaped cells, terminals internal to the
cell, and overlapping terminals. Please be warned that each of these
situations causes \mosaico\ to go through some complicated heuristics to
determine the best way to  connect the problematic terminals.

Any internal terminal must be reachable from the outside using a
straight segment in one of the layers used to implement the terminal. 
Unreachable terminals are generally detected by {\tt vulcan}.

\mosaico\ (and more precisely {\tt cds}) uses the concept of
``projection of a terminal onto a channel''. There 
are 4 channels surrounding each cell, independent of the shape of
the cell. Each terminal is projected onto one channel. Sometimes a terminal is projected
into more channels to give more degrees of freedom to the global router. 

There are a number of ways in which terminals interact among
themselves.  If two terminals overlap, they must be projected onto
two different channels. Similarly, if the straight segment necessary
to connect to an internal terminal ``A'' overlaps another terminal
``B'', then terminals ``A'' and ``B'' must also be projected onto
different channels.

If it is not possible to map interacting terminals onto different
channels, \mosaico\ will not connect one of them. A loud
warning is generated in such a case.

\section{Example output from \mosaico}
This is the untouched output from \mosaico\ running on a small test
chip. Depending on the version of \mosaico\ you are running some
details might be different.

\begin{verbatim}
MOSAICO: ********************************
MOSAICO: * MOSAICO version 0.11 7/22/88 *
MOSAICO: ********************************
MOSAICO: Running on ck:puppy (in /net/eros/eros5/mosaico/examples/ck)
MOSAICO: Technology is: scmos
MOSAICO: Technology directory is: /octtools/lib/technology/scmos
MOSAICO: >>>>>> 1 1 1 1 <<<<<
MOSAICO: Starting channel definition step (atlas) ...
Channel definition and ordering (rev 1.7 88/05/07 19:47:51)
-- Start "Atlas" on Tue Jul 26 11:52:21 1988
Initial memory size = 0.31M
Merged ios - starting pass 2 of atlas ...

Total Cpu Time = 0.27 min
Maximum memory size = 0.95M
-- End "Atlas" on Tue Jul 26 11:52:47 1988
MOSAICO: >>>>>> 2 2 2 2 <<<<<
MOSAICO: Global routing (cds -> TimberWolfMC -> cds)

CDS VERSION 1.5 : Tue Jul 26 11:33:50 PDT 1988 


CDS environment <- Global Router environment(TW)


Reading oct input ck:puppy.cd:contents: 


****************  ck  ******************
Number of channels            = 48
Number of terms               = 85
Number of connected terms     = 78
Number of nets                = 31


Printing input files for TimberWolf
Starting the global router with the following command 
---> TimberWolfMC TWck 
Global router completed 


CDS environment <- Global Router environment(TW)


Reading output files from TimberWolf
Storing informations back to OCT
Flushing data back to OCT
MOSAICO: >>>>>> 3 3 3 3 <<<<<
MOSAICO: Adjusting term/subnets attachements
MOSAICO: Cleaning up global router output
MOSAICO: >>>>>> 4 4 4 4 <<<<<
MOSAICO: Starting power and ground current calculations (PGcurrent)...
PGcurrent: found a source FT_VDD.VDD (instance terminal) for net vdd of type SUPPLY
PGcurrent: found a source VSS (instance terminal) for net vss of type GROUND
MOSAICO: Cleaning up previous router debug stuff (RTstuff directory) ...
MOSAICO: >>>>>> 5 5 5 5 <<<<<
MOSAICO: Starting routing step (cprep) ...
Router driver and channel preparation (rev 1.10 88/06/15 14:04:09)
-- Start "Cprep" on Tue Jul 26 11:54:27 1988
Initial memory size = 0.27M
There are 12 channels in cell ck puppy.cd_after_gr.
This will take a while.  Take a coffee break or something.
Channel router server is working on RTstuff/ck.ch0
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch0
Channel router server is working on RTstuff/ck.ch1
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch1
Channel router server is working on RTstuff/ck.ch2
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch2
Channel router server is working on RTstuff/ck.ch3
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch3
Channel router server is working on RTstuff/ck.ch4
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch4
Channel router server is working on RTstuff/ck.ch5
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch5
Channel router server is working on RTstuff/ck.ch6
WARN Top & bottom instances overlap
INFO Top instance will be moved 2060 to top
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch6
Channel router server is working on RTstuff/ck.ch7
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch7
Channel router server is working on RTstuff/ck.ch8
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch8
Channel router server is working on RTstuff/ck.ch9
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch9
Channel router server is working on RTstuff/ck.ch10
WARN Top & bottom instances overlap
INFO Top instance will be moved 2230 to top
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch10
Channel router server is working on RTstuff/ck.ch11
Running channel router interface (spider) using (yacr) ...
... done routing channel RTstuff/ck.ch11

Total Cpu Time = 4.52 min
Maximum memory size = 1.51M
-- End "Cprep" on Tue Jul 26 12:09:50 1988
MOSAICO: >>>>>> 6 6 6 6 <<<<<
MOSAICO: Flattening step 1 (mosaicoflat) ...
/octtools/bin/mosaicoflat: VERSION 2.01 : Tue Jul 26 11:49:15 PDT 1988
MOSAICO: >>>>>> 7 7 7 7 <<<<<
MOSAICO: Vias minimization (viamin) ...
via minimizer opening ck:puppy.flat
technology ~octtools/lib/technology/scmos
78 fixed met1 terminals
TOTAL 49 essential vias
85 vias needed
time 48.92
MOSAICO: >>>>>> 8 8 8 8 <<<<<
MOSAICO: Flattening step 2 (mosaicoflat) ...
/octtools/bin/mosaicoflat: VERSION 2.01 : Tue Jul 26 11:49:15 PDT 1988
MOSAICO: >>>>>> 9 9 9 9 <<<<<
MOSAICO: Double checking connectivity (mosaicoRC) ...
MOSAICO: >>>>>> 10 10 10 10 <<<<<
MOSAICO: Adding constraints for the compactor
/octtools/bin/padplace: Warning: No side assigned to pad VSS: cannot add sparcs constraints
padplace: VERSION 3.0 : Tue Jul 26 11:08:55 PDT 1988 
Placement of pads for ck:puppy.flat
MOSAICO: >>>>>> 11 11 11 11 <<<<<
MOSAICO: Starting global compacter (sparcs) ...
MOSAICO: >>>>>> 12 12 12 12 <<<<<
MOSAICO: Statistics on the final result
Tue Jul 26 12:17:30 PDT 1988
/octtools/bin/mosaicoStats: Version 1.0 : Chip  ck:puppy.spaced

	Number of instances    = 16
	Number of nets         = 31
	Number of connectors   = 167
	Number of vias         = 85

	Average instance area  =       69625.00
	St.dev. instance area  =       98471.98
	Chip Area W x H        =   1467 x  1459
	Chip Area              =     2140353.00 (100.00%)
	Total Instance Area    =     1114000.00 ( 52.05%)
	Routing + Empty Area   =     1026353.00 ( 47.95%)
	Total   net area       =       87620.00
	Total   net length     =       25502.00
	Average net length     =         822.65
	St.dev. net length     =         564.66

***** 6 LONGEST NETS
(---) NAME                  LENGTH (lambda)  AREA (lambda^2)
(  1) vdd                           2750.00             15473.00
(  2) vss                           2483.00             11340.00
(  3) net2                          1578.00              4734.00
(  4) net13                         1426.00              4278.00
(  5) net12                         1342.00              4026.00
(  6) net6                          1134.00              3402.00
MOSAICO: >>>>>> 13 13 13 13 <<<<<
MOSAICO: Vulcan on the output view ck:puppy.spaced
\end{verbatim}
