The DLXm 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


1 Introduction

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 CAD System (especially logic synthesis and the data path compiler). Beginners who are not familiar with Alliance should start using the addaccu tutorial or the Am2901 tutorial. Each 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:

You can get on-line information on any Alliance tool using the command:

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 Kaufmann Publishers, Inc. 1990.

In order to simplify the task of validating the chip, an entire CPU board has been described in 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.

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

You will use the Alliance tools to validate these sources and to generate first the gate level netlist, then the physical layout of the DLXm. The final output is a 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:

> make

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

> make clean

which will remove all the generated files.

The fully automatic chip generation requires about 22hours on a SPARCstation 5 with 64MB of RAM, running SunOS 5.5.1 / OpenWindows 3.5.1. 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 Alliance tools use UNIX environment variables. They are accessed by the UNIX command setenv. For example:

> setenv MBK_IN_LO vst
> setenv MBK_OUT_LO vst
> setenv MBK_IN_PH ap
> setenv MBK_OUT_PH ap
> setenv MBK_WORK_LIB .
> setenv MBK_CATAL_NAME CATAL
> setenv MBK_CATA_LIB $TOP/cells/sclib:$TOP/cells/bsg:$TOP/cells/rfg:$TOP/cells/rsa:$TOP/cells/fplib:$TOP/cells/padlib

You can get on-line information on Alliance environment variables using the command:

man < envir >

Some of the path names may 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 distribution 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.

2 Simulation method for design validation

2.1 Behavioural model

The specification of the chip which you are going to build is given in the file dlxm_chip.vbe in the form of a 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 VHDL. The CPU board interconnections are described in the file dlxm_cpu.vst using VHDL structural syntax. Each component is described in a separate file using VHDL behavioural syntax:

2.2 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 good) and stops with the following message:

ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended with functional test good ===="

if not, the program branches to another fixed address and stops with the following message:

ERROR: assert violation in dlxm_dec: : "==== ko : simulation has ended with functional test bad  ===="

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

2.3 Simulation

The VHDL simulator asimut can mix structural and behavioural descriptions: a special file, defined by the environment variable MBK_CATAL_NAME (see 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.

3 Interactive Design

3.1 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 Alliance VHDL subset (see vhdl and vbe).

The assembly language programs add000.u and add000.s are used. To assemble them, do:

> setenv MBK_WORK_LIB .
> dlx_asm add000.u romu
> dlx_asm add000.s roms

You can now perform the simulation:

> setenv VH_BEHSFX vbe
> setenv MBK_MAXERR 10
> setenv VH_PATSFX pat
> setenv MBK_IN_LO vst
> setenv MBK_CATAL_NAME CATAL_CPU_CHIP
[ > setenv MBK_WORK_LIB . ]
> setenv MBK_CATA_LIB ./mclib:$TOP/cells/sclib:$TOP/cells/bsg:$TOP/cells/rfg:$TOP/cells/rsa:$TOP/cells/fplib:$TOP/cells/padlib
> asimut -l 1 -p 50 -bdd dlxm_cpu dlxm_cpu add000_chip

You should get the message:

ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended with functional test good ===="

which means that the test has been performed correctly.

The Status Register and the Program Counter are initialized thanks to the RESET input on the board and convenient assembly instructions in the superuser ROM (see add000.s).

The result of the simulation is placed in the pat file called add000_chip.pat. You can take a look at this file using your favorite viewer/editor.

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

All the output files resulting from operations of the paragraph 3.1 can be written automatically using the target functional of the Makefile by typing:

> make functional

3.2 Structural Design

3.2.1 Design Hierarchy

In this step, the structural descriptions of the chip (dlx.vst), and the core (core.vst) are used. The chip is described as a core surrounded by pads. The core is divided into two structural blocks: control and data path, the control block being also divided into two structural blocks: sequencer and status, each of which must be represented by its own behavioural description. The following source files are provided:

3.2.2 Sequencer state assignment

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

[ > setenv MBK_WORK_LIB . ]
> syf -m -V -C -P -E dlxm_seq

The synthesized FSM is in the dlxm_seqm.vbe file.

3.2.3 Validation of the DLXm block view

You can then simulate the resulting model after having copied the structural description of the control in two blocks dlxm_core.vst.h:

> cp dlxm_ctl.vst.h dlxm_ctl.vst
> chmod 644 dlxm_ctl.vst

[ > setenv VH_BEHSFX vbe ]
[ > setenv MBK_MAXERR 10 ]
[ > setenv VH_PATSFX pat ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> setenv MBK_CATAL_NAME CATAL_CPU_BLOCKS
> asimut -l 1 -p 50 -bdd dlxm_cpu dlxm_cpu add000_blocks

You should get the message:

ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended with functional test good ===="

which means that the test has been performed correctly.

The CATAL_CPU_BLOCKS file tells asimut to use the behavioural models for the three blocks data path, sequencer and status.

3.2.4 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 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 man fpgen). You must compile this using the Alliance data path generator fpgen, you will thus use the provided subdirectory mclib to store the generated operators:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_LO vst ]
> setenv MBK_OUT_LO vst
> setenv MBK_IN_PH ap
> setenv MBK_OUT_PH ap
> setenv FPGEN_LIB ./mclib
> fpgen -v dlxm_dpt

