COMPUTING PRACTICES A

Welcome to Computing Practices, a new section created in response to your requests for shorter articles that are timely, technically accurate, and easy to read. Often, advances in one research area aren’t applied to oth- ers because the technology remains buried in literature seldom read by those outside the field. Computing Practices is therefore devoted to has- tening technology transfer by making “bridging” technologies in the design and use of computers and software easily accessible. Identifying these technologies will let scientists and engineers exploit the advances achieved by the various subgroups of the IEEE Computer Society.

We begin, appropriately enough, with two artides on hardwarelsoft- ware codesign. “A Framework for Hardwarel Software Codesign,” by S. Kumar et al., presents a model for evaluating hardware/software trade-offs and a model for hard- ware/software integration that sup ports abstractions and different levels of detail. “Codesign of Communi- cation Protocols,” by A. Wenban et al., provides a practical illustration of a codesign process for translating communication protocol specifica- tions into implementations consisting of both custom hardware and soft- ware.

In future issues, we will look at software tools for managing large Ada systems, at VLSl tools, at object-oriented techniques, and more. Please feel free to contact me directly about articles you liked, didn’t like, or would like to see in this sec- tion (Oman @ cs . uidaho. edu) .

- Paul Oman

A Framework for Hardware/Software Codesign Sanjaya Kumar, James H. Aylor,

Barry W. Johnson, and Wm. A. Wulf

University of Virginia

urrent design practice dictates the separation of hardware and software design paths early in the design cycle.’ These design paths remain inde- pendent. having Lery little interaction until system integration. In particu-

lar, designers often specify hardware without fully appreciating the computational requirements of the software. Also. software development does not influence hardware design and does not track changes made during the hardware design phase. This design approach restricts the ability to explore hardwareisoftware trade-offs. such as the movement of functionality from the software domain to the hardware domain (and vice versa) or the modification of the hardwareisoftware interface.

When the software and hardware are finally combined. system integration problems may require modification of the software and/or hardware. Potentially significant cost increases. schedule overruns. and performance losses can result from the premature selection of hardware whose inadequacies the software must attempt to correct.2

Furthermore. the advcnt of certain technolosics has changed design methodolo- gies for computer systems. For example. improved electronic design-automation tools and application-specific integrated circuits ( ASICs) allow complex algo- rithms t o be implemented quickly and cheaply in silicon as dedicated hardware. Conversely. reduced instruction-set computer technology lets designers transfer functionality from the processor to the sofnvare. Thus. the decision to allocate functionality to hardware or software is not straightforward.

Given these developments. the design of hardwareisoftware systems requires a more unified approach that considers both hardware and software options. This approach is called hardwareisoftuare codesign. or simply codesign.’

Codesign is a concurrent and cooperative desisn approach that includes as a fundamental component the capability to explore hardwareisoftware trade-offs. This capability leads to more efficient implementations and improves overall sys- tem performance. reliability. and cost-effectiveness. Also. because decisions

Hardware/software partition Hardware ~ ~ ~ ~ - , Software alternative

(b)

Figure 1. Hardwarelsoftware partitioning (a) and refinement (b) .

regarding the implementation o f func- tionality in software can impact hard- ware design (and vice versa). problems can be detected and changes made ear- lier in the design process.

Hardwarehf tware trade-off5 - deci- sions about whether hardware can be sacrificed for software in the derivation of an implementation - are a common theme in discussions of fault-tolerant computers. buffer memories. software reliability, minicomputers . pipeline interlocks. and real-time systems. In fac t , many t rade-of fs occur a t t h e instruction-set level. for example. dur- ing instruction-set design. Moreover. because of the new technologies men- tioned above. trade-offs extend beyond those at the instruction-set level. I n particular. hardwareisoftware t rade- offs can occur a t severa l levels of the design process and lead to other types of t rade-offs . such as per for - mance versus cost. Thus. model conri- nuirv,' a system model's capability to span these levels. is essential for the validation of system-level models and their hardwareisoftware implementa- tions.

