Table of Contents

Name

DPR - Placer-Router for Datapath Compiler

Origin

This software belongs to the ALLIANCE CAD system from the CAO-VLSI team at ASIM/LIP6/UPMC laboratory.
LIP6/ASIM
University P. et M. Curie 4, place Jussieu 75252 PARIS Cedex 05 FRANCE
Fax : {33/0} 1.44.27.62.86
E-mail support : alliance-support@asim.lip6.fr

Synopsis

dpr [-v|V] [-p] [-s name1 s:t[,s1:t1]] [-r name2] [-w nb] [-i nb] [-c nb] source

Description

DPR is a specialized placement and routing tool for bit-sliced datapaths. It is recommended to be used with the dedicated datapath description language, FPGEN.

1/ The Bit-slice Topology

A datapath is considered as a set of operators handling bus-structured data. The physical structure is made by abutting operators (or columns) horizontally. In fully regular multi-bit architectures, all operators are N-bit height, N corresponds to the number of bits. So, a bit-sliced datapath structure is similar to a two-dimensional array where lines and columns correspond respectively to bit-slices and operators. Data busses are distributed horizontally in metal2 over the cells, while control lines run vertically in metal1. To perform inter-slice connections, such as shifts and propagations, vertical routing channels are automatically created between operators. Power and ground supplies are horizontal in metal2, they delimit slices and are shared by two adjacent bit-slices. Vertical power and ground wires in metal1 are possible between operators when specified by the user. At the top of the datapath, two slices are dedicated to the control line buffers. For example, if a 32 bit datapath is specified, the compiled layout is 34 slice height.

2/ Datapath components

Two types of components may be used in a datapath:

- Multi-bit optimized blocks, that can be provided by parameterized datapath
block generators. Some complex operators such as fast adders (RSA), barrel shifters (BSG), pipelined multipliers (AMG) and register files (RFG) are considered by DPR as leaf-cells.
- One-bit functional cells called bit-cells. Such components are available
in a specialized datapath cell library called DPLIB. Functions are similar to those found in a classical standard-cell. This type of components may be used to synthesize irregular blocks (or heterogeneous operators).

3/ User Interface

All the hierarchical constraints that we describe in this section may be ignored if the input net-list is synthesized by using the FPGEN language. DPR can be used to perform placement or routing separately, or both placement and routing sequentially.

The place and route tool needs, as input, the datapath net-list, that must be given in the source file. It also needs the structural and physical views of each leaf-cell. After the placement step, we obtain a result file containing the positions of the corresponding physical instances and terminals.

At present, the input datapath net-list must be structured in one or two hierarchical levels, considering optimized blocks, DPLIB cells and FPLIB cells as terminal leaf-cells:
- The first hierarchical level defines the datapath operators (or columns).
- The possible second hierarchical level describes the structured operators. It contains one-bit cells that belong to DPLIB library (heterogeneous operators) or FPLIB library (regular operators). In that case leafcells are stacked vertically in the same column during the placement step.