This generates a hierarchical VHDL netlist of the data path dlxm_dpt.vst. The generated operators (vbe, ap and vst formats) instantiated in dlxm_dpt.vst are stored with their associated CATAL into the subdirectory ./mclib defined by the environment variable FPGEN_LIB.

3.2.5 Sequencer synthesis

A standard cell netlist of the sequencer is synthesized by the logic synthesis tool scmap from the behavioural description contained in dlxm_seqm.vbe:

[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_OUT_LO vst ]
[ > setenv MBK_WORK_LIB . ]
> setenv MBK_TARGET_LIB $TOP/cells/sclib
> scmap dlxm_seqm dlxm_seqm

This generates a VHDL gate netlist dlxm_seqm.vst using the standard cell library defined by the environment variable MBK_TARGET_LIB.

3.2.6 Status synthesis

A standard cell netlist of the status block is synthesized from the behavioural description contained in dlxm_sts.vbe. This is done using scmap as for the sequencer.

[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_OUT_LO vst ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_TARGET_LIB $TOP/cells/sclib ]
> scmap dlxm_sts dlxm_sts

This generates a VHDL gate netlist dlxm_sts.vst using the standard cell library defined by the environment variable MBK_TARGET_LIB.

3.2.7 DLXm structural view validation

We have now a complete gate-level netlist of the processor. This stage can be validated using asimut:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv VH_BEHSFX vbe ]
[ > setenv MBK_MAXERR 10 ]
[ > setenv VH_PATSFX pat ]
[ > setenv MBK_IN_LO vst ]
> setenv MBK_CATAL_NAME CATAL_CPU_GATES
> asimut -l 1 -p 50 -bdd dlxm_cpu dlxm_cpu add000_gates

You should get the message:

ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended with functional test good ===="

which means that the test has been performed correctly.

The CATAL_CPU_GATES file tells asimut to use the behavioural models for the gates and for the generated blocks.

3.2.8 Design for testability

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

Here we check the scan path with the simulator asimut with a dedicated file that fills in the scan path and check the scan output.

[ > setenv VH_PATSFX pat ]
[ > setenv VH_BEHSFX vbe ]
[ > setenv MBK_MAXERR 10 ]
[ > setenv VH_PATSFX pat ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_CATAL_NAME CATAL_CPU_GATES ]
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> asimut -l 10 -p 50 -bdd dlxm_cpu dlxm_scan dlxm_scan_res

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

> make structural

3.3 Physical Layout

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

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

3.3.1 Control block routing

You must now use scr (Standard Cell Router) to generate the physical layout of the control. We will use the Alliance format for input and output symbolic layout by setting the appropriate environment variables:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_VDD vdd ]
[ > setenv MBK_VSS vss ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_OUT_LO vst ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
> scr -p -r -l 5 -i 3000 -a 5 dlxm_ctl

The router takes the netlist specified in the file dlxm_ctl.vst and generates a physical layout in the file dlxm_ctl.ap following the connector parameter file requirements.

In order to verify that no errors occured in the generation of the physical layout, we extract a netlist from the layout using the Alliance tool lynx, and then compare the result with the original netlist using lvx.

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

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_PH ap ]
> setenv MBK_OUT_LO al
> lynx -v dlxm_ctl dlxm_ctl

Then compare:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> lvx vst al dlxm_ctl dlxm_ctl

  • vst and dlxm_ctl: input netlist dlxm_ctl.vst
  • al and dlxm_ctl: extracted netlist dlxm_ctl.al

And you should get the reply "Net Lists are Identical".