Finally. codesign can aid the design of embedded systems' consisting o f hardware and software tailored for a particular application (for example. a d i shwasher . a robot c o n t r o l l e r . o r an aircraft autopi lot) . T h e require- ments of embedded systems include performance. reliability. and form fac- t o r ( s ize . weight . a n d p o w e r c o n - straints).

The increasing complexity of embed- d e d sys tems necess i ta tes design approaches that scale up to more com- plicated systems. Because a detailed

description of a system can be a s com- plex as the system itself. it is increasing- ly important to employ decomposition techniques and abstractions to keep analysis from becoming intractable.

Thus. a hardwareisoftware codesign methodology should support the fol- lowing capabilities:

integration of the h a r d n a r e and software design processes: exploration of hardwareisoftv are trade-offs and e\ aluation of hard- wareisoftware alternatives: and model continuity.

Below. we outline a codesign method- ology that supports many of these capa- bilities.

Definitions and terminology

Our codesign approach relies on the following definitions.' ( I n the notation belo\+. the disjunction symbol "v" is read as "or." A set refers to a collection of elements. and the empty set ..0" refers to a set with no elements.)

Functions. A fiincrion is a mapping from inputs to outputs and can include state. Therefore. successive invocations of a function with the same arguments may not necessarily produce the same effect. Function focuses on Lvhat is to be performed and is independent of an implementation. When modeling a sys- tem's behavior. a s~s tcr i i fiuicriori refers to a function to be performed by the system under consideration and is inde-

pendent of whether t h e funct ion is implemented in hardware or software.

Hardwarekoftware partitions and alternatives. T h e der iva t ion of a n implementation for a function consists of t\vo s teps . T h e first s tep is hard- itwre/softL<wr prrrtirioning (Figure 1 a). Given a collection of functions. hard- \vareisoftware partitioning refers to the selection of functions to be implement- ed in hardware and in software. The result is a hardwareisoftware partition. Harda areisoftware partitioning deci- sions may be based on performance. flexibility. or form factor.

The next step is hardware/.~o,ftware wfineiiietzr. or simply refinement (Figure 1 b ) . Starting with a hardwareisoftware p a r t i t i o n . re f i n e me n t derives design alternatives for a function and involves an interaction (represented by the ver- tical arrows) between the software and hardware design processes. Model con- t inui ty is necessary t o s u p p o r t t h e ref inement of an al ternat ive as the design process proceeds (left to right in Figure Ib). In deriving a hardwarekoft- mare alternative. software functions are implemented as software programs run- ning on a processor. and hardware func- tions are implemented with dedicated harduare modules. Hardwareisoftware alternatives represent a possible imple- mentat ion for a function and corre- spond to a specific mixture of software and hardware.

More specifically. a hardwareisoft- nare alternative A for FL (function k ) consists of a set of software units SFA. a set of hardware units H r , , and their communications C,, . A spectrum of alternatives is possible for the imple-

4 0 COMPUTER

I

mentation of a function. and each alter- native can be evaluated with respect to various metrics. such as performance and cost. Alternatives can be described at various levels of detail, and the rth alternative of Fk can be represented as

In the notation. r is an index used to distinguish between several alternatives for a function. and k is used to distin- guish be tween severa l func t ions . Software and hardware units constitute the fundamental building blocks used to implement Fk. A software unit in S, , represents a softwareiprocessor pair. possibly containing a scheduler. and a hardware unit in HFh corresponds to a dedicated hardware module. Hardware units do not require software instruc- tions to implement functionality. For example, a software program executing on a 68020 processor corresponds to a software unit. On the other hand. a fast Fourier transform ASIC is considered a hardware unit. Kumar et al. provide another view of hardwareisoftware par- titions and hardwareisoftware alterna- tives.i

Exploring hardwarekoftware trade- offs and codesign. Hardwareisoftware trade-offs take place during hardware/ software partitioning and refinement. For example. a software function ma! be transferred into dedicated hardware during refinement.

In general. numerous hardwareisoft- ware trade-offs are possible, allowing for the assignment of several alterna- tives to a particular function. Exploring hardware isoft w a r e trade-offs me an s creating and evaluating several hard- wareisoftware alternatives and selecting a n implementa t ion for a par t icular function based on some criteria. Within this context. the term codesigrz can be defined as the integrated development of the hardware and software portions of a system reflecting the exploration of hardwareisoftware trade-offs through- out the design process.

