Jise98 Unified Approach

8/19/2019 Jise98 Unified Approach

1/245

1

A Unified Approach to Object-Oriented VHDL1

Authors: Martin Radetzki, Wolfram Putzke-Röming, Wolfgang Nebel

Affiliation: OFFIS Research Institute

Address: Escherweg 2

26121 Oldenburg

Germany

e-mail: [email protected]

Abstract —Abstraction and reuse are the keys to deal with the increasing com-

plexity of electronic systems. We motivate the application of object-oriented

modeling as an approach to achieve more reuse and higher abstraction in hard-

ware design. This requires an object-oriented hardware description language,

preferably an extension to VHDL. Several variants of such OO-VHDL are being

discussed controversially. We present our unified approach, Objective VHDL,

adding object-oriented features to the VHDL design entity as well as to the type

system to provide a maximum of modeling power.

Keywords —hardware, design, modeling, system level, reuse, object-oriented,

VHDL

1. This work has been funded as part of the OMI-ESPRIT project

REQUEST under contract 20616. This article is based on a paper [1]

published and copyrighted by the 4th Asia-Pacific Conference on

Hardware Description Languages (APCHDL’97).


2/245

2

1 Introduction

Design reuse and system level design are being among the topics of major

concern within the electronic design community. Advanced techniques need to

be developed in order to keep design productivity in pace with the exponential

growth observed in the complexity of electronic systems as well as in the inte-

gration density offered by submicron technologies. Maintenance is another is-

sue particularly in the life-cycle of long-living products, for instance

telecommunication equipment. Finally, quality and testability are crucial for

safety-critical systems, for instance avionics equipment.

Within the REQUEST (REuse and QUality ESTimation) project of the Eu-

ropean Community [2], several large telecom companies, international EDA

tool vendors, system houses, and research organizations are addressing these is-

sues developing a consistent methodology and tools based on the Very High

Speed Integrated Circuits Hardware Description Language (VHDL). Among

other tasks, the REQUEST workpackages include specification and implemen-

tation of object-oriented (OO) extensions to VHDL, expecting to transfer the

benefits of object-orientation from software engineering to an exploitation in

hardware design.

In this article, we first motivate the application of object-oriented modeling

techniques to hardware. We present the requirements to an advanced design

methodology in the next section. In the third section, we give an overview of the

object-oriented modeling paradigm and show that it meets the requirements.

The second half of the article is devoted to the question how to design an

object-oriented hardware description language in order to facilitate simulation

and synthesis of object-oriented models. We start with general considerations

constraining the design of an object-oriented hardware description language in

the fourth section, leading to the approach of object-oriented extensions to VH-

DL. The state of the art in related work is reviewed in section five. To overcome


3/245

3

the observed split into two contrasting paradigms, we finally present the unified

approach of the Objective VHDL language developed within REQUEST.

2 Problem Description

Hardware becomes increasingly complex. By the end of the century, chips

comprising 100 millions of transistors are likely to be manufacturable, and there

is no doubt that designs will utilize this potential. It will be possible to imple-

ment more sophisticated functionality in hardware and to integrate complete

systems on a single chip instead of a printed circuit board.

Design methodologies must enable designers to cope with that complexity

by increasing design productivity. As well, there are great demands on the de-

sign quality in terms of efficiency (power, speed, and area trade-off), testability,

and not least correctness. Systems must be sufficiently validated before fabrica-

tion to avoid design iterations and to meet the market window.

We have identified two major starting points to tackle these issues. The first

one is design of hardware—eventually together with software—at a high level

of abstraction. The second one (no ranking implied) is reuse.

2.1 Abstract Specification of Hardware

Since the beginning of integrated circuit design, abstraction has been a

valuable means to deal with complexity. Gate level design provided an abstrac-

tion from the electrical behavior of transistors, allowing designers to focus on

the logic functionality and to rely on guaranteed properties of the basic cells.

Currently, design at register transfer level is commonplace, and people get in-

terested in behavioral synthesis to abstract from resource allocation and sched-

uling. The next step towards system level design should

• provide components with more comprehensible abstract interfaces,

• introduce abstract communication mechanisms between components,

and

• support data abstraction.


4/245

4

This will ease the assembly of components to form a system and help to account

for the increasingly complex structure of data that is to be processed.

Starting from a rather abstract, possibly incomplete or graphical specifica-

tion, the refinement towards an implementation should be supported. This

means designers should be enabled to add details incrementally until there is

enough information to apply automatic synthesis using advanced techniques.

2.2 Hardware / Software Co-Design

Hardware / Software Co-Design has been outside the scope of our research.

However, since future systems will have an increasing share of embedded soft-

ware running on standard processor cores or application specific instruction pro-

cessors, the methodology used for initial specification should be applicable to

both, hardware and software, in order to allow a co-specification. After parti-

tioning—be it manually or with tool support—the hardware design methodolo-

gy based on object-oriented VHDL can be applied to the hardware part.

Standard object-oriented programming languages such as Ada95 or C++ can be

used to implement the software part. Automatic generation of code in the chosentarget language from OOD specifications and re-engineering support to generate

OOD diagrams from the target languages could facilitate an easy migration from

hardware to software and vice versa.

2.3 Reuse

Reuse helps to increase designers’ productivity allowing them to focus on

the real innovations. Costs for the re-invention of things can be avoided, and the

time saved can be used to achieve better testing or shorter time-to-market. Intel-

lectual property to be reused includes models of

• components in all their varieties,

• communication mechanisms, ranging from high level protocols like TCP/

IP to simple handshaking,


5/245

5

• data structures and algorithms, for instance the sophisticated ones used

in ATM switches, and not least

• test environments since the effort for validation tends to increase even

faster than the complexity of tested designs.

We emphasize that reuse is not for free. Making things reusable (i.e. producing

reusable models) requires some overhead as compared to tailoring specific so-

lutions. Reusing things (i.e. consuming reusable models) means to select, under-

stand, possibly adapt and debug, integrate and finally test them. The costs

incurred depend on the kind of reuse and the degree of reusability, which will

be addressed in the next two sections. Thus, a methodology supporting proper

reuse is an important economic factor. It can help us to improve the quality of

our hardware designs through secure reuse of proven parts.

2.4 Kinds of Reuse

Of course, reuse is not a new invention. An intuitive approach to reuse is to

take an existing piece of source code or a schematic and adapt it to a new pur-

pose. Such modifying reuse is called white-box reuse. It requires to understandthe internals of the reused item, and this is a frequent source of errors. Due to

the debugging necessary in most cases of white-box reuse, its consumer costs

can approach those of a new design.

Unmodified black-box reuse, on the other hand, is relatively cheap for the

consumer, but it requires a higher initial effort to produce an item that is likely

to be reused. Some knowledge and planning about future applications is desir-

able to build generalized components. The use of parameters helps to makecomponents more flexible, but it also makes testing harder. On the other hand,

once the functionality of such black box is validated, and it is not touched, one

can definitely rely on it in future uses.

To provide a greater flexibility, one can apply grey-box reuse, allowing

controlled modifications. For instance, there may be mechanisms that allow lim-

ited modifications to the original source code without touching it directly. There


6/245

6

should be application rules, validation procedures, or verification methods to

ensure proper functioning.

2.5 Requirements for Reusability

The question "What makes a model reusable?" has already been touched on

in the preceding text. In the following, we transfer a classification done in the

software domain [3] into hardware terms:

• Flexibility —A reusable model must be independent from a special appli-

cation. A methodology should allow the addition of functionality, possi-

bly a modification.

• Portability —The model should be independent from implementation

technology. This favors for instance soft macros over hard macros.

• Understandability —Moderate complexity, good documentation, and a

comprehensible (ideally self-descriptive) interface support reuse.

• Confidence —A reusable model should be reliable and error tolerant; its

proper function should be validated or formally verified. It should ideally

not be touched when reusing it. Note that there are trade-offs between these factors; e.g. white-box reuse pro-

