First steps in using Alliance: The Am2901 tutorial


Équipe Achitecture des Systèmes et Micro-Électronique
Laboratoire d'Informatique de Paris 6
Université Pierre et Marie Curie
4, Place Jussieu 75252 Paris Cedex 05,
France
alliance-support@asim.lip6.fr


The goal of this tutorial is to present a typical design-flow of a simple 4 bit processor (Am2901), using the Alliance tools.

The tools used here are :

At any time you can get information on any Alliance tool using the command:

> man <tool name>

This tutorial doesn't contain a description of the Am2901, but the methodology used in Alliance to produce it. Nevertheless, you will find in the file AMD2901-doc.tgz, the original data-sheet of the circuit. To uncompress the sheets, use the UNIX command:

> gunzip AMD2901-doc.tgz
> tar xvf AMD2901-doc.tar

The design-flow used in this tutorial is composed of six steps:

In order to build the chip in about two hours, all the source files are provided with this tutorial:

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

To build the chip you can:

All Alliance tools use a set of UNIX environment variables. These variables are set by the tcsh shell command setenv.

> setenv MBK_WORK_LIB .
> setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib

Some of the path names have to be modified in order to correspond to your particular installation of Alliance, in this tutorial we will assume that the directory structure of the sources files has not been altered. In this tutorial, the commands which are inside [ ] are preset. If you stay in the same shell during the making of the Am2901, you don't have to set again these environment variables.

1 Behavioural specification

1.1 Behavioural model

The circuit behaviour is described in the amd.vbe file using the Alliance VHDL behavioural subset. You must run the VHDL compiler to validate the VHDL file syntax.

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> asimut -bdd -b -c amd

1.2 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 pattern.pat is given as an example.

1.3 Simulation

You have now a logical description of your circuit, and a list of patterns. You can run the zero-delay VHDL simulator asimut. You have to set up some new environment variables specific to asimut.

> setenv VH_MAXERR 10

> setenv VH_PATSFX pat