3.3.2 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 Alliance tool dpr (Data Path Router).

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_VDD vdd ]
[ > setenv MBK_VSS vss ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
> dpr -v -o -p -r dlxm_dpt dlxm_dpt

  • -v: Verbose mode.
  • -o: Placement optimization.
  • -p: Automatic placement.
  • -r: Automatic routing.
  • dlxm_dpt: Output netlist (dlxm_dpt.ap).
  • dlxm_dpt: Input netlist (dlxm_dpt.vst) and Connector placement parameter file dlxm_dpt.dpr.

The router takes the netlist specified in the file dlxm_dpt.vst and generates a physical layout in the file dlxm_dpt.ap following the connector parameter file requirements.

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

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_LO al ]
> lynx -v dlxm_dpt dlxm_dpt

  • -v: verbose mode.
  • dlxm_dpt: input file (symbolic layout) dlxm_dpt.ap
  • dlxm_dpt: output file (extracted netlist) dlxm_dpt.al

Then compare:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> lvx vst al dlxm_dpt dlxm_dpt

  • vst and dlxm_dpt: input netlist dlxm_dpt.vst
  • al and dlxm_dpt: extracted netlist dlxm_dpt.al

3.3.3 Routing the Core

You must now interconnect the control block and the data path in order to generate the core. You will use Alliance tool bbr to route them together.

First of all, you generate a "placement" file, which tells bbr how the blocks are physically orientated with respect to each other. The simplest way for you to do this is to use genlib with the source file dlxm_core.c, which is provided:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> genlib -v dlxm_core

  • - v: verbose mode dlxm_core: input file name dlxm_core.c

This generates the placement file dlxm_core.ap.

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

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
> bbr dlxm_core -v -o dlxm_core vdd 12 vss 12

  • dlxm_core: Input netlist dlxm_core.vst and placement file dlxm_core.ap. - v: verbose mode.
  • -o: Output file dlxm_core.ap (erasing placement file).
  • vdd 12 vss 12: Width of power and ground wires.

You now have the file dlxm_core.ap containing the physical layout of the core.

Verification of the Core

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

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_LO al ]
> lynx -v dlxm_core dlxm_core

  • -v: verbose mode. dlxm_core: input file (symbolic layout) dlxm_core.ap
  • dlxm_core: output file (extracted netlist) dlxm_core.al

Then compare:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> lvx vst al dlxm_core dlxm_core

  • vst and dlxm_core: input netlist dlxm_core.vst
  • al and dlxm_core: extracted netlist dlxm_core.al

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

3.3.4 Routing the Chip

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

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

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATAL_NAME CATAL ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_LO vst ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_PH ap ]
> ring dlxm_chip dlxm_chip

  • dlxm_chip: input netlist dlxm_chip.vst and placement file dlxm_chip.rin
  • dlxm_chip: output symbolic layout file name dlxm_chip.ap

Thus a physical layout of the chip is generated in the file dlxm_chip.ap.

Verification of the Chip

Finally you must verify at the chip level:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_PH ap ]
[ > setenv MBK_OUT_LO al ]
> lynx -v dlxm_chip dlxm_chip

  • -v: verbose mode.
  • dlxm_chip: input file (symbolic layout) dlxm_chip.ap
  • dlxm_chip: output file (extracted netlist) dlxm_chip.al

Then compare:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
> lvx vst al dlxm_chip dlxm_chip

  • vst and dlxm_chip: input netlist dlxm_chip.vst
  • al and dlxm_chip: extracted netlist dlxm_chip.al

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

You can visualize the chip using graal. Use for example:

[ > setenv MBK_CATA_LIB ... ]
> graal -l dlxm_chip

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

> make physical

3.4 The Final Touch

The last step is to translate the symbolic layout (coordinates in lambda units) into a physical layout for the target CMOS process (two output formats are supported : CIF and GDSII). This task is done by 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 micron process) and then specify the cif format:

[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATAL_NAME CATAL_CPU_GATES ]
[ > setenv MBK_CATA_LIB .:... ]
[ > setenv MBK_IN_PH ap ]
> setenv RDS_TECHNO_NAME $TOP/etc/prol10_7.rds
> setenv RDS_OUT cif
> setenv RDS_IN cif

The variable RDS_IN is required to specify the format of preexisting layout cells.

Then to perform the conversion:

> s2r dlxm_chip dlxm_chip

  • dlxm_chip: input symbolic layout file (dlxm_chip.ap).
  • dlxm_chip: output physical layout file (dlxm_chip.cif).

The output files resulting from commands of the paragraph 3.4 can be written automatically using the target real of the Makefile by typing:

> make real

Congratulations! The chip 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.