\documentstyle[palatino]{article} 
\special{papersize=210mm,297mm}     % A4 paper is what my printer likes
\textheight 9.0in
\textwidth  7.0in
\topmargin  -0.0in
\oddsidemargin  +0in
\evensidemargin -0in
\marginparwidth +0in
\parskip 8pt plus 2pt minus 2pt     % space beetween paragraphe
\parindent 2em                      % indentation of the first line
\topsep 0pt                         % space beetween list and text
\parsep 6pt                         % space beetween 2 par. in item
\partopsep 0pt                      % space beetween 2 par. in item
\itemsep 0pt                        % space beetween 2 items
\def\Sup{\verb+>+}
\def\Inf{\verb+<+}
\newlength{\mylength}
\def\S#1{\protect\makebox[\mylength][l]{\noindent#1}}
\begin{document} 


\begin{center}
{\Large \bf DLX TUTORIAL}\\
February 15,1994 \\
This tutorial requires about 6 hours in batch mode on a Sparc Station
\end{center}

\section{Introduction}

Welcome to the {\bf ALLIANCE CAD} system.
This file contains a complete tutorial based on the design of the 32 bit microprocessor DLX.
This tutorial does not focus on the processor architecture. The
goal is to present the available CAD tools in the ALLIANCE 2.0 release (especially
logic synthesis and the data path compiler).
Beginners who are not familiar with ALLIANCE should start using the
ADDACCU tutorial or the AMD tutorial.
Each {\bf ALLIANCE} tool can operate as a standalone program but in this
tutorial the tools are used according to a precise design flow.
The starting point is a behavioural VHDL model. The output is a CIF file.

The tools used in the design are:
\begin {itemize}
\item {\bf asimut} : {\bf VHDL} compiler and simulator.
\item {\bf dlx\_asm} : DLX assembler.
\item {\bf genpat} : Procedural language for simulation pattern generation.
\item {\bf syf} : Finite State Machine compiler.
\item {\bf logic} : Logic synthesizer
\item {\bf netoptim} : Net list optimizer
\item {\bf scr} : Standard Cell placer and router.
\item {\bf fpgen} : Data path net list capture.
\item {\bf dpr} : Data path placer and router.
\item {\bf genlib} : Net list capture.
\item {\bf bbr} : Block to block router.
\item {\bf ring} : Core to pads router.
\item {\bf lynx} : Layout to net list extractor.
\item {\bf lvx} : Net list comparator.
\item {\bf s2r} : Symbolic to real layout converter.
\end{itemize}

You can get on-line information on any {\bf ALLIANCE} tool using the command :

\fbox {
\shortstack[l] {
\bf man $<$tool name$>$
}
}

DLXm is a 32 bit microprocessor with a micro-programmed internal architecture. The description of the DLX is given by J.L.Hennessy and D.A.Patterson in ``Computer Architecture, A quantitative Approach'', Morgan Kaufman Publishers, Inc. 1990.                                                            

In order to simplify the task of validating the chip, an entire CPU board has been described in {\bf VHDL}. 

Thus the simulations are done using small
assembler programs which are stored in the CPU board's external memory.
This tutorial shows you how to create the DLXm into four steps, 
which must be followed in order to produce a valid chip.

\begin {itemize}
\item {\bf Step 1} : Behavioural Specification and Validation 
\item {\bf Step 2} : Gate Level net list generation and validation 
\item {\bf Step 3} : Physical place and route with extraction and validation 
\item {\bf Step 4} : Translation from symbolic layout to the target process
\end{itemize}

In order to build the chip, all source files are included with this tutorial (see Appendix).


You will use the {\bf ALLIANCE} tools to validate these sources and to generate 
first the gate level net list, then 
the physical layout of the DLXm. The final output is a {\bf CIF} format physical layout file. This can be sent directly to a manufacturer for fabrication.

All you have to do to build the chip is type the commands given in this tutorial. If you are feeling too lazy to type these commands by hand, you can build the entire chip automatically using the command :

\fbox {
\shortstack[l] {
\bf $>$ make
}
}

If you want to start again from scratch, you can type the command :

\fbox {
\shortstack[l] {
\bf $>$ make clean
}
}

which will remove all the generated files.

The fully automatic chip generation requires about 6 hours on a SPARC station.
If you have less time, you can also run separately the four main steps listed above, thanks to special entries in the makefile.
These entries are referenced all along this tutorial.


The {\bf ALLIANCE} tools use {\bf UNIX} environment variables. They are accessed by the {\bf UNIX} command {\em setenv}. For example:

