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:
amd.vbe
: VHDL behavioural model.
pattern.pat
: Simulation Patterns.
chip.c
: Chip structural description.
chip.rin
: Pads placement (for ring).
heart.scr
: Connectors placement (for scr).
chip.inf
: Registers renaming (for yagle).
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:
> make
If you want to start again this example from the begining, you just have to type:
> make clean > make
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
MBK_CATA_LIB
: This variable defines all paths to the
directories containing the Alliance predefined cell libraries.
MBK_WORK_LIB:
This variable defines the working directory:
all user files will be written in this directory.
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.
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
amd
is the filename of the behavioural description (amd.vbe
).
-bdd
means that BDDs will be used to represent expressions.
-b
means that the file is a pure behavioural description.
-c
stands for compilation only (compilability is checked,
no simulation is performed).
The file pattern.pat
is given as an example.
> setenv VH_MAXERR 10
VH_MAXERR
: The maximum number of errors accepted before
asimut stops simulation.
> setenv VH_PATSFX pat
VH_PATSFX
: the extension of simulation patterns file.
[ > 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
amd
: is the filename of the description (amd.vbe
).
pattern
: is the filename for the input patterns (pattern.pat
).
result_beh
: is the filename for the resulting patterns (result_beh.pat
).
-bdd
means that BDDs will be used to represent expressions.
-b
: means that the amd
file is a pure behavioural description.
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.
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.
[ > 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
chip
: is the structural input file (chip.vst
).
pattern
: is the filename for the input patterns (pattern.pat
).
result_str
: is filename for the resulting patterns
(result_str.pat
).
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.
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
heart
: is the input netlist (heart.vst
) and the
connector placement (heart.scr
). The output layout will be
heart.ap
.
-p
: automatic placement.
-r
: routing required.
The symbolic layout file heart.ap
has been created.
druc checks the symbolic layout rules (see man druc
)
[ > 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 heart
If necessary, druc generates an error file (core.err
).
lynx is a hierarchical extractor that provides
a gate netlist. In order to avoid name collision, we use another file format
for extracted netlist (.al
format). This new format is used
to support additional data: extracted parasitic capacitances.
> setenv MBK_OUT_LO al
Then we run the lynx extractor:
[ > setenv MBK_OUT_LO al ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> lynx heart
The extracted netlist file heart.al
is created at this level.
The next tool is the net-compare lvx that performs a
netlist comparison between the input netlist heart.vst
and the
extracted netlist heart.al
, after flattening to the gate level.
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB .:$TOP/cells/sclib:$TOP/cells/padlib ]
> lvx vst al heart heart -f
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
chip
: The input files chip.vst
and chip.rin
(the same name chip
must be used for the two files).
chip
: The output physical file chip.ap
.
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
[ > 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
).
.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.
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
chip
: is the input layout (chip.al
).
-i
: read the chip.inf
file.
-v
: to vectorize the interface of behavioral description.
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
chip
: is the abstracted file (chip.vbe
).
amd
: is the initial behavioral description (amd.vbe
).
-a
: keeps all common intermediate signals.
-d
: displays errors.
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.
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
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
-c
: deletes connectors at the highest level of hierarchy.
You did it...
The file produced is am2901.cif
. It is ready for the foundry.
![]() Université Pierre et Marie Curie - CNRS |
![]() |