vides most flexibility, but it decreases confidence. Another example is that we

have more confidence in cross-talk resistance using hard macros, but our design

will not be portable to new technological platforms.

As a positive point, there is an interrelation of abstractness and reusability:

An abstract model is more likely to be flexible, portable, and human-under-

standable than a model which provides very detailed information. Vice versa,making a model reusable means generalizing, which is a process of abstraction.

Hence, it is not surprising that the units of abstraction identified in 2.1 are as

well candidates for reuse.


7/245

7

2.6 Points Related to Reuse

Following [4], good reuse metrics do not count as reuse maintenance or the

sharing of models between designers in the same project and within one design

team. The first would distort quantitative measurements, and the latter is consid-

ered as good design practice. Anyway, the means to enhance reuse among the

borders of projects or design teams will as well be helpful to achieve sharing of

models within these borders, and we can be optimistic to obtain a maintainable

system when (re-)using subsystems which are flexible, portable, understand-

able, and reliable. Having in mind the typically long life cycle of products in the

telecommunication and avionics domain, we will have to consider maintenance

when choosing a methodology.

3 Benefits from Object-Orientation

Following Booch [5], every object-oriented methodology must provide a

minimum of features, which include (in our terminology): a class concept , mes-

sage passing , inheritance of classes, and polymorphism. These are applied dur-

ing the different main development phases: analysis (OOA), design (OOD), and

programming (OOP). In the following sections, we will present an outline of

these techniques and discuss their impact on our aims, abstraction and reuse,

starting with the overall design process and then moving to the four basic mech-

anisms.

3.1 Object-Oriented Design Process

According to Rumbaugh [6], object-oriented modeling can be divided intothree main phases:

• Object-Oriented Analysis (OOA)—Requirement analysis, extraction of

objects / classes from an informal problem description.

• Object-Oriented Design (OOD)—Identification of interrelationships

between objects / classes such as composition and inheritance; represen-

tation in a graphical notation. Refinement for the description of function-


8/245

8

ality, data and control flow. Descriptive power due to inclusion of data

flow diagrams, hierarchical state machines, message (event timing) dia-

grams.

• Object-Oriented Programming (OOP)—Implementation of the designed

system in a programming language that supports the object-oriented

mechanisms.

With OOD diagrams one can specify a system graphically. This specification

may be informal and incomplete in the beginning; it can be refined in iteration

cycles until a considerable level of detail is achieved. Object-oriented design has

the potential to result in a complete specification and can be applied to mixed

hardware-software systems [7]. OOD diagrams include concepts well-known to

hardware designers, in particular data flow diagrams, hierarchical finite state

machines, and message interaction diagrams similar to timing charts. Hence an

OOD model should be well comprehensible once its notation is known, and it

can contribute a significant part to documentation.

Object-oriented design can and should be supported by tools. These allow

graphical input, provide consistency checks of the models, and translate graph-

ical specifications into the implementation language. In case of design itera-

tions, they will update the source code according to the changes in the

specification.

In the implementation phase, additional details can be added in a textual

form. The textual description can be compiled and executed. It is possible to re-

turn to the design phase in order to maintain a design or add features for an up-

date. As well, one can skip to implementation in order to produce a prototype at

an early stage of the design and return to the design phase later to complete the

system. Providing such flexibility, object-oriented modeling can also deal with

the evolution of systems over a long period of time.


9/245

9

3.2 Classes

The class is the basic object-oriented concept upon which the other build. It

comprises the definition of data fields (attributes) and functionality (methods).

From a class, objects can be created dynamically or by static instantiation. Each

of these objects has its own local state—storage for values of the data fields.

Since no access other than by the invocation of methods is provided to modify

the local state, the designer of a class can ensure the consistency of the local state

by construction. In other words, objects are encapsulated from their environ-

ment by their method interface.

For (re-)using a class, it is sufficient to understand its interface. Thus,

through the hiding of the internals, its degree of abstraction and its understand-

ability are significantly improved. Moreover, by the convention that, once a

class is designed, implemented, and debugged, its source code should not be

touched, a class provides a very safe way of reuse.

3.3 Message Passing

Objects communicate with each other requesting the execution of methods

by passing messages. A message carries the information which method to in-

voke and the input and output data of the method. On the conceptual level many

object-oriented methods (e.g. Booch [5], OMT [6]) do not deal with details

(whereas HOOD [8] does), e.g.

• whether the sender is blocked during method execution by the receiver,

• how a receiver behaves in case several messages arrive from concur-

rently sending objects at the same time or interleaved with the execution

of another method, or

• with whose resources (thread of computation, control flow, task, process)

a method is executed.

The common sense is only that messages should not be lost. Thus, describing

communication through message passing is a significant abstraction at the de-

sign stage. However, implementation languages mostly constrain the message


10/245

10

passing:

• In sequential OOP languages (e.g. C++) message passing and subpro-

gram call are the same. The sender of a message is blocked while the

requested method is executed with the sender’s resources.

• Some concurrent OOP languages (e.g. Java) add synchronization (e.g.

monitor concept) to the subprogram call mechanism.

• Other concurrent OOP languages (e.g. ALPS) let objects process incom-

ing messages by their own thread of control (active object with "body")

and queue messages in case an object is busy.

3.4 Inheritance

Given a class, inheritance allows to derive subclasses with more specific

properties (specialization). A subclass (descendant) inherits all the data fields

and methods from its superclass (ancestor) and can be defined to have additional

ones. Hence inheritance allows to add functionality without having to touch the

source code of the reused superclass. Another commonplace feature is the pos-

sibility to redefine inherited methods and attributes. This controlled modifica-tion again leaves the original code untouched.

Another question is how the reused superclass will behave as a component

of the new derived class. If a designer of a derived class makes only additions,

no modifications, he can be confident that the inherited methods will retain their

proper function with the inherited attributes. He is responsible only for what he

adds.

To study the effect of redefinitions on the inherited code in the subclass, weneed to know more about redefinition semantics. In case the old version of a re-

defined data field or method is removed and replaced by the new version, the

unchanged inherited parts can be significantly distorted. For instance, a rede-

fined method can implement a completely different functionality, and an at-

tribute redefined with a new type may falsify the invocation of operations with

that attribute in the inherited code. Hence, in most cases redefinition will be in-


11/245

11

terpreted as hiding rather than replacing, so that the inherited parts can continue

to work with the hidden old version, and only the added parts will use the rede-

fined new version.

In summary, provided there are no replacing modifications, inheritance al-

lows to reuse a superclass as a black box. Superclasses can be designed for reuse

as generalized, abstract units. It is not necessary to foresee and implement de-

tails about functionality possibly required by some future application. So the

complexity of a reusable class is reduced. Functionality can be added and mod-

ified in a controlled fashion during reuse, specializing classes for new purposes.

This makes class inheritance a model for flexible IP reuse.

3.5 Polymorphism

Polymorphism is a means to uniformly handle objects of classes related by

inheritance. It allows to send a message to an object without having to know at

compile time about the exact class of the receiver. Hence, the binding of mes-

sages (requests for method invocation) to an implementation of a method is to

take place at run time (dynamic binding).Some languages, e.g. Smalltalk, permit to send any message to any object,

raising a run time exception in case a receiver object does not have the requested

method implemented. However, many typed OOP languages (Ada95, Java)

have a mechanism to prevent such behavior— inclusion polymorphism: The

class of the addressed object is restricted by declaration to a given class, C , and

its descendants, and only the methods of the most general class, C , are allowed

to be requested from the object. Since the methods of C are available—either in-herited or redefined—in every transitively derived class, dynamic binding

works without run-time errors. It only has to dispatch a message to the imple-

mentation of the method in the class of the addressed object.

By its weakened typing, polymorphism provides a program with a greater

flexibility regarding the extension of its capabilities. An existing well-tested

program will be able to deal with new derived classes and call their methods


12/245

12

without having to be modified. Through the uniform handling of related classes,

