SLIM: A Language for Microcode Description and Simulation in VLSJ1

John Hennessy Computer Systems Laboratory

Stanford University

Abstract

SLIM (Stanford Language for Implementing Microcode) is a programming language based system for specifying an ' simulating microcode in a VLSI chip. The language is oriented towards PLA implementations of microcoded machines using either a microprogram counter or a finite state machine. The system supports simulation of the microcode and will drive a PLA layout program to automatically create the PLA.

1 Introduction

Vl.SI chip design has rapidly become ::1n area of great importance and interest. Mead and Conway

[6] have proposed a design methodolouy for VLSI systems that has been widely employed. Their

design methodology proposes a chip organization using: fini te state control implemented with a PLA,

functional units controlled by the PLA, and a set of data paths. This design methodology has been

used in a number of large chip designs [5, 1, 2] . The finite state control can be thought of as

microcode. Within a design that follows the microcoded control approach, designing and debugging

the microcode appears to constitute a significant portion of the work involved in the desi9n process

[1, 2] . This paper describes a language for synthesizing the control units of ~ chip from a high level

l&nguage description.

Presently few tools exist to assist the user in designing and debugging the microcoded control.

Programs to construct PLA's from boolean equation are widespread; however , the difficult

component of control unit design is to specify and debug the microcode. This difficulty arises in

generating the boolean equations that describe the finite state machine control. Transforming these

1This resear ch was partially supported by the Join Services Electronics Program under contract It DAAG29-79·C·0047 and the Defense Advanced Research Projects Agency under contract It N0/\903·79 C-0680.

CALTECH CONFERENCE ON VLSI, Janua~y 1981

254 John L. Hennessy

to a PLA layout is tedious and error·prone but mechanically straightforward. Some work has been

done on describing PLA's at a higher level [7] and on synthesizing PLA descriptions from low level

state machine descriptions in DOL [4].

SLIM (Stanford Language for Implementing Microcode) is a programming language useful for the

design of a microcoded system that will employ PLA implementation techniques. Unlike earlier work

SLIM is functionally oriented. Control in SLIM is based on a finite state machine, but SLIM deals with

objects that can be more abstract than the actual PLA inputs and outputs. The SLIM system supports

both microcode simulation and automatic synthesis of the microcoded control function either in ROM

or PLA. SLIM will also accommodate either finite state machine control or control with a program

counter.

Correct microprograms are both tedious and diuicult to write for several reasons. First, the

programming language is extremely low level. Typically, the designer must deal with a primitive finite

state machine without the benefit of a human·engineered interface. Secondly, many of the

microprograms are large. This leads to a relatively complex program without a great deal of structure;

this is especially true if the finite state machine is coded as boolean equations. A boolean equation

approach makes it difficult to consider altering the mlcrocode, even during the debugging process.

Another major difficulty is the significant level of detail that must be expressed. This leads to one of

two pitfalls: either the microcode description is very low level and cluttered with details, which ma!

255 SLIM: A Language for Microcode Description and Si~ulation in VLSI

The SLIM design goals spawn a set of language and system requirements. The microcode

simulation requirement implies the ability to describe the subsy::>tcms that interact with the

microcontroller; we will refer to these subsystems as the environment. Describing the environment

can be easily done in a conventional programming lanr;uage, if the interaction \Nith the microcode

occurs in a restricted and well defined rn:mner. Separating the micromachine description from the

environment description has two benefits. The separation increases comprehensibility of the

micromachine structure. A specialized language is also more appropriate for the microprogram

design; without the separation the translation process is difficult or impossible.

The environment of the finite state micromachine can be described in n conventional programming

language. The environment consists of data structures and variables whi

256 John L . Hennessy

added to the PL/\ may be substantial (up to 2n terms for an expression of length n). Tile property that

-the number of product terms in the PLA is aprroximately equal to the number of preconditions for

the outputs in a SLIM program- has been useful in estimating the PLA size.

There ::.tre two major schemes for imrlemcnting the state component of a finite state machine. A

standard finite state implementation uses a fixed state assignment and includes an encoding of the

nexc-state function in the PLA. An alternat1ve im~,Jiementation uses a microprogram counter that is

incremented under external control. Each approach has benefits that depend on tl1o the micro-

program being implemented. The tradeofls ancl the advantages of the two different VLSI control

implementations are discussed in [3]. SLIM supports both control implementations, provides default

nex t states for program counter implementations, and will support subroutines with call and return in

either case.