\fbox {
\shortstack[l] {
\bf $>$ setenv MBK\_IN\_LO vst\\
\bf $>$ setenv MBK\_OUT\_LO vst\\
\bf $>$ setenv MBK\_IN\_PH ap\\
\bf $>$ setenv MBK\_OUT\_PH ap\\
\bf $>$ setenv MBK\_WORK\_LIB .\\
\bf $>$ setenv MBK\_CATAL\_NAME CATAL\\
\bf $>$ setenv MBK\_CATA\_LIB .:\\
\hspace*{0.2in}\bf \$(TOP)/cells/scr:\\
\hspace*{0.2in}\bf \$(TOP)/cells/bsg:
\$(TOP)/cells/rfg:
\$(TOP)/cells/rsa:\\
\hspace*{0.2 in}\bf  \$(TOP)/cells/fitpath/fplib:\\
\hspace*{0.2in}\bf \$(TOP)/cells/fitpath/dplib:\\
\hspace*{0.2 in}\bf \$(TOP)/cells/ring/pad12
}
}


\begin{itemize}
\item {\bf MBK\_IN\_LO}      : Logical input file format (and filename extension).
\item {\bf MBK\_OUT\_LO}     : Logical output file format (and filename extension).
\item {\bf MBK\_IN\_PH}      : Physical input file format (and filename extension).
\item {\bf MBK\_OUT\_PH}     : Physical output file format (and filename extension).
\item {\bf MBK\_CATAL\_NAME} : Name of the catalogue file.
\item {\bf MBK\_CATA\_LIB}   : Paths to the directories that are to be searched for read-only cell libraries.
\item {\bf MBK\_WORK\_LIB}   : Directory where are saved the output files.
\end{itemize}

You can get on-line information on {\bf ALLIANCE } environment variables using the command :

\fbox {
\shortstack[l] {
\bf man $<$ envir $>$
}
}

Some of the path names may have to be modified, in order to correspond to your particular installation of {\bf ALLIANCE}. In this tutorial we will assume that the directory structure of the source files has not been altered.

In this tutorial, the commands which are inside [ ] are preset. If you make the DLXm from the beginning to the end, you do not have to set again these environment variables.
All operations should be executed in the root directory.




\section{Simulation method for design validation}

    \subsection{Behavioural model}

The specification of the chip which you are going to build is given in the file {\bf dlxm.vbe} in the form of a {\bf VHDL} behavioural description. This allows simulations to be performed immediately.

In order to simplify the task of validating the chip, an entire CPU board has been described in {\bf VHDL}. The CPU board interconnections are described in the file {\bf dlxm\_cpu.vst} using VHDL structural syntax. Each component is described in a separate file using VHDL behavioural syntax :

\begin {itemize}
\item {\bf dlxm\_dec.vbe} : Address decoder.
\item {\bf sr64\_1a.vbe} : RAM.
\item {\bf timer.vbe} : timer for external interrupts.
\item {\bf roms.vbe} : Supervisor ROM.
\item {\bf romu.vbe} : User ROM.
\end{itemize}

	\subsection{Validation Technique}

In order to test the chip, a large number of short assembly language programs have been written. The programs were each designed to test one particular aspect of the chip (e.g. an instruction, or a register). Each works on the same principle: a test is performed, if test is OK, the program branches to a fixed address (defined as {\bf good}), if not, the program branches to another fixed address.

The programs are assembled using the command {\bf dlx\_asm}, which assembles the DLX mnemonics but, instead of generating object code as output, it generates the {\bf VHDL} behavioural description of a 256 byte ROM. It is therefore used to produce the {\bf romu.vbe} and {\bf roms.vbe} files for the board.



    	\subsection{Simulation}


The VHDL simulator {\bf asimut} can mix structural and behavioural descriptions :
a special file,
defined by the environment variable {\bf MBK\_CATAL\_NAME} (see {\em man catal}), tells the simulator which behavioural models are to be taken as leaf cells. 

Simulation is used to check the initial behavioural description of the DLXm processor and the output results for each phase . 
 However as simulation is time greedy, simulation is done in the tutorial with a single assembly program, to show the design flow and the tools as quickly as possible.
Yet the reader must feel free to use all the provided programs for simulation.


\section{Interactive Design}

	\subsection{Behavioural Specification}

Before starting the chip design, remember that all operations should be executed in the root directory.


The circuit behaviour is described in the *.vbe files using the {\bf ALLIANCE} VHDL subset (see {\it man vhdl} and {\it man vbe}). 

The assembly language program and001.u is used. To assemble it, do :

\fbox {
\shortstack[l] {
\bf $>$ setenv MBK\_WORK\_LIB .\\
\bf $>$ dlx\_asm and001.u romu\\
\bf $>$ dlx\_asm def001.s roms
}
}