a program becomes more readable.

Reuse combining inheritance with polymorphism is to be classified as grey-

box because the injection of an object of a new derived class into an existing sys-

tem can change its behavior. However, inclusion polymorphism can provide a

maximum of security to method invocation by static checks.

4 Language Design Considerations

In the previous section we have motivated the usefulness of object-orienta-

tion to increase abstraction and reuse in hardware modeling. It became obvious

that the required modeling power is available with the OOD. But there is not yet

an idea which language to use for hardware model implementation (OOP) pur-

poses. We address this point now.

An implementation of a hardware model should allow us to simulate and

synthesize it. The alternatives for an implementation language are to

• use an existing software programming language,

• design an object-oriented HDL from scratch, or

• extend an existing HDL.

Of course the first approach would be usable instantaneously, but can a

software language satisfy all the requirements of hardware description? A lan-

guage like Ada95 or Java may be used to write a concurrent high-level model in

a software-like style, but it misses the means to describe hardware after refine-

ment towards a lower level of abstraction—for instance a simulation time con-

cept, events, signals, and structural descriptions. Hence, using a software

language, we would not be able to simulate high-level models together with

models at a lower level of abstraction. Moreover, we could not use models writ-

ten in an existing HDL.

The last argument holds as well against the design of a completely new ob-

ject-oriented HDL. The design of upward compatible OO extensions to an ex-

isting widespread HDL is most likely to be accepted by users because it helps


13/245

13

them to save their investments in models and because it reduces the cost thresh-

old to learning the language. For similar reasons also tool vendors are likely to

prefer this solution once they can expect to have a user base.

Among the popular HLDs, VHDL has the best potential for high-level mod-

eling. So we chose VHDL as the basis to add object-oriented extensions. To en-

able cheap evaluation and a smooth transition to object-oriented hardware

modeling, we will provide a preprocessor for the translation of our Objective

VHDL into VHDL (Fig. 1). This allows to use available simulation and synthe-

sis environments and provides a link to existing design flows.

Shortcomings of the preprocessor approach are that

• debugging takes place on VHDL level (but links back to Objective

VHDL sources can be provided),

• tools like VHDL hierarchy browser or waveform display do not account

for object-oriented specifics, and

• some overhead may be caused to the VHDL analysis, simulation, and

synthesis due to the obligatory flattening of inheritance hierarchies.

To overcome these issues in the medium term, we should strive for native OO-

OO methodologyand environment

Objective VHDL

Analyzer

Translator

Objective

VHDL

Preprocessor

Obj. VHDLIntermediate

Format

VHDL

Simulation, Synthesis Native

Environment

Fig. 1: Objective VHDL Tool Architecture

REQUESTdevelopment


14/245

14

VHDL environments. Thus, it is important to note that tools can be build as

back-ends upon a procedural interface to the intermediate format generated by

the analyzer (see Fig. 1). An IEEE standardization of object-oriented extensions

to VHDL and the establishment of a user community interested in such language

will be helpful to convince CAD vendors to support this new technology.

5 Previous OO-VHDL Paradigms

In the previous sections we have shown that object-oriented extensions to

VHDL are a practical approach to achieve higher abstraction and more reuse in

hardware modeling. Subsequently we will address the characteristics of some

approaches to object-oriented VHDL, before we switch to the language design

of Objective VHDL in the next section.

The way object-oriented extensions should be incorporated into VHDL has

been a research topic for the last five years, and about a dozen of different pro-

posals of OO-VHDL have been published (cf. [9]). But despite the growing in-

terest in an OO-VHDL, no general agreement has been achieved up to now

whether the VHDL design entity or the VHDL data type system should serve as

basis for object-oriented extensions. We will provide a short review of these

contrasting directions and their nuances in this section and present a new, uni-

fied approach in section six.

5.1 Entity Approaches

A basic approach to adding some aspect of object-orientation to design en-

tities is structural inheritance as proposed e.g. by Ecker [10]. It facilitates the

extension of entity-architecture pairs for additional generics, ports, declarations,

and concurrent statements, but it does not account for OO concepts like methods

and message passing communication.

The latter points are addressed by the Vista [11] and LaMI [12] proposals,

which present the concept of operations and their invocation by abstract mes-

sage passing. Whereas Vista’s operations are similar to procedures, the LaMI


15/245

15

approach considers them to correspond rather to processes. In both proposals,

message passing serves to request the execution of methods. In the LaMI ap-

proach, there exists a separate message queue for each concurrent operation in

order to store messages arriving while the requested operation is busy. Vista

provide one global queue per object with the option to prioritize certain opera-

tions. A criticism of these queuing mechanisms includes two major points:

• Relation to VHDL principles —Is entity message passing compliant with

event-driven simulation, how much simulated time does it consume, and

in which way can determinism be guaranteed in case two messages arrive

at the same delta cycle of the simulation?

• Relation to hardware —How can a message queue of potentially infinite

length be implemented in hardware, or better: How can its maximum size

be determined?

Another issue is how to enable addressing of a message receiver across the

entity borders of a design hierarchy. Entity handles (pointers) have been pro-

posed for this purpose, but this is hardly in line with present VHDL, and it im-

plies the implementation of a sophisticated communication protocol for the

routing of messages in case of automatic hardware generation.

Thus, the entity approaches which go beyond structural inheritance are suit-

ed for writing an initial specification and to reuse parts of old specifications in

a new one. The specification—at a high level of abstraction—can be simulated,

but its refinement to lower levels of abstraction will be hard. We have identified

abstraction as a main goal, but on the other hand it has to be limited: In order to

still serve as a hardware description language, OO-VHDL must not abstract

from hardware.

5.2 Type Approaches

Whereas the entity approaches allow designers to keep the paradigm of hi-

erarchical decomposition oriented at functional units, type approaches aim to

transfer data-oriented decomposition—as known from object-orientation in the


16/245

16

software world—to hardware design. The proposals differ with respect to their

class concept, the way classes can be instantiated, and the details about inherit-

ance mechanism and polymorphism.

According to OO-VHDL design considerations published by Ashenden [9],

a class concept can arise from the interplay of several language concepts, e.g.

Ada95 tagged types, packages, and private types, or a class may be a single con-

struct in the language, e.g. C++ classes. Schumacher [13] chose the first alter-

native, but without encapsulation by private types, whereas Cabanis [14] and

Zippelius [15] preferred the latter.

The observed choices for the instantiation of classes are:

• Instantiation only as variables (Zippelius)—Mechanisms of program-

ming languages can easily be adopted to deal with polymorphism and

dynamic binding.

• Instantiation only as signals (Cabanis)—Polymorphism is not addressed

in this proposal.

• Both kinds of instantiations (Schumacher)—A variant record mechanism

(as opposed to pointers) allows to provide polymorphism also with sig-

nals.

In our opinion, it is desirable to have a class concept and polymorphism also

with signals in order to use them for abstract communication between compo-

nents. Since Schumacher has shown that it is possible to simulate and synthesize

polymorphism of class types applied to variables as well as signals, we are in

favor of providing a maximum of modeling power by supporting class-typed

variables and signals.

Compared to the entity approaches with queuing and handles, the type ap-

proach—though inspired largely by the software world—is closer to hardware

because it allows translation into hardware-oriented data representations. It even

seems feasible to integrate OO extensions of the type system into core VHDL

because they do not conflict with the above stated VHDL specifics. On the other

hand, the type approach has its shortcomings as well:


17/245

17

• The VHDL type system does not facilitate the description of concurrent

behavior inherent to hardware; functionality associated with data types is

implemented in sequential subprograms as opposed to concurrent pro-

cesses.

• Hardware components cannot be described with types alone; this

becomes evident by the fact that nothing works in VHDL without a sur-

rounding entity, the primary hardware abstraction according to the

LRM [16].

6 The Unified Approach of REQUEST

We have no doubt that a type approach is useful in the context of hardware

modeling to provide abstraction capabilities to deal with the increasingly com-