A SLI!v1 microprogram consists of a set of states listed sequentially. Each state may optionally have

a lnbcl, which denotes the state name. The specification of the first state is preceded by a set of

s;:>~cificat:ons for outputs which are state independent. Figure 1 shows the format of a the state

machi11e specification.

fs:n $tate !:puclfu;alion (for stato mde{)encfent outputs} statc-nam'E! (op/Je>nilO : {state-specilica/ionJ

st action

Where the pi are function invocations and thu qj are product terms, like the first term.

f.igu re 2: .State specifications

COMPUTER -A IDED DESTCN SESSION

257 SLIM: A Language f o r Microcode De sc~iption a~d Simu~ation in VLS[

Each slate may contain a list of such specifications and the entire state is bracketed. During

simulation, state specifications are evaluated and executed sequentially, but in the actual PLA

implementation these operations will occur in parallel. The;efore, side effects between proceJures

that are outputs and functions that are inputs in the same state should b.J employed with great care.

2.1 Actions

There are two types of actions allowed: outputs and state change operr1tions. A lic l of actions can

be used os a single compound action by bracketing the list. Outputs ure invocations of procedures in

the environment and correspond to PLA outputs. The :3tate change directives dictate the next state.

All state change directives have effect only after the current state is completed; thus, all state

specifications with true conditions will be executed in a stole. The state change directives are:

next state-name · makes state-ll [ starlt imt~r: next h ighyel ] ]

