Object-Oriented Techniques in Hardware Design Sanjaya Kumar, James H. Aylor, Barry W. Johnson, and Wm. A. Wulf

University of Virginia

echnology transfer between the software and hardware domains - that is, the appli-

cation of concepts and principles from one domain to the other - has begun to break down the once rigid boundaries between these two engineering disci- plines' (as is starting to happen in hard- warekoftware codesign2). For example, software compilation techniques such as dead-code elimination, loop unrolling, and register allocation using lifetime analysis are embodied in high-level, hardware synthesis t o o k 3 With the advent of hardware description lan- guages and the increased use of simula- tion and modeling in the hardware de- sign process, individuals who model hardware often take on the role of soft- ware programmers.

Given this trend, it makes sense to ex- plore other software techniques that might improve the hardware modeling process. The use of object-oriented tech-

niques, for example, can be invaluable in hardware design. Coupled with the use of hardware abstractions, object- oriented techniques can aid in managing hardware complexity and change, just as they have in the software world.

Although object-oriented techniques might seem foreign to hardware design- ers, many of the underlying concepts and principles are familiar to them. For ex- ample, the construction of systems using reusable library components, a highly touted advantage of object-oriented tech- niques, manifests itself in the hardware world as design using off-the-shelf build- ing blocks4 Using hardware building blocks lets designers quickly construct systems, lowers overall design cost, and increases reliability.

In this article, we focus on using ob- ject-oriented techniques to improve the hardware design process. The advantages of these techniques for hardware design include:

improved modifiability and main- tainability of models; easy component instantiation with different parameters;

*quick composition of new compo- nents; the ability to identify and reuse com- mon components; the ability to tailor general-purpose components to more specialized components; support of dynamic object creation and destruction; and the possibility of employing existing software synthesis and verification techniques.

We illustrate the application of object- oriented techniques using a load-store, reduced instruction-set processor that contains a local memory. The instruction set consists of 22 instructions, which re- quire one or two 16-bit words. Arithmetic is performed in two's complement.

64 oOlX-Y162/Y4/$4 000 1994 IEEE COMPUTER

We use C++ to demonstrate the use- fulness of object-oriented techniques, not to provide arguments for or against its use in hardware modeling and design. (The sidebar provides additional background on object-oriented design concepts.)

Modeling hardware components as classes and objects

It is natural to represent hardware components as classes of objects con- taining state information and operations that manipulate the state. For example, a register contains state information, rep- resented by its contents, and read and write operations. An arithmetic logic unit might contain the operations add, sub- tract, logical AND, and shift. At a higher level of abstraction, a processor contains state information that its supported in- structions can manipulate. Figure 1 shows these three classes.

Figure 2 contains a C++ description of the class regzkiter (class reg). The protected region contains the data structures that represent a register, and only classes de- rived from class reg can directly access this information. Other classes can ma- nipulate this protected information only through the public member functions ac- cessible by any class. The data structures and the member functions collectively constitute what is common to all registers.

There are three pieces of protected in- formation in class reg: contents, num-bits, and bitrep, which indicate the register’s integer contents, the number of bits asso- ciated with the register, and its bit repre- sentation. The data item bitrep is an ob- ject of class Bitstring; the third line in the protected region instantiates bitrep.

The primary member functions in the public region are READ() and WRITE(), which enable the reading and writing of protected information. The reg() member function is called a constructor; it executes when a register object is instantiated. By convention, a constructor has the same name as the class.

This constructor assumes a default size of 16 bits if no size is specified for an in- stance. When an object of class reg is in- stantiated, the constructor initializes the

Figure 1. Examples of hardware classes: (a) register, (b) arithmetic logic unit, and (c) processor. In general, object of a class contains state information (the object’s contents) and operations that manipulate the state.

Figure 2. In this C++ description of a register class, the protected region contains the data structures used to represent the register and is directly accessible only by classes derived from class reg. Other classes have access to it only indirectly via the member functions included in the public region - in this case, the READ and WRITE

functions.

June 1994 65

object’s integer contents to zero and calls the member function resize(). This func- tion initializes the bit representation to all zeros and sets the number of bits for the object using the member function invo- cations bitrep.clear() and bitrep.length(), respectively.