plex data being processed, and to model communication. But to take advantage

of object-oriented concepts when modeling hardware components themselves, a

type approach is not sufficient; it should rather be supported by some object-ori-

entation of design entities. Thus, we decided to provide the Objective VHDL of

REQUEST with both, an object-oriented class type and object-oriented exten-

sions to entities. We will outline the concepts of our language extensions in the

following subsections2, discuss their interrelationships, and motivate with an

example how they can be used synergistically.

A memory (Fig. 2, graphical notation after Rumbaugh [6]) has data as its

content and must at least provide read functionality and a way to define its ini-

tial state (method init ). A ROM is a memory. Hence ROM inherits from mem-

ory, and it may for instance redefine the initialization functionality to read a

file. Also a RAM is a (inherits from) memory. Since a RAM can be written

into, this functionality is added in inheritance. All this will be modeled in the

next chapter using entity inheritance because memories are hardware units.

2. A more detailed presentation of Objective VHDL can be found in

[17]. A concise language definition is available [18].


18/245

18

The size of the memory is a generic of the entity memory. Inside the entity, a

correspondingly sized array with elements of the class mem_datum can be

declared and instantiated as attribute of the entity. The mem_datum is an

abstract class type (cf. 3.4). All the data types to be stored in the heterogeneous

memory, e.g. machine instructions and their operands, will be derived from

mem_datum. The attribute data of the memory must be polymorphic, enabling

the memory to store also every subclass of mem_datum.

If the memory model shall be reused to store something other than e.g.

operands and instructions, this new class will simply be derived from

mem_datum or any of its descendants. Thereby, through use of type polymor-

phism the capabilities of the memory can be extended without having to mod-

ify its code.

The class types can as well be utilized for addressing an entity class and

requesting execution of its methods. Thereby the decision for a communication

memory

read

data

init

RAM

write

ROM

init

mem_datum

operand instruction

exec

size

init

Fig. 2: Memory modelling using entity and type inheritance

TYPE DOMAIN

ENTITY DOMAIN

composition

inheritance


19/245

19

mechanism and the degree of concurrency is left to the user rather than laying it

down at the language level as the pure entity approaches do (cf. 5.1). More-

over, the introduction of entity handles to enable communication across a

design hierarchy becomes superfluous when utilizing the additional capabili-

ties of class-typed signals and polymorphism (see 6.7, [19]). This means

smaller deviation from the concepts of VHDL and avoids issues on the integra-

tion of handles and message passing with the VHDL time concept and event-

driven simulation.

6.1 Declaration of Class Types

The class type of Objective VHDL provides a new mechanism for data abstrac-

tion. It represents a collection of data fields (OO attributes) together with and

encapsulated by associated functionality provided by subprograms. These sub-

programs correspond to methods in object-oriented terminology. Inheritance of

class types supports reuse and extensibility of existing classes through defini-

tion of derived classes. Since multiple inheritance from more than one ancestor

makes a language and its implementation more complicated imposing thenecessity to resolve name conflicts due to repeated inheritance of attributes and

methods from different branches of an inheritance hierarchy, it was decided for

single inheritance.

A class type—be it a base class or a derived class—consists of a declaration

and a body, similar to a protected type of the shared variable language change

specification [20]. This separation of an interface from the implementation may

also be compared to packages, but there are significant differences: one caninstantiate classes, but not packages; and classes are types as opposed to pack-

ages which are design units.

Listing 1: Anchoring class types and bodies in the VHDL grammar

type_definition ::=

... -- VHDL type definitions

| class_type_definition


20/245

20

class_type_definition ::=

class_type_declaration

| derived_class_type_declaration

| class_type_body

Inside a class type declaration, a number of declarations may occur. Besides

other declarations whose semantics are transferred from VHDL, there are class

attribute declarations, subprogram declarations and class configurations:

• class attribute declarations of a class type declare its data fields;

• subprogram declarations in the immediate declarative region of the class

declare methods common to all objects of that class type;

• subprogram declarations in the class configuration for signal (variable,

constant)—see below—declare methods applicable exclusively to signals

(variables, constants) of that class type.

The subprogram declarations—which do not include a subprogram body—

serve as methods forming the interface of the class. Thus, we will use the term

subprogram instead of method in the following. The subprograms declared in

the class can be invoked from outside the class (see 6.3). As opposed to this,

access to the class attribute declarations is limited to the body of the class and

to its descendants.

Listing 2: Grammar of class type declarations

class_type_declaration ::=

[ abstract ] class

{ class_type_declarative_item }

end class [ class_type _simple_name ]

class_type_declarative_item ::=

class_attribute_declaration

| subprogram_declaration

| class_type_configuration


21/245

21

| ... -- further items: constant, [sub]type, alias, use clause

class_type_configuration ::=

for object_specification

{ class_type_configuration_item }

end for;

object_specification ::= signal | variable | constant

A derived class can be declared according to the grammar production shown in

Listing 3. The class type name after the ’new class’ denotes the ancestor.

Besides the explicitly declared subprograms and class attributes, also all

declarative items of the ancestor are implicitly declared in the derived class. An

implicit declaration is hidden by an explicit declaration according to classic

VHDL visibility and overloading rules. To apply these, the declarative region

formed by the direct ancestor of a class type T is considered as immediately

enclosing the declaration of T.

To cope with the implicit declarations, the declaration of the ancestor class

must be analyzed prior to its descendants. This also ensures that a class cannot

inherit from its descendant, which would mean there were a cycle in the inher-

itance relationship.

Listing 3: Grammar of derived class type declarations

derived_class_type_declaration ::=

new [ abstract ] class class_type _name with

{ class_type_declarative_item }

end class [ class_type _simple_name ]

A [derived] class type definition can only occur within a type declaration. If the

optional simple name appears at its end, it must repeat the identifier which is

declared as a class type. For instance, the class mem_datum of Fig. 2 is

declared, and classes are derived from it as shown in Listing 4:


22/245

22

Listing 4: Objective VHDL source code of class declarations

type mem_datum is abstract class

procedure init;

end class mem_datum;

type instruction is new abstract class mem_datum with

for variable

procedure exec;

end for;

end class instruction;

type LOAD is new class instruction with

class attribute address : addressing_mode;

end class LOAD;

type operand is new class mem_datum with

class attribute value : integer;

function get return integer;

end class operand;

6.2 Declaration of Class Bodies

A class type body primarily comprises subprogram body definitions for sub-

programs declared in a class declaration. It must be preceded by a correspond-

ing class type declaration in the same immediate declarative region. Both

together form a single declarative region. Declaration of a class in a package

header followed by a class body in the package body is recommended.Vice versa, a class type declaration may come without a corresponding

body. It is also permitted to leave a subprogram declaration of a class without a

body. In both cases, the class type declaration concerned must use the keyword

abstract (see Listing 2, 3) which means some implementation is still missing.

It may be added in future inheritance steps.


23/245

23

Listing 5: Grammar of class type bodies

class_type_body ::=

class body

{ class_body_declarative_item }

end class body [ class_type _simple_name ]

The declarative items of a class body are those of a class declaration plus sub-

program bodies. Access from these bodies to the class attributes depends on the

place of the subprogram body declaration:

• for a body within a for signal construct, class attributes behave like sig-

nals,

• for a body within a for variable construct, class attributes are like vari-

ables, and

• outside such construct (in the common part or in a for constant con-

struct), class attributes may only be read (like a constant).

A subprogram declared in the common part of the class must have a body

either in the common part of the class body or in all class body configuration

parts (for signal, variable, and constant). Subprogram declarations from a class

configuration part must have a body in the corresponding class body configura-

tion part. Again a class must be declared abstract if it misses any implementa-

tion.

Listing 6: Body corresponding to a class type from Listing 4

type operand is class body

function get return integer is

begin

return value;

end;

for signal

procedure init is


24/245

24

begin

value


25/245

25

A subprogram invoked with a polymorphic object must be declared in its