Placement is performed in two independent steps: a constructive step that builds the different columns and a second step that abuts columns horizontally. During the first step, the vertical bit-cell placemennt is based on the optional information given by the user through the instance name. The integer just after the last underscore `_' in the instance name is supposed to be the slice index in which the cell must be placed. For example an instance named name_0 will be placed in the slice number 0, namely, the LSB slice. If a given cell is more than one slice height, the index must correspond to the lower slice. For example, in a 32 bit datapath, buffers (two slice height) must be named name_32". While constructing columns, vertical abutability is checked to ensure the possible control line continuity. Warning messages may appear during this placement step. During the second step columns are abutted horizontally. The column ordering may be automatically optimized in the routing step.

Datapath external terminals are automatically created and placed by DPR. We define two types of terminals: data terminals and control terminals. A data terminal is placed on the west or east abutment box side, in its corresponding slice. A control terminal is placed on the north or/and south abutment box side(s), in its column. A data terminal can be forced on the north or south abutment box side by using the .dpr file.

The routing step gives a symbolic layout file that contains the final physical description of the datapath components and the routing wires. Vertical power (VDD) and ground (VSS) wires in metal1 are automatically inserted if requested in the .dpr file.

Environment

DPR supports several structural and physical formats for inputs and outputs. The input net-list format of the datapath and its components is defined by the environment variable MBK_IN_LO. The input and output physical format(s) of the datapath and its leaf-cells are defined respectively by the environment variables MBK_IN_PH and MBK_OUT_PH. Files describing the logical view and the physical view of each leaf-cell must be available in one of the directories defined by the environment variable MBK_CATA_LIB.
At the moment, DPR needs a catalog file which name is defined by the environment variable MBK_CATAL_NAME. This file describes which components must be considered as leaf-cells in addition to the DPLIB and FPLIB cells. For example, the catalog file must contain the model names of the optimized blocks used in the datapath description. Such blocks must be generated before invoking the placement and routing tool.

Terminal Placement File

The <source>.dpr optional file allow the designer to place precisely the data-path external DATA terminals. Notice that CTRL terminals are sets to fixed positions on north side of the data-path and cannot be moved. Here is a short example :

#
# Terminal Placement.
#
: Terminal Name : Side : Slice : Track # =====================================================
DP_LOCON
cout NORTH DEFAULT DEFAULT DP_LOCON pin_input[4] EAST 3 DEFAULT DP_LOCON bus_input[15:0] EAST DEFAULT DEFAULT DP_LOCON bus_output[15:0] WEST 15:0 1 # # # Informations For Glue Logic Placer.
#
Model Name : Iterations : Height : CPC # ================================================== DP_GLUE glue_model_us 5000 8 2 # # # Informations For Placer # ======================= DP_KEEP user1_us user2_us # # # Global Power Refreshment.
#
: Number : Width # ========================
DP_POWER
3 60 # # Power Refreshement associated to specific columns.
#
: Column Name : Side : Width # ==================================== DP_POWER nand2 EAST 70 # # # Resize Abutment-Box.
#
: DXAB1 : DXAB2 # =======================
DP_DEFAB
-10 +10

The DP_LOCON instruction : DP_LOCON ConName Side Slice Track

ConName
: Terminal name, a vectorized notation can be used.
Side
: The side of the data-path on which the terminal must be set. The legal values are : - DEFAULT :The terminal will be set on East or West side.
- EAST
:East side.
- WEST
:West side.
- NORTH
:North side.
- SOUTH
:South side. When set to the NORTH or SOUTH side, the fields Slice and Track are not meaningful and must be sets to DEFAULT. There is no means to sets more precisely a terminal to the north or south side.
Slice
: Slice where the terminal will appear, a vectorized notation can be used. In this case the wide of this vector must be the same as the ConName vector.
Track
: The track where the terminal will be set, inside his slice. When a vector is used for the ConName, the track is the same for each bit of the vector.

The DP_GLUE instruction : DP_GLUE ModelName Iterations Height CPC

ModelName : Glue logic model name (must be suffixed by _us, see fpgen(1) ).

Iterations : Number of iterations for the placement algorithm.

Height
: Number of slices allowed to do the placement.
CPC
: Number of cell per columns.

The DP_KEEP instruction : DP_KEEP ModelName1 ModelName2 ...

ModelNameN : Tells the placer to keep any previously generated placement for model ModelNameN. This useful for big glue logic blocks for which placement can take much time.

The DP_POWER instruction : two forms are possibles : DP_POWER ColName Side Width DP_POWER Number Width

ColName
: The name of the column where the vertical power refreshement will be set.
Side
: The side of the column on which set the power refreshment.
Width
: The wide of the power refresment.
Number
: The number of power refreshment. They are splitted across the data-path as periodicaly as possible.

The DP_DEFAB instruction : DP_DEFAB DXAB1 DXAB2

DXAB1
: Number of lambdas added to the top of the abutment-box.
DXAB2
: Number of lambdas added to the bottom of the abutment-box.

Only one instruction DP_DEFAB is allowed in a .dpr file. If DP_DEFAB is not found, then DXAB1 is set to -10 and DXAB2 to +10, in order for the generated data-path to be routed by a floorplan router or bbr(1) .

Options

-p :
This option activates the placement step.
-r :
This option activates the routing step. In that case the name of the routed datapath must be given explicitly after the -r parameter.
-o :
This option optimizes the column ordering. It can be used only if the routing step is activated.
-s :
This option activate the streching step. The datapath will be t tracks strech in slice s. The name after the -s option indicate the final placement and strech layout name and the new netlist name.
-w :
This option indicate the datapath width when DPR can't calculate it.
-i :
This option set the default iteration number for the simulated annealing placement algorithm.
-c :
This option set the default number of cells puts in one column in the glue logic placement step.
-v :
This option set the verbose mode on.
-V :
This option set the verbose mode max.

Examples

To use DPR, some environment variables must be set : If the VHDL format for netlist (.vst) and the ALLIANCE format for layout (.ap) are used for the alu4 example, the user must have the following environment:
MBK_CATA_LIB =/labo/cells/fitpath/fplib:/labo/cells/rsa

MBK_IN_LO = vst
MBK_IN_PH = ap
MBK_OUT_PH = ap
MBK_CATAL_NAME = CATAL
MBK_WORK_LIB = .
The command line to be executed in order to place and route the datapath example called alu4 without any option is the following:

dpr -p -r alu4r alu4

This command generates the datapath layout and saves it in the file alu4r.

See Also

MBK_IN_LO(1) ,
MBK_IN_PH(1) , MBK_OUT_PH(1) , MBK_CATA_LIB(1) , MBK_WORK_LIB(1) , MBK_CATAL_NAME(1) , catal(5) , fpgen(1) , fplib(1) , dplib(1) , rsa(1) , rfg(1) , bsg(1) . amg(1) .

Bug Report

This tool is under development at the ASIM/LIP6/UPMC laboratory, cao-vlsi research team.
We need your feedbak to improve documentation and tools. If you find bugs, please fill-in the form at http://asim.lip6.fr/alliance/support/bug-report/ Thanks for doing this.


Table of Contents

 



Alliance Web Site © 1997, 2002 ASIM/LIP6/UPMC, page maintained by Czo [Olivier Sirol] , last updated on 26 May 2000.