[ > setenv VH_MAXERR 10 ]
[ > setenv VH_PATSFX pat ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> asimut -bdd -b amd pattern result_beh

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

2 Structural Description

2.1 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 scr and the pad library ring. To do this, Alliance doesn't use a schematic editor but the procedural language genlib which is a set of C functions (see man genlib).

The structural description of the Am2901 follows a hierarchical approach.

The chip.c file uses the genlib language to describe these 7 hierarchical blocs.

The Alliance system accepts several external file formats for netlist (EDIF, VHDL, SPICE, Alliance, VLSI). Environment variables allow to set the formats. The .vst extension corresponds to the structural VHDL.

> setenv MBK_IN_LO vst
> setenv MBK_OUT_LO vst

All netlist files created and used by genlib will now be structural VHDL.

[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_OUT_LO vst ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> genlib -v chip

The 7 files alu.vst, accu.vst, ram.vst, muxe.vst, muxout.vst, heart.vst and chip.vst have been created.

2.2 Structural Model Simulation

The various netlist files we have created represent the structural description that should be validated by simulation, using the same patterns as in step 1.

[ > setenv MBK_IN_LO vst ]
[ > setenv VH_PATSFX pat ]
[ > setenv VH_MAXERR 10 ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> asimut chip pattern result_str

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

Any new error appearing will be reported in the result_str.pat file. You can try to introduce a schematic error by modifying the chip.c file, running genlib and asimut to see the errors.

3 Physical Design

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

3.1 Routing the heart

Scr is a standard cell placing and routing tool.

Here again Alliance accepts several external file formats for the symbolic layout. Environment variables allow to set the formats.

 > setenv MBK_IN_PH ap
 > setenv MBK_OUT_PH ap

The hierarchical netlist will be flattenned before routing.

[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> scr -p -r heart

The symbolic layout file heart.ap has been created.

3.2 Heart verification

3.3 Routing the chip

The pad placement depends on external constraints. The file chip.rin defines the pads placement constraints (see man ring).

[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
 > ring chip chip

The symbolic layout file chip.ap has been created. At this point, you can display the chip with the layout editor graal. You can see the chip and the instantiated heart, using the graal commands to go through the hierarchy levels.

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
 > graal -l chip

4 Physical Validation

The Alliance verification tools allow both flat and hierarchical verification. We will use a hierarchical approach.

4.1 Chip verification

The same procedure used for the heart applies for the entire chip.

[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
[ > setenv RDS_TECHNO_NAME $TOP/etc/cmos_7.rds ]
[ > setenv RDS_IN cif ]
[ > setenv RDS_OUT cif ] 
> druc chip

Eventually, druc generates an error file (chip.err).

[ > setenv MBK_OUT_LO al ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_WORK_LIB . ]
> lynx chip

The extracted netlist file chip.al is created by this step (This netlist instantiates the heart).

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> lvx vst al chip chip

Both netlists chip.vst and chip.al are flattened to the gate level by lvx before comparison (see man catal).

4.2 Chip simulation

Finally you can check globally the extracted netlist by applying the original patterns to the extracted netlist. Thanks to the multiformat approach the simulator asimut accepts .al format as structural input description.

 > setenv MBK_IN_LO al

Then you have to run asimut.

[ > setenv MBK_IN_LO al ]
[ > setenv VH_PATSFX pat ]
[ > setenv VH_MAXERR 10 ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
 > asimut chip pattern res_pattern

To complete the validation of our chip, the functional abstraction followed by the proof must be done.

4.3 Functional abstraction and formal proof

The functional abstraction of the transitor netlist is realized by the tool yagle (see man yagle). yagle flattens the chip (chip.al) to obtain a transistor level description, and abstract then a behavioral description (chip.vbe). To keep the coherence of register names between the behavioral description given by yagle (chip.vbe) and the initial behavioral description (amd.vbe), a file describing the name's transformation is required. This file is chip.inf.

[ > setenv MBK_IN_LO al ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
 > yagle chip -i -v

The VHDL DATA FLOW description has been generated: chip.vbe

Now you have the abstracted behavioral description (chip.vbe) and the initial behavioral description (amd.vbe). With proof (see man proof), you can check the formal equivalence between the two descriptions.

[ > setenv MBK_WORK_LIB . ]
 > proof -a -d amd chip

If you want to see an error you can change one line in the file amd.vbe. For example, change the line 302:

scout <= NOT accu ( 3 ) AND test_mode;

and try proof again.

5 Timing analysis

With the extracted net list chip.al tas analyses each path of the circuit taking account of the various capacitances. These results are summarize in a file .ttv. In this file we can see the critical path and the correspnding time. So it is possible to know the period of the chip.

You will enter :

[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_IN_LO al ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
 > tas chip 

6 Chip finishing

Until now we used symbolic layout (all coordinates in 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 s2r. 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 :

> setenv RDS_TECHNO_NAME $TOP/etc/prol10_7.rds

The prol10_7.rds is the technology file that contains the parameters corresponding to the target process. (In this case the target process is 1 micron.)

> setenv RDS_OUT cif

Defines the output format.

> setenv RDS_IN cif

Defines the input format for the preexisting layout cells (pads).

You will enter:

[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
[ > setenv RDS_TECHNO_NAME $TOP/etc/prol10_7.rds ]
[ > setenv RDS_IN cif ]
[ > setenv RDS_OUT cif ]
> s2r -c chip Am2901

You did it...

The file produced is am2901.cif. It is ready for the foundry.


[LIP6]Laboratoire d'Informatique de Paris 6
Université Pierre et Marie Curie - CNRS

[Alliance]

 



Alliance Web Site © 1997, 2002 ASIM/LIP6/UPMC, page maintained by Czo [Olivier Sirol] , last updated on 16 January 2001.