# ~ I n s t l t u t e of E l e c t r o n i c s , S l l e s l a n T e c h n i c a l U n i v e r s i t y 44--100GllWlce, P o l a n d ~ e s e l l s c h a f t f u r R a t h e m a t l k u n d D a t e n v e r a r b e l t u n g (GHD) P r o J e k t E.I.S., 5205 S t , A u g u s t l n , F.R.G.
AB6TRACT The sul~nltted paper presents a k e r n e l of a n e n v i r o n m e n t f o r t h e s t r u c t u r e d d e s i g n of MOS VLSI IC& The d e s c r i b e d CAD s y s t e m I n c l u d e s e l e m e n t s of f o r m a l v e r i f i c a t i o n o f d e s i g n ~-r~-~ I t i s b e i n g p r o t o t y p e d on IBH PC XT a n d lS w r i t t e n In T u r l ~ P a s c a l a n d m i c r o FROIL~ It was a l s o meant t o s e r v e a s a n e n v i r o n m e n t f o r d e v e l o p m e n t of more s o p h i s t i c a t e d CAD tools ( l l k e a u t o m a t i c s y n t h e s i s p r o g r a m s ) . 1. I N T R O D U C T I O N
The m m n g o a l of t h e p r e s e n t e d work w a s to c r e a t e a u~er~frleadly e n v i r o n m e n t f o r a s t r u c t u r e d d e s i g n of VLSI system& Tl~e e n v i r o n m e n t s h o u l d a l s o p r o v i d e u s e r s w l t h the p o s s i b i l i t y of I n v e s t i g a t i o n of f o r mal verlflcaUon methods for dlgltal systems, and l e t t h e m d e v e l o p a v a r i e t y o f CAD t o o l s f o r VL$I design. Ac~x~-dlng t o Read a n d Conway LH ' eCoSO]t h e d e s i g n of a n I n t e g r a t e d c i r c u i t l s d i v i d e d l n t o two p h a s e s : - top-down logic d e s i g n process, - bottom-up pl~yalcal I m p l e m e n t a t i o n . presented s o f t w a r e a l l o w s t h e d e s i g n e r t o f o l l o w that scheme. As s h o w n i n Flg.1 the system c o n s i s t s of four maln routines a n d a user interface. Tl~e floorplan editor creates hierarchical design environment, In which a designer keeps refining the s t r u c t u r e a n d f l o o r p l a n of t h e c h i p s t e p b y s t e p .
The l a y o u t e d i t o r i s u s e d t o s p e c i f y t h e s t r u c t u r e a n d geometry of t h e l o w e s t l e v e l m o d u l e s a n d t o ¢ o m ] ~ e them I n t o a s y s t e m . In order to enhance a correct-by-constructlon design methodology we bullt a formal verification prod'am Into our framework, It allows a designer to verli~ each refinement step. It is done automatlcally by the verification program, but the deslgner must specify t h e b e h a v l o u r of t h e m o d u l e being d e aig~ed and of l t s s u b m o d u l e e . A bullt-ln t e x t e d i t o r serves thls Purpose.
A designer has to speclfy the behavlour of a ~_e~_!gned circuit In m l c r o - P R O L 0 ~ Tl~ere w a s a serlous reason for choosing P R O L O G as a l a n g u a g e of speclflcatlon. The kernel of o u r system, l.e. the verification program, is Implemented In mlcro-PROLOG. Several planned extensions to our system are to be implemented In Prolog. T h u s it is quite natural to spenfy a designed circuit In the same language. Altlwu.~ the expressive power of Prolog makes it a good l a n g u a g e for a digital circuit specification. stlll It w o u l d be more convenient for a deslgner to specify the integrated clrcult In a n y of the exist-
l u g h a r d w a r e d e s c r i p t i o n l a n g u a g e s (e,g. VHDL). I t r e q u i r e s a - q u l t a b l e p a r s e r t h a t we p l a n t o b U l l t . N e v e r t b e l e ~ P r o l o g w111 r e m a i n t h e l a n g u a g e o f l n t e r n a l r e p r e s e n t a t i o n o f d l g l t a l c i r c u i t In o u r system. The v e r l f l c a t l o n p r o g r a m ls b a s e d on B a r r o w ' s I d e a s d e s c r i b e d In [BarB4] a n d i s u s e r e x t e n d a b l e . Due t o m o d u l a r s t r u c t u r e of o u r s y s t e m I t i s a l s o p o s s l b l e to r e p l a c e I t w l t h a n o t h e r p r o g r a m of t h a t kind. T h l s f e a t u r e w l l l l e t u s I n v e s t i g a t e d i f f e r e n t approaches t o w a r d s f o r m a l v e r i f i c a t i o n . presente~ software w a s a l s o aimed a s a n e n v i r o n m e n t for d e v e l o p m e n t o f a u t o m a t i c s y n t h e s i s tOOlS. The f l o o r p l a n e d i t o r d a t a s t r u c t u r e s , w h l c h reflect the deslgn hierarchy and lts graphlc Interface are convenient to extend the edltor w l t h s u c h programs a~: a u t o m a t i c r o u t e r , a u t o m a t i c f l o o r p l a n n e r or t o o l s f o r h l g h l e v e l s y n t h e s i s (1.e, s y n t h e s i s of RTL a r c h i t e c t u r e b a s e d on t h e b e h a v l o u r a l d e s c r i p t i o n of t h e l n t e n d e d c i r c u i t ) . On t h e o t h e r hand, c e l l compilers and module g e n e r a t o r s may be b u i l d a n d v e r l f l e d In t h e l a y o u t edltOr e n v i r o n m e n t .
U
ITEXT I, ~
BEHAVO I UR
i C E
Fig.1.
PROGRAM
j i :; Y I O0~
The general
GEOMETRYI
structure framework
I
FUNCTO I NSLB I RARY]
LELALCRELL
of t h e p r e s e n t e d
I
7:. Grabowiecki et al / A University Framework for Correct
38
2. 7 1 ~ - D O ~
DESI6N PROCEI~
The basic notion u s e d in the description of a hlerarchlcal deslgn process ls a module, which is a part of a dlgltal system wlth the clearly determlned bebavlour (i.e. the w a y h o w its outputs d e p e n d on Its inputs a n d internal states) a n d loglcal a n d physlcal interfaces to other parts of the system. Each m o d u l e m a y consist of a n u m b e r of s u b modules. These submodules, connected according to the designer's intentions, define a m o d u l e structure on the lower level. The m o d u l e slmple e n o u g h to design Its l a y o u t Is called a leaf cell. S u c h a m o d u l e does not consist of submodules, but only of layout editor primitives. These are discussed in d e t a l l s I n 5.1. While deslgnln9 a system, a designer defines a structure a n d a floorplan of each module on subsequent levels of hierarchy. The structure of a m o d u l e is determlned by Interconnectlons of Its submodules. In o r d e r t o d e f l n e a f l o o r p l a n o f a m o d u l e a d e -
+ BEHAVIOURSPECIFICATIONTE[
1
,
I SUBHOOULES BEHAVIOUR SPECIFICATIONTE REFN I EMENT LOOP
CORRECTO IN
I
VERIFICATIONV I
LOOP
I
Yes~
No
,
1
I LEAFCELLSLAYOUT I DESIGN LE 1
I STRUCTURE EXTRATIO]N I
VERIFICATIONV I
L
BOTTOM UPCHIP [ LAYOUTASSEMBLY LE
I
Flg 2. Design process In the presented f r a m e w o r k (TE - text editor, FE - floorplan editor, LE - layout edltOr, v - verlflcatlon program)
slgner must estlmate shapes, relatlve sizes and posltlons of Its submodules. Declslons how to do It are based on the designer's experience. T h e s a m e applies to the placement of termlnals. Modules are represented as boxes wlth terminal symbols. Effects of all the designer's actlvltles, performed by means of a menu-drlven set of procedure~ are displayed Immedlately on a screen. ^ user m a y vlew a modelled system at multlple levels of structural hierarchy. The designer m a y check the correctness of the deslgn he w o r m s on b y m e a n s of the verification progrant In order to take advantage of this program the designer m u s t speclfy the behavlour a n d structure of a m o d u l e Delng designed. A m o d u l e Is conaldered correct If lts specified behavlour meets the behav~ur ~ b y i t s s t r u c t u r e a n d ]b~l~avlour I t s s u l m o d u l e s . The t o o l f o r b e h a v l o u r s p e c i f i cation is a b u i l t - I n t e x t edltor a n d t h e l a n g u a g e used for thls p u r p o s e Is described in part 3. of tbls paper. The structure of a m o d u l e Is derived automatically from floorplan or layout edltor data structures. The correctness of a m o d u l e m a y be proved if each of Its su/)modules falls Into one of the three categories: a - It is a prlmltlve of the verification p r o g r a m (the d i f f e r e n c e s b e t w e e n l a y o u t editor prlmltlves a n d verification program prlmltlves are dlscussed In 5.1); b - I t s detailed structure a n d behavlour Is already k n o w n a n d 1is correctness h a s l)een a l r e a d y proved; c - its b e h a v l o u r is specified b y the deslgner assuming that it w111 be des19ned correctly (thus It Is correct by assumption). The verlflcaUon pro@ram m a y be used In several ways. Firstly, It offers the posslblllty of a hierarchical verlflcatlon of a system that has been already deslgned. In such a case the structure of the system Is deflned u p to the level of prlmttlves. verification program checks consistency between t h e Inltlal speclflcatlon of t h e system's b e h a v l o u r and the behavlour derived from its flnal structure. However, if a mlstake has been m a d e early In the design process, It m a y be necessary to redeslgn a large part of a system. To avoid such a sltuatlon the designer m a y use the verification program after one or several refinement step(s) to m a r e sure that tl~ transformatlon(s) has(have) been done correctly. I f It is done repeatedly on sul)sequent l e v e l s of hlerarcby, the designer wlll flnlsh 121s w o r k wlth tl~e system that Is correct b y construction. Tl~ere Is no place for a n y b u g into the deslgn, b e c a u s e the correctness of every designer's s t e p h a s b e e n proved. To speed u p a designer's work a n d let h l m reuse results of hls earller work, our system supports the library of "ready-made" layout pieces that are frequently used in digital IC design. Layouts a n d behavtoural m o d e l s of leaf cells or more c o m p l e x modules are stored there a n d m a y be used w h e n they fit designer's needs. The meth_~_o!ogy presented ~ has unfortunately a t least one w~ak point. A mlstake can De m a d e while
7". Grabowiecki et al / A University Framework for Correct
s p e c i f y i n g t h e b e h a v l o u r . To m l n l m l Z e t h l s p e s s i b t l l t y o u r system p r o v i d e s t w o o t h e r l i b r a r i e s . The first aw contains parameterlzed behavloural models of functional unlts, which are commonly used in d i g i t a l s y s t e m s . Tl~ese a r e ALUs, a d d e r s , r e g i s t e r s , RAMs, c o u n t e r s , etc. A t t h e moment t h e l r s p e c l f l c a u o n s m a y be used for verification purposes only. However, we plan to develop a variety of m o d u l e generator& that wlll be able to generate a correct structure and layout of these modules automatically according to parameters passed to them. Some parameterlzed behavloural models from this library are listed In an appendix. The second library supports Its users wlth a set o f functions that m a y be lwl~ul whlle specifying the behavlour of less common modules. ~1~e-~ATIM 3~ Integrated
OF ~ circuit
B~iAV~q~ as a finite
A E ) STRUCTURE state
machine
In our s y s t e m e v e r y m o d u l e l s c o n s i d e r e d as a finite s t a t e machine. The finite state machine has some lnputs x, o u t p u t s y a n d (possibly) some state varlables s. Its b e h a v l o u r ls fully d e scribed by a set o f dependencies between all these varlahte~ a ommon way of specyfylng such dependencles is a state transition table of a flnite state m a ~ t l n ~ An a l t e r n a t i v e w a y . e m p l o y e d I n o u r s y s t e m , ls to glve a set of output and state equations Yn = f Cxr~ Sn) sn+l = g(Xr~ Sn) Although this convention is perhaps not v e r y natural to a circuit designer, It ls fairly general and allows one to speclfy modules on different levels o f abstraction. All prlmltlve m o d u l e s o f our s y s t e m ( e n h a n c e m e n t FET, d e p l e t i o n F E T . p u l l - u p , ground and Join) as well as gates, registers, a d ders, buses, ROMS, RAMs, P L A s etc. h a v e a f i n i t e s t a t e machine r e p r e s e n t a t i o n .
3.2.
Signals
Inputs~ o u t p u t s a n d s t a t e v a r i a b l e s a r e a l l e x a m ples of different types of signals. A domain of a slgnal depends on a level of abstraction. On t h e lowest level signals are usually trl-state (high, l o w or h i g h i m p e d a n c e ) , w h l l e on h i g h e r l e v e l s t h e y can be Boolean variables, single blts, Integers of l e n g ~ etc. B e f o r e f o r m u l a U n g a n o u t p u t o r a state equation of a m o d u l e one m u s t specify two parameters of every signal: Its type and its domain. Thls can be accomplished with a Prolog relation slgnal: (signal (module type> and represent user-defined names of a type of a module a n d o f a s l g n a l r e s p e c t i v e l y . The f l r s t o n e c a n b e a single constant or a list (see 3.5), whlle the l a t t e r - always s i n g l e Prolog c o n s t a n t . T e r m ls a l w a y s one of the constants: Input, output or state whose interpretation Is obvious. The last a r g u m e n t of the signal relation depends on a level of abstraction. Here are some
39
examples: ] ) I t - v a l u e 1 o r O. I t I s u s e d t o d e n o t e s i n g l e blts as well as Boolean variables wlth number 1 denoung truth or 0 - falsity, (integer x) - x-blt lnteger (non-negative integ e r s I n a r a n g e [0, 2 X - l ] o r s i g n e d I n t e g e r s In an appropriate range), (hit x) - vector consisting of x slgnals of type /)It (llst of x bits), ((Integer x) y) - vector consisting of y slgnals of type (Jnteg"er .r) (llst of y x-blt Integers). Example: Slgnala of a one-bit multiplexer four clauses: ((signal ((signal ((signal ((signal
multiplexer multiplexer multiplexer multiplexer
In1 Ir2 ctrl out
3.E O u t p u t a n d s t a t e
are described with
Inlmt b i t ) ) Inlmt b i t ) ) Inlmt b i t ) ) outlet b i t ) ) equations
Both o u t p u t a n d s t a t e e q u a t i o n s a single relation equation
are described by
(equation ¢module type> :: (expression>) Term Is u s u a l l y JUSt < s J g n a l name.>. It must be o f i n p u t or state type (this u n a m b l g o u s l y states w h e a t h e r equation Is an output or state equation). The In t h e s i m p l e s t case is a s l n g l e term < s J g n a l name.>, In more complex cases this term takes the form ((function
name> (list
of
arguments>).
Functions encountered most frequently are defined within our system. Currently several functions a r e d e f l n e d : l o g l c a l f u n c t i o n s not, or, and, n o r etc., a r i t h m e t i c operators for addition, subtraction, multiplication, Integer dlvlslon and modulus, three-argument funcUon lf, shifting, conc a t e n a t l o n e t c . I t Is POSSible f o r a d e s i g n e r t o u s e h l s own f u n c t i o n names p r o v i d e d h e d e s c r i b e s them In a way sufficient for a verification program. Every argument of a function m a y be Itself an expreSSion, which means that the functions m a y be embedded to any depth. Examples:
((equation f l i p - f l o p out :: cont)) ((equation multiplexer out :: ( I f ( c t r l In1 Ir2)) )) ((equation ar out :: (*(a (~(b c)))) )) 3~4. N o d u l e
structure
There are two relations for describing Internal structure of a module. RelaUon ~ u l e names e l e m e n t s of a d e s i g n e d module a n d t a k e s t h e form: (salmo~le (sal~mdule name> ). T h e m a l n purpose of the form
of the
relation
connected
(connected (module t~e) a n d < d e a t J n a t l o n
T. Grabowiecki et a l / A University Framework for Correct
40
inl
InI in2 ~
o
ctr[o---
_•
~
out
in2o
f o u n d In a n a p p o n d l x . out
in1 in2
----o o~
in 1 in2
The e x p r e s s i v e p o w e r o f P r o l o g e n a b l e s u s t o c r e a t e common s p e c i f i c a t i o n s f o r a w h o l e c l a s s o f m o d u l e s of the same klnd. I t l s p o s s l b l e to w r i t e one c o m p l e x s p e c i f i c a t i o n e.g. f o r a f a m l l y o f s h i f t registers wlth or wlthout parallel I n p u t / o u t p u t , wlth or without reversion of shlftlng direction etc. Another e x a m p l e is a u n i v e r s a l m o d e l of a f ~ m n y of binary counters (see appendix). Thls feature ls extremely useful In creatlng a llhrary o f D a m c functional unlts. A ~ I ~ M
Flg.3. One-blt multiplexer
sig'nal> are b o t h t w o - e l e m e n t
llsts, the flrst element being lnput or output slgnal n a m e a n d the second - s u b m o d u l e n a m e (ln a case the signal is that of a s u b m o d u l e ) or m o d u l e type (if it ls a slgnal of a designed module). Example: The structure of a one-blt multiplexer speclfled in 3.3 Is s h o w n In Flg.3. The floorplan e d i t o r w l l l generate the f o l l o w i n g clauses:
The relation connected serves also another purpose. If signal names In terms a n d are both names of state varlables then thls relatlon e s t a b lishes equivalence b e t w e e n states of a d e s l g n e d module a n d those of submodules. In thls case relevant clauses have to be supplied by a designer. 3~ Specification of a parameterized
module
Modules on every level of abstraction c a n be parameterlzed. Some examples of p a r a m e t e r s are: n u m b e r of blts In the input to an adder, n u m b e r of inputs to a multl-lnput or gate, n u m b e r of words of storage in a memory, data stored In a R O M etc. T h e maln d i f f e r e n c e In speclftcauon of p a r a m e t e r l z e d modules IS In adJolnlng Its parameters to the term which becomes a llst instead of a slnsle constant. E x a m p l e - behavloural speclflcatlon of a n a d d e r parametm'lzed In l n p u t w o r d l e n g t h :
((m~ule (adOer x))) ((signal (ae;ler x) |nl input (Integer x) )) ((signal (adder x) InZ inpot (Integer x))) ((signal (adder x) sum output (Integer y))(SUH x 1 y)) ((equatlon (adder x) sum :: (*(In1 IrlZ)) )). More e x a m p l e s
of parameterlzed
modules
c a n be
(W A DIGITAL ( ~ u u L - f CORRECTNESS
The aim of t h e v e r i f i c a t i o n l s t o s h o w t h a t t w o clrcult descriptions: a c t u a l D e h a v l o u r i n f e r r e d from 1is s t r u c t u r e a n d d e s l r e d b e h a v l o u r ( c l r c u l t s p e c l flcaUon) are equivalent. Thls verification process oonsists of two a p p a r e n t l y d i f f e r e n t tasks: - I n f e r r i n g m o d u l e b e h a v l o u r (1.e. s t a t e a n d o u t p u t equations) from Its structure (1.e. s p e c i f i c a t i o n of s u b m o d u l e s a n d t h e l r l n t e r c o n n e c t i o n s ) ; - formal proof that specified behavlour and that Inferred from structure are equivalent. 41 In,~Tlng ~eha~_our from structure A c t u a l behaviour of a compound m o d u l e Is fully descrlbed wlth a relation c o n n e c t e d a n d c l a u s e s of equation relating to lts s u b m o d u l e s . T h e alto o f t h e f l r s t s t e p of t h e v e r i f i c a t i o n process ls to reduce this description to the equivalent one, In whlch every o u t p u t a n d s t a t e s l g n a l of t h e c o m p o u n d module ls deecrlbed wlth a slnsle equatlon wlth Input and state slgnals of this m o d u l e as arguments only. This t a s k ls e q u i v a l e n t to t h e r e d u c U o n of Intermediate slSnals (slgnals In ports of submodules). The process of derlvlng equations from structure IS a series of multlple substitutions of s u b m o d u l e equatlons according to relevant clauses connected. It results In a d d l n g a c l a u s e of a relation d e r l v e d - e q u a t l c a to the d a t a base. This relatlon h a s e x a c t l y the s a m e form as the relatlon equation discussed I n 3.3. Example: Relation d e r l w e d - e q u a U o n described in 3 is
for a m u l t i p l e x e r
((derl ve@e(luatl on multl pl exer out : : (nor((nor(Inl ( n o t ( c t r l ) ) ) ) (nor(InZ c t r l ) ) ) ) )). 4.2. P r o o f o f e q u i v a l e n c e Havln9 derlved output and state equations of a werlfled m o d u l e from Its structure, the verlflcatlon p r o g r a m has t o p r o v e t h e s e e q u a t i o n s a n d s p e c i f i e d ones are equivalent. I t lS w e l l k n o w n t h a t t h i s e q u i v a l e n c e c a n h a v e a f o r m of a s t r l c t e q u i v a l e n c e (Identity) or homomorphlsm. We s h a l l c o n c e n t r a t e on t h e former case. There are two basic methods for proving two equations to be equivalent: - evaluate rlght-hand sides of both equations for every possible v a l u e of all (state a n d Input) varla.bles and compare results; - perform symlxxllc manlpulatlons on rlsht-hand sides
T. Grabowiecki et al / A University Framework for Correct
of t h e e q u a t i o n s
until
they are Identical.
The f i r s t m e t h o d w h i c h m a y ~e c a l l e d a n e x h a u s tive test ls based on evaluation rule¢ The~ rules are Implemented In our system as clauses of Prolog relation evaluate. Rules for evaluation of Boolean functions not, or, a n d , nor, n a n d , x o r a n d e q u l v a r e g i v e n e x p l l c 1rely:
Boolean functions m a y h a v e a vector of blts as (an)argRlment(s). In whlch case appropriate function Is calculated for every hlt of Input vector(s). Evaluation of s u c h functions ls performed wlth
in1
I
clauses:
((evaluate Can
in2 odder
in2I
adder sum I
I
in2 I ~dder
J
shifter
i ctrl o2
QV
Flg.4.
averase-~
clrcuit
((evaluate (X(Y Z)) x)Cevaluate Y y)Cevaluate Z z)
(evaluate (X(y z)) x)) etc. During an exl~austlve test two equations: the one s p e c i f i e d b y t h e d e s i g n e r a n d t h a t d e r l v e d f r o m module structure are evaluated for all combinations of t h e I n p u t a n d s t a t e v a r i a b l e s v a l u e ~ T h e r e s u l t s are comPared and If any Incoincldence ls encounte r e d . t h e d i s c r e P a n c y IS r e P o r t e d . A c o u n t e r e x a m p l e may be printed, If necessary.
I f we a s s u m e t h a t a d d e r s a r e t h e s a m e a s I n 3.5 a n d s h i f t e r ' s o u t p u t e q u a t i o n I s out
:: ( s h l f t - r l g h t ( I n ¢ t r l ) ) ,
then the derived
equation
wlll
have
the form
ev : : (slllft-rlghtC(+Ca (eCb (*(C d)))))) 2)) We h a v e
to show that
an equatlon
dlv((*(a b ¢ d)) ~) : ~Ift-rlglltC(*Ca (*(b (*(c d)))))) Z) ls an Identity.
Syml~llc manipulations allow to verify modules wltl~ d n m ~ n ~ a c e t o o big to perform e x l ~ a u s t i v e t e s t e f f e c t i v e l y . T h e p o w e r o f tl~is m e t h o d d e p e n d s h e a v i ly on the mati~ematlcal Knowledge embedded In the s y s t e m . TI~IS k n o w l e d g e I s r e p r e s e n t e d b y r e w r i t e r u l e s t h a t a r e I m p l e m e n t e d I n o u r s y s t e m I n a form of a Prolog relation equivalent. Here are some _ ~ m ~ l e s of r e w r i t e r u l e s f o r B o o l e a n a n d a r i t h m e t i c functions.
Both sides of the equation are analysed from left to right until discrePanCy ls found. Then the relevant clause of equivalent ls employed to remove t l ~ d i s c r e p a n c y . T h e p r o c e s s c o n t i n u e s u n t l l the equation converts Into trivial Identity or the system cannot flnd any appropriate rewrite rule. In our example this leads to the following quence of equations:
se-
dlv((+(a b c d)) 4) = dlv(CeCa (*(b (eCc d)))))) 4) dlv((,(a (.(b c d)))) I) : dlv((,(a (÷(b ( . ( c d)))))) I) di~((,(a (,(b (*(c d)))))) I) : d~((*(a (*(b (*(c el)))))) 4).
T. Grabowiecki et a l / A University Framework for Correct
42
5. I ~ Y O O T O:F.SI6N
Bottom--up~ n y ~
A f t e r comparing several edltlng tools that were exhaustlvely described In the literature, the a u thors decided to employ an ldea o f a symbellc layOUtw ~|mtl~r tO that I m p l e m e n t e d In t h e MAGIC system rOHHS~41 A number of 1terns that a designer m u s t l~andle is thus greatly reduced. However, thanks to the fact that full geometry of the layout Is sl~own (in opposite to stlck d l a g r a m convention rwi178]), he can still achieve near-opUmal results. .51. Tlze l a y o u t
prlmlUvea
Transistors For t h e t l m e b e i n g t h e f r a m e w o r k s u p p o r t s o n l y NNOS technology and thus two kinds of transistors: enhancement a n d depletion m o d e transistors are availalble as primitives. However, as depletion mode t r a n s i s t o r s a r e u ~ u a ~ y u s e d as pull-ups, we d e c i d e d to consider also a p u l l - u p as a primitive of a layout edltor. Furthermore, to make analysis easler, the designer must declare whether a particular eru~ancemmt mode transistor Is a pull-down or a pass transistor. If a designer places a transistor whlle definlng cell layout, a number of rectangles placed In appropriate pbyslcal layers Is a u t o m a t i c a l l y generated. Contacts Tl~Is notion Is used for Interlayer connections. Several kinds of contacts such as: simple diffusionmetal or poly-metal contacts, buried contacts a n d b u t t i n g o m t a c t s m a y be u s e d .
Wires A w l r e Is a n area placed In one layer o f conducUve material, that bounds transistors and interlayer contacts (two or more) wlth one another.
L a y o u t vs. v e r y f l c a U o n
system primitives
Wires and contacts that are connected together form an area that is an electrical node. S u c h a n object represents a prlmltlve of the verlflcatlon p r o g r a m that is called 'Join'. For verification purposes, all s u c h areas which electrical potential is equal to zero volt (i.e.ground) must be 'marked' b y a designer, as they represent a 'contact to ground' which Is a primltlve of the verification program. 5.2. L e a f
cell
design
Layout d e s i g n prooeeds in a typical interactive g r a p h i c a l environment. A d e s i g n e r c o l l e c t s l e a f c e l l layout from the prlmltlves mentioned above. H e or she uses a set of typlcal c o m m a n d s for grapblcal editIng such as moving, mirroring, rotating etc. A cursor driven by arrow keys lets blm posltlon requlred items in a proper place and of course every action ls echoed on the screen.
The cell l a y o u t is represented in computer's me~ as a complex llst structure. It i s bound with data structures that represent the design hierarchy and is meant for qulck geometrical transformations and circuit extracUon.
After all
Imp~ementatma using hierarchy
l e a f c e l l s h a v e been designed or
chosen from a library, a designer m a y start to assemble the chip. The leaf cells m a y be now treated as prlmltlves and transformed llke primitives. They m a y overlap, but this cannot change the number of active devices (i.e. transistors) in overlapping cells. The cells m a y be shown on the screen as 'black boxes' wlth shown terminals or wlth fully displayed layout. Thls applies also to m o d u l e s that lle higher In the hierarchy, l.e.the number of hierarchy levels dlsplayed on the screen Is restricted only by the monitor resolution. The last stage of implementation is to attach contact pads to the highest level module (i.e. the deslgned system Itself). Thls usually requires output buffers and Input-gate protection circuits to be deslnged. When it is done the designer's work is finished. However, if a designed system Is too complex to be Implemented as a single chlp, It can be implemented as several chips. Instead of routing the l~t level module the designer must attach contact pads to Its submodules or group of submodules. We obtaln thus several chips that implement the designed system.
5.4. L a Y o u t r e p r e s e n t a t i o n An external representatlon for l a y o u t is CIF. Omtacts and transistors are defined as symbols and wires are represented as polygons. Such convention make~ it easy to convert external and internal layout representation Into each other. However, a n arbitrary CIF flle cannot be translated into internal data structure directly (without extracting primitives). S ~ i - ~ Imw_I~rfATJ~N ~
D~VI3.0PHI3qT
As It wa~ already mentioned the system ls written In T u r b o Pascal a n d mlcro-PROLOG. It Is belng Implemented on IBM PC XT Just for prototyplng purposes. We intend to move it to PC AT wlth EGA card and we belleve that thls could be satisfying hardware conflguratlon for educational Purposes. However, for proffesslonal use, 32-blt personal computer wlth hlgh reselutlon graphlc seems to be Indispensable. certain features of our system, such as: - modular structure, flexible for extensions° common m a n - m a c b l n e Interface for different routlnes, - data structures that reflect hierarchical nature of design process, - immediate electrical circuit extraction, mare It a ccmfortaltle environment for development of automatic synthesis tools. A n u m b e r of analysis tools that are needed to ensure corectness of designed layout Is to be developed also. T h e y include: - netllst checker, - on-llne Incremental design rule checker, - electrical design rule expert, that would help to achieve good circuit performance for d e s i g n e r s w l t h poor c i r c u i t d e s i g n e x p e r i e n c e . -
T. Grabowiecki et a l / A University Framework for Correct
ACK/'K)WLEDGHENTS The a u t h o r s w a n t t o e x p r e s s t h e i r g r a U t u d e to Miss H a l t n a Delewlcz, who w a s e x t r e m e l y h e l p f u l a s a n e d l t o r of t h i s paper. The d e s l n g a n d p r o t o t y p l n g of t h e d e s o r l b e d s o f t w a r e w a s s u p p o r t e d b y IPI PAN (Instltute of ComPuter Sclence of P o l l s h A c a d e m y of Sclences) as a part of project C P B P 02.17. RJu~~ K E N C E S [Bar84] Barrow H.: "VERIFY: A P r o g r a m for Provlng Correctness of Dtgltal H a r d w a r e Designs", ArUflclal Intelligence, Vol. 16, pp. 437491. 1984. rMeCoSO] C.Mead, L.Conway, "Introduction to VLSI Systems", Addlson & Weslay. 1980. [0HMS84] J.K 0 u s t e r h o u t , G.Hamachl, R.Mayo, w . s c o t t , G T a y l o r "MAGIC: A VLSI L a y o u t System", 21st DeJ1gn Automation Conference, 1984. [W1178] J.W1111ams, "Sticks - A G r a p h l c a l C o m p l l e r f o r H l g h Level LSI D e s l g n " , N a t l o n a l Comp u t e r Conference, 1978. APPENDIX Thls appendix contains some examples of m o d u l e behavloural speciflcatlons put in a (an)functional units library. Multl-lnput nor gate. ((mOdUle (or-n x))(/, x - number of inputs)) ((signal (or-n x) In InPut ( b i t x) )) ((signal (or-n x) out output b i t ) ) ((equation (or-n x) out :: (or In) )). A
fatally
of b l n a r y
counters.
((module (counter x y z X Y)) ( / * x - number of b i t s of the counter y - possible reversion of counting Z - possible disabling of counting X - paral I el I nput y - over flow sl gnal I satl on)) ((sl gnal (counter x y z X Y) cont state (Integer x) )) ((signal (counter x y z X Y) tn input b i t ) ) ((signal (counter x y z X Y) out output (integer x) )) ((Sl gnal (counter x yes z X Y) dlrctrl input b i t ) ) ((sl gnal (counter x y yes X Y) counten input b i t ) ) ((signal (counter x y z yes Y) pin Input (Integer x) )) ((signal (counter x y z X yes) ov output bl t ) ) ((signal (counter x y z yes Y) plnen Input b i t ) )
43
((equation (counter x y z X Y) out :: cont)) ((equation (counter x no no no Y) cont : : (mo(l(,(cont In) Z)))(power Z x Z)) ((equation (counter x yes no no Y) cont : : ( I f ( d l r c t r l (mod((,(cont In)) Z)) (lexl((-(cont In)) Z))))) (power Z x Z)) ((equation (counter x no yes no Y) cont :: (If(counten (md((,(cont In)) Z)) cont)))(power 2 x Z)) ((equation (counter x no no yes Y) cont : : (If(plnen pin (llOd((,(cont in)) Z)))))(power Z x Z)) ((equation (counter x yes yes no Y) cont :: (If(cnunten ( I f ( d l r c t r l (mod((,(cont in)) Z)) (mod((-(cont in)) Z)))) cont)))(power Z x Z)) ((equation (counter x yes no yes Y) cont : : (If(pinon pin ( I f ( d l r c t r l (mod((,(cont in)) Z)) (=xl(C-(cont in)) Z)))))))CPower 2 x Z)) ((equation (counter x no yes yes Y) cont :: (if(plnen pln (if(counten (mod((+(cont In)) Z)) cont)))))(power Z x Z)) ((equation (counter x yes yes yes Y) cont :: (If(plnen pin (If(countefl ( I f ( d l r c t r l (llod((,(cont In)) Z)) (md(C-Ccont in)) Z)))) cont)))))(power Z x Z)) ((equation (counter x y z X yes) ov :: (If((cont=O) 1 0)))) Decoder. ((module (decoder x)) (/= x - number of blts In decoded word)) ((signal (decoder x) In Input (integer x) )) ((signal (decoder x) out output ( b i t y))(po~er Z x y)) ((equation (decoder x) element(z out) :: (If((z--In) 1 0))) (power Z x y)(SUN y 1 X)(bet~een z (0 X) )) ROH.
((module (RON x y z))(/= x - number of words of storage y - nuli)er of bits In each ~0¢d z - RON contents)) ((signal (RON x y z) address Input (Integer X)) (bits-required X x)) ((signal (RUN x y z) out output (Integer y) )) ((equation (RON x y z) out :: (elellent(address z)) )) /gO. ((module (hl.g x))(/= x - number of blts In processed words)) ((signal (N.U x) Ina Input (integer x) )) ((signal (N.U x) Inb Input (integer x) )) ((signal (N.U x) ctrl Input (integer 3) )) ((signal (N.U x) nut output (integer y) )(SUN x I y)) ((equation (N.U x) out :: ( I f ( ( c t r l : 0 ) (,(Ina Inb)) ( I f ( ( c t r l : l ) (-(Ina Inb)) ( I f ( ( c t r l : Z ) (-(0 Ina)) ( I f ( ( c t r l : 3 ) (,(1 Ina)) ( I f ( ( c t r l : 4 ) (or(Ina Inb)) (If((ctrl:5) (and(Ira Inb)) (If((ctrl:$) im leb))))))))))))) ))
