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:
If you want to start again from scratch, you can type the command:
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
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
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
if not, the program branches to another fixed address and stops with the following
message:
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
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.
The circuit behaviour is described in the
The assembly language programs
You can now perform the simulation:
You should get the message:
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
The result of the simulation is placed in the pat file called
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
The synthesized FSM is in the
You should get the message:
which means that the test has been performed correctly.
The
This generates a hierarchical VHDL netlist of the data path
This generates a VHDL gate netlist
This generates a VHDL gate netlist
You should get the message:
which means that the test has been performed correctly.
The
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.
The output files resulting from commands of the paragraph 3.2, can be created
automatically using the target structural of the
Each place and route step will be validated using the following method:
The router takes the netlist specified in the file
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:
Then compare:
And you should get the reply "Net Lists are Identical".
The router takes the netlist specified in the file
Now repeat the verification procedure for the data path. First the extraction:
Then compare:
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
This generates the placement file
The file format environment variables remain the same as before, so to produce
a routed core all you have to do is:
You now have the file
Verification of the Core
Now you perform the same verification process at the core level:
Then compare:
And again you should get the reply "Net Lists are Identical".
Again the file format variables remain unchanged so you can now perform the
routing:
Thus a physical layout of the chip is generated in the file
Verification of the Chip
Finally you must verify at the chip level:
Then compare:
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:
The output files resulting from commands of the paragraph 3.3 can be created
automatically using the target physical of the
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:
The variable
Then to perform the conversion:
The output files resulting from commands of the paragraph 3.4 can be written
automatically using the target real of the
Congratulations! The chip is ready for the foundry.
> make
> make clean
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:
MBK_IN_LO
: Logical input file format (and filename extension).
MBK_OUT_LO
: Logical output file format (and filename extension).
MBK_IN_PH
: Physical input file format (and filename extension).
MBK_OUT_PH
: Physical output file format (and filename extension).
MBK_CATAL_NAME
: Name of the catalogue file in
MBK_WORK_LIB
directory.
MBK_CATA_LIB
: Paths to the directories that are to be searched
for read-only cell libraries.
MBK_WORK_LIB
: Directory where are saved the output files.
man < envir >
[ ]
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.
dlxm_cpu.vst
using VHDL structural syntax. Each component
is described in a separate file using VHDL behavioural syntax:
dlxm_dec.vbe
: Address decoder.
sr64_1a.vbe
: RAM.
timer.vbe
: timer for external interrupts.
roms.vbe
: Supervisor ROM.
romu.vbe
: User ROM.
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 ===="
ERROR: assert violation in dlxm_dec: : "==== ko : simulation has ended with functional test bad ===="
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.
3 Interactive Design
3.1 Behavioural Specification
Before starting the chip design, remember that all operations should be executed
in the root directory.
*.vbe
files using the
Alliance VHDL subset (see vhdl
and vbe).
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
add000.u
and add000.s
are the chosen examples of
assembly source files.
romu
and roms
are the target files (romu.vbe
and roms.vbe
).
> 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
-l 1
: size of the label in the dlxm_cpu.pat
and the
add000_chip.pat
files.
-p 50
: simulation will use sets of 50 patterns (see man
asimut
)
-bdd
: simulation uses bdd representation
dlxm_cpu
: structural description of the board (dlxm_cpu.vst
)
dlxm_cpu
: pattern input filename (dlxm_cpu.pat
)
add000_chip
: result filename (add000_chip.pat
)
ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended
with functional test good ===="
add000.s
).
add000_chip.pat
. You can take a look at this file using your
favorite viewer/editor.
stock_asm
directory and copy it into the root directory.
romu.vbe
and a new roms.vbe
by
assembling a source file.
ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended
with functional test good ===="
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:
dlxm_chip.vst
: VHDL structural model of the DLXm chip
instantiating core and pads.
dlxm_core.vst
: VHDL structural model of the core instantiating
the data path, and the control.
dlxm_ctl.vst.h
: VHDL structural model of the control instantiating
the sequencer and the status (the control model (dlxm_ctl.vst
being
saved in the file dlxm_ctl.vst.h
to prevent future erasing).
dlxm_seq.fsm
: VHDL finite state machine model of the sequencer.
dlxm_sts.vbe
: VHDL behavioural model of the status.
dlxm_dpt.vbe
: VHDL behavioural model of the data path.
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
-m
: uses "Mustang" encoding algorithm.
-V
: verbose mode.
-C
: checks the transition's consistency.
-P
: adds a scan-path to the state register.
-E
: saves encoding result in dlxm_seqm.enc
file.
dlxm_seq
: FSM source file (dlxm_seq.fsm
}.
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
-l 1
: size of the label in the dlxm_cpu.pat
and
the add000_blocks.pat
files.
-p 50
: simulation will use sets of 50 patterns (see man
asimut
)
-bdd
: simulation uses bdd representation.
dlxm_cpu
: structural description of the board (dlxm_cpu.vst
)
dlxm_cpu
: pattern input filename (dlxm_cpu.pat
)
add000_blocks
: result filename (add000_blocks.pat
)
ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended
with functional test good ===="
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
- v
: verbose mode
dlxm_dpt
: input filename (dlxm_dpt.c
)
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
dlxm_seqm
: input behavioural description (dlxm_seqm.vbe
)
dlxm_seq
: output gate netlist description by scmap
(dlxm_seq.vst
)
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
dlxm_sts
: input behavioural description (dlxm_sts.vbe
)
dlxm_sts
: output gate netlist description by scmap
(dlxm_sts.vst
)
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
-l 1
: size of the label in the dlxm_cpu.pat
and the
add000_gates.pat
files.
-p 50
: simulation will use sets of 50 patterns (see man
asimut
)
-bdd
: simulation uses bdd representation
dlxm_cpu
: structural description of the board (dlxm_cpu.vst
)
dlxm_cpu
: pattern input filename (dlxm_cpu.pat
)
add000_gates
: result filename (add000_gates.pat
)
ERROR: assert violation in dlxm_dec: : "==== ok : simulation has ended
with functional test good ===="
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:
-scan
that automatically uses scanable registers.
[ > 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
-l 10
: size of the label in the dlxm_scan.pat
and
the dlxm_scan_res.pat
files.
-p 50
: simulation will use sets of 50 patterns (see man
asimut
)
-bdd
: simulation uses bdd representation
dlxm_cpu
: structural description of the board (dlxm_cpu.vst
)
dlxm_scan
: pattern input filename (dlxm_scan.pat
)
dlxm_scan_res : result filename (
dlxm_scan_res.pat
)
Makefile
by
typing:
> make structural
3.3 Physical Layout
To get the symbolic layout description of the chip, you will:
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
-p
: Automatic placement.
-r
: Perform routing.
-l 5
: Number of rows.
-i 3000
: Number of iterations.
-a 5
: Number of vertical supplies (power and ground wires).
dlxm_ctl
: Input netlist (dlxm_ctl.vst
) and
connector placement parameter file (dlxm_ctl.scr
)
dlxm_ctl.vst
and generates a physical layout in the file dlxm_ctl.ap
following
the connector parameter file requirements.
[ > setenv MBK_WORK_LIB . ]
[ > setenv MBK_CATA_LIB ... ]
[ > setenv MBK_IN_PH ap ]
> setenv MBK_OUT_LO al
> lynx -v dlxm_ctl dlxm_ctl
-v
: verbose mode.
dlxm_ctl
: input file (symbolic layout) dlxm_ctl.ap
dlxm_ctl
: output file (extracted netlist) dlxm_ctl.al
[ > 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
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
.
dlxm_dpt.vst
and generates a physical layout in the file dlxm_dpt.ap
following
the connector parameter file requirements.
[ > 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
[ > 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.
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
dlxm_core.ap
.
[ > 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.
dlxm_core.ap
containing the physical layout
of the core.
[ > 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
[ > 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
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
.
[ > 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
dlxm_chip.ap
.
[ > 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
[ > 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
[ > setenv MBK_CATA_LIB ... ]
> graal -l dlxm_chip
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).
[ > 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
RDS_IN
is required to specify the format of preexisting
layout cells.
> s2r dlxm_chip dlxm_chip
dlxm_chip
: input symbolic layout file (dlxm_chip.ap
).
dlxm_chip
: output physical layout file (dlxm_chip.cif
).
Makefile
by typing:
> make real
Laboratoire
d'Informatique de Paris 6
Université Pierre et Marie Curie - CNRS
Alliance Web Site © 1997, 2002 ASIM/LIP6/UPMC,
page maintained by Czo [Olivier Sirol]
, last updated on 16 January 2001.