man5
This commit is contained in:
Olivier Sirol
parent
76269320dc
commit
08c8a5ad27
|
|
@ -1 +1 @@
|
|||
SUBDIRS = src man1 man3
|
||||
SUBDIRS = src man1 man3 man5
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ dnl Almost ten years since I wrote this stuff, I just can't
|
|||
dnl believe it
|
||||
dnl Date : 01/02/2002
|
||||
dnl Author : Frederic Petrot <Frederic.Petrot@lip6.fr>
|
||||
dnl $Id: configure.in,v 1.2 2002/04/03 16:21:11 ludo Exp $
|
||||
dnl $Id: configure.in,v 1.3 2002/09/24 08:44:21 czo Exp $
|
||||
dnl
|
||||
dnl
|
||||
AC_INIT(src/mut.h)
|
||||
|
|
@ -48,4 +48,5 @@ Makefile
|
|||
src/Makefile
|
||||
man1/Makefile
|
||||
man3/Makefile
|
||||
man5/Makefile
|
||||
])
|
||||
|
|
|
|||
|
|
@ -0,0 +1,2 @@
|
|||
man_MANS = ap.5 catal.5 prol.5 vbe.5 vhdl.5 vst.5
|
||||
EXTRA_DIST = $(man_MANS)
|
||||
|
|
@ -0,0 +1,348 @@
|
|||
.\" $Id: ap.5,v 1.1 2002/09/24 08:44:43 czo Exp $
|
||||
.\" @(#)Labo.l 0.0 91/04/02 UPMC; Author: Vincent POUILLEY
|
||||
.TH AP 5 "October 1, 1997" "ASIM/LIP6" "FILE FORMATS"
|
||||
.SH NAME
|
||||
ap \- Alliance physical format
|
||||
.so man1/alc_origin.1
|
||||
.SH BNF DESCRIPTION
|
||||
file ::=
|
||||
version
|
||||
header
|
||||
connectors
|
||||
segments
|
||||
instances
|
||||
transistors
|
||||
patterns
|
||||
end_of_file
|
||||
|
||||
version ::= 'V ALLIANCE 2.2 SETUP : ' version_number
|
||||
|
||||
header ::= 'H ' name ',' file_type ',' abindex ',' nb_desc
|
||||
',' date ',' index_beg ',' link_mode ','
|
||||
bounding_box ',' [ abutment_box ]
|
||||
/* name : name of the figure */
|
||||
/* file_type : type of the file */
|
||||
/* abindex : index of the abutment box */
|
||||
/* nb_desc : number of descriptors */
|
||||
/* date : saving file date */
|
||||
/* index_beg : index of the begining of the linkage */
|
||||
/* link_mode : indication on the linkage */
|
||||
/* (update or not) */
|
||||
/* bounding_box : coordinates and size of the */
|
||||
/* bounding box */
|
||||
/* abutment_box : coordinates and size, if defined, */
|
||||
/* of the abutment box */
|
||||
|
||||
connectors ::= { connector }
|
||||
|
||||
connector ::= 'C ' index ',' x ',' y ',' w ',' orientation
|
||||
',' layer ',' name ',' connector_type ','
|
||||
nextindex ',' endnet
|
||||
/* x, y, w : coordinates and size of the connector */
|
||||
/* orientation : north, south, east, or west */
|
||||
/* layer : layer of the connector */
|
||||
/* name : name of the connector */
|
||||
/* connector_type : input or output or ... */
|
||||
/* nextindex : next index in the linkage */
|
||||
/* endnet : end in the linkage of the net */
|
||||
|
||||
segments ::= { segment }
|
||||
|
||||
segment ::= 'S ' index ',' x ',' y ',' d ',' w ',' direction
|
||||
',' layer ',' name ',' nextindex ',' endnet
|
||||
/* x, y, d, w : coordinates and size of the segment */
|
||||
/* direction : horizontaly or verticaly */
|
||||
/* layer : layer of the segment */
|
||||
/* name : name of the segment */
|
||||
/* nextindex : next index in the linkage */
|
||||
/* endnet : end in the linkage of the net */
|
||||
|
||||
instances ::= { instance [ connectors ] }
|
||||
/* In case of updated linkage, an instance is followed */
|
||||
/* by his connectors */
|
||||
|
||||
instance ::= 'I ' index ',' x ',' y ',' instance_name ','
|
||||
model_name ',' geoop ',' nextindex ',' endnet
|
||||
/* x, y : coordinates of the instance */
|
||||
/* instance_name : local name of the instance */
|
||||
/* model_name : name of the model */
|
||||
/* geoop : geometric operation */
|
||||
/* nextindex : next index in the linkage */
|
||||
/* endnet : end in the linkage of the net */
|
||||
|
||||
transistors ::= { transistor }
|
||||
|
||||
transistor ::= 'T ' index ',' x ',' y ',' instance_name ','
|
||||
trans_name ',' geoop ',' nextindex ',' endnet
|
||||
/* x, y : coordinates of the transistor */
|
||||
/* instance_name : name of the instance */
|
||||
/* trans_name : generic name of the transistor */
|
||||
/* geoop : geometric operation */
|
||||
/* nextindex : next index in the linkage */
|
||||
/* endnet : end in the linkage of the net */
|
||||
|
||||
patterns ::= { pattern }
|
||||
|
||||
pattern ::= 'M ' index ',' x ',' y ',' instance_name ','
|
||||
pattern_name ',' int_index ',' nextindex ','
|
||||
endnet
|
||||
/* x, y : coordinates of the pattern */
|
||||
/* instance_name : name of the instance of the pattern */
|
||||
/* pattern_name : name of the pattern */
|
||||
/* int_index : internal index of the pattern */
|
||||
/* nextindex : next index in the linkage */
|
||||
/* endnet : end in the linkage of the net */
|
||||
|
||||
end_of_file ::= 'EOF'
|
||||
|
||||
version_number ::= number
|
||||
|
||||
file_type ::= 'P'
|
||||
|
||||
abindex ::= index
|
||||
|
||||
nb_desc ::= number
|
||||
|
||||
date ::= day '/' month '/' year
|
||||
|
||||
index_beg ::= index
|
||||
|
||||
index ::= number
|
||||
|
||||
link_mode ::= 'A JOUR' | 'PAS A JOUR'
|
||||
/* updated, not updated */
|
||||
|
||||
bounding_box ::= x ',' y ',' dx ',' dy
|
||||
|
||||
abutment_box ::= x ',' y ',' dx ',' dy
|
||||
|
||||
x ::= number
|
||||
|
||||
y ::= number
|
||||
|
||||
d ::= number
|
||||
/* lenght */
|
||||
|
||||
w ::= number
|
||||
/* width */
|
||||
|
||||
dx ::= number
|
||||
|
||||
dy ::= number
|
||||
|
||||
direction ::= 'H' | 'V'
|
||||
/* horizontaly or verticaly */
|
||||
|
||||
orientation ::= 'NORD' | 'SUD' | 'EST' | 'OUEST'
|
||||
/* North, south, east, west */
|
||||
|
||||
layer ::= 'POLY' | 'ALU1' | 'ALU2' | 'DIFN' | 'DIFP' |
|
||||
'T_ALU1' | 'T_ALU2' | 'CAISSON_N' | 'CAISSON_P'
|
||||
/* poly : polysilicium */
|
||||
/* alu1 : first metal */
|
||||
/* alu2 : second metal */
|
||||
/* difn : N diffusion */
|
||||
/* difp : P diffusion */
|
||||
/* t_alu1 : first metal through route */
|
||||
/* t_alu2 : second metal through route */
|
||||
/* caisson_n : N bulk */
|
||||
/* caisson_p : P bulk */
|
||||
|
||||
connector_type ::= 'IN' | 'OUT' | 'INOUT'
|
||||
|
||||
nextindex ::= index
|
||||
|
||||
endnet ::= 'NON' | 'FIN'
|
||||
/* non : not the end of the net */
|
||||
/* fin : end of the net */
|
||||
|
||||
model_name ::= name
|
||||
|
||||
instance_name ::= name
|
||||
|
||||
geoop ::= 'NOSYM' | 'ROT_P' | 'ROT_M' | 'SYM_X' | 'SYM_Y' |
|
||||
'SYMXY' | 'SY_RP' | 'SY_RM'
|
||||
/* nosym : no operation */
|
||||
/* rot_p : rotates 90 degrees counter clockwise */
|
||||
/* rot_m : rotates 90 degrees clockwise */
|
||||
/* sym_y : y becomes -y */
|
||||
/* sym_x : x becomes -x */
|
||||
/* symxy : x becomes -x and y becomes -y */
|
||||
/* sy_rp : x becomes -x then rotates 90 degrees */
|
||||
/* counter clockwyse */
|
||||
/* sy_rm : x becomes -x then rotates 90 degrees */
|
||||
/* clockwyse */
|
||||
|
||||
trans_name ::= 'T' transistor_type '_' d '_' w
|
||||
|
||||
pattern_name ::= 'CONT_POLY' | 'CONT_DIF_N' | 'CONT_DIF_P' |
|
||||
'CONT_VIA' | 'C_X_N' | 'C_X_P' | 'REF_CON'
|
||||
| 'REF_REF'
|
||||
/* cont_poly : poly alu1 contact */
|
||||
/* cont_dif_n : alu1 difn contact */
|
||||
/* cont_dif_p : alu1 difp contact */
|
||||
/* cont_via : alu2 alu1 contact */
|
||||
/* c_x_n : L shaped N transistor corner filling */
|
||||
/* c_x_p : L shaped P transistor corner filling */
|
||||
/* ref_con : kind of reference, for multi-acces */
|
||||
/* connectors */
|
||||
/* ref_ref : kind of reference, for all other uses */
|
||||
|
||||
int_index ::= index
|
||||
|
||||
transistor_type ::= 'P' | 'N'
|
||||
|
||||
number ::= { '0' | '1'| '2' | '3' | '4' | '5' |
|
||||
'6' | '7'| '8' | '9' }
|
||||
|
||||
name ::= word
|
||||
.SH EXAMPLES
|
||||
.LP
|
||||
.SS Example 1
|
||||
This example is the physical design of a nand with two input. See
|
||||
example 1 in the description of alc logical format for more
|
||||
details.
|
||||
.LP
|
||||
.nf
|
||||
V ALLIANCE 2.2 SETUP : 2
|
||||
H na2_y,P,10,66,25/10/91,-1,PAS A JOUR,0,0,28,53,5,3,18,42
|
||||
C 0,20,45,2,NORD,ALU2,i0,INOUT,-1,FIN
|
||||
C 1,14,45,2,NORD,ALU2,f,INOUT,-1,FIN
|
||||
C 2,8,45,2,NORD,ALU2,i1,INOUT,-1,FIN
|
||||
C 3,20,3,2,SUD,ALU2,i0,INOUT,-1,FIN
|
||||
C 4,14,3,2,SUD,ALU2,f,INOUT,-1,FIN
|
||||
C 5,8,3,2,SUD,ALU2,i1,INOUT,-1,FIN
|
||||
C 6,23,43,8,EST,ALU1,vdd,INOUT,-1,FIN
|
||||
C 7,5,43,8,OUEST,ALU1,vdd,INOUT,-1,FIN
|
||||
C 8,5,5,8,OUEST,ALU1,vss,INOUT,-1,FIN
|
||||
C 9,23,5,8,EST,ALU1,vss,INOUT,-1,FIN
|
||||
S 11,5,5,18,8,H,ALU1,vss,-1,FIN
|
||||
S 12,8,2,12,2,H,DIFP,*,-1,FIN
|
||||
S 13,8,27,11,3,V,DIFP,*,-1,FIN
|
||||
S 14,20,27,11,3,V,DIFP,*,-1,FIN
|
||||
S 15,20,22,6,2,V,ALU1,*,-1,FIN
|
||||
S 16,19,22,1,2,H,ALU1,*,-1,FIN
|
||||
S 17,5,43,18,8,H,ALU1,vdd,-1,FIN
|
||||
S 18,8,33,10,2,V,ALU1,vdd,-1,FIN
|
||||
S 19,8,22,6,2,V,ALU1,*,-1,FIN
|
||||
S 20,8,22,1,2,H,ALU1,*,-1,FIN
|
||||
S 21,14,30,5,2,V,ALU1,*,-1,FIN
|
||||
S 22,14,13,17,1,V,ALU1,*,-1,FIN
|
||||
S 23,14,13,6,1,H,ALU1,*,-1,FIN
|
||||
S 24,17,22,2,2,H,POLY,*,-1,FIN
|
||||
S 25,17,20,5,1,V,POLY,*,-1,FIN
|
||||
S 26,9,22,2,2,H,POLY,*,-1,FIN
|
||||
S 27,11,20,5,1,V,POLY,*,-1,FIN
|
||||
S 28,8,45,12,2,H,DIFN,*,-1,FIN
|
||||
S 29,5,39,18,26,H,CAISSON_N,*,-1,FIN
|
||||
S 30,8,7,11,3,V,DIFN,*,-1,FIN
|
||||
S 31,8,3,42,2,V,ALU2,i1,-1,FIN
|
||||
S 32,14,3,42,2,V,ALU2,f,-1,FIN
|
||||
S 33,14,27,11,3,V,DIFP,*,-1,FIN
|
||||
S 34,20,7,11,3,V,DIFN,*,-1,FIN
|
||||
S 35,14,7,11,3,V,DIFN,*,-1,FIN
|
||||
S 36,20,3,42,2,V,ALU2,i0,-1,FIN
|
||||
T 37,17,5,*,TN_15_1,NOSYM,-1,FIN
|
||||
T 38,11,5,*,TN_15_1,NOSYM,-1,FIN
|
||||
T 39,17,25,*,TP_15_1,NOSYM,-1,FIN
|
||||
T 40,11,25,*,TP_15_1,NOSYM,-1,FIN
|
||||
S 41,20,43,2,1,V,ALU1,vdd,-1,FIN
|
||||
S 42,8,45,12,1,H,ALU1,vdd,-1,FIN
|
||||
S 43,20,33,10,2,V,ALU1,vdd,-1,FIN
|
||||
S 44,8,2,11,2,V,ALU1,vss,-1,FIN
|
||||
S 45,8,2,12,2,H,ALU1,vss,-1,FIN
|
||||
M 46,20,37,*,CONT_DIF_P,2,-1,FIN
|
||||
M 47,8,37,*,CONT_DIF_P,2,-1,FIN
|
||||
M 48,14,45,*,CONT_DIF_N,1,-1,FIN
|
||||
M 49,14,2,*,CONT_DIF_P,2,-1,FIN
|
||||
M 50,8,13,*,CONT_DIF_N,1,-1,FIN
|
||||
M 51,20,13,*,CONT_DIF_N,1,-1,FIN
|
||||
M 52,8,33,*,CONT_DIF_P,2,-1,FIN
|
||||
M 53,20,33,*,CONT_DIF_P,2,-1,FIN
|
||||
M 54,9,22,*,CONT_POLY,0,-1,FIN
|
||||
M 55,19,22,*,CONT_POLY,0,-1,FIN
|
||||
M 56,8,28,*,CONT_VIA,3,-1,FIN
|
||||
M 57,20,28,*,CONT_VIA,3,-1,FIN
|
||||
M 58,14,22,*,CONT_VIA,3,-1,FIN
|
||||
M 59,8,8,*,CONT_DIF_N,1,-1,FIN
|
||||
M 60,20,2,*,CONT_DIF_P,2,-1,FIN
|
||||
M 61,8,2,*,CONT_DIF_P,2,-1,FIN
|
||||
M 62,20,45,*,CONT_DIF_N,1,-1,FIN
|
||||
M 63,8,45,*,CONT_DIF_N,1,-1,FIN
|
||||
M 64,14,29,*,CONT_DIF_P,2,-1,FIN
|
||||
M 65,14,35,*,CONT_DIF_P,2,-1,FIN
|
||||
EOF
|
||||
.fi
|
||||
.SS Example 2
|
||||
This example is the physical design of a small circuit including
|
||||
three nand.
|
||||
.LP
|
||||
.nf
|
||||
V ALLIANCE 2.2 SETUP : 2
|
||||
H test_nand,P,-1,57,12/ 4/92,10,A JOUR,3,1,61,60,
|
||||
C 0,12,2,2,SUD,ALU2,a,IN,8,FIN
|
||||
C 1,24,2,2,SUD,ALU2,b,IN,21,FIN
|
||||
C 2,30,2,2,SUD,ALU2,c,IN,19,FIN
|
||||
C 3,42,2,2,SUD,ALU2,d,IN,31,FIN
|
||||
C 4,54,2,2,SUD,ALU2,s,OUT,36,FIN
|
||||
C 5,4,47,1,EST,ALU1,vdd,IN,39,FIN
|
||||
C 6,4,8,1,EST,ALU1,vss,IN,7,FIN
|
||||
I 7,9,7,I1,na2_y,NOSYM,33,FIN
|
||||
C 8,24,49,2,NORD,ALU2,i0,INOUT,11,NON
|
||||
C 9,18,49,2,NORD,ALU2,f,INOUT,18,FIN
|
||||
C 10,12,49,2,NORD,ALU2,i1,INOUT,13,NON
|
||||
C 11,24,7,2,SUD,ALU2,i0,INOUT,41,NON
|
||||
C 12,18,7,2,SUD,ALU2,f,INOUT,9,NON
|
||||
C 13,12,7,2,SUD,ALU2,i1,INOUT,40,NON
|
||||
C 14,27,47,8,EST,ALU1,vdd,INOUT,15,NON
|
||||
C 15,9,47,8,OUEST,ALU1,vdd,INOUT,46,NON
|
||||
C 16,9,9,8,OUEST,ALU1,vss,INOUT,45,NON
|
||||
C 17,27,9,8,EST,ALU1,vss,INOUT,16,NON
|
||||
I 18,27,7,I2,na2_y,NOSYM,35,FIN
|
||||
C 19,42,49,2,NORD,ALU2,i0,INOUT,22,NON
|
||||
C 20,36,49,2,NORD,ALU2,f,INOUT,29,FIN
|
||||
C 21,30,49,2,NORD,ALU2,i1,INOUT,24,NON
|
||||
C 22,42,7,2,SUD,ALU2,i0,INOUT,43,NON
|
||||
C 23,36,7,2,SUD,ALU2,f,INOUT,20,NON
|
||||
C 24,30,7,2,SUD,ALU2,i1,INOUT,42,NON
|
||||
C 25,45,47,8,EST,ALU1,vdd,INOUT,26,NON
|
||||
C 26,27,47,8,OUEST,ALU1,vdd,INOUT,14,NON
|
||||
C 27,27,9,8,OUEST,ALU1,vss,INOUT,17,NON
|
||||
C 28,45,9,8,EST,ALU1,vss,INOUT,27,NON
|
||||
I 29,45,7,I3,na2_y,NOSYM,-1,FIN
|
||||
C 30,60,49,2,NORD,ALU2,i0,INOUT,52,NON
|
||||
C 31,54,49,2,NORD,ALU2,f,INOUT,34,NON
|
||||
C 32,48,49,2,NORD,ALU2,i1,INOUT,51,NON
|
||||
C 33,60,7,2,SUD,ALU2,i0,INOUT,30,NON
|
||||
C 34,54,7,2,SUD,ALU2,f,INOUT,44,NON
|
||||
C 35,48,7,2,SUD,ALU2,i1,INOUT,32,NON
|
||||
C 36,63,47,8,EST,ALU1,vdd,INOUT,37,NON
|
||||
C 37,45,47,8,OUEST,ALU1,vdd,INOUT,25,NON
|
||||
C 38,45,9,8,OUEST,ALU1,vss,INOUT,28,NON
|
||||
C 39,63,9,8,EST,ALU1,vss,INOUT,38,NON
|
||||
S 40,12,2,5,2,V,ALU2,*,0,NON
|
||||
S 41,24,2,5,2,V,ALU2,*,1,NON
|
||||
S 42,30,2,5,2,V,ALU2,*,2,NON
|
||||
S 43,42,2,5,2,V,ALU2,*,3,NON
|
||||
S 44,54,2,5,2,V,ALU2,*,4,NON
|
||||
S 45,4,8,5,1,H,ALU1,*,6,NON
|
||||
S 46,4,47,5,1,H,ALU1,*,5,NON
|
||||
S 47,18,55,42,1,H,ALU1,x,53,NON
|
||||
S 48,36,60,12,1,H,ALU1,y,54,NON
|
||||
S 49,18,49,6,2,V,ALU2,*,12,NON
|
||||
S 50,36,49,11,2,V,ALU2,*,23,NON
|
||||
S 51,48,49,11,2,V,ALU2,*,55,NON
|
||||
S 52,60,49,6,2,V,ALU2,*,56,NON
|
||||
M 53,18,55,*,CONT_VIA,3,49,NON
|
||||
M 54,36,60,*,CONT_VIA,3,50,NON
|
||||
M 55,48,60,*,CONT_VIA,3,48,NON
|
||||
M 56,60,55,*,CONT_VIA,3,47,NON
|
||||
EOF
|
||||
.fi
|
||||
.SH SEE ALSO
|
||||
.BR Alliance (1),
|
||||
.BR alc (1),
|
||||
.BR MBK (1)
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
.\" $Id: catal.5,v 1.1 2002/09/24 08:44:43 czo Exp $
|
||||
.\" @(#)catal.2 2.11 91/08/22 ; Labo masi cao-vlsi; Author : Frederic Petrot
|
||||
.TH CATAL 5 "October 1, 1997" "ASIM/LIP6" "ALLIANCE FILE FORMATS"
|
||||
.if t \{\
|
||||
.so man1/alc_contents.mac
|
||||
.XS \n%
|
||||
.ti 0.2i
|
||||
catal
|
||||
.XE \}
|
||||
.SH NAME
|
||||
catal \- catalog file format
|
||||
.SH SYNOPSYS
|
||||
.nf
|
||||
.if n \{\
|
||||
.ft B \}
|
||||
.if t \{\
|
||||
.ft CR \}
|
||||
#include <mutnnn.h>
|
||||
$MBK_WORK_LIB/$MBK_CATAL_NAME
|
||||
($MBK_CATA_LIB)/$MBK_CATAL_NAME
|
||||
.ft R
|
||||
.fi
|
||||
.so man1/alc_origin.1
|
||||
.SH DESCRIPTION
|
||||
.TP
|
||||
Predefined libraries
|
||||
The environment variable \fBMBK_CATA_LIB\fP(1) defines several paths
|
||||
corresponding to the \fIAlliance\fP predefined cell libraries.
|
||||
Each library is in one unix directory.
|
||||
.RS
|
||||
.TP 20
|
||||
\fIsclib\fP
|
||||
standard cell library
|
||||
.TP 20
|
||||
\fIdplib\fP
|
||||
data-path compiler library
|
||||
.TP 20
|
||||
\fIgrlib\fP
|
||||
register file generator library
|
||||
.TP 20
|
||||
\fIbslib\fP
|
||||
barrel shifter generator library
|
||||
.TP 20
|
||||
\fIgalib\fP
|
||||
fast adder generator library
|
||||
.TP 20
|
||||
\fIrolib\fP
|
||||
high speed rom generator library
|
||||
.TP 20
|
||||
\fIralib\fP
|
||||
static ram generator library
|
||||
.PP
|
||||
Only the standart cell library \fBsclib\fP(1) is available in the Alliance 1.1
|
||||
release.
|
||||
.LP
|
||||
For each library, a special file named \fBCATAL\fP describes the library
|
||||
contents.
|
||||
This file must be in the same directory as the library cells.
|
||||
For the \fBAlliance\fP tools, the cells described in the predefined libraries
|
||||
are read only.
|
||||
.RE
|
||||
.TP
|
||||
The working library
|
||||
The environment variable \fBMBK_WORK_LIB\fP(1) defines the current working
|
||||
directory.
|
||||
Its default value is \fB.\fP (dot).
|
||||
This directory will contain the user cells, seen as read write by the
|
||||
\fIAlliance\fP tools.
|
||||
It is not necessary to describe all the user cells in a catalog file.
|
||||
But the user can locally define a catalog file for the working library.
|
||||
The local catalog file name is set by the environment variable
|
||||
\fBMBK_CATAL_NAME\fP(1), \fBCATAL\fP by default.
|
||||
\fIAlliance\fP will concatenate all catalog files of the predefined libraries
|
||||
and the optional catalog file of the working library to access the attributs
|
||||
of each cell.
|
||||
.TP
|
||||
Cells attributs
|
||||
A cell may be characterized by four attributs:
|
||||
.RS
|
||||
.TP 20
|
||||
\fBC\fP
|
||||
this attribut means that the cell is a leaf cell in the context of a recursive
|
||||
flatten, for either the layout or netlist view.
|
||||
The cell will not be flattened.
|
||||
.TP
|
||||
\fBG\fP
|
||||
this attribut means that the cell has an existing equivalent \fIGDS\fP or
|
||||
\fICIF\fP representation.
|
||||
It is used by the symbolic to real translation tool, \fBs2r\fP(1), to
|
||||
make direct replacements.
|
||||
.TP
|
||||
\fBF\fP
|
||||
this attribut means that the cell is used as a feed through by a router.
|
||||
For example, the standard cell router, \fBscr\fP(1), will use such cells to
|
||||
fill gaps in the cells rows.
|
||||
.TP
|
||||
\fBD\fP
|
||||
this attribut is used only in the user defined catalog.
|
||||
As the user is not allowed to delete a cell in a predefined library, it is
|
||||
possible to virtually remove a cell of a predefined library with the \fBD\fP
|
||||
attribut in the user defined catalog.
|
||||
.RE
|
||||
.SH EXAMPLE
|
||||
.ta 3n 6n 9n 12n 15n 18n 21n
|
||||
.nf
|
||||
.if n \{\
|
||||
.ft B \}
|
||||
.if t \{\
|
||||
.ft CR \}
|
||||
a2_y C
|
||||
a2p_y C
|
||||
a3_y C
|
||||
a3p_y C
|
||||
n1_y C
|
||||
na2_y C
|
||||
p1_y C
|
||||
tie_y C
|
||||
\&.
|
||||
\&.
|
||||
\&.
|
||||
p1_y G
|
||||
\&.
|
||||
\&.
|
||||
\&.
|
||||
tie_y F
|
||||
.ft R
|
||||
.fi
|
||||
.SH SEE ALSO
|
||||
.BR mbk (1),
|
||||
.BR sclib (1),
|
||||
.BR incatalog (3),
|
||||
.BR incatalogdelete (3),
|
||||
.BR incatalogfeed (3),
|
||||
.BR incataloggds (3),
|
||||
.BR MBK_CATA_LIB (1),
|
||||
.BR MBK_CATAL_NAME (1),
|
||||
.BR MBK_WORK_LIB (1).
|
||||
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
===================================================================
|
||||
Modification le : Tue Sep 24 10:44:33 CEST 2002
|
||||
Par : czo
|
||||
===================================================================
|
||||
|
||||
Update of /users/outil/alliance/cvsroot/alliance/src/mbk/man5
|
||||
In directory bip.lip6.fr:/users/soft5/newlabo/dev/alliance/src/mbk/man5
|
||||
|
||||
Log Message:
|
||||
Directory /users/outil/alliance/cvsroot/alliance/src/mbk/man5 added to the repository
|
||||
|
||||
|
||||
===================================================================
|
||||
|
||||
|
|
@ -0,0 +1,819 @@
|
|||
.\" $Id: prol.5,v 1.1 2002/09/24 08:44:44 czo Exp $
|
||||
.\" @(#)prol.5 2.11 91/08/22; Labo Cao-vlsi; Author : Frederic Petrot & Franck Wajsburt
|
||||
.TH PROL 5 "October 1, 1997" "ASIM/LIP6" "RDS FILE FORMATS"
|
||||
.SH NAME
|
||||
\fBprol\fP \- define the rules for symbolic to real layout translation
|
||||
.so man1/alc_origin.1
|
||||
.SH DESCRIPTION
|
||||
This file describes the rules used by the \fBmbk\fP(1) to \fBrds\fP translator.
|
||||
In the following file, symbolic layout objects are refered as \fBmbk\fP(1)
|
||||
objects, \fBmbk\fP(1) being the internal data structure that supports
|
||||
symbolic representation.
|
||||
On the other hand, \fBrds\fP is a data structure describing mainly rectangles,
|
||||
and is therefore used for real layout representation.
|
||||
.PP
|
||||
Some syntaxic remarques on the way to write the file follow.
|
||||
The case of identifiers is not significant, so NDIF is equivalent to NdiF.
|
||||
Comments are allowed anywhere in the file, using the \fIsharp\fP (#) as start of
|
||||
comment, and \fInewline\fP as end of comment.
|
||||
A line begining with a \fIsharp\fP will be ignored, and a line containing a
|
||||
\fIsharp\fP will be read up to the character preeceding it.
|
||||
A \fInewline\fP can be escaped using the \fIbackslash\fP (\) followed by
|
||||
the \fInewline\fP.
|
||||
If some character, spaces or tabs for example, follow the \fIbackslash\fP,
|
||||
chances are that a syntax error will be issued.
|
||||
.PP
|
||||
First, some important process parameters are needed, the physical grid step,
|
||||
that is the least common multiple of all the technologies values in terms of
|
||||
layout distances, and the
|
||||
.ie t \(*l,
|
||||
.el lambda,
|
||||
computed from a careful observation of the process design rules.
|
||||
.br
|
||||
Then, a set of tables is needed, to describe how to translate a symbolic
|
||||
object, belonging to the \fBmbk\fP(1) world, and a set of layout rectangles,
|
||||
in \fBrds\fP.
|
||||
.br
|
||||
Each table has a special meaning, and its parametrization exend beeing not
|
||||
full, some borders are to be evocated.
|
||||
Several type of table exists indeed.
|
||||
Some are needed for object translation, others for post treatment
|
||||
parametrization, others to define cif or gds identifiers regarding rds ones.
|
||||
.br
|
||||
Many things seem to be parametrizable, but in fact, mostly, if not only,
|
||||
numbers, names in cif and gds translation tables, and boolean value in post
|
||||
treatement may be changed without problems.
|
||||
.PP
|
||||
For any table, if some layer is not applicable, it can simply be omitted.
|
||||
The default action is `do nothing', or use a value of 0.0 for all entries.
|
||||
.SH LAYERS AND PATTERNS
|
||||
Since the goal of this file is to allow translation from \fBmbk\fP(1)
|
||||
to \fBrds\fP, the meaning of the layers in both representation shall be known.
|
||||
.br
|
||||
\s+2\fBMbk layers\fP\s-2
|
||||
.RS 5
|
||||
.TP 20
|
||||
NWELL
|
||||
minimum width 4 ; N-well.
|
||||
.TP 20
|
||||
PWELL
|
||||
minimum width 4 ; P-well.
|
||||
.TP 20
|
||||
NTIE
|
||||
minimum width 2 ; N diffusion for polarisation.
|
||||
.TP 20
|
||||
PTIE
|
||||
minimum width 2 ; P diffusion for polarisation.
|
||||
.TP 20
|
||||
NDIF
|
||||
minimum width 2 ; N diffusion for transistor.
|
||||
.TP 20
|
||||
PDIF
|
||||
minimum width 2 ; P diffusion for transistor.
|
||||
.TP 20
|
||||
NTRANS
|
||||
minimum width 1 (gate width) ; N transistor.
|
||||
.TP 20
|
||||
PTRANS
|
||||
minimum width 1 (gate width) ; P transistor.
|
||||
.TP 20
|
||||
POLY
|
||||
minimum width 1 ; polysilicon, not transistor gate.
|
||||
.TP 20
|
||||
ALU1
|
||||
minimum width 1 ; first level of metal.
|
||||
.TP 20
|
||||
ALU2
|
||||
minimum width 2 ; second level of metal.
|
||||
.TP 20
|
||||
ALU3
|
||||
minimum width 3 ; third level of metal (unused).
|
||||
.TP 20
|
||||
TPOLY
|
||||
minimum width 1 ; through route for POLY.
|
||||
.TP 20
|
||||
TALU1
|
||||
minimum width 1 ; through route for ALU1.
|
||||
.TP 20
|
||||
TALU2
|
||||
minimum width 2 ; through route for ALU2.
|
||||
.TP 20
|
||||
TALU3
|
||||
minimum width 3 ; through route for ALU3 (unused).
|
||||
.RE
|
||||
\s+2\fBMbk patterns\fP\s-2
|
||||
.RS 5
|
||||
.TP 20
|
||||
CONT_POLY
|
||||
cut pattern from ALU1 to POLY
|
||||
.TP 20
|
||||
CONT_VIA
|
||||
cut pattern from ALU1 to ALU2
|
||||
.TP 20
|
||||
CONT_VIA2
|
||||
cut pattern from ALU2 to ALU3
|
||||
.TP 20
|
||||
CONT_DIF_N
|
||||
cut pattern from ALU1 to NDIF
|
||||
.TP 20
|
||||
CONT_DIF_P
|
||||
cut pattern from ALU1 to PDIF
|
||||
.TP 20
|
||||
CONT_BODY_N
|
||||
cut pattern from ALU1 to NTIE
|
||||
.TP 20
|
||||
CONT_BODY_P
|
||||
cut pattern from ALU1 to PTIE
|
||||
.TP 20
|
||||
C_X_N
|
||||
corner primitive for L or S shaped N transistor
|
||||
.TP 20
|
||||
C_X_P
|
||||
corner primitive for L or S shaped P transistor
|
||||
.RE
|
||||
\s+2\fBRds layers\fP\s-2
|
||||
.RS 5
|
||||
.TP 20
|
||||
RDS_NWELL
|
||||
N-well (or N-tub), bulk for P transistors.
|
||||
.TP 20
|
||||
RDS_PWELL
|
||||
P-well (or P-tub), bulk for N transistors.
|
||||
.TP 20
|
||||
RDS_NDIF
|
||||
use for symbolic extractor as equivalent of NDIF.
|
||||
.TP 20
|
||||
RDS_PDIF
|
||||
use for symbolic extractor as equivalent of PDIF.
|
||||
.TP 20
|
||||
RDS_NTIE
|
||||
use for symbolic extractor as equivalent of NTIE.
|
||||
.TP 20
|
||||
RDS_PTIE
|
||||
use for symbolic extractor as equivalent of PTIE.
|
||||
.TP 20
|
||||
RDS_POLY
|
||||
polysillicon run, for cell internal wirering.
|
||||
.TP 20
|
||||
RDS_GATE
|
||||
transistor polysillicon, for gate.
|
||||
.TP 20
|
||||
RDS_TPOLY
|
||||
polysillicon feed through.
|
||||
Indicate to a router that a track is free of polysillicon.
|
||||
.TP 20
|
||||
RDS_CONT
|
||||
hole in the isolating layer between polysillicon or active area and
|
||||
first metal level.
|
||||
.TP 20
|
||||
RDS_ALU1
|
||||
first metal level run.
|
||||
.TP 20
|
||||
RDS_TALU1
|
||||
first metal level feed through.
|
||||
Indicates to a router that a track is free of first metal level.
|
||||
.TP 20
|
||||
RDS_VIA1
|
||||
hole in the isolating layer between first metal level and second metal level.
|
||||
.TP 20
|
||||
RDS_ALU2
|
||||
second metal level run.
|
||||
.TP 20
|
||||
RDS_TALU2
|
||||
second metal level feed through.
|
||||
Indicate to a router that a track is free of second metal level.
|
||||
.TP 20
|
||||
RDS_VIA2
|
||||
hole in the isolating layer between second metal level and third metal level.
|
||||
.TP 20
|
||||
RDS_ALU3
|
||||
third metal level run.
|
||||
.TP 20
|
||||
RDS_TALU3
|
||||
third metal level feed through.
|
||||
Indicate to a router that a track is free of third metal level.
|
||||
.TP 20
|
||||
RDS_ALU4
|
||||
fourth metal.
|
||||
(Used only for GaAs designs.)
|
||||
.TP 20
|
||||
RDS_VIA3
|
||||
hole in the isolating layer between third metal level and fourth metal level.
|
||||
(Used only for GaAs designs.)
|
||||
.TP 20
|
||||
RDS_ACTIV
|
||||
active area dropped in N or P implant to build transistors.
|
||||
.TP 20
|
||||
RDS_NIMP
|
||||
implant area, (sometime known as N select), for N transistors.
|
||||
.TP 20
|
||||
RDS_PIMP
|
||||
implant area, (sometime known as P select), for P transistors.
|
||||
.TP 20
|
||||
RDS_CPAS
|
||||
passivation, used in pads.
|
||||
.TP 20
|
||||
RDS_USER0
|
||||
user defined purpose layer.
|
||||
(May be used for DRC logical operations.)
|
||||
.TP 20
|
||||
RDS_USER1
|
||||
user defined purpose layer.
|
||||
(May be used for DRC logical operations.)
|
||||
.TP 20
|
||||
RDS_USER2
|
||||
user defined purpose layer.
|
||||
(May be used for DRC logical operations.)
|
||||
.TP 20
|
||||
RDS_REF
|
||||
virtual layer for the representation of symbolic references
|
||||
.TP 20
|
||||
RDS_ABOX
|
||||
virtual layer needed to indicate the abutment box of a model.
|
||||
.TP 20
|
||||
RDS_DEFAULT
|
||||
default layer, shall never appear anywhere.
|
||||
.RE
|
||||
.SH FILE DESCRIPTION
|
||||
The following lines describe the file, entry by entry, specifying what is
|
||||
expected.
|
||||
.TP 20
|
||||
\s+2\fBPhysical grid\fP\s-2
|
||||
.ie t \{\
|
||||
.ta 9m
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ta 25m
|
||||
.ft B \}
|
||||
DEFINE PHYSICAL_GRID .5
|
||||
.ft R
|
||||
.br
|
||||
This statement defines the minimum grid spacing enforced by the foundry.
|
||||
.TP
|
||||
\s+2\fBLambda\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
DEFINE LAMBDA 1
|
||||
.ft R
|
||||
.br
|
||||
This defines the value of the
|
||||
.ie n lambda
|
||||
.el \(*l
|
||||
in
|
||||
.ie n microns.
|
||||
.el \(*m.
|
||||
This value, like any other one in the rest of the file \fImust\fP be a multiple
|
||||
of the
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
PHYSICAL_GRID\fR.
|
||||
.TP
|
||||
\s+2\fBSegment translation table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE MBK_TO_RDS_SEGMENT\fR
|
||||
.br
|
||||
This table contains all the informations needed to translate a symbolic
|
||||
segment of a given layer onto one, two or three real rectangles of
|
||||
specified layers.
|
||||
An example of this table is given below, with values needed for a
|
||||
technology where one
|
||||
.ie n lambda
|
||||
.el \(*l
|
||||
is equal to 1.05
|
||||
.ie microns
|
||||
.el \(*m
|
||||
and the design grid is set to 0.15
|
||||
.ie n microns.
|
||||
.el \(*m.
|
||||
.PP
|
||||
.ie n \{\
|
||||
.ft B \}
|
||||
.el \{\
|
||||
.ft CR \}
|
||||
.nf
|
||||
TABLE MBK_TO_RDS_SEGMENT
|
||||
|
||||
NWELL RDS_NWELL VW 3.15 6.30 0.0 ALL
|
||||
NDIF RDS_ACTIV VW 0.60 -0.90 0.0 ALL \\
|
||||
RDS_NIMP VW 2.10 2.10 0.0 ALL
|
||||
PDIF RDS_ACTIV VW 0.60 -0.90 0.0 ALL \\
|
||||
RDS_PIMP VW 2.10 2.10 0.0 ALL
|
||||
NTIE RDS_ACTIV VW 0.60 -0.90 0.0 ALL \\
|
||||
RDS_NIMP VW 1.20 0.30 0.0 ALL
|
||||
PTIE RDS_ACTIV VW 0.60 -0.90 0.0 ALL \\
|
||||
RDS_PIMP VW 1.20 0.30 0.0 ALL
|
||||
NTRANS RDS_GATE VW 0.00 0.15 0.0 ALL \\
|
||||
RDS_ACTIV VW -1.50 4.35 0.0 ALL \\
|
||||
RDS_NIMP VW 0.00 7.35 0.0 ALL
|
||||
PTRANS RDS_GATE VW 0.00 0.15 0.0 ALL \\
|
||||
RDS_ACTIV VW -1.50 4.35 0.0 ALL \\
|
||||
RDS_PIMP VW 0.00 7.35 0.0 ALL
|
||||
POLY RDS_POLY VW 0.60 0.15 0.0 ALL
|
||||
ALU1 RDS_ALU1 VW 0.90 0.75 0.0 ALL
|
||||
ALU2 RDS_ALU2 VW 0.90 -0.30 0.0 ALL
|
||||
TPOLY RDS_TPOLY VW 0.60 0.15 0.0 ALL
|
||||
TALU1 RDS_TALU1 VW 0.90 0.75 0.0 ALL
|
||||
TALU2 RDS_TALU2 VW 0.90 -0.30 0.0 ALL
|
||||
|
||||
END
|
||||
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
The first column is the \fBmbk\fP(1) layer name to be translated, then there
|
||||
one or more groups of 6 columns each.
|
||||
For each physical rectangle, there are 3 parameters :
|
||||
.br
|
||||
\- rds layer name
|
||||
.br
|
||||
\- One of \fBVW\fR, \fBLCW\fR, \fBRCW\fR that indicates the `type' of segment
|
||||
to be generated
|
||||
.br
|
||||
\- physical length extension: \fIDLR\fP
|
||||
.br
|
||||
\- physical width oversize: \fIDWR\fP
|
||||
.br
|
||||
\- offset from symbolic axis: \fIOFFSET\fP
|
||||
.br
|
||||
\- tools for which the generated rectangle is applicable:
|
||||
\fBALL\fR, \fBDRC\fR (for the symbolic design rule checker,
|
||||
see \fBdruc\fR(1)), \fBEXT\fR
|
||||
(for the symbolic extractor, see \fBlynx\fR(1))
|
||||
These parameters are meant regarding the symbolic segment.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBConnectors translation table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE MBK_TO_RDS_CONNECTOR\fR
|
||||
.br
|
||||
This table contains all the informations needed to translate a symbolic
|
||||
connector of a given layer onto one \fIsingle\fP real rectangle.
|
||||
.br
|
||||
An example of this table is given below, with values needed for a
|
||||
technology where one
|
||||
.ie n lambda
|
||||
.el \(*l
|
||||
is equal to 1.05
|
||||
.ie microns
|
||||
.el \(*m
|
||||
and the design grid is set to 0.15
|
||||
.ie n micron.
|
||||
.el \(*m.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE MBK_TO_RDS_CONNECTOR
|
||||
|
||||
POLY RDS_POLY 0.6 0.15
|
||||
ALU1 RDS_ALU1 0.9 0.75
|
||||
ALU2 RDS_ALU2 0.9 -0.3
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
One symbolic connector is translated into one
|
||||
physical rectangle using 3 parameters :
|
||||
.br
|
||||
\- rds layer name
|
||||
.br
|
||||
\- physical width oversize: \fIDWR\fP
|
||||
.br
|
||||
\- physical extension on each side of the abutment box: \fIDER\fP
|
||||
|
||||
.RE
|
||||
.RS 20
|
||||
It is discouraged to use active or well layers as connectors while
|
||||
designing.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBVias translation table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE MBK_TO_RDS_VIA\fR
|
||||
.br
|
||||
This table contains all the informations needed to translate a symbolic
|
||||
via of a given layer onto one to four real rectangles of user
|
||||
specified layers.
|
||||
An example of this table is given below, with values needed for a
|
||||
technology where one
|
||||
.ie n lambda
|
||||
.el \(*l
|
||||
is equal to 1.05
|
||||
.ie microns
|
||||
.el \(*m
|
||||
and the design grid is set to 0.15
|
||||
.ie n micron.
|
||||
.el \(*m.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE MBK_TO_RDS_VIA
|
||||
|
||||
CONT_BODY_N RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_NIMP 4.5
|
||||
CONT_BODY_P RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_PIMP 4.5
|
||||
CONT_DIF_N RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_NIMP 6.3
|
||||
CONT_DIF_P RDS_ALU1 3 RDS_CONT 1.5 RDS_ACTIV 3.3 RDS_PIMP 6.3
|
||||
CONT_POLY RDS_ALU1 3 RDS_CONT 1.5 RDS_POLY 3
|
||||
CONT_VIA RDS_ALU1 3 RDS_VIA1 1.5 RDS_ALU2 3
|
||||
CONT_VIA2
|
||||
C_X_N RDS_GATE 1.2 RDS_ACTIV 5.4 RDS_NIMP 8.4
|
||||
C_X_P RDS_GATE 1.2 RDS_ACTIV 5.4 RDS_PIMP 8.4
|
||||
|
||||
END
|
||||
|
||||
.fi
|
||||
.br
|
||||
.ft R
|
||||
.RS 20
|
||||
This table describes how to translate one symbolic via,
|
||||
to 2, 3 or 4 physical rectangles.
|
||||
The table is defined as follow :
|
||||
The first column is the \fBmbk\fP(1) via name to translate, then there are
|
||||
4 groups of 2 columns each, which correspond to four potential targets
|
||||
\fBrds\fP rectangles of user specified layer.
|
||||
In one group the first column is the \fBrds\fP layer name, the second one is
|
||||
the \fBrds\fP layer width.
|
||||
The rectangle is centered on the contact coordinates, and expands in the four
|
||||
direction of half the given width value.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBDenotching values table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE S2R_OVERSIZE_DENOTCH\fR
|
||||
.br
|
||||
This table contains the oversize value needed to erase notches.
|
||||
All the rectangles of the same \fBrds\fP layer are oversized by this value
|
||||
and then merged alltogether and undersized by the same value.
|
||||
An example of this table is given below.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE S2R_OVERSIZE_DENOTCH
|
||||
|
||||
RDS_NWELL 3.00
|
||||
RDS_POLY 0.75
|
||||
RDS_GATE 0.75
|
||||
RDS_ALU1 0.75
|
||||
RDS_ALU2 0.75
|
||||
RDS_ACTIV 1.05
|
||||
RDS_NIMP 2.55
|
||||
RDS_PIMP 2.55
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
For some \fBrds\fP layers, like RDS_NWELL, RDS_NIMP and RDS_PIMP, two
|
||||
rectangles distant from less or equal the minimun spacing design
|
||||
rule must be merged in a single one.
|
||||
In this case, the oversize value is equal to the minimum spacing rule
|
||||
between two edges of the same layer divided by 2.
|
||||
.br
|
||||
Some other \fBrds\fP layers, like RDS_ALU1, ..., must not be merged.
|
||||
In this case, the oversize value is equal to the minimum spacing rule
|
||||
between two edges of the same layer divided by 2, minus the physical
|
||||
grid.
|
||||
.br
|
||||
Some layers never create notch, such as RDS_VIA1 or RDS_CONT, so
|
||||
the oversize value is null.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBRing width\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE S2R_BLOC_RING_WIDTH\fR
|
||||
.br
|
||||
s2r must merge segments to erase notches even if those segments
|
||||
are in two different hierarchical level blocs, for example, two
|
||||
blocs abuted side to side.
|
||||
So, it must be able to fetch segments inside blocs.
|
||||
It is not needed to flatten the entire bloc, only a ring is
|
||||
necessary. The ring is computed from the abutment box edges or from
|
||||
the envelop edges of the overlapping blocs.
|
||||
.br
|
||||
An example of this table is given below.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE S2R_BLOC_RING_WIDTH
|
||||
|
||||
RDS_NWELL 6
|
||||
RDS_POLY 1.8
|
||||
RDS_GATE 1.8
|
||||
RDS_ALU1 1.8
|
||||
RDS_ALU2 1.8
|
||||
RDS_ACTIV 2.4
|
||||
RDS_NIMP 1.8
|
||||
RDS_PIMP 1.8
|
||||
|
||||
END
|
||||
.fi
|
||||
.br
|
||||
.ft R
|
||||
.RS 20
|
||||
The normal ring width is the minimum spacing design rule between two
|
||||
segments of the same rds layer.
|
||||
.br
|
||||
A zero means that no ring is wanted for that rds layer.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBMinimum real layer width design rule\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE S2R_MINIMUM_LAYER_WIDTH\fR
|
||||
.br
|
||||
This table contains the minimum width of each rds layer.
|
||||
It is used by s2r to avoid creating rectangles below the minimum
|
||||
required, during the merge operation.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE S2R_MINIMUM_LAYER_WIDTH
|
||||
RDS_NWELL 6
|
||||
RDS_POLY 1.2
|
||||
RDS_GATE 1.2
|
||||
RDS_ALU1 1.8
|
||||
RDS_ALU2 1.8
|
||||
RDS_ACTIV 1.2
|
||||
RDS_NIMP 2.7
|
||||
RDS_PIMP 2.7
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
A zero can be specified, when it is sure that this layer is
|
||||
not to be merged, because not treated by s2r.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBPost treatment configuration table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE S2R_POST_TREAT\fR
|
||||
.br
|
||||
This table indicates to s2r which rds layers must be post-processed.
|
||||
Precicely if a layer is only to be be translated, or translated
|
||||
and then post-processed.
|
||||
Translated means translate and fit from symbolic to real, and
|
||||
postreated that it should also be merged with its neighbours.
|
||||
For example, it's not necesary to merge cut layers such as RDS_CONT.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE S2R_POST_TREAT
|
||||
|
||||
RDS_NWELL TREAT NULL
|
||||
RDS_PWELL NOTREAT NULL
|
||||
RDS_NDIF NOTREAT NULL
|
||||
RDS_PDIF NOTREAT NULL
|
||||
RDS_NTIE NOTREAT NULL
|
||||
RDS_PTIE NOTREAT NULL
|
||||
RDS_POLY TREAT NULL
|
||||
RDS_GATE TREAT NULL
|
||||
RDS_TPOLY NOTREAT NULL
|
||||
RDS_CONT NOTREAT NULL
|
||||
RDS_ALU1 TREAT NULL
|
||||
RDS_TALU1 NOTREAT NULL
|
||||
RDS_VIA1 NOTREAT NULL
|
||||
RDS_ALU2 TREAT NULL
|
||||
RDS_TALU2 NOTREAT NULL
|
||||
RDS_VIA2 NOTREAT NULL
|
||||
RDS_ALU3 NOTREAT NULL
|
||||
RDS_TALU3 NOTREAT NULL
|
||||
RDS_ACTIV TREAT NULL
|
||||
RDS_NIMP TREAT RDS_PIMP
|
||||
RDS_PIMP TREAT RDS_NIMP
|
||||
RDS_REF NOTREAT NULL
|
||||
RDS_ABOX NOTREAT NULL
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
If set to NOTREAT, the first parameter indicates a translation.
|
||||
If set to TREAT, then the layer is translated and then post-treated
|
||||
.br
|
||||
To post-process creates problems with the implantation layers.
|
||||
It is possible to have a good symbolic layout (no symbolic design
|
||||
rule errors), and have a resulting layout with DRC violations,
|
||||
created by a poor post-processing.
|
||||
It is due to the fact that these layers do not exist in symbolic,
|
||||
so it is not possible to apply them drc verifications.
|
||||
If two rectangles of these layers are too close (less than a
|
||||
given value), they must be merged.
|
||||
Generally, there is no problem, but when corners are too near it is
|
||||
impossible to merge with the classical algorithm,
|
||||
\fIexpand\fP, \fImerge\fP, then \fIshrink\fP.
|
||||
.br
|
||||
Rectangles, known as scotches, are created to merge anyway,
|
||||
like this :
|
||||
.RE
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \fB
|
||||
.nf
|
||||
+--------+ +--------+ +-----+--+
|
||||
|////////| |////////| |/////|//|
|
||||
|//+--+//| |//+--+//| |//+--|//|
|
||||
|//| |//| gives -> |//| |//| or -> |//| |//|
|
||||
|//+--+//| +-----------+ |//+--|//|
|
||||
|////////| |///////////| |/////|//|
|
||||
+--------+ +--------+//| +-----|//|
|
||||
^ +--------+ |//|-----+ |//+--------+
|
||||
| |////////| |//|/////| |///////////|
|
||||
o--->|//+--+//| |//|--+//| +-----------+
|
||||
| |//| |//| |//| |//| |//| |//|
|
||||
implant |//+--+//| |//|--+//| |//|--+//|
|
||||
areas |////////| |//|/////| |//|/////|
|
||||
+--------+ +--+-----+ +--+-----+
|
||||
.fi
|
||||
.ft R
|
||||
.RS 20
|
||||
A N implantation layer should not overlap a P implantation one.
|
||||
We say that P implantations and N implantations are
|
||||
complementary. A scotch will not be created if it intersects with
|
||||
any of the rectangles of the complementary layers.
|
||||
.br
|
||||
If a record contains in the second field a rds layer different from
|
||||
NULL, it indicates the complementary layer.
|
||||
This implies that if it is a layer that might need scotches
|
||||
the algorithm will try not to intersect with it when creating
|
||||
scotches.
|
||||
.RE
|
||||
.TP 20
|
||||
\s+2\fBExtraction graph table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE LYNX_GRAPH\fR
|
||||
.br
|
||||
This table gives the connexion graph between the rds layers.
|
||||
For each layer, the list of the connectable layers is written.
|
||||
Up to now, the extractor works only on translated symbolic layout.
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE LYNX_GRAPH
|
||||
|
||||
RDS_NDIF RDS_CONT RDS_NDIF
|
||||
RDS_PDIF RDS_CONT RDS_PDIF
|
||||
RDS_NTIE RDS_CONT RDS_NTIE
|
||||
RDS_PTIE RDS_CONT RDS_PTIE
|
||||
RDS_POLY RDS_CONT RDS_GATE RDS_POLY
|
||||
RDS_GATE RDS_POLY RDS_GATE
|
||||
RDS_CONT RDS_PDIF RDS_NDIF RDS_POLY RDS_PTIE RDS_NTIE RDS_ALU1 RDS_CONT
|
||||
RDS_ALU1 RDS_CONT RDS_VIA1 RDS_ALU1 RDS_REF
|
||||
RDS_REF RDS_CONT RDS_VIA1 RDS_ALU1 RDS_REF
|
||||
RDS_VIA1 RDS_ALU1 RDS_ALU2 RDS_VIA1
|
||||
RDS_ALU2 RDS_VIA1 RDS_VIA2 RDS_ALU2
|
||||
RDS_VIA2 RDS_ALU2 RDS_ALU3 RDS_VIA2
|
||||
RDS_ALU3 RDS_VIA2 RDS_ALU3
|
||||
|
||||
END
|
||||
.fi
|
||||
.TP 20
|
||||
\s+2\fBExtraction capacitance table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE LYNX_CAPA\fR
|
||||
.br
|
||||
This table gives the capacitance in picofarad per square lambda of each
|
||||
layer.
|
||||
The extractor computes only substrat capacitances.
|
||||
The capacitances associated with gate or drain or sources are not computed.
|
||||
On the other hand the transistor sizes (area, perimeter) are computed.
|
||||
(This is to ensure compatibility with Spice).
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE LYNX_CAPA
|
||||
|
||||
RDS_POLY 1.00e-04
|
||||
RDS_ALU1 0.50e-04
|
||||
RDS_ALU2 0.25e-04
|
||||
|
||||
END
|
||||
.fi
|
||||
.TP 20
|
||||
\s+2\fBCif translation table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE CIF_LAYER\fR
|
||||
.br
|
||||
This table gives the equivalence between internal layers and their
|
||||
representation in the \fBcif\fP file format.
|
||||
A table may look like that (for MOSIS layers):
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE CIF_LAYER
|
||||
|
||||
RDS_NWELL CWN
|
||||
RDS_PWELL CWP
|
||||
RDS_ACTIV CAA
|
||||
RDS_NIMP CSN
|
||||
RDS_PIMP CSP
|
||||
RDS_POLY CPG
|
||||
RDS_GATE CPG
|
||||
RDS_CONT CCA
|
||||
RDS_ALU1 CMF
|
||||
RDS_VIA1 CVA
|
||||
RDS_ALU2 CMS
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.TP 20
|
||||
\s+2\fBGds translation table\fP\s-2
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
TABLE GDS_LAYER\fR
|
||||
.br
|
||||
This table gives the equivalence between internal layers and there
|
||||
representation in the \fBgds\fP file.
|
||||
A table may look like that (for CMP layers):
|
||||
.PP
|
||||
.ie t \{\
|
||||
.ft CR \}
|
||||
.el \{\
|
||||
.ft B \}
|
||||
.nf
|
||||
TABLE GDS_LAYER
|
||||
|
||||
RDS_NWELL 1
|
||||
RDS_POLY 11
|
||||
RDS_GATE 11
|
||||
RDS_CONT 16
|
||||
RDS_ALU1 17
|
||||
RDS_VIA1 18
|
||||
RDS_ALU2 19
|
||||
RDS_ACTIV 2
|
||||
RDS_NIMP 12
|
||||
RDS_PIMP 14
|
||||
RDS_CPAS 20
|
||||
|
||||
END
|
||||
.fi
|
||||
.ft R
|
||||
.SH SEE ALSO
|
||||
Insights on the symbolic to real translation process are available in
|
||||
the file \fBmapping.ps\fR
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
|
|
@ -0,0 +1,283 @@
|
|||
.\" $Id: vbe.5,v 1.1 2002/09/24 08:44:44 czo Exp $
|
||||
.\" @(#)VBE.5 1.0 Jan 28 1992 UPMC ; VUONG H.N.
|
||||
.TH VBE 5 "October 1, 1997" "ASIM/LIP6" "VHDL subset of ASIM/LIP6/CAO-VLSI lab."
|
||||
|
||||
.SH NAME
|
||||
.PP
|
||||
\fBvbe\fP
|
||||
.br
|
||||
VHDL behavioural subset.
|
||||
|
||||
.so man1/alc_origin.1
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
This document describes the ALLIANCE VHDL subset for behavioural data
|
||||
flow descriptions.
|
||||
|
||||
.PP
|
||||
\fBCONCURRENT STATEMENTS\fP
|
||||
.br
|
||||
In a data flow architecture only concurrent statements (except \fIprocess\fP)
|
||||
are supported. All sequential statements including loops, signal assignment,
|
||||
etc .. are to be banished.
|
||||
|
||||
.PP
|
||||
Allowed concurrent statements are:
|
||||
.RS
|
||||
simple signal assignment
|
||||
.br
|
||||
conditional signal assignment
|
||||
.br
|
||||
selected signal assignment
|
||||
.br
|
||||
concurrent assert statement
|
||||
.br
|
||||
block statement
|
||||
.RE
|
||||
|
||||
.PP
|
||||
\fBBUSES\fP
|
||||
.br
|
||||
When using concurrent statements, an ordinary signal can be assigned only once.
|
||||
The value of the signal must be explicitly defined by the signal assignment
|
||||
(for example, in a selected signal assignment the value of the target signal
|
||||
is to be defined for \fBevery\fP value that the select expression can take).
|
||||
|
||||
.PP
|
||||
The above constraint may be felt as a hard restriction when designing
|
||||
distributed controled hardware (precharged line, distributed multiplexer,
|
||||
etc ...). To hurdle this, VHDL uses a special feature: guarded-resolved signals.
|
||||
|
||||
.PP
|
||||
A resolved signal is a signal declared with a resolved subtype (see vhdl(5)).
|
||||
A resolved subtype is a type combined with a resolution function. A resolved
|
||||
signal can be assigned by multiple signal assignments. Depending on the value
|
||||
of each driver, the resolution function determines the effective value of the
|
||||
signal.
|
||||
|
||||
.PP
|
||||
A guarded signal is a resolved signal with drivers that can be disconected.
|
||||
A guarded signal must be assigned inside a \fIblock\fP statement through a
|
||||
\fIguarded\fP signal assignment.
|
||||
|
||||
.PP
|
||||
A distributed multiplexer may be described as :
|
||||
.nf
|
||||
|
||||
signal Distributed_Mux : mux_bit bus;
|
||||
|
||||
begin
|
||||
|
||||
first_driver_of_mux : block (Sel1 = '1')
|
||||
begin
|
||||
Distributed_Mux <= guarded Data1;
|
||||
end block;
|
||||
|
||||
second_driver_of_mux : block (Sel2 = '1')
|
||||
begin
|
||||
Distributed_Mux <= guarded Data2;
|
||||
end block;
|
||||
|
||||
.fi
|
||||
|
||||
.PP
|
||||
\fBLATCHES and REGISTERS\fP
|
||||
.br
|
||||
Sequential elements must be explicitly declared using the type \fIreg_bit\fP
|
||||
or \fIreg_vector\fP (and must be of kind \fIregister\fP). A sequential element
|
||||
must be assigned inside a \fIblock\fP statement by a \fIguarded\fP signal
|
||||
assignment.
|
||||
|
||||
.PP
|
||||
Rising edge triggered D flip flop :
|
||||
.nf
|
||||
|
||||
signal Reg : reg_bit register;
|
||||
|
||||
begin
|
||||
|
||||
flip_flop : block (ck = '1' and not ck'STABLE)
|
||||
begin
|
||||
Reg <= guarded Din;
|
||||
end block;
|
||||
.fi
|
||||
|
||||
.PP
|
||||
Level sensitive latch:
|
||||
.nf
|
||||
|
||||
signal Reg : reg_bit register;
|
||||
|
||||
begin
|
||||
|
||||
latch : block (ck = '1')
|
||||
begin
|
||||
Lat <= guarded Din;
|
||||
end block;
|
||||
.fi
|
||||
|
||||
.PP
|
||||
In both cases, the guard expression must depend only on one signal if the
|
||||
description is to be processed by the logic synthetizer (bop + scmap).
|
||||
|
||||
.PP
|
||||
The following operators are only supported: \fBnot, and, or, xor, nor, nand,
|
||||
&, =, /=\fP
|
||||
|
||||
.PP
|
||||
They can be applied on all types supported by the subset. Other standard VHDL
|
||||
operators (+, -, >, <, ...) have not been implemented in the present release.
|
||||
|
||||
.\" .PP
|
||||
.\" \fBTIMING\fP
|
||||
.\" .br
|
||||
.\" A VHDL description can be used for:
|
||||
.\" .RS
|
||||
.\" a) validation of a specification (behavioural)
|
||||
.\" .br
|
||||
.\" b) direct synthesis of hardware (behavioural)
|
||||
.\" .br
|
||||
.\" c) validation of a structural netlist
|
||||
.\" .RE
|
||||
.\"
|
||||
.\" .PP
|
||||
.\" Detailed timing information is not available at design time (cases a and b).
|
||||
.\" .PP
|
||||
.\" For an extracted netlist (case c) the detailed timing analysis is performed
|
||||
.\" by a specific tool: the static timing analyser TAS (not delivered in the
|
||||
.\" present version of ALLIANCE).
|
||||
.\"
|
||||
.\" .PP
|
||||
.\" Thus, timing specification is not supported by the ALLIANCE VHDL subset.
|
||||
.\" Simulation is performed in zero delay mode.
|
||||
|
||||
.PP
|
||||
\fBTIMING\fP
|
||||
.br
|
||||
Timing information can be specified in behavioural descriptions using
|
||||
\fIafter clauses\fP. However, those delays are currently only used for
|
||||
simulation. \fIAfter clauses\fP are supported but not used for synthesis
|
||||
and formal proof.
|
||||
|
||||
.PP
|
||||
\fIAfter clauses\fP in block statements (for guarded signal assignments)
|
||||
are not supported for sequential elements (signals of kind register), but
|
||||
supported for bus elements (signals of kind bus). This is because the VHDL
|
||||
default \fIdisconnection time\fP is null and this can generate
|
||||
unexpected behavior for sequential elements.
|
||||
|
||||
.PP
|
||||
In selected signal assignment, only uniform delays are supported
|
||||
(the same \fIAfter clause\fP in all assignments).
|
||||
|
||||
.PP
|
||||
\fITransport option\fP is not supported. All delays are inertial delays.
|
||||
.PP
|
||||
\fBASSERT STATEMENT\fP
|
||||
.br
|
||||
Only two severity levels are supported in concurrent
|
||||
assert statements:
|
||||
.TP 15
|
||||
\fBwarning\fP
|
||||
print a warning message if the assert condition is not satisfied.
|
||||
.TP 15
|
||||
\fBerror\fP
|
||||
print an error message if the assert condition is not satisfied. Then, stop
|
||||
the simulation.
|
||||
|
||||
.PP
|
||||
Assert statements are ignored by the logic synthesis tool.
|
||||
|
||||
.PP
|
||||
\fBDON'T CARE\fP
|
||||
.br
|
||||
A special feature has been introduced in order to allow "don't care"
|
||||
specification when the logic synthtizer is targeted (\fB Beware : this feature
|
||||
is incompatible with the IEEE VHDL standard !!\fP).
|
||||
|
||||
.PP
|
||||
An output can be assigned to the value 'D' (don't care). This is taken into
|
||||
account by the logic synthesis tool in the optimization process. When the value
|
||||
of an output is 'D' the logic synthesis tool may turn it into a '1' or a '0'.
|
||||
|
||||
.PP
|
||||
A 'D' value is understood as a '0' by the logic simulator (asimut).
|
||||
|
||||
.PP
|
||||
\fBARRAIES\fP
|
||||
.br
|
||||
Arraies other than bit_vector, reg_vector, mux_vector and wor_vector are not
|
||||
supported.
|
||||
|
||||
.SH EXAMPLES
|
||||
.PP
|
||||
Here is the description of an adder with an accumulator register.
|
||||
|
||||
.nf
|
||||
entity add_accu is
|
||||
port (
|
||||
clk : in bit;
|
||||
command : in bit;
|
||||
data_in : in bit_vector (31 downto 0);
|
||||
data_out : out bit_vector (31 downto 0);
|
||||
cry_out : out bit;
|
||||
vdd : in bit;
|
||||
vss : in bit
|
||||
);
|
||||
end add_accu;
|
||||
|
||||
architecture data_flow of add_accu is
|
||||
|
||||
signal eff_data : bit_vector (31 downto 0); -- effective operande
|
||||
signal adder_out : bit_vector (31 downto 0); -- adder's result
|
||||
signal adder_cry : bit_vector (32 downto 0); -- adder's carry
|
||||
signal accum_reg : reg_vector (31 downto 0) register; -- accumulator
|
||||
|
||||
constant initialize : bit := '0';
|
||||
constant accumulate : bit := '1';
|
||||
|
||||
begin
|
||||
|
||||
-- select the effective operand
|
||||
|
||||
with command select
|
||||
eff_data <= X"0000_0000" when initialize,
|
||||
accum_reg when accumulate;
|
||||
|
||||
-- compute the result out of the adder
|
||||
|
||||
adder_out <= eff_data xor data_in xor adder_cry;
|
||||
adder_cry (0) <= '0';
|
||||
adder_cry (32 downto 1) <= (eff_data and adder_cry (31 downto 0)) or
|
||||
(data_in and adder_cry (31 downto 0)) or
|
||||
(aff_data and data_in ) ;
|
||||
|
||||
-- write the result into the register on the rising edge of clk
|
||||
|
||||
write : block (clk = '1' and not clk'STABLE)
|
||||
begin
|
||||
accum_reg <= guarded adder_out;
|
||||
end block;
|
||||
|
||||
-- assign outputs
|
||||
|
||||
cry_out <= adder_cry (32);
|
||||
data_out <= accum_reg ;
|
||||
|
||||
-- check power supply
|
||||
|
||||
assert (vdd = '1' and vss = '0')
|
||||
report "power sypply is missing"
|
||||
severity ERROR;
|
||||
|
||||
end;
|
||||
|
||||
.fi
|
||||
|
||||
.SH SEE ALSO
|
||||
.PP
|
||||
vhdl(5), vst(5), bop(1), glop(1), scmap(1), c4map(1), asimut(1), proof(1), yagle(1)
|
||||
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
.\" $Id: vhdl.5,v 1.1 2002/09/24 08:44:44 czo Exp $
|
||||
.\" @(#)vhdl.5 1.0 Jan 28 1993 UPMC ; VUONG H.N.
|
||||
.TH VHDL 5 "October 1, 1997" "ASIM/LIP6" "VHDL subset of ASIM/LIP6/CAO-VLSI lab."
|
||||
|
||||
.SH NAME
|
||||
.PP
|
||||
\fBALLIANCE VHDL Subset\fP
|
||||
|
||||
.so man1/alc_origin.1
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
The ALLIANCE VHDL subset is dedicated to digital synchronous circuits design.
|
||||
The same subset is used for:
|
||||
.RS
|
||||
logic simulation (asimut)
|
||||
.br
|
||||
logic synthesis (bop, scmap, glop)
|
||||
.br
|
||||
functionnal abstraction (yagle)
|
||||
.br
|
||||
formal proof (proof)
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The ALLIANCE VHDL subset is fully compatible with the IEEE VHDL standard Ref.
|
||||
1076 (1987). That means that a VHDL description using the ALLIANCE subset can
|
||||
be simulated with any full-VHDL commercial compiler-simulator.
|
||||
|
||||
.PP
|
||||
Here follows the main restrictions of the ALLIANCE subset.
|
||||
|
||||
.PP
|
||||
The VHDL description of a circuit is made of two seperate parts: the external
|
||||
view and the internal view.
|
||||
|
||||
.PP
|
||||
The external view defines the name of the circuit and its interface. The
|
||||
interface of a circuit is a list of ports. Each port is specified by its name,
|
||||
its mode, its type, its constraint for an array and, its kind.
|
||||
|
||||
.PP
|
||||
The mode of a port depends only on the manner the port is used inside the
|
||||
circuit (in the internal view of the circuit). If the value of a port is to be
|
||||
read in the view of the description, the port must be declared with the mode
|
||||
\fIin\fP. If the value of a port is to be written by the internal view, the
|
||||
port must be declared with the mode \fIout\fP. If both above conditions are
|
||||
satisfied the port must be declared with the mode \fIinout\fP.
|
||||
|
||||
.PP
|
||||
Only \fIstructural\fP and \fIbehavioural data flow\fP are supported as internal
|
||||
view.
|
||||
|
||||
.PP
|
||||
In order to allow automatic translation from structural VHDL to other netlist
|
||||
formats (EDIF, ALLIANCE, COMPASS, ...) it is not possible to mix behavioural
|
||||
and structural description. Of course, a circuit, a subcircuit or a cell can
|
||||
have two different descriptions:
|
||||
.RS
|
||||
a structural view may be defined in a file with a .vst extension (see vst(5)).
|
||||
.br
|
||||
a behavioural data flow description may be defined in a file with a .vbe
|
||||
extension (see vbe(5)).
|
||||
.RE
|
||||
.PP
|
||||
A typical VHDL model will be made of a hierarcical structural description (a
|
||||
hierarchy of structural files) and, for each leaf cell, a behavioural
|
||||
description.
|
||||
|
||||
.PP
|
||||
In a behavioural description, only concurrent statements (except \fIprocess\fP)
|
||||
are supported. Up to now, sequential statements are not allowed by the ALLIANCE
|
||||
VHDL compiler.
|
||||
|
||||
.\" .PP
|
||||
.\" As behavioural descriptions are used for both logic simulation and logic
|
||||
.\" synthesis, detailed timing information is not needed. That means, within a
|
||||
.\" concurrent statement no delay can be specified (\fIafter\fP is not supported).
|
||||
|
||||
.PP
|
||||
Timing information can be specified in behavioural descriptions using \fIAfter clauses\fP. However, those delays are currently only used for simulation. \fIAfter clauses\fP are supported but not used for synthesis and formal proof.
|
||||
|
||||
.PP
|
||||
A predefined set of types has been defined (other user defined types are not
|
||||
supported):
|
||||
.TP 15
|
||||
\fBbit\fP
|
||||
the predefined standard bit type ('0' or '1')
|
||||
.TP 15
|
||||
\fBbit_vector\fP
|
||||
array of bit
|
||||
.TP 15
|
||||
\fBmux_bit\fP
|
||||
a resolved subtype of bit using the \fImux\fP resolution function. This
|
||||
function checks that only one driver is actually connected to a signal. The
|
||||
effective value of the signal is the value of the active driver. If all drivers
|
||||
are disconnected, the value of the signal is '1' (pull up). A signal of type
|
||||
mux_bit must be declared with the kind \fIbus\fP.
|
||||
.TP 15
|
||||
\fBmux_vector\fP
|
||||
array of mux_bit
|
||||
.TP 15
|
||||
\fBwor_bit\fP
|
||||
a resolved subtype of bit using the \fIwor\fP resolution function. This
|
||||
function allows a signal be driven by more than one driver. All active drivers
|
||||
have to drive the same value. The effective value of the signal is the value
|
||||
of active drivers. If all drivers are disconnected, the value of the signal
|
||||
is '1' (pull up). A signal of type wor_bit must be declared with the kind
|
||||
\fIbus\fP.
|
||||
.TP 15
|
||||
\fBwor_vector\fP
|
||||
array of wor_bit
|
||||
.TP 15
|
||||
\fBreg_bit\fP
|
||||
a resolved subtype of bit using the \fIreg\fP resolution function. This
|
||||
function checks that only one driver is actually connected to a signal. The
|
||||
effective value of the signal is the value of the active driver. A signal of
|
||||
type reg_bit must be declared with the kind \fIregister\fP (which makes the
|
||||
signal keep its previous value when all drivers are disconnected).
|
||||
.TP 15
|
||||
\fBreg_vector\fP
|
||||
array of reg_bit
|
||||
|
||||
.PP
|
||||
In the next ALLIANCE release the VHDL subset will be largely extended
|
||||
(sequential statements, user defined types) .
|
||||
|
||||
.SH SEE ALSO
|
||||
.PP
|
||||
vst(5), vbe(5), asimut(1), bop(1), glop(1), scmap(1), c4map(1), proof(1), yagle(1)
|
||||
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
.\" $Id: vst.5,v 1.1 2002/09/24 08:44:44 czo Exp $
|
||||
.\" @(#)VST.5 1.0 Jan 28 1992 UPMC ; VUONG H.N.
|
||||
.TH VST 5 "October 1, 1997" "ASIM/LIP6" "VHDL subset of ASIM/LIP6/CAO-VLSI lab."
|
||||
|
||||
.SH NAME
|
||||
.PP
|
||||
\fBvst\fP
|
||||
.br
|
||||
VHDL structural subset.
|
||||
|
||||
.so man1/alc_origin.1
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
This document describes the ALLIANCE VHDL subset for structural descriptions.
|
||||
|
||||
.PP
|
||||
The declaration part of a structural description includes signal decalarations
|
||||
and component declarations.
|
||||
|
||||
.PP
|
||||
An internal signal can be declared of any type supported by the present VHDL
|
||||
subset except reg_bit and reg_vector.
|
||||
|
||||
.PP
|
||||
A component must be declared with exactly the same port description as in its
|
||||
entity specification. This means that local ports are to be declared with the
|
||||
same name, type and kind and in the same order.
|
||||
|
||||
.PP
|
||||
A structural description is a set of component instanciation statements.
|
||||
Instances' ports are connected to each other trough signals in a port map
|
||||
specification. Both explicit and implicit port map specifications are supported
|
||||
by the ALLIANCE VHDL subset.
|
||||
|
||||
.PP
|
||||
The present version of the VHDL compiler does not allow unconnected ports (the
|
||||
\fIopen\fP mode is not supported).
|
||||
|
||||
.PP
|
||||
Only the concatenation operator (&) can be used in the actual part (effective
|
||||
signal conntected to a formal port) of a port map specification.
|
||||
|
||||
.SH EXAMPLES
|
||||
.PP
|
||||
Here is the description of an adder with an accumulator register.
|
||||
|
||||
.nf
|
||||
entity add_accu is
|
||||
port (
|
||||
clk : in bit;
|
||||
command : in bit;
|
||||
data_in : in bit_vector (31 downto 0);
|
||||
data_out : out bit_vector (31 downto 0);
|
||||
cry_out : out bit;
|
||||
vdd : in bit;
|
||||
vss : in bit
|
||||
);
|
||||
end add_accu;
|
||||
|
||||
architecture structural of add_accu is
|
||||
|
||||
signal eff_data : bit_vector (31 downto 0); -- effective operande
|
||||
signal adder_out : bit_vector (31 downto 0); -- adder's result
|
||||
signal accu_out : bit_vector (31 downto 0); -- accumulator
|
||||
|
||||
component adder
|
||||
port (a : in bit_vector (31 downto 0);
|
||||
b : in bit_vector (31 downto 0);
|
||||
res : out bit_vector (31 downto 0));
|
||||
end component;
|
||||
|
||||
component and_32
|
||||
port (a : in bit_vector (31 downto 0);
|
||||
cmd : in bit;
|
||||
res : out bit_vector (31 downto 0));
|
||||
end component;
|
||||
|
||||
component falling_edge_reg
|
||||
port (din : in bit_vector (31 downto 0);
|
||||
clk : in bit;
|
||||
dout : out bit_vector (31 downto 0));
|
||||
end component;
|
||||
|
||||
begin
|
||||
|
||||
my_adder : adder
|
||||
port map (a => eff_data, b => accu_out, res => adder_out);
|
||||
|
||||
my_mux : and_32
|
||||
port map (cmd => command, a => accu_out, res => eff_data);
|
||||
|
||||
my_reg : falling_edge_reg
|
||||
port map (din => adder_out, clk => clk, dout => accu_out);
|
||||
|
||||
end;
|
||||
.fi
|
||||
|
||||
.SH SEE ALSO
|
||||
.PP
|
||||
vhdl(5), vbe(5), asimut(1)
|
||||
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
||||
Loading…
Reference in New Issue