\begin{itemize}
\item
{\bf and001.u} is the chosen example of assembly source file.
\item
{\bf romu} is the target file ({\bf romu.vbe}).
\item 
This test does not have a supervisor ROM program, however a {\bf roms.vbe} must neverthless be provided. To do this a special assembly source file is provided {\bf def001.s} that you must also assemble.
\end{itemize}

You can now perform the simulation :

\fbox {
\shortstack[l] {
\bf $>$ setenv VH\_BEHSFX vbe\\ 
\bf $>$ setenv MBK\_MAXERR 10 \\ 
\bf $>$ setenv VH\_PATSFX pat \\ 
\bf $>$ setenv MBK\_IN\_LO vst \\ 
\bf $>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_CHIP \\ 
\bf [$>$ setenv MBK\_WORK\_LIB .]\\ 
\bf $>$ setenv MBK\_CATA\_LIB .:\\ 
\hspace*{0.2in}\bf \$(TOP)/cells/scr:\\ 
\hspace*{0.2in}\bf \$(TOP)/cells/bsg: \$(TOP)/cells/rfg: \$(TOP)/cells/rsa:\\ 
\hspace*{0.2 in}\bf  \$(TOP)/cells/fitpath/fplib:\\ 
\hspace*{0.2in}\bf \$(TOP)/cells/fitpath/dplib:\\ 
\hspace*{0.2 in}\bf \$(TOP)/cells/ring/pad12\\ 
\bf $>$ asimut dlxm\_cpu dlxm\_cpu\_chip and001\_chip
} 
} 

\begin{itemize} 
\item 
{\bf dlxm\_cpu} : structural description of the board  ({\bf dlxm\_cpu.vst}) 
\item
{\bf dlxm\_cpu\_chip} : pattern input filename ({\bf dlxm\_cpu\_chip.pat}) 
\item
{\bf and001\_chip} : result filename ({\bf and001\_chip.pat}) 
\end{itemize}

The pattern file {\bf dlxm\_cpu\_chip.pat} takes care of initializing all the registers necessary for the simulation : 
the Program Counter must be set to 7FFFFFF0 and the Microinstruction register set to the IFETCH state 

The result of the simulation is placed in the {\bf pat} file called {\bf and001\_chip.pat} . You should now take a look at this file using your favorite viewer/editor. The penultimate column represents the value on the address bus for each pattern. Move to the end of the file, if you can see the value {\bf $ 7ffffff0 $} then the test has been performed correctly, as this is the address defined as {\bf good} in test programs.

The reader who is willing to do more simulation test should follow the same procedure :

\begin{itemize}
\item
select a new assembly program (user and possibly supervisor) in the {\bf stock\_asm} directory and copy it into the root directory    
\item
create a new romu.vbe and a possibly new roms.vbe by assembling a source file.

Note that if the test also has a corresponding supervisor ROM ({\bf .s}) program, you must also assemble it. For example :

\fbox {
\shortstack[l] {
\bf $>$ dlx\_asm movi2sr000.s roms
}
}

\item
run asimut
\item
check the simulation result : address good
\end{itemize}


All the output files resulting from operations of the paragraph 3.1 can be created automatically using the target {\bf functional} of the Makefile by typing :

\fbox {
\shortstack[l] {
\bf $>$ Make functional 
}
}


	\subsection{Structural Design}

    		\subsubsection{Design Hierarchy}


In this step, the structural descriptions of the chip ({\bf dlxm.vst}), and the core ({\bf core.vst}) are used.
The chip is described as a core surrounded by pads.
 The core is divided into three structural blocks: sequencer, status, and data path, each of which must be represented by its own behavioural description. The following source files are provided :

\begin {itemize}
\item
{\bf dlxm.vst} : VHDL structural model of the dlxm instantiating core and pads.
\item
{\bf core.3blocks.vst} : VHDL structural model of the core instantiating the data path, the sequencer and the status.
\item {\bf dlxm\_seq.fsm} : Sequencer.
\item {\bf dlxm\_sts.vbe} : Status.
\item {\bf dlxm\_dpt.vbe} : Data path.
\end{itemize}

    		\subsubsection{Sequencer state assignment}

The sequencer is written using a subset of {\bf VHDL} specifically designed for the description of finite state machines. You must therefore compile this into a VHDL data-flow behavioural model ({\bf vbe}) using the {\bf ALLIANCE} tool {\bf syf} :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf $>$ syf -s dlxm\_seq -of dlxm\_seq -scan -save
}
}

