A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35

A Unified Approach to Object-Oriented VHDL1

Authors:

Martin Radetzki, Wolfram Putzke-Rming, Wolfgang Nebel

Affiliation:

OFFIS Research Institute

Address:

Escherweg 2
26121 Oldenburg
Germany

e-mail:

radetzki@offis.uni-oldenburg.de

AbstractAbstraction and reuse are the keys to deal with the increasing complexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hardware 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.

Keywordshardware, 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 (APCHDL97).

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 integration density offered by submicron technologies. Maintenance is another issue 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 European Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these issues 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 implementation 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 VHDL. The state of the art in related work is reviewed in section five. To overcome

the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.

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 implement 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 design quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrication 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 hardwareeventually together with softwareat 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 abstraction 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 interested in behavioral synthesis to abstract from resource allocation and scheduling. 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.

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 specification, 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 software running on standard processor cores or application specific instruction processors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After partitioningbe it manually or with tool supportthe hardware design methodology 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 chosen
target 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. Intellectual 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,

 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 solutions. Reusing things (i.e. consuming reusable models) means to select, understand, 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 purpose. Such modifying reuse is called white-box reuse. It requires to understand
the 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 desirable to build generalized components. The use of parameters helps to make
components 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 limited modifications to the original source code without touching it directly. There

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:
FlexibilityA reusable model must be independent from a special application. A methodology should allow the addition of functionality, possibly a modification.
PortabilityThe model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
UnderstandabilityModerate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
ConfidenceA 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 provides 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-understandable 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.

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 considered 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, understandable, 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.

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, message passing, inheritance of classes, and polymorphism. These are applied during 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 mechanisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided into
three 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; representation in a graphical notation. Refinement for the description of function-

ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) diagrams.
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 graphical specifications into the implementation language. In case of design iterations, 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 return to the design phase in order to maintain a design or add features for an update. 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.

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 statestorage 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 environment 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 understandability 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 invoke 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 concurrently 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 design stage. However, implementation languages mostly constrain the message

passing:
In sequential OOP languages (e.g. C++) message passing and subprogram call are the same. The sender of a message is blocked while the
requested method is executed with the senders 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 incoming 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 possibility to redefine inherited methods and attributes. This controlled modification 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, we
need to know more about redefinition semantics. In case the old version of a redefined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a redefined method can implement a completely different functionality, and an attribute 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-

10

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 redefined new version.
In summary, provided there are no replacing modifications, inheritance allows 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 details about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and modified 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 messages (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 behaviorinclusion 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 availableeither inherited or redefinedin every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the implementation 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

11

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 greybox because the injection of an object of a new derived class into an existing system can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.

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) purposes. 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 language 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 refinement towards a lower level of abstractionfor instance a simulation time concept, 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 written in an existing HDL.
The last argument holds as well against the design of a completely new object-oriented HDL. The design of upward compatible OO extensions to an existing widespread HDL is most likely to be accepted by users because it helps

12

them to save their investments in models and because it reduces the cost threshold 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 modeling. So we chose VHDL as the basis to add object-oriented extensions. To enable 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 synthesis 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 methodology
and environment
Objective VHDL

Objective
VHDL
Preprocessor

Analyzer
Translator

REQUEST
development

Obj. VHDL
Intermediate
Format

VHDL
Simulation, Synthesis

Native
Environment

Fig. 1: Objective VHDL Tool Architecture

13

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.

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 proposals of OO-VHDL have been published (cf. [9]). But despite the growing interest 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, unified approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design entities 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 message passing. Whereas Vistas operations are similar to procedures, the LaMI

14

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

message passing serves to request the execution of methods. In the LaMI approach, 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 operations. A criticism of these queuing mechanisms includes two major points:
Relation to VHDL principlesIs 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 hardwareHow 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 proposed for this purpose, but this is hardly in line with present VHDL, and it implies 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 suited for writing an initial specification and to reuse parts of old specifications in
a new one. The specificationat a high level of abstractioncan 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 hierarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decompositionas known from object-orientation in the

15

software worldto hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inheritance 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 construct in the language, e.g. C++ classes. Schumacher [13] chose the first alternative, 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 programming 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 signals.
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 components. 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 approachthough inspired largely by the software worldis 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:

16

 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 processes.
Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a surrounding entity, the primary hardware abstraction according to the
LRM [16].

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 complex 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-orientation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented extensions 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 initial state (method init). A ROM is a memory. Hence ROM inherits from memory, 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].

17

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

memory

TYPE DOMAIN

init
read
data

composition
size
mem_datum
init

RAM

ROM

write

init

inheritance
operand

ENTITY DOMAIN

instruction
exec

Fig. 2: Memory modelling using entity and type inheritance