base class T. Since the subprogram is inherited to the ancestors, we can be sure

that the call is valid for all classes comprised by T’CLASS . Possibly the imple-

mentation (subprogram body) has been redefined during inheritance, in case of

which the body corresponding to the actual class membership of the object is

executed (dynamic binding mechanism). For instance, if classes LOAD and

STORE are derived from the instruction class of the memory model, a call to

subprogram exec with the instruction register (see below) will be dispatched to

the implementation of exec in either LOAD or STORE , depending on what kind

of instruction is in the instruction register at the time of the call.

Assignment operators are predefined for class types as well as class-wide

types. Whereas there is strict type checking with the class types (i.e. destination

and source of assignment must be of the same class), assignments involving

class-wide types S’CLASS (source) and D’CLASS (destination) are checked

as follows (cf. the code example below):

(1) S is subclass of D (or equal): ok because D’CLASS includes S’CLASS;

(2) S is superclass of D: passes analysis, but causes a run-time error if the

actual class of the source object is not included in D’CLASS;

(3) S and D are not related by inheritance: error—no compatibility.

Listing 7: Use of class-wide types and objects

variable instruction_register : instruction’CLASS := ... ; -- initialization is

variable operand_register : operand’CLASS := ... ; -- mandatory for

variable memory_location : mem_datum’CLASS := ... ; -- ’CLASS objects

...

instruction_register.exec; -- dynamic binding applies

instruction_register := memory_location; -- (2) may cause run-time error

memory_location := operand_register; -- (1) works always

operand_register := instruction_register; -- (3) not permitted; static error


26/245

26

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entity—which is an entity

together with a corresponding architecture—shows that many properties of an

OO class are already present:

• The entity defines the interface of a hardware unit. Thus, it can be com-

pared to the declaration of a class.

• The architecture gives the implementation of a hardware unit, like a class

body implements the functionality of a class.

• In the declarative part of an entity, signals and shared variables can be

declared. These can be interpreted as OO attributes.

• As well, the declaration of subprograms is permitted in the entity’s

declarative part. These subprograms are regarded as methods in the fol-

lowing. Their bodies (i.e. the implementation) can be defined in a corre-

sponding architecture.

What remains to add to the modeling capabilities available with design entities

is at least inheritance. See below our extension of the VHDL notion of a pri-

mary unit (secondary unit, resp.) for new constructs allowing to declare derived

entities (architectures, resp.). A fixed message passing mechanism as a way to

invoke the subprograms from outside is not included as part of the language.

Instead, it can be modeled using the class types as proposed in section 6.7.

Polymorphism of design entities is not provided since a piece of hardware is

supposed to be static, i.e. not to change its structure during simulation.

Listing 8: Extension of VHDL grammar for derived design units

primary_unit ::=

... -- primary units of VHDL

| derived_entity_declaration

secondary_unit ::=

... -- secondary units of VHDL

| derived_architecture_body


27/245

27

6.5 Derived Entities

With the exception of stating in a new ... with clause the ancestor from which a

derived entity inherits, its declaration is syntactically identical to the regular

entity of VHDL. Header, declarative part, and statement part of a derived entity

share the syntax of their respective entity counterparts. But, as opposed to a

non-derived ’base class’ entity, they declare extensions and modifications with

respect to the ancestor.

Listing 9: Grammar of derived entity declaration

derived_entity_declaration ::=entity identifier is new entity _name with

derived_entity_header

derived_entity_declarative_part

[ begin

derived_entity_statement_part ]

end [ entity ] [ entity _simple_name ] ;

Effective port and generic lists of a derived entity define its full interface to be

used at instantiation. The effective port list of a derived entity is the concatena-

tion of the ancestor’s effective port list and the list of ports added in inherit-

ance, which must be disjoint to prevent name conflicts. The effective port list

of a non-derived entity is simply its port list. An analogous definition holds for

generics.

An effective entity statement part takes the place of a regular entity’s state-

ment part wherever a derived entity is used instead of an entity. It is the union

of

• all concurrent statements from the derived entity statement part,

• all concurrent statements from the effective entity statement part of the

ancestor entity that do not have a label, and


28/245

28

• all labelled concurrent statements from the effective entity statement part

of the ancestor entity whose label does not occur as a label of a concur-

rent statement in the derived entity statement part.

Again, the effective statement part of a base entity is its statement part. We

emphasize that the ordering of concurrent statements is insignificant, and that

the third point defines the replacement of labelled concurrent statements, e.g.

processes, during inheritance.

Inheritance of the ancestor entity’s declarations is defined by their implicit

declaration in the derived entity. In case the derived entity explicitly declares a

homograph of an inherited name and no overloading can be applied, the

explicit declaration hides the implicit one (redeclaration). Such hidden declara-

tion can be made visible by selection using the ancestor entity name as a prefix.

The example in Listing 10 corresponds to Fig. 2. It shows how a RAM

entity can be derived from a memory.

Listing 10: Implemetation of inheritance hierarchy of memories

-- here: some library / use clause to make the used types directly visible

entity memory is

generic( size : natural );

port( message : memory_msg’CLASS ); -- for message passing cf 6.7

subtype address_range is natural range 0 to size-1;

type mem_data is array ( address_range ) of mem_datum’CLASS;

shared variable data : mem_data; -- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datum’CLASS );

-- read could also be implemented as a function returning the data

procedure init;

end memory;

entity RAM is new memory with

generic( initial_value : mem_datum’CLASS );


29/245

29

procedure write(constant address : in address_range;

constant datum : in mem_datum’CLASS );

end RAM;

6.6 Derived Architectures

A derived architecture inherits declarations and concurrent statements from its

ancestor. It is declared using the following syntax:

Listing 11: Grammar of derived architecture body

derived_architecture_body ::=

architecture identifier of entity _name_#1 is