\begin {itemize}
\item {\bf -s} : uses a vertical encoding algorithm
\item
{\bf dlxm\_seq} : fsm source file ({\bf dlxm\_seq.fsm)}
\item  
{\bf -of dlxm\_seq} : output behavioural description ({\bf dlxm\_seq.vbe})
\item {\bf -scan} : adds a scan-path to the state register.
\item
{\bf -save} : saves encoding result in {\bf dlxm\_seq.cod} file
\end{itemize}

		\subsubsection{Validation of the DLXm block view}

You can then simulate the resulting model after having copied the structural description of the core in three blocks into the {\bf core.vst } file :


\fbox {
\shortstack[l] {
\bf $>$ cp core.3blocks.vst core.vst \\
\bf $>$ chmod 644 core.vst
}
}

\fbox {
\shortstack[l] {
\bf [$>$ setenv VH\_BEHSFX vbe]\\
\bf [$>$ setenv MBK\_MAXERR 10]\\
\bf [$>$ setenv VH\_PATSFX pat]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf $>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_BLOCKS\\
\bf $>$ asimut dlxm\_cpu dlxm\_cpu\_blocks and001\_blocks
}
}

\begin{itemize}
\item
{\bf core.vst} : VHDL structural model of the core instantiating the data path, the sequencer and the status.
\item
{\bf dlxm\_cpu} : structural description of the board ({\bf dlxm\_cpu.vst})
\item
{\bf dlxm\_cpu\_blocks} : pattern input filename ({\bf dlxm\_cpu\_blocks.pat}) 
\item
{\bf and001\_blocks} : result filename ({\bf and001\_blocks.pat}) 
\end{itemize}

The {\bf CATAL\_CPU\_BLOCKS} file tells {\bf asimut} to use the behavioural models for the three blocks data path, sequencer and status.

The pattern file {\bf dlxm\_cpu\_blocks.pat} takes care of initializing all the registers necessary for the simulation, the same way as before.


You should then verify that the program ended up at address {\bf good} in the same way as before.


    		\subsubsection{Data path compilation}

The first stage in the synthesis of the structural description of the chip is the generation of the data path. The structural description of the data path is given in the source file {\bf dlxm\_dpt.c}.
This textual description is equivalent to a schematic capture of the data path.
This description uses a set of predefined macros (see {\em man fpgen}).
 You must compile this using the {\bf ALLIANCE} data path generator {\bf fpgen} :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf $>$ setenv MBK\_OUT\_LO vst\\
\bf $>$ setenv MBK\_IN\_PH ap\\
\bf $>$ setenv MBK\_OUT\_PH ap\\
\bf $>$ fpgen dlxm\_dpt
}
}

\begin{itemize}
\item
{\bf dlxm\_dpt} : input filename ({\bf dlxm\_dpt.c})
and
 output structural view of the data-path ({\bf dlxm\_dpt.vst})
\end{itemize}

This generates a hierarchical {\bf VHDL} gate-level net list of the data path, {\bf dlxm\_dpt.vst}.


    		\subsubsection{Sequencer synthesis}

A standard cell net list of the sequencer is synthesized by the logic synthesis tool {\bf logic}
from the behavioural description contained in {\bf dlxm\_seq.vbe} :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf $>$ setenv MBK\_TARGET\_LIB \$(TOP)/cells/scr\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_OUT\_LO vst]\\
\bf $>$ logic -o dlxm\_seq dlxm\_seqo\\
\bf $>$ logic -s dlxm\_seqo dlxm\_seq
}
}

\begin{itemize}
\item
{\bf -o } : activates the behavioural optimizer and creates {\bf dlxm\_seqo.vbe}
\item
{\bf -s } : activates the standard cells mapper and creates {\bf dlxm\_seq.vst}
\item
{\bf dlxm\_seq} : input behavioural description for logic behavioural optimiser ({\bf dlxm\_seq.vbe})
\item
{\bf dlxm\_seqo} : behavioural optimized description ({\bf dlxm\_seqo.vbe})
\item
{\bf dlxm\_seq} : output gate net list description by logic ({\bf dlxm\_seq.vst})
\end{itemize}


This generates a VHDL gate net list {\bf dlxm\_seq.vst} using the standard cell library {\bf SCLIB}.


    		\subsubsection{Status synthesis}

A standard cell net list of the status block is synthesized from the behavioural description contained in {\bf dlxm\_sts.vbe}. This is done using {\bf logic} as for the sequencer.


\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_TARGET\_LIB \$(TOP)/cells/scr]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_OUT\_LO vst]\\
\bf $>$ logic -o dlxm\_sts dlxm\_stso\\
\bf $>$ logic -s dlxm\_stso dlxm\_sts
}
}