When exploring hardwareisoftware trade-offs. we evaluate the alternatives for a given function with respect t o metrics. For example. suppose that Fk

December 1993

VHDUPetri nets (Primitive elements;

.....* Analysis - Codesign *Not under investigation

Figure 2. System design methodology supporting codesign.

designates some function for which an implementation I is required. Then. a collection of 1%' alternatives being con- sidered for the implementation of Fk can be represented by

using the definition ot an alternative presented earlier. Thus. if the metric for selecting an implementation is execu- tion time ( T ) . an implementation I , ^ will be chosen using

If . however. the metric for selcctinp an implementation is reliability ( R ) . an implementa t ion I , , u i l l be chosen based on

The above expression requires a unified h a r d w a re i s o f t w a re p e r s p c c t i v e for determining the reliability of an alter- native.

A I t ern at i vc ev a I ua t i o n r e q ui re s t WO steps. The first compares individual alternatives. and the second assesses each alternative's impact o n thc overall system. These steps address two impor- tant issues in alternative evaluation: ( 1 ) the subtleties associated with integrat- ing hardwareisoftware implementations bvithin a system: and ( 7 ) the assumption that optimization of individual imple- mentations will lead to optimization of thc whole system.

To address the first issue. \ve ha \e d e ve I oped a q I I ( I I I f i ( ( 1 ti 1.6, 6, I I I ( I r io P I

modcd that compares alternatives based

on various metricsh Using a collection of weights (on a scale of 0 to 1). the model determines the qudiity K of an alternative based on the relative impor- tance of a particular metric. In deriving implementations. different metrics may be important for different system func- tions. For example. one system function may require an implementation with a minimum execution time. while another may r e q u i r e high rel iabi l i ty . T h e weights can elevate the importance of certain metrics. affecting an alterna- tive's quality and thus its selection as an implementation. (We provide an exam- ple of this evaluation niodel below.)

Codesign approach Figure 7 depicts a system design

methodology supporting the codesign concepts presented above. The method- ology is iterative in nature and serves to guide codesign exploration with the unin te rpre ted i in te rpre ted model ing approach.' This approach integrates performance (uninterpreted) models and functional (interpreted) models in a common simulation envi ronment . Using this approach. models are con- structed with a collection of primitive elements. The primitives use tokens to model the flow of information through a system and communicate via a uni- form. well-defined handshaking proto- col. Each primitive is described as a VHSIC hardware description language (VHDL) process and has a correspond- ing colored Petri net representation. As shown in the left side of Figure 2, the primitives provide a unifying represen- tation for several stages of the design process. Within the context of codesign.

41

1

Software designlevaluation

SM = Software model I t 4 = Interface model

HM = Hardware model

Higher abstractions Hardware designlevaluation Lower abstractions

Figure 3. Refinement of an integrated hardwarekoftware model.

a unifying representation (or model) can describe both hardware und software. Examples include Petri nets, dataicon- trol flow graphs, concurrent processes. and finite-state machines. Following is a more detailed discussion of the individ- ual steps of the methodology.

Step 1: System representation. A sys- tem is described as a collection of sys- tem functions (each one represented by Fk) to be performed independently of hardwareisoftware. The system func- t ions a r e descr ibed a s concurren t processes in VHDL that interact in some fashion.

Step 2: System partitioning. System functions a re mapped onto separate physical units. such as chips or boards. For example, system functions 1 and 2 might be performed on one board while system function 3 might be performed on another. One criterion for partition- ing might be the minimization of com- munication between system functions.

Step 3: Codesign. A hardwareisoft- ware implementation is selected for each system function using an integrat- ed hardwareisoftware model to explore hardwarelsoftware trade-offs.

Codesign consists of iteratively per- forming decomposition, hardwareisoft- ware par t i t ion ing , re f inement . a n d alternative evaluation for each system funct ion . D e c o m posi t i o n in v 01 v e s breaking down a system function into a col lect ion of subfunct ions . H a r d - warekoftware partitioning determines which of the subfunctions should be implemented in hardware and which in software. Refinement uses an integrat- ed hardwareisoftware model to pro- duce a hardwareisoftware alternative. Alternative evaluation uses the quanti- tative evaluation model to evaluate

individual alternatives. determines the impact of the alternative on overall sys- tem behavior. and selects an implemen- tation for the system function.

We use the integrated hardwareisoft- ware model under development during t h e re f inement s tage . As shown i n Figure 3. there are three elements of interest in developing such a model: ( 1 ) a software model (SM). (2) a hardware model ( H M ) . a n d ( 3 ) a n in te r face model ( IM) which expresses the inter- action between the software and hard- ware descr ipt ions. All of these ele- ments are described at some level of detail. Functional abstractions or data abstractions can be used to describe the software and hardware representations. Object-oriented design techniques may prove useful for these representations and are being investigated.

T h e re f inement of a n in tegra ted hardware isof tware model suppor ts model continuity and maintains consis- tency between the software and hard- ware descriptions. As hardnareisoft- ware refinement proceeds (toward the right in Figure 3). evaluation and hard- wareisoftware trade-off exploration can be performed at various stages of the design process. For example. evalua- tion of different algorithm implementa- tions of a software function on a given h a r d w a r e conf igura t ion ( a n d vice \ ersa) is possible. Also. different inter- faces (for example. various instruction- set archi tectures) can be evaluated. A pp r o ac h e s for e v a I u a t i n g co m p u t e r architectures using intermediate soft- U R I K representations and a single com- piler can be applied here!

Step 4: S\.nrhesis. Hardware realiza- tions are generated from the VHDL descriptions obtained in Step 3: high-

level synthesis. logic synthesis, and m o d u l e g e n e r a t i o n too ls would be used.

Step 5: System integration. The actu- al software is run with the synthesized hardware.

Examples of codesign 0 u r ha r d w a re i s o I t w a r e cod e s i g n

approach can be used to evaluate and optimize systems that range in com- plexity from a simple sort function to a distributed system supporting parallel discrete-event simulation.

Unifying representations and inte- grated hardwarekoftware models. The primitive elements of the uninterpret- ediinterpreted modeling methodology provide a unifying representation for hardware and software in the form of a directed graph. We have researched methods for using the primitives to develop an in tegra ted h a r d w a r e / software model and t o explore hard- wareisoftware abstractions.’ The struc- ture in Figure 4 represents the integrat- ed hardwareisoftware model.

As an examplc. a sort function was considered. One alternative, a software sort program executing on a processor. was modeled and analyzed using the structure in Figure 4. Using the primi- tive elements. u e represented the soft- ware as a dataicontrol flow graph con- sisting of a collection of computation nodes ( N ) representing functions: we represented the hardware as an inter- connection of resources. The software description consisted of 12 nodes bro- ken down into three categories: trans- form. compare. and assign. Each cate- gory reflects a particular mapping of source (src) values to destination (dest) values using mathematical operators (op) or relational ( re l ) operators. For example. a transform node would be represented a s dest = src 1 o p src 2 . compare as dest = src 1 re1 src 2, and assign as dest = src I . The interaction between software and hardware con- sisted of software functions that use various hardware resources. such as res i s te rs a n d func t iona l uni ts . W e implemented this interaction using the

42 COMPUTER

1

interface modeL5 This alternative cor- responds to a single software unit and can be described as

We simulated this alternative to ana- lyze its performance. The parameters for the simulation were as follows. The read and wr i te delays for reg is te r operands ( R ) were 10 ns and 15 ns, respectively. The read and write delays for main memory operands (M) were 200 ns and 250 ns, respectively. We chose a constant fetch delay of 400 ns, and the time to perform the actual function, that is, the functional unit (FU) delay, was either 40 ns or 80 ns. We assumed that a single functional unit performed all computations, such as add, subtract, and compare.

Given these parameters , Table 1 shows the execution times and resource allocations for five of the functions (nodes). The columns src 1, src 2, FU, and dest refer to the resources utilized in reading operand 1, reading operand 2, performing a computation, and writ- ing the result, respectively. A dash "-" indicates tha t t he resource was not used. (Note that assign nodes 1 and 3 do not require src 2 or FU resources.) Using the function execution times and sensitivity metrics, we can analyze bot- tlenecks in the software or hardware. For example, software nodes that rep- resent bottlenecks may require addi- tional hardware support or hardware optimization.

Evaluating hardwarelsoftware alter- natives. To explore several hardwarel software alternatives, we chose a square root function employing the Newton- Raphson iterative method. Four differ- ent instruction-set-level hardwarekoft- ware alternatives for the square root funct ion were developed using the u n i n t e r p r e t e d h t e r p r e t e d modeling approach. The first alternative consisted of a square root program running on a general-purpose processor. The second alternative consisted of a square root program running on a general-purpose processor with a floating-point unit. Note that both of these alternatives cor- respond to software units.

December 1993

Figure 4. Integrated hardware/software

model structure.

In the third alternative, the floating- point divide operation was performed in dedicated hardware, while all other operations were performed in software. Thus, this alternative consisted of a software unit communicating with a ha rdware uni t . T h e sof tware unit included a driver program that loaded inputs into the hardware unit, polled the hardware unit's status register to check for completion of the operation, and extracted the result upon comple- tion. The fourth alternative consisted of dividing the input data between two independent software units, allowing the square root of several data items to be computed in parallel.

The hardware was modeled using a mixture of primitive elements and cus- tom V H D L descriptions. We devel- o p e d a genera l -purpose-processor model, a simple load-store machine, that included a probabilistic instruction cache model. A memory model con- tained the instructions of the square root program. The model parameters for the hardware included the proces-

sor clock-cycle time, the hit ratio of the instruction cache. the readlwrite times f r o d t o memory, and the delay associ- ated with integer and floating-point instructions.

Table 2 summarizes some informa- tion regarding the four alternatives described above. Using the data inputs 100, 400, 900, 1,600, 2,500, and 3,249, we compared these alternatives' total execution time (the total time required to perform the square root for all six d a t a i tems). The results a r e shown under the column labeled Ttotal in Table 2. The parameters for the s imulat ion included a clock-cycle time of 100 ns, two clock cycles for memory readwrites, one cycle for instruction cache access, and a 60 percent instruction-cache hit ratio. Alternative three had the worst performance due to excessive commu- nication and synchronization.

The quantitative evaluation model can be used to evaluate the four alter- natives according to multiple metrics. For example, suppose that the metrics of interest are execution time ( T ) and

Table 1. Simulation results for sort routine execution (nodes 1-5).

~ Node Time (ns) srcl src2 FU (ns) dest 1 R

$ 2 515 R R 80 R R

' 4 705 R M 80 R

- - 615 M

3 615 M - -

~ 5 475 R R 40 R

Figure 5. Hardwarekoftware frame- work for parallel discrete-event simulation.

cost (C). Assume that the cost of an alternative is calculated by associating a cost of 1.0 for a basic software unit (soft- ware t o implement functionality plus general-purpose-processor hardware). adding 0.3 for a hardware unit or a spe- cial-purpose unit. and adding 0.3 for communications software. A floating- point unit, employed in alternatives two through four, is an example of a special- purpose unit, and the driver program used to interface to the hardware unit in alternative three is an example of com- munications software. Using this hypo- thetical cost evaluation scheme, the cost of the alternatives is shown in the col- umn labeled CtOtal in Table 2.

The use of a particular set of weights reflects the importance of the metrics and thus influences the quality of an alternative. For example. if only execu- tion time was important in evaluating the above alternatives, the weight for execution time would be assigned 1. a n d t h e weight for cost would b e assigned 0, resulting in the K~ quality values in Table 2. On the other hand. if

Figure 6. Serialized

message acknow- ledgment times

for parallel discrete-event

simulation model.

only cost was important. a \\eight of 1 would be assigned to cost and 0 to exe- cution time. resulting in the K/' quality values. If execution time and cost were equal ly i m p o r t a n t . a weight of 0.5 would be assigned t o both metrics. resulting in the e quality values. Thus, using the first set of weights. alternative four is the best choice. Using the sec- ond set of weights. alternative onc is the best choice. Finally. using the last w e i g h t ing scheme. a It ern at iv e t wz o is the best choice.

Parallel discrete-event simulation. At this time. we are applying the above concepts to an actual system. In particu- lar. we are modeling a hardwareisoft- a a r e f ramework" ' cur ren t ly u n d e r deve lopment a t the Universi ty of Virginia to support parallel discrete- event simulation (PDES). (See Figure 5 . ) The PDES framework consists of a collection of host processors (HPs) that communicate via a host communication network (HCN) using messages. The HPs execute a discrete-event simulation

Table 2. Simulation results for square root alternatives.

Alternative TtotaI (PSI Ct,t'lI Kl' Kh IC

AF\qr t ('1 ''sqrt (*I AFPqrt(3)

cqrt (4)

543 48 1 0 0 44 1 00 720 345.50 1 3 0 7s 0 81 78 1 823.40 1 9 0 00 0 44 21Y 182.30 2 6 1 00 0 00 500

l

and interface to auxiliary processors ( A P s ) using a dua l -por ted R A M (DPRAM). The APs execute synchro- nizat ion a lgor i thms a n d exchange information with a para 11 e 1 -reduction network (PRN) through a register inter- face (IniOut). The PRN. a synchroniza- tion network consisting of a binary tree of pipelined ALUs. can rapidly compute and disseminate information to the HPs.

The PDES framework incorporates an interesting hardwareisoftware trade- off. The ability to quickly compute and disseminate global synchronizat ion information is important in reducing the total time required to perform a PDES. One option is to perform synchroniza- tion and such global operations as mini- mum or maximum using software run- ning on the HPs. Another approach. represented by the PDES framework, is to perform the global operations in ded- icated hardware (the PRN) and offload the synchronization activities to sepa- rate processors (the APs).

The codesign approach discussed ear l ier can be applied t o the P D E S f r a me W O r k . B e for e code sign , t h e framework can be viewed as a collec- tion of concurrent processes indepen- dent of hardware and software (HPs. APs. and PRN) that communicate and synchronize. After codesign, the frame- work can be considered an implemen- tation for the abstract function PDES, consisting of several software units and a hardware unit. The HPs and APs are

44

I

COMPUTER

software units, and the PRN corre- sponds to a hardware unit.

To reduce message traffic in the HCN, the APs and the PRN are used to acknowledge messages sent between HPs. A two-phase acknowledgment protocol, requiring two global reduc- tions through the PRN, is used for mes- sage acknowledgments. When more t h a n o n e A P t r ies t o acknowledge simultaneously, message acknowledg- ments become serialized through the PRN. In the worst case , all APs acknowledge simultaneously. Thus, it is important to analyze the effect of this serialization on the performance of the framework.

An eight-node (N = 8 HPIAP pairs) shared-bus model for this framework has been developed. At this time, the HPs and APs are represented as con- current processes written in VHDL. Primitive elements have been used to model all other portions of the frame- work. For the worst case scenario, the simulation results in Figure 6 display the serialized acknowledgment times for messages sen t be tween H P s in “chained” fashion (1 to 2 ,2 to 3, and so on). As a next step in developing the model, the A P process will be refined into a hardwarelsoftware description that will be used to evaluate different alternatives, for example, different soft- ware units. The techniques and models described earlier will be applied to per- form the evaluation.

oday, the hardware and soft- ware design paths employ dif- ferent modeling representations

and notations. The codesign approach presented in this article a t tempts to bridge the separation between the soft- ware and hardware domains through the in tegra ted hardware lsof tware model . In addi t ion , this unif ied approach supports hardwarelsoftware trade-off exploration and model conti- nuity as the design of a system pro- ceeds.

It is desirable to provide hardware1 software abstractions that allow the evaluation of alternatives earlier in the design process. The amount of detail

December 1993

required within these hardwarelsoft- ware abstractions is an important con- cern. W

Acknowledgments We thank the Semiconductor Research

Corp. for supporting this research. We would also like to acknowledge Joanne Dugan, Robert Klenke, Richard MacDonald, David Martin, Sudhir Srinivasan, and Shivani Kumar for their comments and suggestions regarding this article. Thanks also go to Ramesh Rao and Eric Cutright for their modeling expertise, and to Ron Williams for many insightful codesign discussions.

References 1.

2.

3.

4.

5.

6.

7 .

8.

D.W. Franke and M.K. Purvis, “Hardware/Software Codesign: A Perspective,” Proc. 13th lnt’l Conf. Software E n g . , IEEE CS Press, Los Alamitos, Calif., Order No. 2140-02, 1991, pp. 344-352.

G.-C. Roman et al., “A Total System Design Framework,” Computer, Vol. 17, No. 5, May 1984, pp. 15-26.

G.A. Frank et al., “An Architecture Design and Assessment System for SoftwarelHardware Codesign,” Proc. 22nd Design Automation Conf: , IEEE CS Press, Los Alamitos, Calif., Order No. 635 (microfiche only), 1985, pp. 417-424.

G. De Micheli, “Extending CAD Tools and Techniques,” Computer, Vol. 26, No. 1, Jan. 1993, pp. 84-87.

S . Kumar et al., “A Framework for HardwareBoftware Codesign,” Tech. Report No. 920525.0, Dept. of Electrical Engineering, Univ. of Virginia, Charlottesville, Va., 1992.

S. Kumar et al., “Exploring Hard- ware/Software Abstractions and Alternatives for Codesign,” Tech. Report No. 930830.0, Dept. of Electri- cal Engineering, Univ. of Virginia, Charlottesville. Va., 1993.

J.H. Aylor et al., “The Integration of Performance and Functional Modeling in VHDL,” in Performance and Fault Modeling with VHDL, J. Schoen, ed., Prentice Hall, Englewood Cliffs, N.J., 1992, pp. 22-145.

B. Bray et al., “The Computer Arch- itect’s Workbench,” in Information

9.

10.

Processing ‘89, G.X. Ritter, ed., Elsevier Science Publishers B.V., North Holland, IFIP, 1989, pp. 509-514.

S. Kumar et al., “Hardware/Software Modeling and Evaluation in a Unified Codesign Environment,” Tech. Report No. 920505.0, University of Virginia, Charlottesville, Va., 1992.

P.F. Reynolds Jr., C.M. Pancerella, and S. Srinivasan, “Design and Performance Analysis of Hardware Support for Parallel Simulations,” J . Parallel and Distributed Computing, Vol. 18, Aug. 1993, pp. 435-453.

Sanjaya Kumar is a PhD candidate in elec- trical engineering at the University of Virginia. His research interests include hard- warekoftware codesign, performance and reliability modeling, parallel processing, and computer architecture. He received a BS in computer engineering from the University of Illinois at Champaign-Urbana in 1985, and a MSE in electrical engineering from the University of Michigan in 1986. From 1985 to 1989, he worked at AT&T Bell Laboratories in Naperville, Ill., where he participated in various hardware modeling efforts. He is a student member of IEEE.

James H. Aylor is a professor and associate chair in the Dept. of Electrical Engineering at the University of Virginia. His research interests include design automation of digi- tal systems, VLSI architectures, fault toler- ance and testing, and hardware description languages. He is currently president of the IEEE Computer Society.

Barry W. Johnson is an associate professor in the Dept. of Electrical Engineering at the University of Virginia. His research interests include fault-tolerant computing, VLSI architectures, VLSI testing, and micro- processor-based systems. He is currently serving as vice president of publications and as a member of the Executive Committee of the IEEE Computer Society.

Wm. A. Wulf is the AT&T Professor of Engineering and Applied Science in the Dept. of Computer Science at the University of Virginia. His research interests span pro- gramming systems and computer ar- chitecture. He was previously assistant director of the National Science Foundation and currently chairs the Computer Science and Telecommunications Board of the National Research Council.

Readers can contact the authors through James H. Aylor, Dept. of Electrical Engineering, Thornton Hall, University of Virginia, Charlottesville, VA, 22903-2442; e-mail jha@virginia.edu.

45