\documentstyle{rapport} 
\begin{document} 

\begin{center}
\Huge\bf TUTORIAL : AMD 2901
\end{center}

Welcome to the {\bf ALLIANCE 2.0} CAD system.\\
The goal of this tutorial is to present a typical design-flow of a
simple 4 bits processor (AMD2901), using the {\bf ALLIANCE} tools.

The tools used here are :

\begin{itemize}
\item {\bf asimut} :	{\bf VHDL} compiler and simulator.
\item {\bf genlib} :	Net-List capture.
\item {\bf scr} :	Standard Cell placer and router.
\item {\bf ring} :	Core to pads router.
\item {\bf lynx} :	Symbolic layout extractor.
\item {\bf lvx} :	Net-List comparator.
\item {\bf druc} :	Design rule checker.
\item {\bf graal} :	Graphic layout editor.
\item {\bf desb} :	Functional abstractor.
\item {\bf proof} :	Formal proof between two behavioral descriptions.
\item {\bf s2r} :	Symbolic to real layout converter.
\end{itemize}
At any time you can get information on any {\bf ALLIANCE} tool using 
the command :\\
\\
\fbox{
{\bf $>$ man $<$tool name$>$} 
}\\
\\
All the available documentation is described in the {\bf README} file.
This tutorial doesn't contain a description of the {\bf AMD2901}, but
the methodology used in {\bf ALLIANCE} to produce it.
Nevertheless, you will find in the file {\bf AMD2901\_doc.ps.tar},
 the original data-sheet of the circuit.
To uncompress the sheets, use the {\bf UNIX} command :\\
\\
\fbox{
\shortstack[l]{
{\bf $>$tar xvf  AMD2901\_doc.ps.tar} \\
{\bf $>$uncompress AMD2901*.Z} 
}}\\
A GIF format of the data-sheet is also available in the file  {\bf AMD2901\_doc.gif.tar}.
\\
The design-flow used in this tutorial is composed of five steps :
\begin{itemize}
\item {\bf Step 1} : Behavioural description ({\bf VHDL} model) and simulation.
\item {\bf Step 2} : Generation and validation of the structural description 
(gate net-list).
\item {\bf Step 3} : Physical design layout (Place and route).
\item {\bf Step 4} : Extraction and verification.
\item {\bf Step 5} : Chip finishing.
\end{itemize}

In order to build the chip in about two hours, all the source files
are provided with this tutorial : 
\begin{itemize}
\item {\bf amd.vbe} : {\bf VHDL} behavioural model.
\item {\bf pattern.pat} : Simulation Patterns.
\item {\bf chip.c} : Chip structural description.
\item {\bf chip.rin} : Pads placement (for {\bf ring}).
\item {\bf chip.inf} : Registers renaming (for {\bf desb}).
\end{itemize}

You will use the {\bf ALLIANCE} tools to validate these input files
and to build the physical layout. 
The output is a {\bf CIF} layout file ready for the foundry.

To build the chip you can :
\begin{itemize}
\item - run the {\bf UNIX} commands in the order indicated by this tutorial.
\item - build automatically the entire {\bf AMD2901 CHIP} using the command : \\
\\
\fbox{
{\bf $>$ make} 
}\\
\\
If you want to start again this example from the begining,
you just have to type :\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ make clean} \ \\
{\bf $>$ make} 
}}
\end{itemize}

All {\bf ALLIANCE} tools use a set of {\bf UNIX} environment variables.
These variables are set by the {\bf UNIX} command ``export''.\\
Some environment variables indicate a list of absolute pathnames of files
or libraries. The given pathnames correspond to our local system file 
organisation
at {\bf MASI}, and you must change them in order to respect yours.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ MBK\_WORK\_LIB=.} \\
{\bf $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12} \\
{\bf $>$ export MBK\_WORK\_LIB MBK\_CATA\_LIB}
}}

\begin{itemize}
\item{\bf MBK\_CATA\_LIB :} This variable defines all paths to the directories
containing the {\bf ALLIANCE} predefined cell libraries.
\item{\bf MBK\_WORK\_LIB :} This variable defines the working directory : 
all user files will be written in this directory.
\end{itemize}
In this tutorial, the commands which are inside [ ] are preset. 
If you stay in  the same shell during the making of the {\bf AMD2901},
 you don't have to set again these environment variables.

\section{Behavioural specification}

\subsection{Behavioural model}