\begin{itemize}
\item
{\bf -o } : activates the behavioural optimizer and creates {\bf dlxm\_stso.vbe}
\item
{\bf -s } : activates the standard cells mapper and creates {\bf dlxm\_sts.vst}
\item
{\bf dlxm\_sts} : input behavioural description for logic behavioural optimiser ({\bf dlxm\_sts.vbe})
\item
{\bf dlxm\_stso} : behavioural optimized description ({\bf dlxm\_stso.vbe})
\item
{\bf dlxm\_sts} : output gate net list description by logic ({\bf dlxm\_sts.vst})
\end{itemize}

This generates a VHDL gate net list {\bf dlxm\_sts.vst} using the standard cell library {\bf SCLIB}.



		
		\subsubsection{DLXm structural view validation}


We have now a complete gate-level net list of the processor.
This stage can be validated using {\bf asimut} :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [ $>$ setenv VH\_BEHSFX vbe]\\
\bf [$>$ setenv MBK\_MAXERR 10]\\
\bf [$>$ setenv VH\_PATSFX pat]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf $>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES\\
\bf $>$ asimut dlxm\_cpu dlxm\_cpu\_gates and001\_gates
}
}

\begin{itemize}
\item
{\bf dlxm\_cpu} : structural description of the board ({\bf dlxm\_cpu.vst})
\item
{\bf dlxm\_cpu\_gates} : pattern input filename ({\bf dlxm\_cpu\_gates.pat})
\item
{\bf and001\_gates} : result filename ({\bf and001\_gates.pat}) 
\end{itemize}

Two new files have been used to run asimut :

\begin{itemize}
\item
The {\bf CATAL\_CPU\_GATES} file tells {\bf asimut} to use the behavioural models for the gates and for the generated blocks.
\item
{\bf dlxm\_cpu\_blocks.pat } to initialize as before the sequencer state register and the Program Counter, whose name has changed.
\end{itemize}

If your test program ends up at address {\bf good} you can move on to the generation of the chip's physical layout.


		\subsubsection{Design for testability}

All registers, except the 32 word register file, are in the scan-path :

\begin{itemize}
\item
{\bf data path } : The structural description uses scanable registers.
\item
{\bf sequencer } : SYF has been used with the option {\bf -scan} that automatically uses scanable registers.
\item
{\bf status } : The behavioural description explicitly describes scanable registers.
\end{itemize}

Here we check the scan path with the simulator {\bf asimut}.
Writing patterns is a very tedious job, {\bf genpat} makes it much more convenient and reliable.
{\bf genpat} is a dedicated language for simulation pattern description. It is actually a library of C functions.

The following command processes the {\bf dlxm\_scan.c} file, creates appropriate patterns in the file {\bf dlxm\_scan.pat} and simulates the structural DLXm.

\fbox {
\shortstack[l] {
\bf [$>$ setenv VH\_PATSFX pat]\\
\bf $>$ genpat dlxm\_scan\\
\bf [ $>$ setenv VH\_BEHSFX vbe]\\
\bf [$>$ setenv MBK\_MAXERR 10]\\
\bf [$>$ setenv VH\_PATSFX pat]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf $>$ asimut dlxm\_cpu dlxm\_scan dlxm\_scan\_res
}
}

\begin{itemize}
\item
{\bf dlxm\_cpu } : structural description of the board ({\bf dlxm\_cpu.vst})
\item
{\bf dlxm\_scan } : pattern input filename ({\bf dlxm\_scan.pat})
\item
{\bf dlxm\_scan\_res } : result filename ({\bf dlxm\_scan\_res.pat})
\end{itemize}

The output files resulting from commands of the paragraph 3.2, can be created automatically using the target {\bf structural} of the Makefile by typing:

\fbox {
\shortstack[l] {
\bf $>$ Make structural
}
}

	\subsection{Physical Layout}



To get the symbolic layout description of the chip, you will :

\begin{itemize}
\item
merge the sequencer and status into the control block ({\bf dlxm\_ctl.vst} file)
\item
route the control block with the standard cells router {\bf scr}
\item
route the data path with  the specialized router {\bf dpr}
\item
route the data path and the control together with {\bf bbr} (biblock channel router)
\item
route the core to the pads with the {\bf ring} router
\end{itemize}

Each place and route step will be validated using the following method :

\begin{itemize}
\item
extracting a net list from the symbolic layout file using {\bf lynx}
\item
comparing input net list and extracted net list with {\bf lvx}
\end{itemize}



    		\subsubsection{Control block generation and routing}