mem_datum or any of its descendants. Thereby, through use of type polymorphism the capabilities of the memory can be extended without having to modify 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

18

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). Moreover, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabilities of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integration of handles and message passing with the VHDL time concept and eventdriven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstraction. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These subprograms correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through definition of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing the
necessity 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 typebe it a base class or a derived classconsists 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 can
instantiate classes, but not packages; and classes are types as opposed to packages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
...

-- VHDL type definitions

| class_type_definition

19

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 belowdeclare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarationswhich 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

20

| ... -- 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 inheritance 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:

21

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 subprograms declared in a class declaration. It must be preceded by a corresponding 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.

22

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 subprogram 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 signals,
for a body within a for variable construct, class attributes are like variables, and
outside such construct (in the common part or in a for constant construct), 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 configuration part. Again a class must be declared abstract if it misses any implementation.
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

23

begin
value <= 0 after 1 ns;
end;
end for;
for variable
procedure init is
begin
value := 0;
end;
end for;
end class body operand;

6.3 Type Objects and their Use

A type object is a signal, [shared] variable, or constant of a non-abstract class
type, as well as a dynamically allocated VHDL object denoted by an access
type of a class. Using an object as a prefix, the following subprograms of the
class can be invoked with the particular object:
if the VHDL class of the object is constant, the common subprograms
and the subprograms declared in a for constant construct,
if the prefix denotes a signal, the common subprograms as well as the
subprograms declared in a for signal construct, and
if it is a variable, the subprograms of the common part and the for variable part.
Polymorphism comes at work through object declarations using the so-called
class-wide type that can be deduced from a class type with the predefined
Objective VHDL attribute CLASS. For each class type T, TCLASS includes T
and all the classes derived from T. An object declared as TCLASS can have
any of these types. Some actual class information is managed with each
instance of a class-wide type to deal with subprogram calls to such object.

24

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 TCLASS. Possibly the implementation (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 SCLASS (source) and DCLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because DCLASS includes SCLASS;
(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 DCLASS;
(3) S and D are not related by inheritance: errorno compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instructionCLASS := ... ; -- initialization is
variable operand_register : operandCLASS := ... ;

-- mandatory for

variable memory_location : mem_datumCLASS := ... ; -- 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

25

6.4 Extensions of the VHDL Design Entity

An investigation of the existing VHDL design entitywhich is an entity
together with a corresponding architectureshows that many properties of an
OO class are already present:
The entity defines the interface of a hardware unit. Thus, it can be compared 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 entitys
declarative part. These subprograms are regarded as methods in the following. Their bodies (i.e. the implementation) can be defined in a corresponding 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 primary 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

26

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 concatenation of the ancestors effective port list and the list of ports added in inheritance, 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 entitys statement 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

27

 all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concurrent 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 entitys 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 declaration 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_msgCLASS ); -- 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_datumCLASS;
shared variable data : mem_data;

-- signal also possible

procedure read( constant address : in address_range;

variable datum : out mem_datumCLASS );
-- 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_datumCLASS );

28

procedure write(constant address : in address_range;

constant datum : in mem_datumCLASS );
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 declarative region together with its corresponding entity, also its entitys 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.

29

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_datumCLASS ) 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_datumCLASS ) 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 consequence, 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

30

whereas the RAM shown above has some generic initial value. It also adds specific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entitys subprogram
(i.e. a method) from outside the entity. Such mechanism, called message passing, 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 language.
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 could
have a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and receiving a message.
By providing a number of processes that watch the channel signal(s) and invoke 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-

31

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

passing primitives into the language.
Listing 13: A simple dispatching process
process( channelTRANSACTION )
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 methodologies 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 classes). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combinations must be avoided:
Cross-inheritanceA derived design entity cannot inherit from a class
type and vice versa.
Cross-compositionAn entity can contain the declaration or instantiation 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-communicationInstances of entities and class types can communicate 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).

32

 Parameter passingInstances 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 VHDLs dichotomy into separate entity and type domains.

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 abstraction. Considerations on the design of an object-oriented hardware description language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been reviewed. The language architecture of REQUEST Objective VHDLcombining
type and entity object-orientationhas 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 hardware and software.

References

[1] M. Radetzki. W. Putzke-Rming, 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.

33

[2] W. Nebel, W. Putzke-Rming, 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 Economic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Redwood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. ObjectOriented 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 University Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Reference HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Extensions 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 VHDLThe LaMI
proposal. CHDL97, Toledo, Spain, 1997, pp. 334-347.

34

[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Oriented Extensions to VHDL. Proceedings of the Euro-DAC95 with EuroVHDL95, 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. Mller-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-Rming, 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-Rming, 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-Rming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specification (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Rming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF 98.

35