As demonstrated with bitrep, object instantiation occurs in the same manner

as variable declaration. In Figure 3, the main() program creates three register ob- jects: the condition code register (ccr), the memory address register (mar), and the memory data register (mdr). The size of the registers in bits appears in paren- theses. Thus, we can reuse the same code to create different sized registers with the same basic properties. Once these objects

Object-oriented design concepts

Data abstractions,5s6 or abstract data types, provide the basis for object-oriented design techniques and are typically used to describe user-defined data types created to represent

reflects a design decision. Parnas’ pointed out the need to

information from the users of an ab large, complex designs are likety to change many times. Thus, to preserve the ability to change a module’s implemen- tation without affecting its users, it is crucial that those users depend only upon the module’s extemal specification and that all implementations preserve that specification.

Data abstractions were invented to provide the means for enforcing at least some of Parnas’ information hiding. Consider, for exam- ple, the abstract register file depicted in Figure A. The register file includes the methods read, write, clear, and increment, and the shaded region depicts an abstract representation. The specification might define the abstract representation as a vector of elements initialized to zero, with the above methods defined in terms of accesses and modifications to this vector. The concrete representation may be some collection of combina- tional gates and memory elements. However, the user of the abstraction

are created, various operations can be performed on them, such as reading the memory address register.

Although not shown in Figure 2, we can include the member functions read-delay(), write-delay(), area(), and power() to extract the delay associated with a read or write operation, as well as the area of the register and the register’s

can only access the internal structure through the specified operations.

In C++, a data abstraction is called a class, and the meth-

can be affected

code to be reused and allows quick composition of new classes from existing ones. In some cases, many base classes can be used to derive a new class. This process is

Register file Abstract Concrete /-\ representation representation

Read Write Clear

Increment CLK

Figure A. Data abstractions hide implementation information. A specifica- tion for a register file is implemented through a collection of more primitive components, but users can only access this structure via the read, write, clear, and increment operations.

~ 66 COMPUTER

Code

main() I 1

power consumption. In so doing, we are using a software abstraction - namely, data abstraction - to describe a hard- ware abstraction at the register-transfer level. We can also use data abstraction to describe hardware at other levels of de- tail, such as the logic level.

Deriving specialized components

Starting with a collection of base classes, we can derive more specialized classes of components through inheri- tance. For example, we can use the regis- ter class shown in Figure 4 to derive more specialized registers. In particular, a pro- gram counter is a register with an incre- ment operation, and a stack pointer is a register with both increment and decre- ment operations. An instruction register is another specialized register that divides its contents into distinct fields - the op- code, the source operands, and the desti- nation of the result - requiring addi- tional member functions to extract this information. These newly derived classes obtain all of the data structures and mem- ber functions of class reg. Thus, they have an integer value and a corresponding bit representation.

Figure 5 shows the derived class sp-reg (stack pointer), wherein the constructor for class sp-reg invokes the constructor for class reg. Although the READ() and WRITE() member functions do not ap- pear in the figure, we can still manipulate the contents of a stack pointer using these functions, because this specialized regis- ter inherits the member functions of the base class reg.

Inheritance is equally applicable to the processor class and is especially useful for deriving application-specific processors for embedded systems. For example, we can derive a more specialized digital sig- nal processor from a processor with a set of basic instructions by adding a multi- ply-add-accumulate (maa) instruction. Similarly, we can use a memory array class with read and write operations to derive other hardware components, such as a memory module or a register file containing special operations such as clear and increment.

reg ccr(3); reg mar(l6); reg mdr(l6);

Comments

Create a 3-bit condition code register Create a 16-bit memory address register Create a 16-bit memory data register

int contents = mar.READ(); Read contents of memory address register 1

Figure 3. Registers are created within the main program through instantiation (allocation of memory). Thus, the same code can be reused to create different sized registers with the same basic properties.

Register -

A

Processor

-$- Digital signal

processor

Read Add Write Subtract

Increment Load Decrement Multiply-add-

accumulate

Read Write

Increment