The status and sequencer must be merged together to create a single control block. This is easily accomplished using a few {\bf genlib} functions (see {\em man genlib}) contained in the file {\bf unflat\_flat.c}~:
firstly a new model called {\bf dlxm\_ctl}, which instantiates the sequencer and the status, is created, as well as a new core model which instantiates this {\bf dlxm\_ctl} instead of the sequencer and status.
 Secondly the
{\bf dlxm\_ctl} model is flattened to gate level.

You must now call this macro by typing the commands :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB .]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_LO vst ]\\
\bf [$>$ setenv MBK\_OUT\_LO vst ]\\
\bf $>$ genlib unflat\_flat
}
}

The logic synthesizer does not take care of fanout constraints. 
In order to minimize delays
you now use the {\bf ALLIANCE} tool {\bf netoptim}. This performs fan-out optimisation and buffering of a structural description in order to minimise propagation delays of critical paths :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_OUT\_LO vst]\\
\bf $>$ setenv MBK\_VDD vdd \\
\bf $>$ setenv MBK\_VSS vss \\
\bf $>$ netoptim -f dlxm\_ctl dlxm\_ctl dlxm\_ctl
}
}

\begin{itemize}
\item
{\bf -f } : netoptim performs a local optimization
\item
{\bf dlxm\_ctl } : input structural description ({\bf dlxm\_ctl.vst})
\item
{\bf dlxm\_ctl } : output optimised structural description ({\bf dlxm\_ctl.vst})
\item
{\bf dlxm\_ctl } : source file of output capacitances ({\bf dlxm\_ctl.lax})
\end{itemize}


You must now use {\bf scr} (Standard Cell Router) to generate its physical layout. We will use the ALLIANCE format for input and output symbolic layout by setting the appropriate environment variables :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_VDD vdd]\\
\bf [$>$ setenv MBK\_VSS vss]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_OUT\_LO vst]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_PH ap]\\
\bf $>$ scr -p -r -l 5 -i 5000 dlxm\_ctl
}
}

\begin {itemize}
\item {\bf -p } : Automatic placement.
\item {\bf -r } : Perform routing.
\item {\bf -l 5 } : Number of rows.
\item {\bf -i 5000 } : Number of iterations.
\item {\bf dlxm\_ctl } : Input net list ({\bf dlxm\_ctl.vst})
and connector placement file ({\bf dlxm\_ctl.scr})
\end{itemize}

The router takes the net list specified in the file {\bf dlxm\_ctl.vst} and generates a physical layout in the file {\bf dlxm\_ctl.ap}.

In order to verify that no errors occured in the generation of the physical layout, we extract a net list from the layout using the {\bf ALLIANCE} tool {\bf lynx}, and then compare the result with the original net list using {\bf lvx}. 

To avoid confusion between original and extracted net lists we use the {\bf al} format to represent extracted net lists. For {\bf lynx} to generate its output in this format, you must set the appropriate environment variable :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf $>$ setenv MBK\_OUT\_LO al\\
\bf $>$ lynx  dlxm\_ctl dlxm\_ctl
}
}

\begin{itemize}
\item
{\bf dlxm\_ctl } : input symbolic layout file {\bf dlxm\_ctl.ap}
\item
{\bf dlxm\_ctl } : output extracted net list {\bf dlxm\_ctl.al}
\end{itemize}


Then compare :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf $>$ lvx vst al dlxm\_ctl dlxm\_ctl
}
}

\begin{itemize}
\item
{\bf vst } and {\bf dlxm\_ctl } : input net list {\bf dlxm\_ctl.vst}
\item
{\bf al } and  {\bf dlxm\_ctl } : extracted net list {\bf dlxm\_ctl.al}
\end{itemize}

And you should get the reply ``Net Lists are Identical''.


    		\subsubsection{Routing the Data Path}

The data path uses a special type of cell library which is designed to allow routing over the cells, thus saving a considerable amount of space compared with standard-cell implementation. For this routing you must use the {\bf ALLIANCE} tool {\bf dpr} (Data Path Router).



\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_VDD vdd]\\
\bf [$>$ setenv MBK\_VSS vss]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_PH ap]\\
\bf $>$ dpr dlxm\_dpt -p -r dlxm\_dpt
}
}

\begin {itemize}
\item {\bf dlxm\_dpt } : Input net list ({\bf dlxm\_dpt.vst}).
\item {\bf -p } : Automatic placement .
\item {\bf -r } : Automatic  routing.
\item {\bf dlxm\_dpt } : Output net list ({\bf dlxm\_dpt.ap}).
\end{itemize}

The router takes the net list specified in the file {\bf dlxm\_dpt.vst} and generates a physical layout in the file {\bf dlxm\_dpt.ap}. 


Now repeat the verification procedure for the data path. 
First the extraction :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_LO al]\\
\bf $>$ lynx dlxm\_dpt dlxm\_dpt
}
}