The circuit behaviour is described in the amd.vbe file using the 
{\bf ALLIANCE VHDL} subset (see {\it man vhdl} and {\it man vbe}).
You must run the {\bf VHDL} compiler to validate the {\bf VHDL}
file syntax.\\
\\
\fbox{
\shortstack[l]{
{\bf [$>$ MBK\_WORK\_LIB=.]}\\
{\bf [$>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12]}\\
{\bf [$>$ export MBK\_CATA\_LIB MBK\_WORK\_LIB]}\\
{\bf $>$ asimut -b -c amd}
}
}
\begin{itemize}
\item {\bf amd} is the filename of the behavioural description ({\bf amd.vbe}).
\item {\bf -b} means that the file is a pure behavioural description.
\item {\bf -c} stands for compilation only (compilability is checked, 
no simulation is performed).
\end{itemize}

\subsection{Simulation patterns}
As you have specified a formal specification,
you have to define a set of simulation patterns.
The same patterns will be used to validate each design step
from specification to physical layout.
\\
The file {\bf pattern.pat} is given as an example.

\subsection{Simulation}
You have now a logical description of your circuit, and a list of patterns.
You can run the zero-delay VHDL simulator {\bf asimut}.
You have to set up some new environment variables specific to {\bf asimut}.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ VH\_MAXERR=10} \ \\
{\bf $>$ export VH\_MAXERR}
}}\\
\\
{\bf VH\_MAXERR} : The maximum number of errors accepted before 
{\bf asimut} stops simulation.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ VH\_PATSFX=pat} \ \\
{\bf $>$ export VH\_PATSFX}
}}\\
\\
{\bf VH\_PATSFX} The extension of simulation patterns file.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ VH\_MAXERR=10 ]}\\
{\bf [ $>$ VH\_PATSFX=pat ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB VH\_MAXERR MBK\_WORK\_LIB]}\\
{\bf $>$ asimut -b amd pattern result\_beh}
}}
\begin{itemize}
\item {\bf amd} : is the filename of the description ({\bf amd.vbe}).
\item {\bf pattern} : is the filename for the input patterns ({\bf pattern.pat}).
\item {\bf result\_beh} : is the filename for the resulting patterns ({\bf result\_beh.pat}).
\item {\bf -b} : means that the {\bf amd} file is a pure behavioural description.
\end{itemize}

The input pattern file can provide the expected outputs.
Any difference between predicted outputs in {\bf pattern.pat} and simulation 
results will be reported as commentary
on the screen and in {\bf result\_beh.pat}. This output file may be used again
for an another simulation, since it has the same format as the input file.

\section{Structural Description}

\subsection{Structural Design}

The aim of this step is to build the gate level schematic 
corresponding to the behavioural specification.

We must instantiate and connect logical gates and pads,
supplied in the standard cell library {\bf scr} and the pad 
library {\bf ring}. 
To do this, {\bf ALLIANCE} doesn't use a schematic editor
but the procedural language {\bf genlib}
which is a set of C functions (see {\it man genlib}).

The structural description of the {\bf AMD2901} follows a hierarchical
approach.

\begin{itemize}
\item First, each functionnal block is described as a separate gate net-list.
There are five blocks : {\bf accu, alu, ram, muxe, muxout}.
\item The next hierarchical level is the {\bf heart} 
that interconnects these five blocks among each others.
\item The final hierarchical level is the {\bf chip}
that connects the {\bf heart} to the {\bf pads}.
\end {itemize}

The {\bf chip.c} file uses the {\bf genlib} language to describe
these 7 hierarchical blocs.

The {\bf ALLIANCE} system accepts several external file formats for net-list
(EDIF, VHDL, SPICE, ALLIANCE, COMPASS).
Environment variables allow to set the formats.
The {\bf .vst} extension corresponds to the structural {\bf VHDL}.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ MBK\_IN\_LO=vst}\\
{\bf $>$ MBK\_OUT\_LO=vst} \\
{\bf $>$ export MBK\_OUT\_LO MBK\_IN\_LO} 
}}

All net-list files created and used by {\bf genlib} will now
be structural {\bf VHDL}.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_LO=vst ]}\\
{\bf [ $>$ MBK\_OUT\_LO=vst ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_LO MBK\_OUT\_LO MBK\_WORK\_LIB]}\\
{\bf $>$ genlib chip}
}}

The 7 files {\bf alu.vst accu.vst ram.vst muxe.vst muxout.vst 
heart.vst chip.vst} have been created.

\subsection{Structural Model Simulation}

The various net-list files we have created represent the structural 
description that should be validated by simulation, using the same patterns as in step 1.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_LO=vst ]}\\
{\bf [ $>$ VH\_PATSFX=pat ]}\\
{\bf [ $>$ VH\_MAXERR=10 ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_LO VH\_PATSFX VH\_MAXERR MBK\_WORK\_LIB]}\\
{\bf $>$ asimut chip pattern result\_str}
}}
\begin{itemize}
\item {\bf chip} is the structural input file ({\bf chip.vst}).
\item {\bf pattern} : is the filename for the input patterns ({\bf pattern.pat}).
\item {\bf result\_str} : is filename for the resulting patterns
({\bf result\_str.pat}).
\end{itemize}