Figure 4. A specialized component with additional operations can be created from a base class: a program counter (a) and a stack pointer (h) can be derived from a class register by adding increment and decrement operations, and a digital signal processor (c) can be derived from a processor class by adding a multiply-add-accu- mulate operation.

Code

class sp-reg: public reg ( public:

sp-reg(int size): reg(size) ( 1

{

I

(

1

void INCREMENT()

contents++; write-regbits(contents);

int DECREMENT()

contents-; write-regbits(contents);

I

Comments

Derive class stack pointer from class reg

Initialize class sp-reg

Increment stack pointer

Increment contents Write the bit representation

Decrement stack pointer

Decrement contents Write the bit representation

Figure 5. A stack pointer is derived from class register (class reg) and contains the additonal member functions INCREMENT() and DECREMENT().

June 1994 67

Code Comments

fetch(pc-reg &pc, reg &mar, reg &mdr, instr-reg &ir, memory &mem)

int contents = pc.READ();

mar. WRITE(contents);

addr = mar.READ(); Bitstring contents =

mem[addr].read-bitrep(); mdr.write-bitstring(c0ntents);

int data = mdr.READ();

ir.WRITE(data);

pc.INCREMENT();

{

I

Read contents from program

Write contents into memory address

Send address to memory

counter

register

register

regist er

register

Read contents of memory data

Write contents into instruction

Increment program counter

Figure 6. The parameters for a fetch procedure reflect the hardware components being used.

case:JMP int contents = pc.READ(); mar.WRITE(contents); ad& = mar.READ(); bitrep =

mdr.write-bitstring(bitrep); Write destination into memory data register addr = mdr.READ(); pc. WRITE( addr); break;

Read contents from program counter Write contents into memory address register Send address to memory Get jump destination address

mem[addr] .read-bitrep();

Read contents of memory data register Write jump address into program counter

Figure 7. A jump instruction is executed by fetching the destination address and writing it into the program counter register.

Another application of inheritance is the construction of a more powerful ma- chine through the composition of execu- tion units. Consider a class called inte- ger-unit, which represents an execution unit that supports integer instructions, and a class called float-unit, which supports floating-point instructions. We can derive a new machine that supports both integer and floating-point instructions using the base classes integer-unit and float-unit.

These examples illustrate the reuse of code - for example, that of class reg - and the ability to create more specialized components (program counter and stack pointer) from general-purpose ones (reg- ister). Therefore, new classes of compo- nents can be composed quickly and eas- ily, reducing the amount of modeling effort and the time required to validate the models. Also, the close conceptual relationship to libraries should be evident

from this discussion. One can imagine li- braries of classes which can be used di- rectly in, or specialized for, a particular application.

Class-transformation function representation

A processor can be modeled as a trans- formation function (algorithm) that in- vokes the member functions of a collec- tion of classes. In particular, the transformation function consists of a fetch() and an execute() procedure. and the classes correspond to hardware com- ponents. The execute portion is modeled as a collection of case statements, one for each instruction in the instruction set. Additional operand fetching is handled within the branches of the case statement.

Figure 6 shows the procedure for fetch- ing instructions from memory. The pro- cedure's parameters reflect the compo- nents being used. This procedure places the program counter into the memory ad- dress register and obtains an instruction from memory. The instruction is placed into the memory data register and then transferred into the instruction register. Finally, to prepare for the next instruc- tion, it increments the program counter.

As an example of modeling instruction execution, Figure 7 shows the statements required to perform a JMP (jump) in- struction. Because the JMP instruction has a second word that contains the des- tination address, it needs to fetch this ad- dress. Once fetched, the procedure places it in the program counter.

Some points are worth mentioning about constructing a model using this ap- proach. The transformation function con- sists of a collection of invocations to var- ious classes of objects. Assuming that a collection of reusable library elements (classes) already exists, we can develop a new processor model by constructing a new transformation function. In many circumstances, the robustness of the classes determines how easy it is to write the transformation function.

In a sense, the resulting model resem- bles a data pathicontrol decomposition.

68 COMPUTER

In particular, when a processor object is instantiated, the components constitute the elements of the data path, and the trans- formation function represents the control. that is, the sequencing of the operations to be performed. Thus, in the transformation function for the processor, each machine instruction is interpreted as a collection of invocations to the components required to execute the instruction. For example, to fetch and execute a subtract instruction, the processor performs operations on the memory address register. the memory data register, the register file, the arithmetic logic unit, the condition code register, and the program counter.

Identifying reusable components and managing change

In a system developed using functional decomposition, the functions contain in- timate knowledge of the data structures. Therefore, changes in the data structures can result in extensive modifications to the functions. Also, because of the tree- like structure of the decomposition, iden- tification of common, reusable functions is difficult.

Data decomposition is a different re- finement technique that manages com- plexity and addresses the problems men- tioned above. In this approach, we decompose a higher level class into a col- lection of more primitive classes and a transformation function. The primitive classes constitute a concrete representa- tion for the higher level class. Thus, the decomposition is equivalent to deriving an implementation - consisting of the primitive classes and a transformation function - for a given specification of the higher level class. We can apply this tech- nique recursively to each primitive class.

We can consider each class to be a vir- tual machine, a reusable element that in- terprets a specific virtual instruction set consisting of its methods. Thus, we can view data decomposition as the decom- position of a virtual machine into more primitive virtual machines.

In the previous section, we showed how a processor class can be decomposed into

function

Processor A Processor B

Transformatio Primitive classes

Invocation to class

Invocation to class - f

J

ation ass -

ansfonation function

Figure 8. This directed acyclic graph structure of data decomposition helps to reveal common, reusable components. Each node in the decomposition corre- sponds to a class. For example, the data decomposition of two processors “points to” common arithmetic logic units, register files, and caches.

a collection of more primitive classes (pro- gram counter, hardware stack, register file, and arithmetic logic unit) and a transfor- mation function consisting of the fetch(j and execute() procedures. At a lower level of decomposition, an arithmetic logic unit can be decomposed into a collection of XOR gates, OR gates, AND gates, and in- verters, along with a corresponding trans- formation function. The reusable elements are the classes employed at a given level.

The data decomposition of several dif- ferent classes “points to” a common col- lection of more primitive classes. This ability to identify reusable components stems in part from the directed acyclic graph (DAG) structure produced by the decomposition, wherein a node (class) can have multiple predecessors. In Fig- ure 8, for example, the data decomposi- tion of two processors being designed by different teams might reveal common, reusable components, such as arithmetic

logic units, multiplexers, caches, and reg- ister files. In addition, change is localized to a class. Specifically, as long as imple- mentation changes do not affect the ex- ternal specification of a class, transfor- mation functions that use the class do not require change. Thus, this approach makes it easier to identify reusable com- ponents and supports change more read- ily than functional decomposition does.

Related applications Several other applications of object-

oriented techniques exist. Given a speci- fication of an abstract data type, we can use software synthesis techniques’ to gen- erate an implementation. In addition, we can use verification techniques’O to es- tablish the correctness of an implemen- tation with respect to its specification. For example, we could verify that a register-

June 1994 69

transfer-level implementation of a pro- cessor satisfies its instruction-set archi- tecture specification.

Object-oriented design techniques also hold promise for modeling distributed and fault-tolerant systems. In distributed systems, we can view objects as comput- ing elements that have internal state. In such a model, concurrent objects com- municate using messages that contain the method to be invoked in another object. Also. dynamic object creation and de- struction are useful in modeling task mi- gration from one processor to another in fault-tolerant systems.

One important area of research in hardwarelsoftware codesign focuses on bringing the now separate hardware and software design paths closer together. Us- ing object-oriented techniques in both the hardware and software world is one means of achieving this. In particular, both hardware and software developers can employ common design techniques and share a common view of their indi- vidual subsystems. In addition, develop- ers can use the virtual machine concept as a basis for deriving application-specific hardwarelsoftware implementations and for promoting hardwarelsoftware reuse.

bject-oriented concepts provide new techniques for hardware modeling and design. The view

that components contain state and oper- ations that manipulate this state provides a natural modeling paradigm for hard- ware. We have illustrated the potential benefits of these techniques in such ar- eas as reuse and specialization of com- ponents through inheritance, as well as the identification of reusable components through data decomposition. These tech- niques hold promise in the development of embedded systems.

Extending Parnas’ concept of program families to the hardware world offers in- teresting insights into the development of families of components, such as families of processors (see Smith and Gross’). For ex- ample, we can parameterize a register file model with a type and reuse the same code in constructing an integer register file and a floating-point register file. In fact, the C++ language supports such parameteri- zation through constructs called templates.

Finally, it is useful to combine the as- pect of concurrency, which is fundamental in hardware modeling, with the concepts of object-oriented design. The use of object-oriented concepts - for example, the notion of classes of components - has already started to appear in hardware de- sign” and ments further investigation.We hope that this article will stimulate interest in this area. W

Acknowledgments We thank the Semiconductor Research Cor- poration for partial support of this research. We also acknowledge Richard MacDonald. Lori Kaufman, and Shivani Kumar for their comments and suggestions regarding this arti- cle. Thanks to Ron Williams for use of the ex- ample processor presented here, Ron Wax- man for his continuing interaction, and John Knight for discussions on object-oriented con- cepts. Finally, we thank Sanjay Srinivasan and Gnanasekaran Swaminathan for their help in implementing many of the ideas in C++.

References 1. C.U. Smith and R.R. Gross, “Technology

Transfer between VLSI Design and Soft- ware Engineering: CAD Tools and Design Methodologies,” Proc. IEEE, IEEE Press. New York. Vol. 74, No. 6, June 1986, pp, 875-885.

2. S. Kumar et al.. “A Framework for Hard- warelsoftware Codesign,” Computer, Vol. 26, No. 12, Dec. 1993, pp. 39-45.

3. M.C. McFarland, A.C. Parker, and R. Camposano, “The High-Level Synthesis of Digital Systems,’’ Proc. IEEE, IEEE Press, New York, Vol. 78, No. 2, Feb. 1990, pp. 301-318.

4. J.R. Tobias, “LSINLSI Building Blocks,” Computer, Vol. 14, No. 8, Aug. 1981, pp. 83-101.

5. P. Jalote, A n Integrated Approach to Soft- ware Engineering, Springer-Verlag. New York, 1991.

6. B. Liskov and J. Guttag, Abstraction and Specification in Program Development. MIT Press, Cambridge, Mass., 1986.

7. D.L. Parnas, “On the Criteria to be Used in Decomposing Systems into Modules,” Comm. ACM,Vol. 15, No. 12, Dec. 1972, pp. 1,053-1,058.

8. G. Booch, “Object-Oriented Develop-

ment,” IEEE Trans. Software Eng., Vol. 12,No. 2, Feb. 1986, pp. 211-221.

9. D. Setliff, E. Kant, and T. Cain, “Practical Software Synthesis,” IEEE Software, Vol. 10, No. 3, May 1993, pp. 6-10.

10. C.A.R. Hoare, “An Axiomatic Basis for Computer Programming,” Comm A C M , Vol. 12, No. 3, Mar. 1969, pp. 335-355.

11. M.J. Chung and S. Kim, “An Object-Ori- ented VHDL Design Environment, ”27th ACM/IEEE Design Automation Con$ , IEEE CS Press, Los Alamitos, Calif., Or- der No. 2050,1990, pp. 431-436.

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

James H. Aylor is a professor and associate chair in the Department of Electrical Engi- neering at the University of Virginia. His re- search interests include design automation of digital systems, VLSI architectures, fault tol- erance and testing, and hardware description languages. He served as president of the IEEE Computer Society in 1993.

Barry W. Johnson is an associate professor in the Department of Electrical Engineering at the University of Virginia. His research inter- ests include fault-tolerant computing, VLSI architectures, VLSI testing, and microproces- sor-based systems. He served as vice president of publications and as a member of the Ex- ecutive Committee of the IEEE Computer So- ciety in 1993.

Wm. A. Wulf is the AT&T Professor of Engi- neering and Applied Science in the Depart- ment of Computer Science at the University of Virginia. His research interests include pro- gramming systems and computer architecture. He was previously assistant director of the Na- tional Science Foundation and currently chairs the Computer Science and Telecommunica- tions Board of the National Research Council.

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

COMPUTER