highyel: ( highll ght(y ollow): fa•·rnlight(red): {Htghway yellow and farmroar1 r·ed} if nott1meout( short) => n~~t highyol: if timcout.(short) "> [ starttimer; otext farmgrn J ]

farmgrn : ( highl iuhl{I'Crt); fa1·ml ighl{green); {lligloway red and farm1•o ad green} if ca1 s and not timeout( long) •> ntJxt f.Jrmgrn: if notcJrs or l.imeout(lona) => [ slarttimer: next faronyel ] ]

fumyel: [ highlight(1·ed); farmlight(yellow): {llighway red and fa1·mroad yellow} if nottimeout( short) '> n('xt farmyel: 1f timtJout(short) ~> [ starttimer: next highgrn ] ].

CALTECH CONFERENCE ON VLSI, January 1981

258 John L. Hennessy

3 Defininn the Relationship to the PLA

The relationship between the microcode specification of the control program and the PLA is

defil'led by: declaring the input and output sianals for the PLA and defining tile mappings between

environment functions / procedures and input/output signals. The expressive power of this mapping

is one of the advantages of SLIM.

3 .1 Defininy input and output signals

PLA signals are defined by means of input and output signal declarations, which appear just before

the de finition of the environment procedures. Signal declarations beg in with the keyword inputs or

outputs, as appropriate. The general form of each declaration is then:

{name [ '(' bounds')' ]} [ ':' parameters]';'

The list of names are the names of input or cutput signals being declared. The optional bounds

designator indicates whether a ;:>articular signal is a single bit or a vector of bits. In the latter case the

line can be treated as an integer encoded number; the order of the bounds (low to high or high to

low) specifies the order of the lines in the signal vector. If any optional parameters appear they are

associated with all inputloutpw ne.mes in the declaration. Table 1 defines the legal parameters.

{Syntax

pia (n) top bottom renames (id) e

SLIM: A Language foP MicPocod e Desc~iption and Simu~ation in VLSI

with a single operation, must occur earlier. A frequently occurring example of this is precharging or

enabling of alu's. Although the functional operation add appears to occur in a single state the alu

must be precharged/enabled one state earlier. The pipelined directives provide a convienent way to

express such relationships without adding needless details to the microcode description . If an output

signal x appears in a state s conditional on input c and x is pipelined ca rlie r(i), then the output x will

appear, conditional on c, in all the staten that precedes by i states. Although pipelining can be done

into both predecessor o.nd successor states, by far the most common situation is pipelining into the

immediate successor state. SLIM finds all predecessor or successor states, including those that

occur when the state that is pipellned from is the target of a branch or call. Pipelining is not permitted

across a procedure return, i.e. in the state followiny a co.ll. The renames directive gives a signal

another name, without associating the other cl1aractcristics (e.g . p1pelining) of the renamed signal.

This is useful if a particular signal must be pipelined nearly all the time, but occasionally nonpipelined

generation of the signal is needed.

3.2 Describing the relationship oetween environment and outputs

Since a procedure or function in the environment can logically correspond to one or more signals,

SLIM provides a method of defining the mapping between environment routines and signals. This

method allows the microcode description to be functionally oriented, and to significantly decrease tl1e

amount of code needed to describe the PLA implementation of the microcode.

The mapping between environment procedures and signals to be generated in the PLA is aiven in

the definition section of an environment procedure or function . The definition section starts with the

keyword definition and appears immediately after the function or procedure header. Procedures in

the environment without a definition section are presumed to be for simulation purposes only. The

definition section consists of a list of signal definitions which arc separated by semicolons; the

ddinition section is tz rminated by end.

A signal definition has the form :

[pattern -string : ] signal-expression

The optional pattern-string is used to specify different signal combinations b

260

Tl1e signal-expression specifics what sionals to generate; it m:ly also contain invocation ~~ other

cnvironmP.nt procedures. Before it is ~valuated any identrlicrs in the siunol- list that corre3pond to

forrnnl parameters nre replacod by t11e ac tu al p.p.·r~:;:;ion

sianal name procedure-name(parumetcrs) Stgnal-c.-

£.U.l

SLIM : A Lnnguage fo~ Mi~roeode Descr[ption ani ~i ~u 1 ~tl1~ t n VLS[

4 Using SLIM

A SLIM program can be used to drive a microcode simulatinn as well as genP.mte a PLA l wl1ich arise

because the simulation does not e:~mu l ation may fail to test all pcssiiJic COitlbinations of int.Juts or

fail to t.)st all states.

The major reasons t11at t11e simulation :.1nd PLA implementation llliullt behave ditfcrc1lfly is because

tile simulation treats outputs, envir0111ncnt procedures, and the state 3S uniqu8 Ullli!ics i11 r1 ~;equential

manner. In the PLA tilcsa objects are interrel

262 Jo hn L. He nn e ss y

microcode. SLIM checks tor common sorts of errors , suc l1 as tailing to assign a next-state in a finite

state machine implementation , or attempting to assign more than one next-state.

Many of the hardware/mic rocode inconsistencies arise from situations where certain outputs are

beinu incorrectly used, perhaps with respect to timing, or the hardware is being instructed to preform

some task it is not physically able to undertal

IJVV

SLIM : A Language for Microcode Description and Simu~~tion in VLSl

a SLIM program are consistent and correct, two types of output-generation checl

264

John h . Hennessy

,1.\ppendix 1. Annotated Syntax of SLIM

This is the syn tax fnr tile non-Pascal portion of SLIM. Nonterminal symbols appear to the left of =;

terminal symbols in the grammar are d ist inguished by being in quotes. The metasyntax [a] means

tho.t the string a is optional, and {a) means that the strina a may b8 repeated zero or more times.

Comme:1ts cnn appear at the end of a production and are started with -- .

Program = 'program' '(td)' Ptogrlock - Co11stpnrt T~·w~dcfpat t V.::rdeclpart lopa1 t Procpart Fsm -· fl Pascal program w1th a Ism body Prochl!atltng ~ 'proc.edure' '(irl>' f Ollll;llparms ':' Defin'tionpart Procedures contain definitions Fun~.:heading = funct•on' '(id>' Fnt mnlporms '·' '(ttl)' ';' Definilionpart lopart = [' tnputs' Spec { ',' Spcc)j [outputs' S~JC;;C {','Spec}} .. Input/outpu t declaratio ns Spec = Vecto1 { '.' Vt•ctor} [ ' · PatamctN {Paratm'tct } ';'] ·An input/output vector Vector = '' I [' '(lilt)' ' '(int>' ') ) · Vector has integer bounds Parameter = 'pia' '{' '(itH)' ')' PLA numher

= 'top ' .. rop of PLA = 'bottom' Bottom of Plfl = 'e.:u hct' 'i' '' ')' · ri~Jlofi. 10 into earlier ~; tatcs = 'later' '{' '(tnt)' ')' .. Ptpelllle in to I::JtPr r.t.1tcs :: 'ren;~mer;' '(' '(td)' ')' - Rl·nomc a '>ignal (witho11t pipelining)

Dcflntttonpart = [ 't.lcftntlloo' Odimtto" {Defintticn} 1 Def111itton "' 1 '(' rattu1 ntist ')' ···)Ou tput {'and' Outpu t} ';' -- DclinitiC'n 15 a neries ol pattern lists Pat1e1111ist = Pnttern { ' ,' Patlern} -· Cach pattern It

SLIM: A Language fo~ Mic~ocode Desc~iption and Sirnuration in VLSI

Appendix 2. More Exnmples

The Full Traffic Controller from Mead/Conway

program traffic( input .output): const sho1·t = 2: 1 ong • 4; type colortype = (green,yellow,red):

signaltype = 0 .. 1: var time: integer: hl,fl: colortype: inputs outputs procedure begin procedure begm proccdu re definition

c. tl. ts : bottom: sl.hl[t .. O],Fl[l .. O] :bottom:

getinput; ( for simulation purposes only } write('car:;? '):rcad(c); e nd ;

timer: ( for simulation purposes only } if time c long then time :• time + 1 end;

highlight(color: cvlortype);

(green): hl = 0; (yellow): hl 3 1 ; (reu): hl • 2 :

begin hl := colo•· end: procedure farmlight(color: colortype); definition

(arenn): fl =0: (yellow): fl n 1; (•· eo): fl = 2;

bP.gin fl := color end; procedure stJrttimer: definition s t: begin time : ~ 0 e nd: function cars :boolean; de finition c: begin cars : ~ ( c 2 l) e nd: functi o n notca•·s :boolean ; delinition not c: begin no tears : = nc.t cars e nd: fun ctio n timeout(length: intege•·) :boolnan; definition

(long): tl: (short): ts :

t:oeqin timeout :~(time> = length) end: fun c tion not.timeout(length: inteuer) :boolean: definition

(long): not tl : (s hort): not ts ;

begin nottimeout : = not timeout(length)cnd;

Ism [ getinput: timer ] ( stale independnnt component }

highgrn: [ h•ghlight(gt·"!en): fal'mllgllt.(•·ed): tf no1.cars or not.t.11neout(lonq) => nc>~t hi (Jhgt·n:

c: signal type;

1f cars ilnd Lloneout.(long) => r st.nrttimer: next highyel ) ] highyel: [ hlghlight.{yt:lluw): farmlight.(red);

if nottimeoul(short) => ne>~t hi ghyel: if timeout(short) ~ > [ starttimer: ne>~t ra,.,ngrn])

farmgrn: [ highlight(rcu); farml1ght(green): if cars and nott i meout(long) => next farmgrn; if notcars or t1oncout(long) • > [ slarttimer: next farmyel ] )

farmyel: [ hi ghl ight(rcd); farml1ght(yellow); if noLt imeouL( short) R • • nex t farmyel; if timeout(short) => [ startlimer; next highgrn ] ].

CALTECH CONFERENCE ON VLSI, Janua~y 1981

266

Exa m ple - Computing GCD

program test (input,output); var x,y: integer; inputs

eql,eqO,gtx, gty: bottom; ou tp uts

aluopf1. .2 ] : bo tto m ; enabLA , onnul&y: top e:arlior ( 1);

p rocedu re in it; begm read(x); read(y); en d; P•Ocedure subt (v nc' (subt (x.y); next two ]; if groater(y,x) • > (subt (y,x); next two]]

three: (assert equal(x.y): 1f equal(x,l) ~> [writeln(l); return]; 1f ne(x,l) => [writeln(y): return]]

ends tate: [ halt ] .

COMPUTER-AIDED DESIGN SESSION

SLIM: A Language fo~ Mic~ocode Desc~iption and Simu~ation in VLSI

References

1. Clark, J.H. "A VLSI Geometry Processor for Graphics." Computer 13, -r (July 1980), 59·68.

2. Clark, J.H. and Hannah, M.R. "Distributed Processing in a High-Performance Smart Image Memory." Lambda 1, 3 (1980), 40-45.

3. Clark, J.H .. Hennessy, J.L. , Hannah M.R. A comparasion of two different VLSI control structures. Computer Systems Laboratory, Stanford Universi ty, Dec, 1980.

4. Duley, J.R. and Dietmeyer, D.L. "Translation of DOL digital system specification to Boolean equations." IEEE Trans. Computers c-18, 4 (Apr 1969), 305·313.

5. llolloway J., Steele, G., Sussman, G., Bell, A. The Scheme-79 Chip. Tech. Rept. 599, Artificial Intelligence Laboratory, MIT, Jan, 1980.

6. Mead, C. and Conway, L. . Introduction to VLSI Systems. Addison-Wesley, Menlo Park, Ca., 1980.

7. Weber, H. High Level Design for Programmed Logic Arruys. Proceedings of Fourth Cor.f. on Computer Hardware Description Languages. May, 1979, pp. 96· 1 01 .

CAL TECH CONFERENCE ON VLSI, Janua~y 1981