\begin{itemize}
\item
{\bf dlxm\_dpt } : input symbolic layout file {\bf dlxm\_dpt.ap}
\item
{\bf dlxm\_dpt } : output extracted net list {\bf dlxm\_dpt.al}
\end{itemize}

Then compare :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf $>$ lvx vst al dlxm\_dpt dlxm\_dpt -f
}
}

\begin{itemize}
\item
{\bf vst } and {\bf dlxm\_dpt } : input net list {\bf dlxm\_dpt.vst}
\item
{\bf al } and {\bf dlxm\_dpt } : extracted net list {\bf dlxm\_dpt.al}
\item
{\bf -f } : specifies that the net lists are being flattened. This is required because the original net list is hierarchical ({\em see fpgen}) whereas the extracted net list is a flat gate level net list ({\em see dpr}).
\end{itemize}



    		\subsubsection{Routing the Core}

You must now interconnect the control block and the data path in order to generate the core.
You will use {\bf ALLIANCE} tool {\bf bbr} to route them together.


First of all, you generate a ``placement'' file, which tells {\bf bbr} how the blocks are physically orientated with respect to each other. The simplest way for you to do this is to use {\bf genlib} with the soure file {\bf core.c}, which is provided.

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap ] \\
\bf [$>$ setenv MBK\_OUT\_PH ap ] \\
\bf $>$ genlib core
}
}

The file format environment variables remain the same as before, so to produce a routed core all you have to do is :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_PH ap]\\
\bf $>$ bbr core -o core vdd 10 vss 10
}
}

\begin {itemize}
\item {\bf core } : Input net list {\bf core.vst} and placement file {\bf core.ap}.
\item {\bf -o core } : Output file {\bf core.ap} (erasing placement file).
\item {\bf vdd 10 vss 10 } : Width of power and ground wires.
\end{itemize}


You now have the file {\bf core.ap} containing the physical layout of the core.

{\bf Verification of the Core}

Now you perform the same verification process at the core level :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_LO al]\\
\bf $>$ lynx core core
}
}

\begin{itemize}
\item
{\bf core } : input symbolic layout file {\bf core.ap}
\item
{\bf core } : output extracted net list {\bf core.al}
\end{itemize}

Then compare :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf $>$ lvx vst al core core
}
}

\begin{itemize}
\item
{\bf vst } and {\bf core } : input net list {\bf core.vst}
\item
{\bf al } and {\bf core } : extracted net list {\bf core.al}
\end{itemize}

And again you should get the reply ``Net Lists are Identical''.



    		\subsubsection{Routing the Chip}

The final stage in generating the physical layout of the chip is to route the core to the pads using {\bf ring}. The pad placement depends on external constraints (see {\em man ring}) and is therefore defined in the file {\bf dlxm.rin}.

Again the file format variables remain unchanged so you can now perform the routing :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_LO vst]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_PH ap]\\
\bf $>$ ring dlxm dlxm
}
}

\begin{itemize}
\item
{\bf dlxm } :  input net list {\bf dlxm.vst } and pad placement file {\bf dlxm.rin}
\item
{\bf dlxm } :   output symbolic layout file name {\bf dlxm.ap}
\end{itemize}

 Thus a physical layout of the chip is generated in the file {\bf dlxm.ap}.

 
{\bf Verification of the Chip}

Finally you must verify at the chip level :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf [$>$ setenv MBK\_OUT\_LO al]\\
\bf $>$ lynx dlxm dlxm
}
}

\begin{itemize}
\item
{\bf dlxm } : input symbolic layout file {\bf dlxm.ap}
\item
{\bf dlxm } : output extracted net list {\bf dlxm.al}
\end{itemize}


Then compare :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf $>$ lvx vst al dlxm dlxm 
}
}


\begin{itemize}
\item
{\bf vst } and {\bf dlxm } : input net list {\bf dlxm.vst}
\item
{\bf al } and {\bf dlxm } : extracted net list {\bf dlxm.al}
\end{itemize}

And if you get the reply ``Net Lists are Identical'' your entire chip has been correctly routed.

You can visualize the chip using {\bf graal}.
Use for example :

\fbox {
\shortstack[l] {
\bf $>$ graal dlxm
}
}


The output files resulting from commands of the paragraph 3.3 can be created automatically using the target {\bf physical} of the Makefile by typing:

\fbox {
\shortstack[l] {
\bf $>$ Make physical
}
}


\subsection{The Final Touch}

The last step is to translate the symbolic layout (coordinates in lambda units) into a real physical layout for the target CMOS process (two output formats are supported : CIF and GDSII). This task is done by {\bf s2r}, which performs symbolic to real expansion, gap filling, denotching, and instantiates preexisting layout cells (necessary for the pads).