new [ abstract ] architecture _name [ of entity _name_#2 ] with

derived_architecture_declarative_part

begin

derived_architecture_statement_part

end [ architecture ] [ architecture _simple_name ] ;

The architecture name stated after the keyword new denotes the ancestor. To

make sure inheritance of implementations (architectures) is consistent with the

inheritance of interfaces (entities) they correspond to, the optional second

entity name must denote an ancestor of the first. In case the second entity name

is omitted or equal to the first entity name, the derived architecture corresponds

to the same entity as the ancestor architecture.

Inheritance of concurrent statements and declarations is defined in analogy

to entities (cf. 6.5) through an effective architecture statement part and implicit

declarations, respectively. Since a derived architecture forms a single declara-

tive region together with its corresponding entity, also its entity’s implicit (i.e.

inherited) and explicit declarations are visible. Hence, in the example below,

the procedure read implemented in an architecture of entity RAM can write to

the shared variable data declared in the ancestor entity memory.


30/245

30

Listing 12: Architectures corresponding to entities of Listing 10

architecture OO of memory is abstract

procedure read( constant address : in address_range;

variable datum : out mem_datum’CLASS ) is

begin

datum := data( address );

end;

begin ... end OO;-- statement part implements method invocation; see 6.7

architecture OO of RAM is new OO of memory with

procedure write(constant address : in address_range;

constant datum : in mem_datum’CLASS ) is

begin

data( address ) := datum;

end;

procedure init is

begin

data := ( others => initial_value );

end; -- initial_value is a generic of entity RAM

begin end OO; -- empty statement part; the inherited is sufficient

The subprogram init declared in entity memory is said to be abstract because

architecture OO of memory does not define its subprogram body. In conse-

quence, architecture OO of memory must be declared abstract which means

some implementation is missing. Objective VHDL forbids instantiation of such

abstract architectures, and since there is no other architecture of memory, it will

never be instantiated. Memory and its abstract architecture serve solely to

declare and partially implement once what is common to all kinds of memories.

Non-abstract devices, e.g. a ROM or a RAM derived from memory, will add

the missing initialization functionality. A ROM may read its content from a file


31/245

31

whereas the RAM shown above has some generic initial value. It also adds spe-

cific write functionality not available from a ROM.

6.7 Message Passing

We have not yet considered the mechanism to invoke an entity’s subprogram

(i.e. a method) from outside the entity. Such mechanism, called message pass-

ing, must include:

• transmission of actuals required as inputs parameters of the subprogram,

• invocation of the requested method from inside the entity, and

• transmission of results (i.e. output parameters or function return values).

Thus, in essential sending a message means transmission of information that

can be modeled using the class types as briefly described in the following.

Notice this is a modeling guideline to the user, not an integral part of the lan-

guage.

A message class corresponding to a method should comprise data fields

(i.e. class attributes) to hold the parameter values and a dispatch procedure that

calls the corresponding method with these parameters. A channel class couldhave a class-wide attribute to hold a message to be transmitted via the channel

and describe the exchange protocol through subprograms for sending and re-

ceiving a message.

By providing a number of processes that watch the channel signal(s) and in-

voke the dispatching of messages, the degree of inner-object concurrency can be

specified. Thus, rather than integrating a fixed message passing mechanism as

part of Objective VHDL, language primitives can be used to model message passing solutions. This idea and the modeling guidelines are explained in more

detail in [19, 21]. In the simplest case, a single dispatching process completing

architecture OO of memory (cf. 6.6) may look like Listing 13. However, using

more complicated protocols and messages, their modeling may be cumbersome

to the user. Hence, future research and development will be done to ease mes-


32/245

32

sage passing through protocol-generating tools and an inclusion of message

passing primitives into the language.

Listing 13: A simple dispatching process

process( channel’TRANSACTION )

begin

channel.dispatch;

end;

6.8 Class Interrelationships

Due to the decision to provide class types as well as derived design entities,

Objective VHDL has two different kinds of classes. Object-oriented methodol-

ogies do in general not account for different kinds of classes (e.g. OMT [6],

Booch [5]; HOOD [8] on the other hand distinguishes active and passive class-

es). Nonetheless we must investigate the interrelationships between entity and

type classes; they prove to be not totally orthogonal so that improper combina-

tions must be avoided:

• Cross-inheritance —A derived design entity cannot inherit from a class

type and vice versa.

• Cross-composition —An entity can contain the declaration or instantia-

tion of a class type, but the reverse is not permitted; a passive object

(instance of a class type) cannot contain an active object (instance of an

entity).

• Cross-communication —Instances of entities and class types can commu-

nicate with each other, but the appropriate mechanism has to be chosen:

An entity can call methods of the class (if visible), and a class can send

messages to an entity via a channel (cf. 6.7).


33/245

33

• Parameter passing —Instances of class types (variables, signals) can be

passed as parameters, which enables the receiver to send them messages.

An entity cannot be passed as parameter, but it is possible to pass the

message signal that it receives.

These rules are canonic extensions of the way things go in present VHDL; they

are the result of VHDL’s dichotomy into separate entity and type domains.

7 Conclusion

Object-oriented techniques are an attractive means to deal with complexity

issues in hardware design. We have shown how object-orientation can help to

achieve more reuse in hardware modeling and to shift it to a higher level of ab-

straction. Considerations on the design of an object-oriented hardware descrip-

tion language as an extension to VHDL have been presented. Against this

background, the main branches recognized in previous work have been re-

viewed. The language architecture of REQUEST Objective VHDL—combining

type and entity object-orientation—has been justified, the interrelations of type

classes and entity classes have been addressed, and their cooperation has been

illuminated. An Objective VHDL language reference manual is available from

http://eis.informatik.uni-oldenburg.de/research/request.html. An Objective

VHDL compiler front end and a translator into VHDL, being developed by

LEDA S.A. and OFFIS, respectively, will be publically available in 1998.

Future work includes research on synthesis optimization of object-oriented

hardware models, properties pertained during inheritance, and message passing

improvements as well as to broaden the scope to include the co-design of hard-

ware and software.

8 References

[1] M. Radetzki. W. Putzke-Röming, W. Nebel. OO-VHDL: What Is It, and

Why Do We Need It? Proc. 4th Asia-Pacific Conference on Hardware

Description Languages. Hsin-Chu, Taiwan, 1997, pp. 16-23.


34/245

34

[2] W. Nebel, W. Putzke-Röming, M. Radetzki. Das OMI-Projekt REQUEST .

Invited talk, 3. GI/ITG/GMM Workshop „Hardwarebesch-

reibungssprachen und Modellierungsparadigmen“, Holzhau, Germany,

1997.

[3] E.-A. Karlsson, G. Sindre, T. Stalhane. Techniques for Making More

Reusable Components. REBOOT Technical Report No. 41, 1992.

[4] J.S. Poulin. Measuring Software Reuse: Principles, Practices, and Eco-

nomic Models. Addison-Wesley, 1997.

[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Red-

wood City, 1991.

[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-

Oriented Modeling and Design. Prentice Hall, 1991.

[7] E. Holz et al. INSYDE Integrated Methods for Evolving System Design—

Application Guidelines. ESPRIT Project 8641 Report, Humboldt Univer-

sity Berlin.

[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Ref-

erence HRM4-9/26/95, 1995. Available from http://www.hood.be

[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Exten-

sions to VHDL. VHDL International Users’ Forum (Spring Conference),

Santa Clara, USA, 1997, pp. 109-118.

[10]W. Ecker. An Object-Oriented View of Structural VHDL Description.

VHDL International Users’ Forum (Spring Conference), Santa Clara,

USA, 1996, pp. 255-264.

[11] S. Swamy, A. Molin, B. Covnot. OO-VHDL. Object-Oriented Extensions

to VHDL. IEEE Computer, October 1995, pp. 18-26.

[12] J. Benzakki, B. Djafri. Object Oriented Extensions to VHDL—The LaMI

proposal . CHDL’97, Toledo, Spain, 1997, pp. 334-347.


35/245

35

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Ori-

ented Extensions to VHDL. Proceedings of the Euro-DAC’95 with Euro-

VHDL’95, IEEE Computer Society Press, 1995, pp. 428-435.

[14] D. Cabanis, S. Medhat, N. Weavers. Classification-Orientation for VHDL:

A Specification. VHDL International Users’ Forum (Spring Conference),

Santa Clara, USA, 1996, pp. 265-274.

[15] R. Zippelius, K. D. Müller-Glaser. An Object-oriented Extension of

VHDL. VHDL Forum for CAD in Europe (Spring Conference), 1992,

pp. 155-163.

[16] IEEE Standard VHDL Language Reference Manual . IEEE Std 1076-1993.

[17] M. Radetzki, W. Putzke-Röming, W. Nebel, S. Maginot, J.-M. Bergé, A.-

M. Tagant. VHDL language extensions to support abstraction and re-use.

Proc. 2nd Workshop on Libraries, Component Modelling, and Quality

Assurance. Toledo, Spain, 1997, pp. 47-62.

[18] S. Maginot, W. Nebel, W. Putzke-Röming, M. Radetzki. Final Objective

VHDL language definition. REQUEST Deliverable 2.1.A (public), 1997.Available on the WWW from URL http://eis.informatik.uni-oldenburg.de/

research/request.html

[19] W. Putzke-Röming, M. Radetzki, W. Nebel. A flexible message passing

mechanism for Objective VHDL. Submitted to DATE’98.

[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specifi-

cation (PAR 1076), Version 5.7, December 1996.

[21] W. Putzke-Röming, M. Radetzki, W. Nebel. Modeling communication

with Objective VHDL. Submitted to Spring VIUF ’98.


36/245

1

A Unified Approach to Object-Oriented VHDL1

Authors: Martin Radetzki, Wolfram Putzke-Röming, Wolfgang Nebel

Affiliation: OFFIS Research Institute

Address: Escherweg 2

26121 Oldenburg

Germany

e-mail: [email protected]

Abstract —Abstraction and reuse are the keys to deal with the increasing com-

plexity of electronic systems. We motivate the application of object-oriented

modeling as an approach to achieve more reuse and higher abstraction in hard-

ware design. This requires an object-oriented hardware description language,

preferably an extension to VHDL. Several variants of such OO-VHDL are being

discussed controversially. We present our unified approach, Objective VHDL,

adding object-oriented features to the VHDL design entity as well as to the type

system to provide a maximum of modeling power.

Keywords —hardware, design, modeling, system level, reuse, object-oriented,

VHDL

1. This work has been funded as part of the OMI-ESPRIT project

REQUEST under contract 20616. This article is based on a paper [1]

published and copyrighted by the 4th Asia-Pacific Conference on

Hardware Description Languages (APCHDL’97).


37/245

2

1 Introduction

Design reuse and system level design are being among the topics of major

concern within the electronic design community. Advanced techniques need to

be developed in order to keep design productivity in pace with the exponential

growth observed in the complexity of electronic systems as well as in the inte-

gration density offered by submicron technologies. Maintenance is another is-

sue particularly in the life-cycle of long-living products, for instance

telecommunication equipment. Finally, quality and testability are crucial for

safety-critical systems, for instance avionics equipment.

Within the REQUEST (REuse and QUality ESTimation) project of the Eu-

ropean Community [2], several large telecom companies, international EDA

tool vendors, system houses, and research organizations are addressing these is-

sues developing a consistent methodology and tools based on the Very High

Speed Integrated Circuits Hardware Description Language (VHDL). Among

other tasks, the REQUEST workpackages include specification and implemen-

tation of object-oriented (OO) extensions to VHDL, expecting to transfer the

benefits of object-orientation from software engineering to an exploitation in

hardware design.

In this article, we first motivate the application of object-oriented modeling

techniques to hardware. We present the requirements to an advanced design

methodology in the next section. In the third section, we give an overview of the

object-oriented modeling paradigm and show that it meets the requirements.

The second half of the article is devoted to the question how to design an

object-oriented hardware description language in order to facilitate simulation

and synthesis of object-oriented models. We start with general considerations

constraining the design of an object-oriented hardware description language in

the fourth section, leading to the approach of object-oriented extensions to VH-

DL. The state of the art in related work is reviewed in section five. To overcome


38/245

3

the observed split into two contrasting paradigms, we finally present the unified

approach of the Objective VHDL language developed within REQUEST.

2 Problem Description

Hardware becomes increasingly complex. By the end of the century, chips

comprising 100 millions of transistors are likely to be manufacturable, and there

is no doubt that designs will utilize this potential. It will be possible to imple-

ment more sophisticated functionality in hardware and to integrate complete

systems on a single chip instead of a printed circuit board.

Design methodologies must enable designers to cope with that complexity

by increasing design productivity. As well, there are great demands on the de-

sign quality in terms of efficiency (power, speed, and area trade-off), testability,

and not least correctness. Systems must be sufficiently validated before fabrica-

tion to avoid design iterations and to meet the market window.

We have identified two major starting points to tackle these issues. The first

one is design of hardware—eventually together with software—at a high level

of abstraction. The second one (no ranking implied) is reuse.

2.1 Abstract Specification of Hardware

Since the beginning of integrated circuit design, abstraction has been a

valuable means to deal with complexity. Gate level design provided an abstrac-

tion from the electrical behavior of transistors, allowing designers to focus on

the logic functionality and to rely on guaranteed properties of the basic cells.

Currently, design at register transfer level is commonplace, and people get in-

terested in behavioral synthesis to abstract from resource allocation and sched-

uling. The next step towards system level design should

• provide components with more comprehensible abstract interfaces,

• introduce abstract communication mechanisms between components,

and

• support data abstraction.


39/245

4

This will ease the assembly of components to form a system and help to account

for the increasingly complex structure of data that is to be processed.

Starting from a rather abstract, possibly incomplete or graphical specifica-

tion, the refinement towards an implementation should be supported. This

means designers should be enabled to add details incrementally until there is

enough information to apply automatic synthesis using advanced techniques.

2.2 Hardware / Software Co-Design

Hardware / Software Co-Design has been outside the scope of our research.

However, since future systems will have an increasing share of embedded soft-

ware running on standard processor cores or application specific instruction pro-

cessors, the methodology used for initial specification should be applicable to

both, hardware and software, in order to allow a co-specification. After parti-

tioning—be it manually or with tool support—the hardware design methodolo-

gy based on object-oriented VHDL can be applied to the hardware part.

Standard object-oriented programming languages such as Ada95 or C++ can be

used to implement the software part. Automatic generation of code in the chosentarget language from OOD specifications and re-engineering support to generate

OOD diagrams from the target languages could facilitate an easy migration from

hardware to software and vice versa.

2.3 Reuse

Reuse helps to increase designers’ productivity allowing them to focus on

the real innovations. Costs for the re-invention of things can be avoided, and the

time saved can be used to achieve better testing or shorter time-to-market. Intel-

lectual property to be reused includes models of

• components in all their varieties,

• communication mechanisms, ranging from high level protocols like TCP/

IP to simple handshaking,


40/245

5

• data structures and algorithms, for instance the sophisticated ones used

in ATM switches, and not least

• test environments since the effort for validation tends to increase even

faster than the complexity of tested designs.

We emphasize that reuse is not for free. Making things reusable (i.e. producing

reusable models) requires some overhead as compared to tailoring specific so-

lutions. Reusing things (i.e. consuming reusable models) means to select, under-

stand, possibly adapt and debug, integrate and finally test them. The costs

incurred depend on the kind of reuse and the degree of reusability, which will

be addressed in the next two sections. Thus, a methodology supporting proper

reuse is an important economic factor. It can help us to improve the quality of

our hardware designs through secure reuse of proven parts.

2.4 Kinds of Reuse

Of course, reuse is not a new invention. An intuitive approach to reuse is to

take an existing piece of source code or a schematic and adapt it to a new pur-

pose. Such modifying reuse is called white-box reuse. It requires to understandthe internals of the reused item, and this is a frequent source of errors. Due to

the debugging necessary in most cases of white-box reuse, its consumer costs

can approach those of a new design.

Unmodified black-box reuse, on the other hand, is relatively cheap for the

consumer, but it requires a higher initial effort to produce an item that is likely

to be reused. Some knowledge and planning about future applications is desir-

able to build generalized components. The use of parameters helps to makecomponents more flexible, but it also makes testing harder. On the other hand,

once the functionality of such black box is validated, and it is not touched, one

can definitely rely on it in future uses.

To provide a greater flexibility, one can apply grey-box reuse, allowing

controlled modifications. For instance, there may be mechanisms that allow lim-

ited modifications to the original source code without touching it directly. There


41/245

6

should be application rules, validation procedures, or verification methods to

ensure proper functioning.

2.5 Requirements for Reusability

The question "What makes a model reusable?" has already been touched on

in the preceding text. In the following, we transfer a classification done in the

software domain [3] into hardware terms:

• Flexibility —A reusable model must be independent from a special appli-

cation. A methodology should allow the addition of functionality, possi-

bly a modification.

• Portability —The model should be independent from implementation

technology. This favors for instance soft macros over hard macros.

• Understandability —Moderate complexity, good documentation, and a

comprehensible (ideally self-descriptive) interface support reuse.

• Confidence —A reusable model should be reliable and error tolerant; its

proper function should be validated or formally verified. It should ideally

not be touched when reusing it. Note that there are trade-offs between these factors; e.g. white-box reuse pro-

vides most flexibility, but it decreases confidence. Another example is that we

have more confidence in cross-talk resistance using hard macros, but our design

will not be portable to new technological platforms.

As a positive point, there is an interrelation of abstractness and reusability:

An abstract model is more likely to be flexible, portable, and human-under-

standable than a model which provides very detailed information. Vice versa,making a model reusable means generalizing, which is a process of abstraction.

Hence, it is not surprising that the units of abstraction identified in 2.1 are as

well candidates for reuse.


42/245

7

2.6 Points Related to Reuse

Following [4], good reuse metrics do not count as reuse maintenance or the

sharing of models between designers in the same project and within one design

team. The first would distort quantitative measurements, and the latter is consid-

ered as good design practice. Anyway, the means to enhance reuse among the

borders of projects or design teams will as well be helpful to achieve sharing of

models within these borders, and we can be optimistic to obtain a maintainable

system when (re-)using subsystems which are flexible, portable, understand-

able, and reliable. Having in mind the typically long life cycle of products in the

telecommunication and avionics domain, we will have to consider maintenance

when choosing a methodology.

3 Benefits from Object-Orientation

Following Booch [5], every object-oriented methodology must provide a

minimum of features, which include (in our terminology): a class concept , mes-

sage passing , inheritance of classes, and polymorphism. These are applied dur-

ing the different main development phases: analysis (OOA), design (OOD), and

programming (OOP). In the following sections, we will present an outline of

these techniques and discuss their impact on our aims, abstraction and reuse,

starting with the overall design process and then moving to the four basic mech-

anisms.

3.1 Object-Oriented Design Process

According to Rumbaugh [6], object-oriented modeling can be divided intothree main phases:

• Object-Oriented Analysis (OOA)—Requirement analysis, extraction of

objects / classes from an informal problem description.

• Object-Oriented Design (OOD)—Identification of interrelationships

between objects / classes such as composition and inheritance; represen-

tation in a graphical notation. Refinement for the description of function-


43/245

8

ality, data and control flow. Descriptive power due to inclusion of data

flow diagrams, hierarchical state machines, message (event timing) dia-

grams.

• Object-Oriented Programming (OOP)—Implementation of the designed

system in a programming language that supports the object-oriented

mechanisms.

With OOD diagrams one can specify a system graphically. This specification

may be informal and incomplete in the beginning; it can be refined in iteration

cycles until a considerable level of detail is achieved. Object-oriented design has

the potential to result in a complete specification and can be applied to mixed

hardware-software systems [7]. OOD diagrams include concepts well-known to

hardware designers, in particular data flow diagrams, hierarchical finite state

machines, and message interaction diagrams similar to timing charts. Hence an

OOD model should be well comprehensible once its notation is known, and it

can contribute a significant part to documentation.

Object-oriented design can and should be supported by tools. These allow

graphical input, provide consistency checks of the models, and translate graph-

ical specifications into the implementation language. In case of design itera-

tions, they will update the source code according to the changes in the

specification.

In the implementation phase, additional details can be added in a textual

form. The textual description can be compiled and executed. It is possible to re-

turn to the design phase in order to maintain a design or add features for an up-

date. As well, one can skip to implementation in order to produce a prototype at

an early stage of the design and return to the design phase later to complete the

system. Providing such flexibility, object-oriented modeling can also deal with

the evolution of systems over a long period of time.


44/245

9

3.2 Classes

The class is the basic object-oriented concept upon which the other build. It

comprises the definition of data fields (attributes) and functionality (methods).

From a class, objects can be created dynamically or by static instantiation. Each

of these objects has its own local state—storage for values of the data fields.

Since no access other than by the invocation of methods is provided to modify

the local state, the designer of a class can ensure the consistency of the local state

by construction. In other words, objects are encapsulated from their environ-

ment by their method interface.

For (re-)using a class, it is sufficient to understand its interface. Thus,

through the hiding of the internals, its degree of abstraction and its understand-

ability are significantly improved. Moreover, by the convention that, once a

class is designed, implemented, and debugged, its source code should not be

touched, a class provides a very safe way of reuse.

3.3 Message Passing

Objects communicate with each other requesting the execution of methods

by passing messages. A message carries the information which method to in-

voke and the input and output data of the method. On the conceptual level many

object-oriented methods (e.g. Booch [5], OMT [6]) do not deal with details

(whereas HOOD [8] does), e.g.

• whether the sender is blocked during method execution by the receiver,

• how a receiver behaves in case several messages arrive from concur-

rently sending objects at the same time or interleaved with the execution

of another method, or

• with whose resources (thread of computation, control flow, task, process)

a method is executed.

The common sense is only that messages should not be lost. Thus, describing

communication through message passing is a significant abstraction at the de-

sign stage. However, implementation languages mostly constrain the message


45/245

10

passing:

• In sequential OOP languages (e.g. C++) message passing and subpro-

gram call are the same. The sender of a message is blocked while the

requested method is executed with the sender’s resources.

• Some concurrent OOP languages (e.g. Java) add synchronization (e.g.

monitor concept) to the subprogram call mechanism.

• Other concurrent OOP languages (e.g. ALPS) let objects process incom-

ing messages by their own thread of control (active object with "body")

and queue messages in case an object is busy.

3.4 Inheritance

Given a class, inheritance allows to derive subclasses with more specific

properties (specialization). A subclass (descendant) inherits all the data fields

and methods from its superclass (ancestor) and can be defined to have additional

ones. Hence inheritance allows to add functionality without having to touch the

source code of the reused superclass. Another commonplace feature is the pos-

sibility to redefine inherited methods and attributes. This controlled modifica-tion again leaves the original code untouched.

Another question is how the reused superclass will behave as a component

of the new derived class. If a designer of a derived class makes only additions,

no modifications, he can be confident that the inherited methods will retain their

proper function with the inherited attributes. He is responsible only for what he

adds.

To study the effect of redefinitions on the inherited code in the subclass, weneed to know more about redefinition semantics. In case the old version of a re-

defined data field or method is removed and replaced by the new version, the

unchanged inherited parts can be significantly distorted. For instance, a rede-

fined method can implement a completely different functionality, and an at-

tribute redefined with a new type may falsify the invocation of operations with

that attribute in the inherited code. Hence, in most cases redefinition will be in-


46/245

11

terpreted as hiding rather than replacing, so that the inherited parts can continue

to work with the hidden old version, and only the added parts will use the rede-

fined new version.

In summary, provided there are no replacing modifications, inheritance al-

lows to reuse a superclass as a black box. Superclasses can be designed for reuse

as generalized, abstract units. It is not necessary to foresee and implement de-

tails about functionality possibly required by some future application. So the

complexity of a reusable class is reduced. Functionality can be added and mod-

ified in a controlled fashion during reuse, specializing classes for new purposes.

This makes class inheritance a model for flexible IP reuse.

3.5 Polymorphism

Polymorphism is a means to uniformly handle objects of classes related by

inheritance. It allows to send a message to an object without having to know at

compile time about the exact class of the receiver. Hence, the binding of mes-

sages (requests for method invocation) to an implementation of a method is to

take place at run time (dynamic binding).Some languages, e.g. Smalltalk, permit to send any message to any object,

raising a run time exception in case a receiver object does not have the requested

method implemented. However, many typed OOP languages (Ada95, Java)

have a mechanism to prevent such behavior— inclusion polymorphism: The

class of the addressed object is restricted by declaration to a given class, C , and

its descendants, and only the methods of the most general class, C , are allowed

to be requested from the object. Since the methods of C are available—either in-herited or redefined—in every transitively derived class, dynamic binding

works without run-time errors. It only has to dispatch a message to the imple-

mentation of the method in the class of the addressed object.

By its weakened typing, polymorphism provides a program with a greater

flexibility regarding the extension of its capabilities. An existing well-tested

program will be able to deal with new derived classes and call their methods


47/245

12

without having to be modified. Through the uniform handling of related classes,

a program becomes more readable.

Reuse combining inheritance with polymorphism is to be classified as grey-

box because the injection of an object of a new derived class into an existing sys-

tem can change its behavior. However, inclusion polymorphism can provide a

maximum of security to method invocation by static checks.

4 Language Design Considerations

In the previous section we have motivated the usefulness of object-orienta-

tion to increase abstraction and reuse in hardware modeling. It became obvious

that the required modeling power is av

Documents

Jise98 Unified Approach