DPR(1)

NAME

DPR
     : Datapath Place and Route tool

ORIGIN
This software belongs to the ALLIANCE CAD system from the
CAO-VLSI team at MASI laboratory, University P. et M. Curie
4, place Jussieu; 75252 PARIS Cedex 05; FRANCE
Fax: (33-1) 44.27.62.86; E-mail: cao-vlsi@masi.ibp.fr

SYNOPSIS

dpr <source> [-p [-o1/-o2]] [-r <result> [-o3]]

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. The Least Significant Bit (LSB) is supposed to be at the bottom, then the Most Significant Bit (MSB) is at the top. 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 leaf-cells 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 and optimizes (if specified by the user) the column ordering. 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 by three different algorithms.
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. This file is automatically generated if the FPGEN langauage is used. The syntax of the .dpr file and an example of use can be found in the FPGEN mannual.
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.

OPTIONS

-p :
    This option activates the placement step.

-o1 :
    This option optimizes the column ordering using a first algorithm. It can be used only if the placement step is activated.

-o2 :
    This option optimizes the column ordering using a second algorithm. It can be used only if the placement step is activated.

-r :
    This option activates the routing step. In that case the name of the routed datapath must be given explicitly in the "result" parameter.

-o3 :
    This option optimizes the column ordering using a third algorithm. It can be used only if the routing step is activated.

ERROR MESSAGES
1/ <figname> is not in the CATAL!
This message appears when a figure is instanciated in the second hierarchical level and is not in the CATAL file. 2/ Physical terminal <name> with no logical corresponding in <figure>!
This message appears when a physical terminal has no corresponding logical terminal for a given leaf-cell. Logical and physical terminals must have the same name in both logical and physical descriptions. 3/ Virtual terminal <name> in <figure> is not valid!
This message appears when a virtual terminal does not respect the naming convention which is "conname_tracknumber" (for example "in_0") or when it is not located on an allow-metal2 track. 4/ Allow-metal2 wire in <figname> not valid!
This message appears when an allow-metal2 wire is fully or partially out of the abutment box of the figure.
5/ The index must be an integer in <insname>!
This message appears when the string, just after the underscore, in the instance name is not an integer.
6/ Space [i,j] is already full!
This message appears when two different instances in the same column have the same index or when instance indexes are not conflicting.
7/ Not enough horizontal tracks in channel <index>!
This message appears when there is not enough horizontal tracks in a vertical routing channel. The channel is idendified by its index. The left side that contains west terminals has the index 1, the first channel has the index 2, the first operator has the index 3, the second channel has the index 4 and so on.
8/ VDD and VSS supplies must be in the instance!
This message appears when a cell does not contain VDD and VSS terminals.
9/ Segment, via and reference lists of figure must be NULL!
This message may appear if the user tries to route a datapath already routed, if the CATAL file is not accessible or if some leaf-cells are not in the CATAL file.
10/ Vertical Alim <supply> terminal must be in a Channel!
This message appears when a power or ground terminal, for vertical wires, is not located in a channel, it should be exactly between two operators.

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/dplib:/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 alu4 -p -r alu4r
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).

DIAGNOSTICS
If problems arise please e-mail to : cao-vlsi@masi.ibp.fr