You must first define an environment variable with the name of a file containing the parameters of the target process (in our case a 1.2 micron process) :

\fbox {
\shortstack[l] {
\bf $>$ setenv RDS\_TECHNO\_NAME \$(TOP)/etc/prol12.rds
}
}

Then to specify the cif format :

\fbox {
\shortstack[l] {
\bf [$>$ setenv MBK\_WORK\_LIB . ]\\
\bf [$>$ setenv MBK\_CATAL\_NAME CATAL\_CPU\_GATES]\\
\bf [$>$ setenv MBK\_CATA\_LIB .:...]\\
\bf [$>$ setenv MBK\_IN\_PH ap]\\
\bf $>$ setenv RDS\_OUT cif\\
\bf $>$ setenv RDS\_IN cif
}
}

The variable {\bf RDS\_IN} is required to specify the format of preexisting layout cells.

Then to perform the conversion :

\fbox {
\shortstack[l] {
\bf $>$ s2r  dlxm dlxm
}
}

\begin{itemize}
\item
{\bf dlxm } : input symbolic layout file ({\bf dlxm.ap}).
\item
{\bf dlxm } : output physical layout file ({\bf dlxm.cif}).
\end{itemize}

The output files resulting from commands of the paragraph 3.4 can be created automatically using the target {\bf real} of the Makefile by typing:

\fbox {
\shortstack[l] {
\bf $>$ Make real
}
}

Congratulations$!$ The chip is ready for the foundry.


\newpage

\begin{center}
{\Large \bf DLX TUTORIAL - APPENDIX}\\
February 15,1994\\
\end{center}

You can find below all the source files for the DLX microprocessor.

\begin{center}
{\bf functional specification} 
\end{center}
\begin{itemize}
\item {\bf dlxm\_cpu.vst} : VHDL structural model of the board instantiating RAM, ROM, timer, decoder, dlxm. 
\item {\bf sr64\_1a.vbe}, 
{\bf sr64\_8a.vst}  and
{\bf sr64\_32a.vst} : Behavioural and structural description for the RAM .
\item {\bf dlxm\_dec.vbe}  : VHDL behavioural description of the address decoder.
\item {\bf timer.vbe}     : VHDL behavioural description of the timer.
\item {\bf dlxm.vbe}        : VHDL behavioural description of the dlxm.
\item {\bf and001.u and def001.s} : Short assembly language programs.
\item {\bf CATAL\_CPU\_CHIP}    : List of behavioural models required for a simulation using the behavioural
model of DLXm.
\item {\bf dlxm\_cpu\_chip.pat}   : Pattern input file for testing behavioural model of dlxm chip.
\end{itemize}

\begin{center}
{\bf structural design} 
\end{center}
\begin{itemize}
\item
{\bf dlxm.vst} : VHDL structural model of the dlxm instantiating core and pads.
\item
{\bf core.3blocks.vst} : VHDL structural model of the core instantiating the data path, the sequencer and the status.
\item
{\bf dlxm\_seq.fsm} : Finite State Machine description for sequencer.
\item {\bf dlxm\_dpt.vbe} : Behavioural description for data path.
\item {\bf dlxm\_sts.vbe} : Behavioural description for status and interrupts.
\item {\bf CATAL\_CPU\_BLOCKS}    : List of behavioural models required for a simulation using 
behavioural descriptions  for data path, sequencer and status.
\item {\bf dlxm\_cpu\_blocks.pat} : Pattern input file for testing behavioural descriptions  for data path, sequencer and status.
\item {\bf dlxm\_dpt.c}   : Source code for data path generator.
\item {\bf CATAL\_CPU\_GATES}    : List of behavioural models required for a simulation using 
structural descriptions for data path, sequencer and status.
\item {\bf dlxm\_cpu\_gates.pat} : Pattern input file for testing structural descriptions  for data path, sequencer and status.
\item {\bf dlxm\_scan.c} : Source code for pattern generation for scan path simulation.
\end{itemize}

\begin{center}
{\bf physical layout} 
\end{center}
\begin{itemize}
\item {\bf unflat\_flat.c}        : Source code for hierarchical net list restructuration
\item {\bf dlxm\_ctl.lax}        : Parameter file for {\bf netoptim}
\item {\bf dlxm\_ctl.scr} : Placement file for control block connectors ({\bf scr} tool)
\item {\bf core.c}        : Placement file for control and data path ({\bf bbr} tool)
\item {\bf dlxm.rin}      : Placement file for dlxm pads ({\bf ring} tool)
\end{itemize}

\end{document}