Note the {\bf -b} option does not appear any more, since we now have a 
structural model.

Any new error appearing will be reported in the {\bf result\_str.pat} file.
You can try to introduce a schematic error by modifying the {\bf chip.c} file,
running {\bf genlib} and {\bf asimut} to see the errors.
\section{Physical Design}

Building the heart, and routing the heart to the pads are quite different jobs.
So we use different tools.

\subsection{Routing the heart}

{\bf Scr} is a standard cell placing and routing tool.

Here again {\bf ALLIANCE} accepts several external file formats
for the symbolic layout (COMPASS, ALLIANCE, MODGEN).
Environment variables allow to set the formats.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ MBK\_IN\_PH=ap}\\
{\bf $>$ MBK\_OUT\_PH=ap}\\
{\bf $>$ export MBK\_OUT\_PH MBK\_IN\_PH}
}}\\
\\
The hierarchical net-list will be flattenned before routing.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_OUT\_PH=ap ]}\\
{\bf [ $>$ MBK\_IN\_LO=vst ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_PH  MBK\_OUT\_PH MBK\_IN\_LO MBK\_WORK\_LIB]}\\
{\bf $>$ scr -p -r -i 1000 heart} 
}}
\begin{itemize}
\item {\bf heart}     is the input net-list (heart.vst). The output layout will be heart.ap.
\item {\bf -p}        Automatic placement.
\item {\bf -r}        routing required.
\item {\bf -i 1000}   Number of iterations (increasing this number will improve
the placement).
\end{itemize}
The symbolic layout file {\bf heart.ap} has been created.

\subsection{Heart verification}

\begin{itemize}
\item {DRC} : Druc checks the symbolic layout rules
(see {\it man druc})\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_PH MBK\_WORK\_LIB]}\\
{\bf $>$ druc heart} 
}}\\
\\
If necessary, {\bf druc} generates an error file ({\bf core.err}).

\item {Net-list extraction}.

{\bf Lynx} is a hierarchical extractor that provides a gate net-list.\\
In order to avoid name collision, we use another file format
for extracted net-list ({\bf .al} format). This new format is used
to support additional data : extracted parasitic capacitances.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ MBK\_OUT\_LO=al}\\
{\bf $>$ export MBK\_OUT\_LO}
}}\\
\
Then we run the {\bf lynx extractor} :\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_OUT\_LO=al ]}\\
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_OUT\_LO MBK\_IN\_PH MBK\_WORK\_LIB]}\\
{\bf $>$ lynx heart}
}}\\
\\
The extracted net-list file {\bf heart.al} is created at this level.
\item {Net-compare}.

The next tool is the net-compare {\bf lvx} that performs a netlist comparison 
between the input net-list {\bf heart.vst} and the extracted net-list
{\bf heart.al}, after flattening to the gate level.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_WORK\_LIB]}\\
{\bf $>$ lvx vst al heart heart -f}
}}

\end{itemize}

\subsection{Routing the chip}

The pad placement depends on external constraints.
The file {\bf chip.rin} defines the pads placement constraints
(see {\it man ring}).\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_LO=vst ]}\\
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_OUT\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_LO MBK\_IN\_PH MBK\_OUT\_PH MBK\_WORK\_LIB]}\\
{\bf $>$ ring chip chip}
}}
\begin{itemize}
\item {\bf chip} The input files chip.vst and chip.rin (the same name
{\bf chip} must be used for the two files).
\item {\bf chip} The output physical file chip.ap.
\end{itemize}

The symbolic layout file {\bf chip.ap} has been created.
At this point, you can display the chip with the layout editor {\bf graal}.\\
You can see the chip and the instantiated heart, using the {\bf graal} commands to
go through the hierarchy levels.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_WORK\_LIB]}\\
{\bf $>$ graal}
}}

\section{Physical Validation}

The {\bf ALLIANCE} verification tools allow both flat and hierarchical
verification. We will use a hierarchical approach.

\subsection{Chip verification}

The same procedure used for the heart applies for the entire chip.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_WORK\_LIB  MBK\_IN\_PH ]}\\
{\bf $>$ druc chip}
}}\\
\\
Eventually, {\bf druc} generates an error file ({\bf chip.err}).\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_OUT\_LO=al ]}\\
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_OUT\_LO MBK\_IN\_PH]}\\
{\bf $>$ lynx chip}
}}\\
\\
The extracted net-list file {\bf chip.al} is created by this step
(This net-list instantiates the heart).\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_WORK\_LIB]}\\
{\bf $>$ lvx vst al chip chip}
}}\\
\\
Both net-lists {\bf chip.vst} and {\bf chip.al} are flattened to the gate level
by {\bf lvx} before comparison (see {\it man catal}).

