Sone key ideas originating
in the domain of software
technology have been used
in the design of the architecture
description language SMW.
MC. Escher, Waterfa/l, 1961 (D M.C. Escher Heirs c/o Cordon
Art, Baarn, Holland
Axiomatic Specifications
in Firmware Development Systems
Subrata Dasgupta and Philip A. Wilsey
University of Southwestern Louisiana
Juha Heinanen, Tampere University of Technology
ossibly the most interesting facet of microprogramming engineering is, in a very real sense, a meeting ground for software
is its Janus-like nature* On the one hand there is the older, technology and microprogramming.
P more orthodox view that microprogramming is a tech- For our present purposes we will use the term microprogramnique for implementing a computer's control unit.' That is, it is ming system to denote any integrated set of tools and techniques
basically viewed as an aspect of hardware design at the register- that can be used in the firmware design and implementation
transfer level. On the other hand many view it as a method of pro- process.
One of the problems that has attracted a great deal of attention
gramming the computer at one level of abstraction to create
another.2 The microprogramming level, according to this per- in recent years is the development of machine-independent, or
spective, is one of several levels at which abstract machines can retargetable, microprogramming systems. Such a system can be
be created. To emphasize the nature of this level relative to those used in the design, implementation, simulation, and verification
more familiar to software and hardware designers, the wordfirm- of efficient and correct microcode for a variety of microarchitecware was coined as a synonym for microprogram.
tures:I*
The discipline of firmware engineering emerged largely from
This relatively recent and widespread interest in retargetability
this latter, more recent, point of view. Broadly speaking, firmware stems from the realization that while the development of
engineering is concerned with the discovery of the scientific prin- computer-aided tools for microprogramming is a laudable goal,
ciples and logic governing microprogramming and their applica- the long and costly lead time required to develop such tools on
tion to the firmware development process.3 In fact, most of the a per-machine basis is economically unattractive. Thus, the argudevelopments in this field have been largely concerned with the ment goes, microprogramming systems will only become an indusway programming theory, languages, systems, and technology can
be effectively applied to firmware development.3
Some of the important issues in this domain include the design 'Janus, the Roman god of gates, had two faces looking in opposite directions.
and implementation of high-level microprogramming languages;
V.We use the term microarchitecture to mean the architecture of the computer as
strategies for generating, optimizing, and compacting microcode;
by the assembly language microprogrammer or the microcode compiler writer.
techniques for the systematic design of firmware; and the formalAseen
A retargetable microprogramming system is "retargetable" in the sense that it can
verification of microprograms. As these topics suggest, firmware be used to generate, verify, optimize, or simulate microprograms intended for exeP
An earlier version of this article was presented at the Seventh International Symposium on Hardware Description Languages, held in Tokyo, August 1985.
July 1986
cution on different "target" microarchitectures. This use of the word target is quite
the opposite of its use in the traditional microprogramming literature: There, the
architecture that executes the microcode is called the host machine, while the architecture that the microcode implements is the target machine.
0740-7459/86/0700/0049$01.00 © 1986 IEEE
49
Formal description of
microprogram in a
high-level, machine-independent
microprogramming language (HLML)
HLML compiler
Formal description
of microarchitecture A
in an architecture
Vertical microcode
description language (ADL)
Optimizer/
compactor
§
(Possibly horizontal)
microcode for
microarchitecture A
|
|
~~~ADL compiler
ADlopl
l
Internal representation
of A
User
interface
i
Figure 1. The general structure of a retargetable (machine-independent) microprogramming system.
trial reality if a single system can be used and reused in different
processor development projects.
Figure 1 gives the general structure of a retargetable microprogramming system that can be used for designing, producing,
and testing microprograms for (in principle, at least) arbitrary target microarchitectures. A microprogram specified in a high-level,
machine-independent microprogramming language is compiled,
optimized, and compacted to produce microcode (usually of a
horizontal type). In the absence of a "real" processor (possibly
still under construction) the microcode can be executed and
debugged on a simulated target machine. In fact, the simulator
is useful for testing and debugging even when the corresponding
and nonprocedural (or rule-based) invocation of actions-have
found their way into the design of S*M. At the same time, in constructing specifications of microarchitectures, one encounters
several problems not normally encountered in the software
domain: for example, side effects, residual control, transient storage values, and timing. Thus, as in most facets of firmware engineering, what we see here is not simply a transfer of technology
from software to firmware; rather it is the judicious and creative
adaptation of software theory and technology to suit the particular idiosyncrasies of the microprogramming environment.
Machine independence in such a system is achieved by formally
describing the microarchitecture in an architecture description language, or ADL, translating this description (if necessary) into an
appropriate internal representation, and providing the other components with this representation. Several retargetable microprogramming systems with one or more features in common with
Figure 1 and with varying degrees of sophistication have been
implemented or are presently under development.3
Figure 2 shows, in highly simplified form, a machine-independent system for the formal verification of microprograms currently being developed by Damm et al. at the Technische
Hochschule in Aachen, West Germany.4'5 Again, the boxed components are intended to be machine independent, and the system's
retargetability is achieved through the formal description of
microarchitectures in some language.
Our focus in this article will be on the rationale, design, and
implementation of a language called S*M, which has some distinctive characteristics that seem appropriate for the specific problem of describing target architectures that can serve as inputs to
retargetable firmware development systems. In particular we wish
to show how some of the key ideas originating in the domain of
software technology-specifically those on functional specifications, axiomatic (or assertional) proofs of program correctness,
To summarize the preceding discussion, in designing S *M we
desired a language that would be useful for (1) the description of
clocked microarchitectures that would serve the needs of automatic, retargetable systems for microcode generation, optimization, compaction, and verification; and (2) simulating the
operation of machines at the microarchitectural level to evaluate
the performance of, or to debug and test, microprograms.
Note that implicit in both uses is the assumption that the target system (microarchitecture) already exists and that what is
required is a means of formally specifying this system. Most of
firmware development, however, is intertwined with the concurrent development of the target machine that will execute the microcode. Thus we add the following intended application of S*M: The
formal specification of clocked architectures at varying levels of
abstraction down to and including the microarchitectural level as
may be developed during the systematic design of architectures.
A key issue that crops up at this point is whether the ADL
should support operational or functional descriptions.6 In an
operational description the user defines the behavior of a system
in terms of a program or algorithm. In contrast, functional
descriptions represent a style in which the behavior of the system
is specified in terms of one or more mappings from the set of system inputs to the set of system outputs without, however, reveal-
real machine is available.
50
The need for functional descripffon
IEEE SOFTWARE
Formal description
of microprogram in a
high -level microprogramming
language (HLML)
HLML compiler
Internal representation
of microprogram
Formal description of
microarchitecture A
in an architecture
description language (ADL)
ADL compiler
Internal representation
of A
IFigure 2. A machine-independent
It
microprogram verification system.
ing how the system performs the mapping. That is, functional
descriptions treat the system as a black box whose behavior is
defined only in terms of inputs to and outputs of the system. Functional descriptions, in other words, reveal only the functionality
of the system.
It should be clear from the foregoing discussion that functional
descriptions are pragmatically necessary in two areas: as a means
of postponing decisions concerning the internal details of a system (or subsystem) and as a means to confessing ignorance of the
internal details of a system (or subsystem).
Postponing decisions: The design of
abstractions
As one
notedofabove,
oftheintende
on
l
s oS*M
As noted above,
the intended
of S* isi s to
applications
support the systematic, controlled design of target machine
w,7 t
architectures. Given an informal design to begin Wt,
language would serve to express and document the design in a formal fashion down to a level sufficiently detailed for implementation.
However, there may be a substantial gap between informal
design and formal descriptions, and the problem is to provide the
means to bridge this gap effectively,
One of the techniques advocated for this is abstraction-a simplified or selective description of a system that emphasizes some
of its properties while suppressing others.8 Thus, a procedural
abstraction, for instance, describes the intended behavior of a pro-
cedure while deliberately ignoring the details of how this behavior
is realized. A data abstraction defines the "behavior" of a data
object purely in terms of the operations (specified in turn as procedural abstractions) that can act upon or manipulate the object
while ignoring the internal structure or representation of the
object. Both forms of abstraction can be achieved, as will be seen
later, through functional descriptions.
In the design process known as stepwise refinement, key steps
in each state of the refinement include the identification of distinct modules and the creation of abstractions for these modules.
The abstractions serve two functions: a use function which characterizes all that needs to be known about a module to use it as a
component in the system, and a requirement function which iden-m
tifies the purpose and objectives of the module that must be satisfled when the module is refined to the next level of detail. Again,
note that a functional mode of specifications provides the appropriate medium in which to express these characteristics and needs.
JulIy 1986
Confession of ignorance
In contrast to the above, which is a case of pretending ignorance,
there are situations in which we actually do not know the internal workings of a system, and, equally important, we do not particularly care. Consider, for example, the application shown in
Figure 1. In formulating the description of a machine's microarchitecture, we may be totally ignorant of the internal structure and
logic of many of the hardware components-the arithmetic-logic
unit, or ALUJ, for instance. One sees the ALU as a primitive entity
whose internal workings one has no control over or access to. The
only property of the ALU that is known to the microprogrammer,
or firmware engineer, is how it responds to external stimuli-the
micro-operations.
Note that we may certainly define this behavior in operational
terms. The problem is that in describing operationally an entity
whose internal structure is unknown to us, we may have to make
unwarranted assumptions about the system. The use of functional
descri
ptions
abovide system. eve elegant,
descriptions may instead provide a convenient, even elegant,
means of confessing to our ignorance about the internal logic yet
enable us to describe the system adequately.
In summary, given the needs of our particular applications, a
language that fundamentally supports functional descriptions was
deemed necessary.
Axiomatic style of functional
descriptions
The ideas presented so far owe a substantial debt to concepts
in programming methodology and software specification languages.8'9 In fact, there are several styles of functional descriptions: one is based on abstract heterogenous algebras,9 another
on Lisp-like functional or applicative languages.'0
S*M follows a third style of functional descriptions; it is an axiomatic language whose main characteristic is that the behavior of
a system is expressed in terms of assertions in some axiomatic or
deductive system. Consider, for example, a system module M that
computes a state transformation function:
f S -~S
where S is a set of states. Then the essence of an axiomatic description is to specify this function in terms of an ordered pair of assertions <PRE, POST> which carries the following meaning: If the
state is such that PRE (called the precondition) is true when M
51
Shifter
l~~~~~~~~oa
AI
Figure 3. A partial view of a 32-bit data path.
is activated, then when M terminates, the state will be such that
POST (called the postcondition) is true.
In a certain sense, then, the assertions PRE and POST together
capture the behavior, or "meaning, " of the module M. There is
thus a natural analogy between the way system behavior is defined
here and the axiomatic semantics of programming languages
where the meanings of language constructs are also defined in
terms of assertions or formulas in a deductive system. I' Hence
the term "axiomatic description. " In fact, the roots of axiomatic
descriptions presented in the next section go back to Parnas's early
work on software module specifications,12 which later formed
the basis for the software specification language Special at SRI
International.9
Axiomatic specification: Notation
and examples
We will illustrate the use of axiomatic specifications through
examples. The notation and syntactic entities used here are based
on the language S *M. 13
Informal description. Figure 3 is a block diagram of the
ALU/shifter part of a 32-bit data path that is inspired by but not
identical to the data path of the Nanodata QM-1.7 It thus
represents part of a machine's microarchitecture.
the logical shifts involve 65-bit quantities (carry included).
Shift operations are specified by the microprogrammer through
a 7-bit shift-amount field and a 5-bit shift control; the latter has
subfields for the shift type (circular, logical, arithmetic), mode
(single or double), and shift direction (left or right).
Test conditions. Six test conditions are generated by the
ALU/shifter system:
* carry: the output of COH;
* sign: the high-order bit on the AOD bus;
* result: the bit-wise logical "or" of the low-order 31 bits on
the AOD bus;
* overflow: set if and only if the carryin to the sign bit and
to the carry-out positions are of opposite values;
* shifter high bit: the high-order bit on the SOD bus; and
*
shifter low bit: the low-order bit on the SOD bus.
Timing. The machine is controlled by a three-phase clock cycle
(or microcycle). The first and third phases are both 25 nanoseconds long, while the second phase is 50 nanoseconds. Basically,
the timing scheme is so defined that a pair of operands can be
gated from local store to the ALU or shifter, an arithmetic/logical/shift operation can be performed, and the result can be written back to local store in one microcycle. The shifter operates in
the second phase of the clock. Test conditions are generated in and
remain stable for the duration of the last phase.
The shifter. Consider in particular the shifter. This unit can perform a number of different shift operations on the data present
Formal description. Our objective is to provide a complete and
on the SID bus. The result is placed on the SOD bus, where it is accurate specification of the shifter as perceived by the microavailable for gating to a local store register upon execution of a programmer or the implementer of a microprogramming system.
particular micro-operation. When no shifter operation is speci- It is clear that we must both confess to and feign ignorance regardfied, the shifter simply passes the value from SID to SOD.
ing much of the shifter; typically, a microprogramming manual
The following types of single shifts can be specified:
or "hardware user's guide" will provide descriptions of machine
* left and right logical-zeros shifted in at one end, bits shifted behavior much as we have done above. Thus, any attempt at
off the other end;
developing an operational description would be presumptuous at
* right arithmetic-sign bit extended (copied) rightward, bits best and grossly inaccurate at worst. Furthermore, the user of the
shifted off right end; and
microarchitecture description does not normally need to know
* left and right circular-rotations of the 32-bit quantity. exactly how the shifter works or how the three-phase microcycle
Each of the above operations can perform shifts of 0 through is actually realized.
32 positions without any time penalty associated with the shift
Our first version of the shifter description will be as depicted
amount. When single shifts are specified, the shifter extension in Figure 4. Here, we have global definitions of two data types,
(SHXTN) functions as a direct connection from the ALU output a collection of stores that are instances of predefined or the
to the AOD bus.
declared data types, and a clock.
When a double shift is specified, SHXTN and the shifter operate together, accepting the output of the ALU and the value on
Data typesand stores. The primitive data type in S*M is the bit,
the SID bus as the high- and low-order halves, respectively, of a while structured data types are built from the constructors
64-bit input. The corresponding halves of the 64-bit double-shift sequence, array, and record. In this particular example all the
output appear on the AOD and SOD buses, respectively. The types stores are instances of either the primitive data type bit or the userof double shift are similar to the types of single shift except that -defined structured data types "microinst" and "bus." Of spe52
-IEEE SOFTWARE
system
micro-example
type microinst is record . end record
type bus is seq[31..0]of bit
store
mir: microinst;
sid, aod, sod: bus;
cih, coh: bit;
pseudo psign, presult, povflo, pshb, pslb: bit transient after(25ns);
pseudo alu: bus;
clock clk
aligned with tk = Ons
dur lOOns
subclock
phl : dur 25ns;
ph2: dur 50ns;
ph3 : dur 25ns
end clock
module shifter . . end module
end system
Figure 4. Overview of shifter system description.
cial note in the definition of stores is the declaration
pseudo psign, presult, ..., pslb: bit transient after(25ns)
In the formal specification of architectures it often becomes
necessary for the sake of clarity to postulate storage elements that
are not explicitly visible in the informal description or block diagram. For instance, the informal shifter description simply states
that six "conditions" are generated as a result of ALU/shifter
operations that may be subsequently tested. Where these conditions are held is not specified. It is convenient in such situations
to use pseudo stores to model such entities.
Another idiosyncratic feature of microarchitectures is that certain stores may retain the most recently written values for only a
specified period of time after which the state of the store is reset
to some standard default or becomes undefined. Any language
intended for the description of microarchitectures must be able
to distinguish between such transient stores and the more common static stores.6 The pseudo stores psign, presult, ..., pslb are
instances of such transient stores, and their declaration states that
their values (which, as we'll see later, are actually set in the second phase of the clock clk) are retained only for a duration of 25
nanoseconds-that is, for the duration of the third phase of clk.
The value becomes undefined hereafter until it is subsequently
reset. Had there been a default value, such as 0, for these transient
stores, the last part of the declaration would have indicated this
fact:
phl, ph2, and ph3, of durations 25, 50, and 25 nanoseconds,
respectively, and that the clock begins its cyclic behavior when syn-
chronized with the initial value of tk = 0.
For the description of the shifter system, a single clock definition suffices. In general, though, different architectural components may exhibit different timing characteristics, in which case
several clocks would be declared, each synchronized with some
particular value of the timekeeper and designating a particular
set of periodic events in the target architecture. For example, a
machine description may require the clock declarations shown in
Figure 5. The timing diagram corresponding to these declarations
is given in Figure 6.
clock
clkl
agnd w
dur 100ns
sub
end clock
July 1986
ph
: dur 50ns;
dur 5Ons
clock clk2
aligned with tk
dur 75ns
du
phi:
bit transient after(25ns,0)
Clocks. The clock clk is synchronized with the initial value of
a global timekeeper (tk), which is simply a counter that increments
itself after a predefined unit interval-in this example, a nanosecond. In contrast to tk, which keeps "linear" time, a clock declaration allows us to describeperiodic events, or cycles. The clock
definition simply states that it cycles through three phases or states,
plockphi
|l
end clock
50ns
r
25ns;l
ph2 : dur 25ns;
ph3 : dur 25ns
Figure 5. Definition of a two-clock system.
53
tk j
0
clkl
cIk2
clk2
25
ph
50
75
|
h
~~phi
100 125 150 175 200 225 250 275 300
-
.
ph2
ph3
Figure 6. Timing diagram for the two-clock system.
In more complex situations, the duration of a particular clock
can be stretched, depending on some condition being true. This
situation is illustrated in Figure 7, which is part of a VAX 11/780
microarchitecture description in S *M.13 Here, C2 is a singlephase clock with two inputs (designated as inports), the (previously declared) stores mir and interrupt. Under normal conditions
the duration of C2 is 50 nanoseconds. However, when the value
of the (bit type) store "interrupt" is 1, the clock duration extends
to eight times the normal duration, or 400 nanoseconds. When
interrupt = 0 but mir.kmx > 8, the duration of the clock doubles. When a clock duration is stretched, the duration of its constituent phases is also stretched by the same factor.
It is important to note that the admission of an arbitrary number of clock definitions in an S*M description does not imply the
presence of an equal number of "physical" clocks in the real
machine. The description is intended to reflect accurately the overall timing behavior of a target microarchitecture and not the means
by which the behavior is realized. (A more rigorous formulation
of the entire model underlying the structure, behavior, and timing of microarchitectures is provided by Wilsey. 13)
Modules
A module may also contain private declarations of stores and
store types. Obviously, such declarations are visible only within
the module and are inaccessible to the external environment.
A guard is of the form
{Boolean condition, clock (or subclock) identifier}
and denotes the fact that if the Boolean condition is true, the timing behavior of the module as a whole is defined by the clock (or
subclock) specifier. In general, a module can be controlled by
several mutually exclusive guards, although in the example here
only one guard is given. Thus, each of the operations depicted
within the effects section of Figure 8 can be activated at the beginning of the clock phase clk.ph2 and is guaranteed to terminate at
the end of the phase.
Consider now the specification of module behavior-for example, the effects of the single right arithmetic shift operation. The
semantics ofthis operation are described in terms of pre- and postconditions shown in the effects section in Figure 8. Taken in conjunction with the guard definition, such a declaration states that
if the precondition is true at the beginning of a guard's clock
period, then the result of the operation satisfies the postcondition
that will hold at the end of the guarding clock period. In S *M, we
therefore activate operators nonprocedurally, that is, not by
explicit calls but by the fact that some particular condition
holds. 13 This aspect is further discussed in the next section.
Although we are eschewing operational descriptions for the
semantics of operators, we would, for obvious reasons, like to
make the axiomatic specifications as "programlike" as possible;
hence, such considerations as modularization, structuring, under-
Consider now the definition of the module named shifter. Our
intention is to define this in terms of
* its interface with the environment-that is, the means by
which data passes to and from the module and the means by
which the module may be activated;
* its timing characteristics; and
* the meanings of the constituent operations of the module.
Leaving aside for the moment the last of these items, we charac- _terize the shifter module according to Figure 8. Basically, this
clock C2
defines the shifter as a data abstraction comprising a set of input
and output ports which provide the module's data interface with
i o
inport
its environment, a "guard" (see below), and an effects section
mir.kmx;
which specifies the behavior of this module.
interrupt
The port declarations refer to one or more of the stores previwith tk
Ons
aligned
dur SOns
ously declared globally (as shown in Figure 4, for example).
Although not shown in this example, it iS possible for an
input/output port to be bound to a module for the entire durastretch
tion of the module's activity. For example, the declaration
{(|
{ interrupt),d(8}kx
inport sid bound
end clock
causes the store sid to be dedicated as a port to shifter; no other|l
active module can use sid as either an input or an output port while
the shifter is active.
Figure 7. A stretched, one-phase clock.
54
,,8),2}
IEEE SOFTWARE
module shifter
inport sid; mir; alu
outport sod; psign; presult; povflow; pshb; pslb
inoutport cih; coh
guard {true, clk.ph2}
effects
case mir.f34[3..01 is
when 2#0100#
when 2#0101#
when 2#1100#
when 2.#1101#
when 2#1001#
when 2#0110#
when 2#0111#
when 2#1110#
when 2#1111#
when 2#1011#
end case
end module
=>
=>
>
=>
>
>
>
=>
=>
=>
.
...
...
..
. . .
. .
. ..
. ..
. ..
..
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
left logical */
right logical *7
left circular *7
right circular */
single right arith */
double left logical */
double right logical */
double left circular */
double right circular */
double right arith *7
single
single
single
single
Figure 8. Overview of the shifter module specification.
function sra(x:seq[6..0]of bit; y:seq[n..0]of bit):seq[n..0Oof bit=
if y[n]
then shr(x,y)
else shrl(x,y)
end if
end function
when 2#1001# -> /* single right arithmetic *7
if mir.f35 <= 32 then
new sod = sra(mir.f35,sid) &
new sod[31] &
new pshb
new pslb new sod[O]
end if
Figure 9. Definition of a private function.
standability, etc., must prevail. Figure 9 is thus a specification of
the single right arithmetic operation in a structured form that uses
a private function called sra. Note that sra in turn uses primitivelanguage-defined operators shr and shrl.:These denote, respectively, operations that perform a right shift with O's inserted at the
high-order end, and a right shift with l's inserted at the high-order
end. Note also that sra is defined as a generic function in the sense
that its formal parameter "n" is bound to an integer constant at
compvile time.sy
The precondition for the single right arithmetic operation iS
defined by conjunction of the when and if clauses and states the
values that fields f34 and f35 of mir (the microinstruction register) must satisfy. If this precondition holds, the behavior of the
operation is given by the rest of the specification. The notation
"new x," wherexidentifies an output port, denotes the new value
of x- that is, the state of the port x existing at the termination of
the (sub)clock guarding the operation. When the postcondition
contains a reference to an old value of a port, the prefix new is
simply omitted.
Consider now the specification of a double shift operator, say,
double right logical. In the case of double shifts the input and output ports are virtual 64- or 65-bit entities, as indicated in the informal description. We thus declare the following synonyms:
syn
compile
timc~~~~~~~~~~~double
sicLwitL_carryin:seq[M4..O..........
jof bit = alu @ sid @ cih
dobeowiharnse[.O fbt=au@sd@
July 1986
coh
which create two virtual 65-bit sequences that are concatenations
of previously defined data objects and assign identifiers to these
entities. Figure 10 describes the double right logical operation. Its
postcondition refers to private function "concLpresult, " which
55
function bit_or
'if n=
end if
end function
(x:array(O ..m)of bit;n:seq[5 ..O]ofbit):bit
=.: '
then x(1) or x(O)
else x(n) or bit or(x,n-1)
function cond_presult(x,y:seq[31..0]of bit):bit=
if mir.f34[5] or mir.f34[4]
then bit or(x[30..0]@y,61)
else bit_or(x,31)
end if
end function
when 2#0111# => /* double right logical */
if mir.f35 <= 64 then
new double_sod_with_carryin
shr(mir.f35,double_sid_with_carryin) &
new psign = new double_sod_with_carrvin[641 &
new presult = cond_presult(aod,sid) &
new pshb = new sod[31] &
new pslb
new sod[03
end if
Figure 10. Specification of a double right logical shift operation.
in turn depends on the private recursive function "bitLor."
In this particular example, a specific module has been defined.
It is also possible in S*M to define a module type and declare
instances of this type. 13
We can illustrate further the nature of nonprocedural activations by showing the interaction between the shifter module (Figure 8) and a module called "fetch" which is intended to fetch a
microinstruction from control store and place it in the microinstruction register. However, the precise outcome of this fetch process depends on the current state of the microinstruction
Nonprocedural interaction of modules register-for example, whether or not the latter encodes a branch
As previously noted, modules in S*M are activated not through
explicit calls, as in a procedural description, but nonprocedurally;
that is, they are activated by one or more conditions being true
at the beginning of a clock period. More specifically, the activation of a module is determined by the following conditions:
* The module is not active.
* One or more of the clocks in the guard list associated with
the module are entering a period of activity in the current unit
interval of the timekeeper. We refer to these as "rising"
clocks*
* One and only one of the Boolean expressions in the guard
list associated with a rising clock is true.
Under these conditions the module becomes active, and the rising clock associated with the Boolean expression that is true
becomes the controlling clock for the module. At the fall of the
controlling clock the postconditions associated with the precondition (that is, the assertions in the effects section defined on the
input ports and/or private stores) that was true at the rise of the
controlling clock will hold.
Note that if the three above-mentioned conditions hold but
microinstruction. A specification of a portion of fetch is given in
Figure 11. Note the presence of private stores in this module; the
init clause in the declaration of mpc indicates that mpc i$.initialized to some constant value.
This module should be read in conjunction with the description of shifter. Since the durations of fetch and shifter overlap,
and since it is possible for preconditions in both modules to be
simultaneously true, the modules may be activated in parallel.
One must therefore ensure that the concurrent activation of
these two modules does not allow them to interfere with one
another. Specifically, in this case, the value of mir at the beginning of clk's activity should not be destroyed (by the new value
resulting from fetch's activation) prior to the fall of clk.ph2 (that
is, prior to the termination of shifter). The semantics of S *M guarantee this, since the postcondition for the fetch module is said to
hold only when the module terminates; prior to that, mir holds
the game value as at the beginning of clk's activation*
In general, it will be up to the S*M user describing some
architectural system to formally demonstrate that certain global
properties resulting from the interaction of the constituent modules are satisfied-for example, that the system is deadlock free,
or that it is interference free, or that the specification as a whole
is consistent.
Note that since we express module behavior in the form of pre-
*ln this discussion we will appeal to the reader's intuitive understanding of what
we mean by rise and fall of the controlling clock. A rigorous characterization of these
predicates is provided by Wilsey.'t3
/otodtos
none of the preconditions in the effects section are true, the effect
is the equivalent of a "no-op" (that is, time passes, a clock cycle
is consumed, but no state change takes place).
n
osnthv opoeayhn
buhs
*In this entire discussion, "time" refers to the values of the timekeeper.
56
.I EEE SOFTWVARE
module fetch
inoutport mir
store
cs: array(O. .8196)of microinstr;
mpc: seq[12..O]of bit init (...)
guard {true, clk}
effects
if mir.f26 then /* sequence to next */
new mir = cs(mpc) &
new mpc
mpc + 1
else
/* branch to next */
new mpc= mir.branch &
new mir
cs(mpc)
end if
end module
fetch module.
Figure 11. A microinstruction
effectso
descriptions: the axiomatically defined behavior is taken as given.
These assertions are then used in essentially three ways: (1) as funcend if
tional specifications for subsequent (possibly operational) implementations of the modules-either through systematic manual
design procedures or automated synthesis; (2) as functional
specifications of the target architecture that can be used in
code/tmicrocode generation, synthesis, and verification; and (3) as
axioms of module behavior which are used for proving global
properties of the system as a whole. While this latter problem is
beyond the scope of this article, it should be evident that such
demonstrations require an axiomatic proof theory for S*M4. Such
legmnt
A compiler that generates virtual machine code from S*M
has been completed, and we have also completed the
descriptions
mmets
implementation of an interactive simulator that interpr'ets the
compiler-generated code. It is interesting to note that the simulated machine isgnrated directly from the functional description. The S *M software runs in a VAX 11 /780 Unix environment.
We are presently investigating the use of S*M4 in the context of various firmware engineering and other system design applications.
Acnweg
nt
mentatios
thmurrently
oduleseither
hroughsstemati manua
Hussoe-gnerte
Mcroprogrammsing:eresincile aondtPractie Prentimua proofof
teoryis
nder devlopment.This
work was supported in part by a grant from RCA Corporation and
n this article we have argued
for, and illustrated with exam-
by grant DCR 8408750 from the National Science Foundation. We would
like to thank Werner Damm and the referees for their many useful
flples, the use of functional specifications of clocked architecbytmasiadvantages
fatue
latte prbleeni
wofeofSWhileu
thinkn
Inopevteslopin
tures. The the
such specifications
primary
appear
when we wish to either postpone making operational design deci- References
1.pl.5.nHusson oprogramming PiplanPraticerpretice
sions or express our ignorance of the internal structure of mode ngewoom Cliffs, N.J,r170
Hall,
ules.iWe have illustrated the key ideas of the axiomatic style of
2.
functional specifications and its association with nonprocedural
tion,"ainandbok/f8oftwaengineng,
descriptions with example S*M descriptions of microarchitectural
C.R. Vick and C(V. Ramamoorthy, eds., Van Nostrand Reinhold, New
l|osopyt those exiitdb
fn thenalseiianguage AAD develoed by5aWramcnhGiohmntVeiictocicorgrme
York, 1984, pp. 134-148.
components.
thdue
ofh Se dfordiferetinlesg
thinking deis
3 eomuere
S. Dasgupta
and
B.rD.
Shriver, "Developments in Firmware Engineer' Perhaps
Damendevelsopin
toether
mostp fundameknta
tht
Archiectrsish
In basifehatore
inAdvances
in Computers, Sse:AaeSuy"Po.1t
Vol. 24, M.C. Yovits, ed, Academic
S.S.
Microprogramming
: (MC nd) NewYork,
Workshople
PrnieEE
Prs,NwYk,18,p.0276
heavily influenced by -Parnas's early work in module specifi- 1. Husson;~~~Ann
AAuLc
bby the work of Lisko These
with
thnmconprogedrammn
Copue
Press<muato,>
oko
Sfwrenieei
1
985.
ationd musta
thanduspedinicatonjuandisacition
influences come 4. W.
of
Damm,Societ
"Stepwise Design Microprogrammed Computer
languageioscwihemaml
Swheeascrip*Mois
*M
ofmpleachtecua
sefC..Vk
and
6.5VDsupa
D esritio
hy Microprogramming
Languagstrn RinhMcoprogramare
behind S -*M
domain. Other ideas
Proc. 18th
Ann.
directly from the software
Architectures,""Hardamore
Workshop
sufficients.
mn
Copuer
System,"New
Thspoabyepanswyteerrklo,eeaifeVo.384N.-,Fe.195,pp87-6
from the arena
of microprogaramnmin and are very similar in phi(MICRO-18),
York, IEEE
Computer Society Press, 1985.
*
hasbeen
ence in he peciicsof te to laguaes, hic wil beevidnt
when thelangluaesebPareascompared indetail.
or
Juonly1986
tewr
fLso.8Teeifune
~~~~~~~~~~~~~~~~~ing,"
3. 5. Dasgupta, hDsg
and
BDShie"Desrptopmnt
of Co rmpuearchEniteues,
JohniWileys
&e Sons, New5 York198417.
oe
4 W
am
Sews
einofMcorgamdCmue
8. B. Liskov, "Modular Program Construction," in Abstract Software
Specifications, D. Bjorner, ed., Springer-Verlag, New York, 1980,
(LNCS-86).
9. M. Melliar-Smith, "System Specification," in Computing Systems
Reliability, B. Randell and T. Anderson, eds., Cambridge University
Press, Cambridge, UK, 1979.
10. S.W. Smoliar, "Applicative and Functional Programming," in Handbook of Software Engineering, C.R. Vick and C.V. Ramamoorthy,
eds., Van Nostrand Reinhold, New York, 1984, pp. 565-597.
11. J. deBakker, Mathematical Theory ofProgram Correctness, PrenticeHall, Englewood Cliffs, N.J., 1980.
12. D.L. Parnas, "A Technique for Software Module Specification with
Examples," Comm. ACM, Vol. 15, No. 5, May 1972.
13. P.A. Wilsey, "S*M: An Axiomatic, Non-Procedural Hardware
Description Language for Clocked Architectures," Center for
Advanced Computer Studies, Univ. of Southwestern Louisiana,
Lafayette, La., 1985.
Subrata Dasgupta is a guest editor of this issue of IEEE Software. His
photo and biography appear on page 5.
(
10 o
i nu
Philip A. Wilsey received his MS in computer science in 1985 and is currently working toward his PhD in computer science at the University of
Southwestern Louisiana. His research interests include the study of hardware and firmware design systems.
Juha 1. Heinanen is associate professor of computer science at the Tampere University of Technology in Finland. He has been active in computer
design and microprogramming language areas. Currently, his research
interests range from hardware description to operational specification of
software. Prior to holding his current position, Heinanen was a visiting
faculty member at the University of Southwestern Louisiana. He received
his MS in computer science from the University of Thmpere in 1977, and
his Dr. Tech. degree in computer science from the Tampere University of
Technology in 1983.
United Technologies Research Center, a recognized source for broad ranging research of the first rank has gained wide recognition for significant
achievements both in basic and applied research. Here you'll discover a
research environment tailored to your needs ... top researchers ... ample
funding ... outstanding back-up services ... a scientifically-oriented
management ... encouragement and reward for publication of papers.
Expanded activities in Computer Science Research offer you an opportunity to build professional recognition in a wide spectrum of
assignments. Projects span the area of Ada, Ada support
envirnm ents, and formal approaches to software development. The diversity of the projects offer wider exposure
r and
t
earlier recognition of your talents.
!Weare particularly interested in candidates who have a
s e.
or PhD degree in Computer Science with signifis v Master's
cant course work in software
ta
engineeering, data-base/
knowledge-base management, operating systems, formal
specification and design languages, and Artificial Intelligence. Research
experience focused on Ada, Ada support environments, UNIX and
knowledge-based software development techniques would be advantageous.
Find out more about the advantages that include excellent compensation
and benefits. Send resume with salary history in confidence to:
Dr. M.H. Kuhnly, United Technologies Research Center, Silver Lane, East
Hartford, CT 06108.
SL1n
cle
-i-v.L
Software
Development
p
UENUNITED
TECHNOLOGIES
RESEARCH
CENTER
An equal opportunity employer * U.S. Citizenship required