\subsection{Chip simulation}

Finally you can check globally the extracted net-list
by applying the original patterns to the extracted net-list.
Thanks to the multiformat approach the simulator {\bf asimut}
accepts {\bf .al} format as structural input description.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ MBK\_IN\_LO=al}\\
{\bf $>$ export MBK\_IN\_LO}
}}\\
\\
Then you have to run {\bf asimut}.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_LO=al]}\\
{\bf [ $>$ VH\_PATSFX=pat ]}\\
{\bf [ $>$ VH\_MAXERR=10 ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_LO VH\_PATSFX  VH\_MAXERR MBK\_WORK\_LIB]}\\
{\bf $>$ asimut chip pattern res\_pattern}
}}\\
\\
To complete the validation of our chip, the functional abstraction followed
by the proof must be done.

\subsection{Functionnal abstraction and formal proof}

The functional abstraction of the transitor net-list is realized by the tool
{\bf desb} (see {\it man desb}). {\bf desb} flattens the chip ({\bf chip.al})
to obtain a transistor level description, and abstract then a behavioral description ({\bf chip.vbe}).
To keep the coherence of register names between the behavioral description
given by {\bf desb} ({\bf chip.vbe}) and the initial behavioral description
({\bf amd.vbe}), a file describing the name's transformation is required.
This file is {\bf chip.inf}.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_LO=al ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ export MBK\_CATA\_LIB MBK\_IN\_LO MBK\_WORK\_LIB]}\\
{\bf $>$ desb chip -i -v}
}}
\begin{itemize}
\item {\bf chip}	is the input layout ({\bf chip.al}).
\item {\bf -i}		read the {\bf chip.inf} file.   
\item {\bf -v}		to vectorize the interface of behavioral description.
\end{itemize}

The VHDL DATA FLOW description as been generated : {\bf chip.vbe}\\

Now you have the abstracted behavioral description ({\bf chip.vbe})
and the initial behavioral description ({\bf amd.vbe}).
With {\bf proof} (see {\it man proof}), you can check the formal equivalence
between the two descriptions.\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ export MBK\_WORK\_LIB]}\\
{\bf $>$ proof -d amd chip}
}}
\begin{itemize}
\item {\bf chip}	is the abstracted file ({\bf chip.vbe}).
\item {\bf amd}		is the initial behavioral description ({\bf amd.vbe}).
\item {\bf -d}		displays errors.
\end{itemize}

If you want to see an error you can change one line in the file {\bf amd.vbe}.
For example, change the line 301 :\\
 scout $<=$ NOT accu(3) AND test\_mode ;\\
and try {\bf proof} again.

\section{Chip finishing}

Until now we used symbolic layout (all coordinates in {\bf lambda}-units).
We should now convert them to real dimensions, creating the physical layout
(two output formats are supported : CIF and GDSII).
This last step is done by {\bf s2r}.
{\bf s2r} performs symbolic to real expansion, gap filling, denotching
and instantiates preexisting physical cells 
(this is necessary for the pads).

You must define 3 new environment variables :\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ RDS\_TECHNO\_NAME=/labo/etc/prol12.rds} \\
{\bf $>$ export RDS\_TECHNO\_NAME}
}}\\
\\
The {\bf prol12.rds} is the technology file that contains the parameters
corresponding to the target process.
(In this case the target process is 1.2 micron.)\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ RDS\_OUT cif}  \\
{\bf $>$ export RDS\_OUT cif}
}}\\
\\
Defines the output format.\\
\\
\fbox{
\shortstack[l]{
{\bf $>$ RDS\_IN cif}\\
{\bf $>$ export RDS\_IN}
}}\\
\\
Defines the input format for the preexisting layout cells (pads).

You will enter :\\
\\
\fbox{
\shortstack[l]{
{\bf [ $>$ MBK\_IN\_PH=ap ]}\\
{\bf [ $>$ MBK\_WORK\_LIB=. ]}\\
{\bf [ $>$ MBK\_CATA\_LIB=.:/labo/cells/scr:/labo/cells/ring/pad12 ]}\\
{\bf [ $>$ RDS\_TECHNO\_NAME=/labo/etc/prol12.rds ]}\\
{\bf [ $>$ RDS\_IN=cif ]}\\
{\bf [ $>$ RDS\_OUT=cif]}\\
{\bf [ $>$ export RDS\_OUT  MBK\_IN\_PH MBK\_WORK\_LIB MBK\_CATA\_LIB RDS\_TECHNO\_NAME RDS\_IN]}\\
{\bf $>$ s2r -c  chip amd2901}
}}
\begin{itemize}
\item {\bf -c} deletes connectors at the highest level of hierarchy.
\end{itemize}

You did it...\\
The file produced is {\bf amd2901.cif}.
It is ready for the foundry.

\end{document}


