jise98 unified approach
TRANSCRIPT
-
8/19/2019 Jise98 Unified Approach
1/245
1
A Unified Approach to Object-Oriented VHDL1
Authors: Martin Radetzki, Wolfram Putzke-Röming, Wolfgang Nebel
Affiliation: OFFIS Research Institute
Address: Escherweg 2
26121 Oldenburg
Germany
e-mail: [email protected]
Abstract —Abstraction and reuse are the keys to deal with the increasing com-
plexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hard-
ware design. This requires an object-oriented hardware description language,
preferably an extension to VHDL. Several variants of such OO-VHDL are being
discussed controversially. We present our unified approach, Objective VHDL,
adding object-oriented features to the VHDL design entity as well as to the type
system to provide a maximum of modeling power.
Keywords —hardware, design, modeling, system level, reuse, object-oriented,
VHDL
1. This work has been funded as part of the OMI-ESPRIT project
REQUEST under contract 20616. This article is based on a paper [1]
published and copyrighted by the 4th Asia-Pacific Conference on
Hardware Description Languages (APCHDL’97).
-
8/19/2019 Jise98 Unified Approach
2/245
2
1 Introduction
Design reuse and system level design are being among the topics of major
concern within the electronic design community. Advanced techniques need to
be developed in order to keep design productivity in pace with the exponential
growth observed in the complexity of electronic systems as well as in the inte-
gration density offered by submicron technologies. Maintenance is another is-
sue particularly in the life-cycle of long-living products, for instance
telecommunication equipment. Finally, quality and testability are crucial for
safety-critical systems, for instance avionics equipment.
Within the REQUEST (REuse and QUality ESTimation) project of the Eu-
ropean Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these is-
sues developing a consistent methodology and tools based on the Very High
Speed Integrated Circuits Hardware Description Language (VHDL). Among
other tasks, the REQUEST workpackages include specification and implemen-
tation of object-oriented (OO) extensions to VHDL, expecting to transfer the
benefits of object-orientation from software engineering to an exploitation in
hardware design.
In this article, we first motivate the application of object-oriented modeling
techniques to hardware. We present the requirements to an advanced design
methodology in the next section. In the third section, we give an overview of the
object-oriented modeling paradigm and show that it meets the requirements.
The second half of the article is devoted to the question how to design an
object-oriented hardware description language in order to facilitate simulation
and synthesis of object-oriented models. We start with general considerations
constraining the design of an object-oriented hardware description language in
the fourth section, leading to the approach of object-oriented extensions to VH-
DL. The state of the art in related work is reviewed in section five. To overcome
-
8/19/2019 Jise98 Unified Approach
3/245
3
the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.
2 Problem Description
Hardware becomes increasingly complex. By the end of the century, chips
comprising 100 millions of transistors are likely to be manufacturable, and there
is no doubt that designs will utilize this potential. It will be possible to imple-
ment more sophisticated functionality in hardware and to integrate complete
systems on a single chip instead of a printed circuit board.
Design methodologies must enable designers to cope with that complexity
by increasing design productivity. As well, there are great demands on the de-
sign quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrica-
tion to avoid design iterations and to meet the market window.
We have identified two major starting points to tackle these issues. The first
one is design of hardware—eventually together with software—at a high level
of abstraction. The second one (no ranking implied) is reuse.
2.1 Abstract Specification of Hardware
Since the beginning of integrated circuit design, abstraction has been a
valuable means to deal with complexity. Gate level design provided an abstrac-
tion from the electrical behavior of transistors, allowing designers to focus on
the logic functionality and to rely on guaranteed properties of the basic cells.
Currently, design at register transfer level is commonplace, and people get in-
terested in behavioral synthesis to abstract from resource allocation and sched-
uling. The next step towards system level design should
• provide components with more comprehensible abstract interfaces,
• introduce abstract communication mechanisms between components,
and
• support data abstraction.
-
8/19/2019 Jise98 Unified Approach
4/245
4
This will ease the assembly of components to form a system and help to account
for the increasingly complex structure of data that is to be processed.
Starting from a rather abstract, possibly incomplete or graphical specifica-
tion, the refinement towards an implementation should be supported. This
means designers should be enabled to add details incrementally until there is
enough information to apply automatic synthesis using advanced techniques.
2.2 Hardware / Software Co-Design
Hardware / Software Co-Design has been outside the scope of our research.
However, since future systems will have an increasing share of embedded soft-
ware running on standard processor cores or application specific instruction pro-
cessors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After parti-
tioning—be it manually or with tool support—the hardware design methodolo-
gy based on object-oriented VHDL can be applied to the hardware part.
Standard object-oriented programming languages such as Ada95 or C++ can be
used to implement the software part. Automatic generation of code in the chosentarget language from OOD specifications and re-engineering support to generate
OOD diagrams from the target languages could facilitate an easy migration from
hardware to software and vice versa.
2.3 Reuse
Reuse helps to increase designers’ productivity allowing them to focus on
the real innovations. Costs for the re-invention of things can be avoided, and the
time saved can be used to achieve better testing or shorter time-to-market. Intel-
lectual property to be reused includes models of
• components in all their varieties,
• communication mechanisms, ranging from high level protocols like TCP/
IP to simple handshaking,
-
8/19/2019 Jise98 Unified Approach
5/245
5
• data structures and algorithms, for instance the sophisticated ones used
in ATM switches, and not least
• test environments since the effort for validation tends to increase even
faster than the complexity of tested designs.
We emphasize that reuse is not for free. Making things reusable (i.e. producing
reusable models) requires some overhead as compared to tailoring specific so-
lutions. Reusing things (i.e. consuming reusable models) means to select, under-
stand, possibly adapt and debug, integrate and finally test them. The costs
incurred depend on the kind of reuse and the degree of reusability, which will
be addressed in the next two sections. Thus, a methodology supporting proper
reuse is an important economic factor. It can help us to improve the quality of
our hardware designs through secure reuse of proven parts.
2.4 Kinds of Reuse
Of course, reuse is not a new invention. An intuitive approach to reuse is to
take an existing piece of source code or a schematic and adapt it to a new pur-
pose. Such modifying reuse is called white-box reuse. It requires to understandthe internals of the reused item, and this is a frequent source of errors. Due to
the debugging necessary in most cases of white-box reuse, its consumer costs
can approach those of a new design.
Unmodified black-box reuse, on the other hand, is relatively cheap for the
consumer, but it requires a higher initial effort to produce an item that is likely
to be reused. Some knowledge and planning about future applications is desir-
able to build generalized components. The use of parameters helps to makecomponents more flexible, but it also makes testing harder. On the other hand,
once the functionality of such black box is validated, and it is not touched, one
can definitely rely on it in future uses.
To provide a greater flexibility, one can apply grey-box reuse, allowing
controlled modifications. For instance, there may be mechanisms that allow lim-
ited modifications to the original source code without touching it directly. There
-
8/19/2019 Jise98 Unified Approach
6/245
6
should be application rules, validation procedures, or verification methods to
ensure proper functioning.
2.5 Requirements for Reusability
The question "What makes a model reusable?" has already been touched on
in the preceding text. In the following, we transfer a classification done in the
software domain [3] into hardware terms:
• Flexibility —A reusable model must be independent from a special appli-
cation. A methodology should allow the addition of functionality, possi-
bly a modification.
• Portability —The model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
• Understandability —Moderate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
• Confidence —A reusable model should be reliable and error tolerant; its
proper function should be validated or formally verified. It should ideally
not be touched when reusing it. Note that there are trade-offs between these factors; e.g. white-box reuse pro-
vides most flexibility, but it decreases confidence. Another example is that we
have more confidence in cross-talk resistance using hard macros, but our design
will not be portable to new technological platforms.
As a positive point, there is an interrelation of abstractness and reusability:
An abstract model is more likely to be flexible, portable, and human-under-
standable than a model which provides very detailed information. Vice versa,making a model reusable means generalizing, which is a process of abstraction.
Hence, it is not surprising that the units of abstraction identified in 2.1 are as
well candidates for reuse.
-
8/19/2019 Jise98 Unified Approach
7/245
7
2.6 Points Related to Reuse
Following [4], good reuse metrics do not count as reuse maintenance or the
sharing of models between designers in the same project and within one design
team. The first would distort quantitative measurements, and the latter is consid-
ered as good design practice. Anyway, the means to enhance reuse among the
borders of projects or design teams will as well be helpful to achieve sharing of
models within these borders, and we can be optimistic to obtain a maintainable
system when (re-)using subsystems which are flexible, portable, understand-
able, and reliable. Having in mind the typically long life cycle of products in the
telecommunication and avionics domain, we will have to consider maintenance
when choosing a methodology.
3 Benefits from Object-Orientation
Following Booch [5], every object-oriented methodology must provide a
minimum of features, which include (in our terminology): a class concept , mes-
sage passing , inheritance of classes, and polymorphism. These are applied dur-
ing the different main development phases: analysis (OOA), design (OOD), and
programming (OOP). In the following sections, we will present an outline of
these techniques and discuss their impact on our aims, abstraction and reuse,
starting with the overall design process and then moving to the four basic mech-
anisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided intothree main phases:
• Object-Oriented Analysis (OOA)—Requirement analysis, extraction of
objects / classes from an informal problem description.
• Object-Oriented Design (OOD)—Identification of interrelationships
between objects / classes such as composition and inheritance; represen-
tation in a graphical notation. Refinement for the description of function-
-
8/19/2019 Jise98 Unified Approach
8/245
8
ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) dia-
grams.
• Object-Oriented Programming (OOP)—Implementation of the designed
system in a programming language that supports the object-oriented
mechanisms.
With OOD diagrams one can specify a system graphically. This specification
may be informal and incomplete in the beginning; it can be refined in iteration
cycles until a considerable level of detail is achieved. Object-oriented design has
the potential to result in a complete specification and can be applied to mixed
hardware-software systems [7]. OOD diagrams include concepts well-known to
hardware designers, in particular data flow diagrams, hierarchical finite state
machines, and message interaction diagrams similar to timing charts. Hence an
OOD model should be well comprehensible once its notation is known, and it
can contribute a significant part to documentation.
Object-oriented design can and should be supported by tools. These allow
graphical input, provide consistency checks of the models, and translate graph-
ical specifications into the implementation language. In case of design itera-
tions, they will update the source code according to the changes in the
specification.
In the implementation phase, additional details can be added in a textual
form. The textual description can be compiled and executed. It is possible to re-
turn to the design phase in order to maintain a design or add features for an up-
date. As well, one can skip to implementation in order to produce a prototype at
an early stage of the design and return to the design phase later to complete the
system. Providing such flexibility, object-oriented modeling can also deal with
the evolution of systems over a long period of time.
-
8/19/2019 Jise98 Unified Approach
9/245
9
3.2 Classes
The class is the basic object-oriented concept upon which the other build. It
comprises the definition of data fields (attributes) and functionality (methods).
From a class, objects can be created dynamically or by static instantiation. Each
of these objects has its own local state—storage for values of the data fields.
Since no access other than by the invocation of methods is provided to modify
the local state, the designer of a class can ensure the consistency of the local state
by construction. In other words, objects are encapsulated from their environ-
ment by their method interface.
For (re-)using a class, it is sufficient to understand its interface. Thus,
through the hiding of the internals, its degree of abstraction and its understand-
ability are significantly improved. Moreover, by the convention that, once a
class is designed, implemented, and debugged, its source code should not be
touched, a class provides a very safe way of reuse.
3.3 Message Passing
Objects communicate with each other requesting the execution of methods
by passing messages. A message carries the information which method to in-
voke and the input and output data of the method. On the conceptual level many
object-oriented methods (e.g. Booch [5], OMT [6]) do not deal with details
(whereas HOOD [8] does), e.g.
• whether the sender is blocked during method execution by the receiver,
• how a receiver behaves in case several messages arrive from concur-
rently sending objects at the same time or interleaved with the execution
of another method, or
• with whose resources (thread of computation, control flow, task, process)
a method is executed.
The common sense is only that messages should not be lost. Thus, describing
communication through message passing is a significant abstraction at the de-
sign stage. However, implementation languages mostly constrain the message
-
8/19/2019 Jise98 Unified Approach
10/245
10
passing:
• In sequential OOP languages (e.g. C++) message passing and subpro-
gram call are the same. The sender of a message is blocked while the
requested method is executed with the sender’s resources.
• Some concurrent OOP languages (e.g. Java) add synchronization (e.g.
monitor concept) to the subprogram call mechanism.
• Other concurrent OOP languages (e.g. ALPS) let objects process incom-
ing messages by their own thread of control (active object with "body")
and queue messages in case an object is busy.
3.4 Inheritance
Given a class, inheritance allows to derive subclasses with more specific
properties (specialization). A subclass (descendant) inherits all the data fields
and methods from its superclass (ancestor) and can be defined to have additional
ones. Hence inheritance allows to add functionality without having to touch the
source code of the reused superclass. Another commonplace feature is the pos-
sibility to redefine inherited methods and attributes. This controlled modifica-tion again leaves the original code untouched.
Another question is how the reused superclass will behave as a component
of the new derived class. If a designer of a derived class makes only additions,
no modifications, he can be confident that the inherited methods will retain their
proper function with the inherited attributes. He is responsible only for what he
adds.
To study the effect of redefinitions on the inherited code in the subclass, weneed to know more about redefinition semantics. In case the old version of a re-
defined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a rede-
fined method can implement a completely different functionality, and an at-
tribute redefined with a new type may falsify the invocation of operations with
that attribute in the inherited code. Hence, in most cases redefinition will be in-
-
8/19/2019 Jise98 Unified Approach
11/245
11
terpreted as hiding rather than replacing, so that the inherited parts can continue
to work with the hidden old version, and only the added parts will use the rede-
fined new version.
In summary, provided there are no replacing modifications, inheritance al-
lows to reuse a superclass as a black box. Superclasses can be designed for reuse
as generalized, abstract units. It is not necessary to foresee and implement de-
tails about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and mod-
ified in a controlled fashion during reuse, specializing classes for new purposes.
This makes class inheritance a model for flexible IP reuse.
3.5 Polymorphism
Polymorphism is a means to uniformly handle objects of classes related by
inheritance. It allows to send a message to an object without having to know at
compile time about the exact class of the receiver. Hence, the binding of mes-
sages (requests for method invocation) to an implementation of a method is to
take place at run time (dynamic binding).Some languages, e.g. Smalltalk, permit to send any message to any object,
raising a run time exception in case a receiver object does not have the requested
method implemented. However, many typed OOP languages (Ada95, Java)
have a mechanism to prevent such behavior— inclusion polymorphism: The
class of the addressed object is restricted by declaration to a given class, C , and
its descendants, and only the methods of the most general class, C , are allowed
to be requested from the object. Since the methods of C are available—either in-herited or redefined—in every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the imple-
mentation of the method in the class of the addressed object.
By its weakened typing, polymorphism provides a program with a greater
flexibility regarding the extension of its capabilities. An existing well-tested
program will be able to deal with new derived classes and call their methods
-
8/19/2019 Jise98 Unified Approach
12/245
12
without having to be modified. Through the uniform handling of related classes,
a program becomes more readable.
Reuse combining inheritance with polymorphism is to be classified as grey-
box because the injection of an object of a new derived class into an existing sys-
tem can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.
4 Language Design Considerations
In the previous section we have motivated the usefulness of object-orienta-
tion to increase abstraction and reuse in hardware modeling. It became obvious
that the required modeling power is available with the OOD. But there is not yet
an idea which language to use for hardware model implementation (OOP) pur-
poses. We address this point now.
An implementation of a hardware model should allow us to simulate and
synthesize it. The alternatives for an implementation language are to
• use an existing software programming language,
• design an object-oriented HDL from scratch, or
• extend an existing HDL.
Of course the first approach would be usable instantaneously, but can a
software language satisfy all the requirements of hardware description? A lan-
guage like Ada95 or Java may be used to write a concurrent high-level model in
a software-like style, but it misses the means to describe hardware after refine-
ment towards a lower level of abstraction—for instance a simulation time con-
cept, events, signals, and structural descriptions. Hence, using a software
language, we would not be able to simulate high-level models together with
models at a lower level of abstraction. Moreover, we could not use models writ-
ten in an existing HDL.
The last argument holds as well against the design of a completely new ob-
ject-oriented HDL. The design of upward compatible OO extensions to an ex-
isting widespread HDL is most likely to be accepted by users because it helps
-
8/19/2019 Jise98 Unified Approach
13/245
13
them to save their investments in models and because it reduces the cost thresh-
old to learning the language. For similar reasons also tool vendors are likely to
prefer this solution once they can expect to have a user base.
Among the popular HLDs, VHDL has the best potential for high-level mod-
eling. So we chose VHDL as the basis to add object-oriented extensions. To en-
able cheap evaluation and a smooth transition to object-oriented hardware
modeling, we will provide a preprocessor for the translation of our Objective
VHDL into VHDL (Fig. 1). This allows to use available simulation and synthe-
sis environments and provides a link to existing design flows.
Shortcomings of the preprocessor approach are that
• debugging takes place on VHDL level (but links back to Objective
VHDL sources can be provided),
• tools like VHDL hierarchy browser or waveform display do not account
for object-oriented specifics, and
• some overhead may be caused to the VHDL analysis, simulation, and
synthesis due to the obligatory flattening of inheritance hierarchies.
To overcome these issues in the medium term, we should strive for native OO-
OO methodologyand environment
Objective VHDL
Analyzer
Translator
Objective
VHDL
Preprocessor
Obj. VHDLIntermediate
Format
VHDL
Simulation, Synthesis Native
Environment
Fig. 1: Objective VHDL Tool Architecture
REQUESTdevelopment
-
8/19/2019 Jise98 Unified Approach
14/245
14
VHDL environments. Thus, it is important to note that tools can be build as
back-ends upon a procedural interface to the intermediate format generated by
the analyzer (see Fig. 1). An IEEE standardization of object-oriented extensions
to VHDL and the establishment of a user community interested in such language
will be helpful to convince CAD vendors to support this new technology.
5 Previous OO-VHDL Paradigms
In the previous sections we have shown that object-oriented extensions to
VHDL are a practical approach to achieve higher abstraction and more reuse in
hardware modeling. Subsequently we will address the characteristics of some
approaches to object-oriented VHDL, before we switch to the language design
of Objective VHDL in the next section.
The way object-oriented extensions should be incorporated into VHDL has
been a research topic for the last five years, and about a dozen of different pro-
posals of OO-VHDL have been published (cf. [9]). But despite the growing in-
terest in an OO-VHDL, no general agreement has been achieved up to now
whether the VHDL design entity or the VHDL data type system should serve as
basis for object-oriented extensions. We will provide a short review of these
contrasting directions and their nuances in this section and present a new, uni-
fied approach in section six.
5.1 Entity Approaches
A basic approach to adding some aspect of object-orientation to design en-
tities is structural inheritance as proposed e.g. by Ecker [10]. It facilitates the
extension of entity-architecture pairs for additional generics, ports, declarations,
and concurrent statements, but it does not account for OO concepts like methods
and message passing communication.
The latter points are addressed by the Vista [11] and LaMI [12] proposals,
which present the concept of operations and their invocation by abstract mes-
sage passing. Whereas Vista’s operations are similar to procedures, the LaMI
-
8/19/2019 Jise98 Unified Approach
15/245
15
approach considers them to correspond rather to processes. In both proposals,
message passing serves to request the execution of methods. In the LaMI ap-
proach, there exists a separate message queue for each concurrent operation in
order to store messages arriving while the requested operation is busy. Vista
provide one global queue per object with the option to prioritize certain opera-
tions. A criticism of these queuing mechanisms includes two major points:
• Relation to VHDL principles —Is entity message passing compliant with
event-driven simulation, how much simulated time does it consume, and
in which way can determinism be guaranteed in case two messages arrive
at the same delta cycle of the simulation?
• Relation to hardware —How can a message queue of potentially infinite
length be implemented in hardware, or better: How can its maximum size
be determined?
Another issue is how to enable addressing of a message receiver across the
entity borders of a design hierarchy. Entity handles (pointers) have been pro-
posed for this purpose, but this is hardly in line with present VHDL, and it im-
plies the implementation of a sophisticated communication protocol for the
routing of messages in case of automatic hardware generation.
Thus, the entity approaches which go beyond structural inheritance are suit-
ed for writing an initial specification and to reuse parts of old specifications in
a new one. The specification—at a high level of abstraction—can be simulated,
but its refinement to lower levels of abstraction will be hard. We have identified
abstraction as a main goal, but on the other hand it has to be limited: In order to
still serve as a hardware description language, OO-VHDL must not abstract
from hardware.
5.2 Type Approaches
Whereas the entity approaches allow designers to keep the paradigm of hi-
erarchical decomposition oriented at functional units, type approaches aim to
transfer data-oriented decomposition—as known from object-orientation in the
-
8/19/2019 Jise98 Unified Approach
16/245
16
software world—to hardware design. The proposals differ with respect to their
class concept, the way classes can be instantiated, and the details about inherit-
ance mechanism and polymorphism.
According to OO-VHDL design considerations published by Ashenden [9],
a class concept can arise from the interplay of several language concepts, e.g.
Ada95 tagged types, packages, and private types, or a class may be a single con-
struct in the language, e.g. C++ classes. Schumacher [13] chose the first alter-
native, but without encapsulation by private types, whereas Cabanis [14] and
Zippelius [15] preferred the latter.
The observed choices for the instantiation of classes are:
• Instantiation only as variables (Zippelius)—Mechanisms of program-
ming languages can easily be adopted to deal with polymorphism and
dynamic binding.
• Instantiation only as signals (Cabanis)—Polymorphism is not addressed
in this proposal.
• Both kinds of instantiations (Schumacher)—A variant record mechanism
(as opposed to pointers) allows to provide polymorphism also with sig-
nals.
In our opinion, it is desirable to have a class concept and polymorphism also
with signals in order to use them for abstract communication between compo-
nents. Since Schumacher has shown that it is possible to simulate and synthesize
polymorphism of class types applied to variables as well as signals, we are in
favor of providing a maximum of modeling power by supporting class-typed
variables and signals.
Compared to the entity approaches with queuing and handles, the type ap-
proach—though inspired largely by the software world—is closer to hardware
because it allows translation into hardware-oriented data representations. It even
seems feasible to integrate OO extensions of the type system into core VHDL
because they do not conflict with the above stated VHDL specifics. On the other
hand, the type approach has its shortcomings as well:
-
8/19/2019 Jise98 Unified Approach
17/245
17
• The VHDL type system does not facilitate the description of concurrent
behavior inherent to hardware; functionality associated with data types is
implemented in sequential subprograms as opposed to concurrent pro-
cesses.
• Hardware components cannot be described with types alone; this
becomes evident by the fact that nothing works in VHDL without a sur-
rounding entity, the primary hardware abstraction according to the
LRM [16].
6 The Unified Approach of REQUEST
We have no doubt that a type approach is useful in the context of hardware
modeling to provide abstraction capabilities to deal with the increasingly com-
plex data being processed, and to model communication. But to take advantage
of object-oriented concepts when modeling hardware components themselves, a
type approach is not sufficient; it should rather be supported by some object-ori-
entation of design entities. Thus, we decided to provide the Objective VHDL of
REQUEST with both, an object-oriented class type and object-oriented exten-
sions to entities. We will outline the concepts of our language extensions in the
following subsections2, discuss their interrelationships, and motivate with an
example how they can be used synergistically.
A memory (Fig. 2, graphical notation after Rumbaugh [6]) has data as its
content and must at least provide read functionality and a way to define its ini-
tial state (method init ). A ROM is a memory. Hence ROM inherits from mem-
ory, and it may for instance redefine the initialization functionality to read a
file. Also a RAM is a (inherits from) memory. Since a RAM can be written
into, this functionality is added in inheritance. All this will be modeled in the
next chapter using entity inheritance because memories are hardware units.
2. A more detailed presentation of Objective VHDL can be found in
[17]. A concise language definition is available [18].
-
8/19/2019 Jise98 Unified Approach
18/245
18
The size of the memory is a generic of the entity memory. Inside the entity, a
correspondingly sized array with elements of the class mem_datum can be
declared and instantiated as attribute of the entity. The mem_datum is an
abstract class type (cf. 3.4). All the data types to be stored in the heterogeneous
memory, e.g. machine instructions and their operands, will be derived from
mem_datum. The attribute data of the memory must be polymorphic, enabling
the memory to store also every subclass of mem_datum.
If the memory model shall be reused to store something other than e.g.
operands and instructions, this new class will simply be derived from
mem_datum or any of its descendants. Thereby, through use of type polymor-
phism the capabilities of the memory can be extended without having to mod-
ify its code.
The class types can as well be utilized for addressing an entity class and
requesting execution of its methods. Thereby the decision for a communication
memory
read
data
init
RAM
write
ROM
init
mem_datum
operand instruction
exec
size
init
Fig. 2: Memory modelling using entity and type inheritance
TYPE DOMAIN
ENTITY DOMAIN
composition
inheritance
-
8/19/2019 Jise98 Unified Approach
19/245
19
mechanism and the degree of concurrency is left to the user rather than laying it
down at the language level as the pure entity approaches do (cf. 5.1). More-
over, the introduction of entity handles to enable communication across a
design hierarchy becomes superfluous when utilizing the additional capabili-
ties of class-typed signals and polymorphism (see 6.7, [19]). This means
smaller deviation from the concepts of VHDL and avoids issues on the integra-
tion of handles and message passing with the VHDL time concept and event-
driven simulation.
6.1 Declaration of Class Types
The class type of Objective VHDL provides a new mechanism for data abstrac-
tion. It represents a collection of data fields (OO attributes) together with and
encapsulated by associated functionality provided by subprograms. These sub-
programs correspond to methods in object-oriented terminology. Inheritance of
class types supports reuse and extensibility of existing classes through defini-
tion of derived classes. Since multiple inheritance from more than one ancestor
makes a language and its implementation more complicated imposing thenecessity to resolve name conflicts due to repeated inheritance of attributes and
methods from different branches of an inheritance hierarchy, it was decided for
single inheritance.
A class type—be it a base class or a derived class—consists of a declaration
and a body, similar to a protected type of the shared variable language change
specification [20]. This separation of an interface from the implementation may
also be compared to packages, but there are significant differences: one caninstantiate classes, but not packages; and classes are types as opposed to pack-
ages which are design units.
Listing 1: Anchoring class types and bodies in the VHDL grammar
type_definition ::=
... -- VHDL type definitions
| class_type_definition
-
8/19/2019 Jise98 Unified Approach
20/245
20
class_type_definition ::=
class_type_declaration
| derived_class_type_declaration
| class_type_body
Inside a class type declaration, a number of declarations may occur. Besides
other declarations whose semantics are transferred from VHDL, there are class
attribute declarations, subprogram declarations and class configurations:
• class attribute declarations of a class type declare its data fields;
• subprogram declarations in the immediate declarative region of the class
declare methods common to all objects of that class type;
• subprogram declarations in the class configuration for signal (variable,
constant)—see below—declare methods applicable exclusively to signals
(variables, constants) of that class type.
The subprogram declarations—which do not include a subprogram body—
serve as methods forming the interface of the class. Thus, we will use the term
subprogram instead of method in the following. The subprograms declared in
the class can be invoked from outside the class (see 6.3). As opposed to this,
access to the class attribute declarations is limited to the body of the class and
to its descendants.
Listing 2: Grammar of class type declarations
class_type_declaration ::=
[ abstract ] class
{ class_type_declarative_item }
end class [ class_type _simple_name ]
class_type_declarative_item ::=
class_attribute_declaration
| subprogram_declaration
| class_type_configuration
-
8/19/2019 Jise98 Unified Approach
21/245
21
| ... -- further items: constant, [sub]type, alias, use clause
class_type_configuration ::=
for object_specification
{ class_type_configuration_item }
end for;
object_specification ::= signal | variable | constant
A derived class can be declared according to the grammar production shown in
Listing 3. The class type name after the ’new class’ denotes the ancestor.
Besides the explicitly declared subprograms and class attributes, also all
declarative items of the ancestor are implicitly declared in the derived class. An
implicit declaration is hidden by an explicit declaration according to classic
VHDL visibility and overloading rules. To apply these, the declarative region
formed by the direct ancestor of a class type T is considered as immediately
enclosing the declaration of T.
To cope with the implicit declarations, the declaration of the ancestor class
must be analyzed prior to its descendants. This also ensures that a class cannot
inherit from its descendant, which would mean there were a cycle in the inher-
itance relationship.
Listing 3: Grammar of derived class type declarations
derived_class_type_declaration ::=
new [ abstract ] class class_type _name with
{ class_type_declarative_item }
end class [ class_type _simple_name ]
A [derived] class type definition can only occur within a type declaration. If the
optional simple name appears at its end, it must repeat the identifier which is
declared as a class type. For instance, the class mem_datum of Fig. 2 is
declared, and classes are derived from it as shown in Listing 4:
-
8/19/2019 Jise98 Unified Approach
22/245
22
Listing 4: Objective VHDL source code of class declarations
type mem_datum is abstract class
procedure init;
end class mem_datum;
type instruction is new abstract class mem_datum with
for variable
procedure exec;
end for;
end class instruction;
type LOAD is new class instruction with
class attribute address : addressing_mode;
end class LOAD;
type operand is new class mem_datum with
class attribute value : integer;
function get return integer;
end class operand;
6.2 Declaration of Class Bodies
A class type body primarily comprises subprogram body definitions for sub-
programs declared in a class declaration. It must be preceded by a correspond-
ing class type declaration in the same immediate declarative region. Both
together form a single declarative region. Declaration of a class in a package
header followed by a class body in the package body is recommended.Vice versa, a class type declaration may come without a corresponding
body. It is also permitted to leave a subprogram declaration of a class without a
body. In both cases, the class type declaration concerned must use the keyword
abstract (see Listing 2, 3) which means some implementation is still missing.
It may be added in future inheritance steps.
-
8/19/2019 Jise98 Unified Approach
23/245
23
Listing 5: Grammar of class type bodies
class_type_body ::=
class body
{ class_body_declarative_item }
end class body [ class_type _simple_name ]
The declarative items of a class body are those of a class declaration plus sub-
program bodies. Access from these bodies to the class attributes depends on the
place of the subprogram body declaration:
• for a body within a for signal construct, class attributes behave like sig-
nals,
• for a body within a for variable construct, class attributes are like vari-
ables, and
• outside such construct (in the common part or in a for constant con-
struct), class attributes may only be read (like a constant).
A subprogram declared in the common part of the class must have a body
either in the common part of the class body or in all class body configuration
parts (for signal, variable, and constant). Subprogram declarations from a class
configuration part must have a body in the corresponding class body configura-
tion part. Again a class must be declared abstract if it misses any implementa-
tion.
Listing 6: Body corresponding to a class type from Listing 4
type operand is class body
function get return integer is
begin
return value;
end;
for signal
procedure init is
-
8/19/2019 Jise98 Unified Approach
24/245
24
begin
value
-
8/19/2019 Jise98 Unified Approach
25/245
25
A subprogram invoked with a polymorphic object must be declared in its
base class T. Since the subprogram is inherited to the ancestors, we can be sure
that the call is valid for all classes comprised by T’CLASS . Possibly the imple-
mentation (subprogram body) has been redefined during inheritance, in case of
which the body corresponding to the actual class membership of the object is
executed (dynamic binding mechanism). For instance, if classes LOAD and
STORE are derived from the instruction class of the memory model, a call to
subprogram exec with the instruction register (see below) will be dispatched to
the implementation of exec in either LOAD or STORE , depending on what kind
of instruction is in the instruction register at the time of the call.
Assignment operators are predefined for class types as well as class-wide
types. Whereas there is strict type checking with the class types (i.e. destination
and source of assignment must be of the same class), assignments involving
class-wide types S’CLASS (source) and D’CLASS (destination) are checked
as follows (cf. the code example below):
(1) S is subclass of D (or equal): ok because D’CLASS includes S’CLASS;
(2) S is superclass of D: passes analysis, but causes a run-time error if the
actual class of the source object is not included in D’CLASS;
(3) S and D are not related by inheritance: error—no compatibility.
Listing 7: Use of class-wide types and objects
variable instruction_register : instruction’CLASS := ... ; -- initialization is
variable operand_register : operand’CLASS := ... ; -- mandatory for
variable memory_location : mem_datum’CLASS := ... ; -- ’CLASS objects
...
instruction_register.exec; -- dynamic binding applies
instruction_register := memory_location; -- (2) may cause run-time error
memory_location := operand_register; -- (1) works always
operand_register := instruction_register; -- (3) not permitted; static error
-
8/19/2019 Jise98 Unified Approach
26/245
26
6.4 Extensions of the VHDL Design Entity
An investigation of the existing VHDL design entity—which is an entity
together with a corresponding architecture—shows that many properties of an
OO class are already present:
• The entity defines the interface of a hardware unit. Thus, it can be com-
pared to the declaration of a class.
• The architecture gives the implementation of a hardware unit, like a class
body implements the functionality of a class.
• In the declarative part of an entity, signals and shared variables can be
declared. These can be interpreted as OO attributes.
• As well, the declaration of subprograms is permitted in the entity’s
declarative part. These subprograms are regarded as methods in the fol-
lowing. Their bodies (i.e. the implementation) can be defined in a corre-
sponding architecture.
What remains to add to the modeling capabilities available with design entities
is at least inheritance. See below our extension of the VHDL notion of a pri-
mary unit (secondary unit, resp.) for new constructs allowing to declare derived
entities (architectures, resp.). A fixed message passing mechanism as a way to
invoke the subprograms from outside is not included as part of the language.
Instead, it can be modeled using the class types as proposed in section 6.7.
Polymorphism of design entities is not provided since a piece of hardware is
supposed to be static, i.e. not to change its structure during simulation.
Listing 8: Extension of VHDL grammar for derived design units
primary_unit ::=
... -- primary units of VHDL
| derived_entity_declaration
secondary_unit ::=
... -- secondary units of VHDL
| derived_architecture_body
-
8/19/2019 Jise98 Unified Approach
27/245
27
6.5 Derived Entities
With the exception of stating in a new ... with clause the ancestor from which a
derived entity inherits, its declaration is syntactically identical to the regular
entity of VHDL. Header, declarative part, and statement part of a derived entity
share the syntax of their respective entity counterparts. But, as opposed to a
non-derived ’base class’ entity, they declare extensions and modifications with
respect to the ancestor.
Listing 9: Grammar of derived entity declaration
derived_entity_declaration ::=entity identifier is new entity _name with
derived_entity_header
derived_entity_declarative_part
[ begin
derived_entity_statement_part ]
end [ entity ] [ entity _simple_name ] ;
Effective port and generic lists of a derived entity define its full interface to be
used at instantiation. The effective port list of a derived entity is the concatena-
tion of the ancestor’s effective port list and the list of ports added in inherit-
ance, which must be disjoint to prevent name conflicts. The effective port list
of a non-derived entity is simply its port list. An analogous definition holds for
generics.
An effective entity statement part takes the place of a regular entity’s state-
ment part wherever a derived entity is used instead of an entity. It is the union
of
• all concurrent statements from the derived entity statement part,
• all concurrent statements from the effective entity statement part of the
ancestor entity that do not have a label, and
-
8/19/2019 Jise98 Unified Approach
28/245
28
• all labelled concurrent statements from the effective entity statement part
of the ancestor entity whose label does not occur as a label of a concur-
rent statement in the derived entity statement part.
Again, the effective statement part of a base entity is its statement part. We
emphasize that the ordering of concurrent statements is insignificant, and that
the third point defines the replacement of labelled concurrent statements, e.g.
processes, during inheritance.
Inheritance of the ancestor entity’s declarations is defined by their implicit
declaration in the derived entity. In case the derived entity explicitly declares a
homograph of an inherited name and no overloading can be applied, the
explicit declaration hides the implicit one (redeclaration). Such hidden declara-
tion can be made visible by selection using the ancestor entity name as a prefix.
The example in Listing 10 corresponds to Fig. 2. It shows how a RAM
entity can be derived from a memory.
Listing 10: Implemetation of inheritance hierarchy of memories
-- here: some library / use clause to make the used types directly visible
entity memory is
generic( size : natural );
port( message : memory_msg’CLASS ); -- for message passing cf 6.7
subtype address_range is natural range 0 to size-1;
type mem_data is array ( address_range ) of mem_datum’CLASS;
shared variable data : mem_data; -- signal also possible
procedure read( constant address : in address_range;
variable datum : out mem_datum’CLASS );
-- read could also be implemented as a function returning the data
procedure init;
end memory;
entity RAM is new memory with
generic( initial_value : mem_datum’CLASS );
-
8/19/2019 Jise98 Unified Approach
29/245
29
procedure write(constant address : in address_range;
constant datum : in mem_datum’CLASS );
end RAM;
6.6 Derived Architectures
A derived architecture inherits declarations and concurrent statements from its
ancestor. It is declared using the following syntax:
Listing 11: Grammar of derived architecture body
derived_architecture_body ::=
architecture identifier of entity _name_#1 is
new [ abstract ] architecture _name [ of entity _name_#2 ] with
derived_architecture_declarative_part
begin
derived_architecture_statement_part
end [ architecture ] [ architecture _simple_name ] ;
The architecture name stated after the keyword new denotes the ancestor. To
make sure inheritance of implementations (architectures) is consistent with the
inheritance of interfaces (entities) they correspond to, the optional second
entity name must denote an ancestor of the first. In case the second entity name
is omitted or equal to the first entity name, the derived architecture corresponds
to the same entity as the ancestor architecture.
Inheritance of concurrent statements and declarations is defined in analogy
to entities (cf. 6.5) through an effective architecture statement part and implicit
declarations, respectively. Since a derived architecture forms a single declara-
tive region together with its corresponding entity, also its entity’s implicit (i.e.
inherited) and explicit declarations are visible. Hence, in the example below,
the procedure read implemented in an architecture of entity RAM can write to
the shared variable data declared in the ancestor entity memory.
-
8/19/2019 Jise98 Unified Approach
30/245
30
Listing 12: Architectures corresponding to entities of Listing 10
architecture OO of memory is abstract
procedure read( constant address : in address_range;
variable datum : out mem_datum’CLASS ) is
begin
datum := data( address );
end;
begin ... end OO;-- statement part implements method invocation; see 6.7
architecture OO of RAM is new OO of memory with
procedure write(constant address : in address_range;
constant datum : in mem_datum’CLASS ) is
begin
data( address ) := datum;
end;
procedure init is
begin
data := ( others => initial_value );
end; -- initial_value is a generic of entity RAM
begin end OO; -- empty statement part; the inherited is sufficient
The subprogram init declared in entity memory is said to be abstract because
architecture OO of memory does not define its subprogram body. In conse-
quence, architecture OO of memory must be declared abstract which means
some implementation is missing. Objective VHDL forbids instantiation of such
abstract architectures, and since there is no other architecture of memory, it will
never be instantiated. Memory and its abstract architecture serve solely to
declare and partially implement once what is common to all kinds of memories.
Non-abstract devices, e.g. a ROM or a RAM derived from memory, will add
the missing initialization functionality. A ROM may read its content from a file
-
8/19/2019 Jise98 Unified Approach
31/245
31
whereas the RAM shown above has some generic initial value. It also adds spe-
cific write functionality not available from a ROM.
6.7 Message Passing
We have not yet considered the mechanism to invoke an entity’s subprogram
(i.e. a method) from outside the entity. Such mechanism, called message pass-
ing, must include:
• transmission of actuals required as inputs parameters of the subprogram,
• invocation of the requested method from inside the entity, and
• transmission of results (i.e. output parameters or function return values).
Thus, in essential sending a message means transmission of information that
can be modeled using the class types as briefly described in the following.
Notice this is a modeling guideline to the user, not an integral part of the lan-
guage.
A message class corresponding to a method should comprise data fields
(i.e. class attributes) to hold the parameter values and a dispatch procedure that
calls the corresponding method with these parameters. A channel class couldhave a class-wide attribute to hold a message to be transmitted via the channel
and describe the exchange protocol through subprograms for sending and re-
ceiving a message.
By providing a number of processes that watch the channel signal(s) and in-
voke the dispatching of messages, the degree of inner-object concurrency can be
specified. Thus, rather than integrating a fixed message passing mechanism as
part of Objective VHDL, language primitives can be used to model message passing solutions. This idea and the modeling guidelines are explained in more
detail in [19, 21]. In the simplest case, a single dispatching process completing
architecture OO of memory (cf. 6.6) may look like Listing 13. However, using
more complicated protocols and messages, their modeling may be cumbersome
to the user. Hence, future research and development will be done to ease mes-
-
8/19/2019 Jise98 Unified Approach
32/245
32
sage passing through protocol-generating tools and an inclusion of message
passing primitives into the language.
Listing 13: A simple dispatching process
process( channel’TRANSACTION )
begin
channel.dispatch;
end;
6.8 Class Interrelationships
Due to the decision to provide class types as well as derived design entities,
Objective VHDL has two different kinds of classes. Object-oriented methodol-
ogies do in general not account for different kinds of classes (e.g. OMT [6],
Booch [5]; HOOD [8] on the other hand distinguishes active and passive class-
es). Nonetheless we must investigate the interrelationships between entity and
type classes; they prove to be not totally orthogonal so that improper combina-
tions must be avoided:
• Cross-inheritance —A derived design entity cannot inherit from a class
type and vice versa.
• Cross-composition —An entity can contain the declaration or instantia-
tion of a class type, but the reverse is not permitted; a passive object
(instance of a class type) cannot contain an active object (instance of an
entity).
• Cross-communication —Instances of entities and class types can commu-
nicate with each other, but the appropriate mechanism has to be chosen:
An entity can call methods of the class (if visible), and a class can send
messages to an entity via a channel (cf. 6.7).
-
8/19/2019 Jise98 Unified Approach
33/245
33
• Parameter passing —Instances of class types (variables, signals) can be
passed as parameters, which enables the receiver to send them messages.
An entity cannot be passed as parameter, but it is possible to pass the
message signal that it receives.
These rules are canonic extensions of the way things go in present VHDL; they
are the result of VHDL’s dichotomy into separate entity and type domains.
7 Conclusion
Object-oriented techniques are an attractive means to deal with complexity
issues in hardware design. We have shown how object-orientation can help to
achieve more reuse in hardware modeling and to shift it to a higher level of ab-
straction. Considerations on the design of an object-oriented hardware descrip-
tion language as an extension to VHDL have been presented. Against this
background, the main branches recognized in previous work have been re-
viewed. The language architecture of REQUEST Objective VHDL—combining
type and entity object-orientation—has been justified, the interrelations of type
classes and entity classes have been addressed, and their cooperation has been
illuminated. An Objective VHDL language reference manual is available from
http://eis.informatik.uni-oldenburg.de/research/request.html. An Objective
VHDL compiler front end and a translator into VHDL, being developed by
LEDA S.A. and OFFIS, respectively, will be publically available in 1998.
Future work includes research on synthesis optimization of object-oriented
hardware models, properties pertained during inheritance, and message passing
improvements as well as to broaden the scope to include the co-design of hard-
ware and software.
8 References
[1] M. Radetzki. W. Putzke-Röming, W. Nebel. OO-VHDL: What Is It, and
Why Do We Need It? Proc. 4th Asia-Pacific Conference on Hardware
Description Languages. Hsin-Chu, Taiwan, 1997, pp. 16-23.
-
8/19/2019 Jise98 Unified Approach
34/245
34
[2] W. Nebel, W. Putzke-Röming, M. Radetzki. Das OMI-Projekt REQUEST .
Invited talk, 3. GI/ITG/GMM Workshop „Hardwarebesch-
reibungssprachen und Modellierungsparadigmen“, Holzhau, Germany,
1997.
[3] E.-A. Karlsson, G. Sindre, T. Stalhane. Techniques for Making More
Reusable Components. REBOOT Technical Report No. 41, 1992.
[4] J.S. Poulin. Measuring Software Reuse: Principles, Practices, and Eco-
nomic Models. Addison-Wesley, 1997.
[5] G. Booch. Object Oriented Design. Benjamin/Cummings Publishing, Red-
wood City, 1991.
[6] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-
Oriented Modeling and Design. Prentice Hall, 1991.
[7] E. Holz et al. INSYDE Integrated Methods for Evolving System Design—
Application Guidelines. ESPRIT Project 8641 Report, Humboldt Univer-
sity Berlin.
[8] HOOD Technical Group. The HOOD Reference Manual, Release 4. Ref-
erence HRM4-9/26/95, 1995. Available from http://www.hood.be
[9] P. J. Ashenden, P. A. Wilsey. Considerations on Object-Oriented Exten-
sions to VHDL. VHDL International Users’ Forum (Spring Conference),
Santa Clara, USA, 1997, pp. 109-118.
[10]W. Ecker. An Object-Oriented View of Structural VHDL Description.
VHDL International Users’ Forum (Spring Conference), Santa Clara,
USA, 1996, pp. 255-264.
[11] S. Swamy, A. Molin, B. Covnot. OO-VHDL. Object-Oriented Extensions
to VHDL. IEEE Computer, October 1995, pp. 18-26.
[12] J. Benzakki, B. Djafri. Object Oriented Extensions to VHDL—The LaMI
proposal . CHDL’97, Toledo, Spain, 1997, pp. 334-347.
-
8/19/2019 Jise98 Unified Approach
35/245
35
[13] G. Schumacher, W. Nebel. Inheritance Concept for Signals in Object-Ori-
ented Extensions to VHDL. Proceedings of the Euro-DAC’95 with Euro-
VHDL’95, IEEE Computer Society Press, 1995, pp. 428-435.
[14] D. Cabanis, S. Medhat, N. Weavers. Classification-Orientation for VHDL:
A Specification. VHDL International Users’ Forum (Spring Conference),
Santa Clara, USA, 1996, pp. 265-274.
[15] R. Zippelius, K. D. Müller-Glaser. An Object-oriented Extension of
VHDL. VHDL Forum for CAD in Europe (Spring Conference), 1992,
pp. 155-163.
[16] IEEE Standard VHDL Language Reference Manual . IEEE Std 1076-1993.
[17] M. Radetzki, W. Putzke-Röming, W. Nebel, S. Maginot, J.-M. Bergé, A.-
M. Tagant. VHDL language extensions to support abstraction and re-use.
Proc. 2nd Workshop on Libraries, Component Modelling, and Quality
Assurance. Toledo, Spain, 1997, pp. 47-62.
[18] S. Maginot, W. Nebel, W. Putzke-Röming, M. Radetzki. Final Objective
VHDL language definition. REQUEST Deliverable 2.1.A (public), 1997.Available on the WWW from URL http://eis.informatik.uni-oldenburg.de/
research/request.html
[19] W. Putzke-Röming, M. Radetzki, W. Nebel. A flexible message passing
mechanism for Objective VHDL. Submitted to DATE’98.
[20] J. Willis, S. Bailey, C. Swart. Shared Variable Language Change Specifi-
cation (PAR 1076), Version 5.7, December 1996.
[21] W. Putzke-Röming, M. Radetzki, W. Nebel. Modeling communication
with Objective VHDL. Submitted to Spring VIUF ’98.
-
8/19/2019 Jise98 Unified Approach
36/245
1
A Unified Approach to Object-Oriented VHDL1
Authors: Martin Radetzki, Wolfram Putzke-Röming, Wolfgang Nebel
Affiliation: OFFIS Research Institute
Address: Escherweg 2
26121 Oldenburg
Germany
e-mail: [email protected]
Abstract —Abstraction and reuse are the keys to deal with the increasing com-
plexity of electronic systems. We motivate the application of object-oriented
modeling as an approach to achieve more reuse and higher abstraction in hard-
ware design. This requires an object-oriented hardware description language,
preferably an extension to VHDL. Several variants of such OO-VHDL are being
discussed controversially. We present our unified approach, Objective VHDL,
adding object-oriented features to the VHDL design entity as well as to the type
system to provide a maximum of modeling power.
Keywords —hardware, design, modeling, system level, reuse, object-oriented,
VHDL
1. This work has been funded as part of the OMI-ESPRIT project
REQUEST under contract 20616. This article is based on a paper [1]
published and copyrighted by the 4th Asia-Pacific Conference on
Hardware Description Languages (APCHDL’97).
-
8/19/2019 Jise98 Unified Approach
37/245
2
1 Introduction
Design reuse and system level design are being among the topics of major
concern within the electronic design community. Advanced techniques need to
be developed in order to keep design productivity in pace with the exponential
growth observed in the complexity of electronic systems as well as in the inte-
gration density offered by submicron technologies. Maintenance is another is-
sue particularly in the life-cycle of long-living products, for instance
telecommunication equipment. Finally, quality and testability are crucial for
safety-critical systems, for instance avionics equipment.
Within the REQUEST (REuse and QUality ESTimation) project of the Eu-
ropean Community [2], several large telecom companies, international EDA
tool vendors, system houses, and research organizations are addressing these is-
sues developing a consistent methodology and tools based on the Very High
Speed Integrated Circuits Hardware Description Language (VHDL). Among
other tasks, the REQUEST workpackages include specification and implemen-
tation of object-oriented (OO) extensions to VHDL, expecting to transfer the
benefits of object-orientation from software engineering to an exploitation in
hardware design.
In this article, we first motivate the application of object-oriented modeling
techniques to hardware. We present the requirements to an advanced design
methodology in the next section. In the third section, we give an overview of the
object-oriented modeling paradigm and show that it meets the requirements.
The second half of the article is devoted to the question how to design an
object-oriented hardware description language in order to facilitate simulation
and synthesis of object-oriented models. We start with general considerations
constraining the design of an object-oriented hardware description language in
the fourth section, leading to the approach of object-oriented extensions to VH-
DL. The state of the art in related work is reviewed in section five. To overcome
-
8/19/2019 Jise98 Unified Approach
38/245
3
the observed split into two contrasting paradigms, we finally present the unified
approach of the Objective VHDL language developed within REQUEST.
2 Problem Description
Hardware becomes increasingly complex. By the end of the century, chips
comprising 100 millions of transistors are likely to be manufacturable, and there
is no doubt that designs will utilize this potential. It will be possible to imple-
ment more sophisticated functionality in hardware and to integrate complete
systems on a single chip instead of a printed circuit board.
Design methodologies must enable designers to cope with that complexity
by increasing design productivity. As well, there are great demands on the de-
sign quality in terms of efficiency (power, speed, and area trade-off), testability,
and not least correctness. Systems must be sufficiently validated before fabrica-
tion to avoid design iterations and to meet the market window.
We have identified two major starting points to tackle these issues. The first
one is design of hardware—eventually together with software—at a high level
of abstraction. The second one (no ranking implied) is reuse.
2.1 Abstract Specification of Hardware
Since the beginning of integrated circuit design, abstraction has been a
valuable means to deal with complexity. Gate level design provided an abstrac-
tion from the electrical behavior of transistors, allowing designers to focus on
the logic functionality and to rely on guaranteed properties of the basic cells.
Currently, design at register transfer level is commonplace, and people get in-
terested in behavioral synthesis to abstract from resource allocation and sched-
uling. The next step towards system level design should
• provide components with more comprehensible abstract interfaces,
• introduce abstract communication mechanisms between components,
and
• support data abstraction.
-
8/19/2019 Jise98 Unified Approach
39/245
4
This will ease the assembly of components to form a system and help to account
for the increasingly complex structure of data that is to be processed.
Starting from a rather abstract, possibly incomplete or graphical specifica-
tion, the refinement towards an implementation should be supported. This
means designers should be enabled to add details incrementally until there is
enough information to apply automatic synthesis using advanced techniques.
2.2 Hardware / Software Co-Design
Hardware / Software Co-Design has been outside the scope of our research.
However, since future systems will have an increasing share of embedded soft-
ware running on standard processor cores or application specific instruction pro-
cessors, the methodology used for initial specification should be applicable to
both, hardware and software, in order to allow a co-specification. After parti-
tioning—be it manually or with tool support—the hardware design methodolo-
gy based on object-oriented VHDL can be applied to the hardware part.
Standard object-oriented programming languages such as Ada95 or C++ can be
used to implement the software part. Automatic generation of code in the chosentarget language from OOD specifications and re-engineering support to generate
OOD diagrams from the target languages could facilitate an easy migration from
hardware to software and vice versa.
2.3 Reuse
Reuse helps to increase designers’ productivity allowing them to focus on
the real innovations. Costs for the re-invention of things can be avoided, and the
time saved can be used to achieve better testing or shorter time-to-market. Intel-
lectual property to be reused includes models of
• components in all their varieties,
• communication mechanisms, ranging from high level protocols like TCP/
IP to simple handshaking,
-
8/19/2019 Jise98 Unified Approach
40/245
5
• data structures and algorithms, for instance the sophisticated ones used
in ATM switches, and not least
• test environments since the effort for validation tends to increase even
faster than the complexity of tested designs.
We emphasize that reuse is not for free. Making things reusable (i.e. producing
reusable models) requires some overhead as compared to tailoring specific so-
lutions. Reusing things (i.e. consuming reusable models) means to select, under-
stand, possibly adapt and debug, integrate and finally test them. The costs
incurred depend on the kind of reuse and the degree of reusability, which will
be addressed in the next two sections. Thus, a methodology supporting proper
reuse is an important economic factor. It can help us to improve the quality of
our hardware designs through secure reuse of proven parts.
2.4 Kinds of Reuse
Of course, reuse is not a new invention. An intuitive approach to reuse is to
take an existing piece of source code or a schematic and adapt it to a new pur-
pose. Such modifying reuse is called white-box reuse. It requires to understandthe internals of the reused item, and this is a frequent source of errors. Due to
the debugging necessary in most cases of white-box reuse, its consumer costs
can approach those of a new design.
Unmodified black-box reuse, on the other hand, is relatively cheap for the
consumer, but it requires a higher initial effort to produce an item that is likely
to be reused. Some knowledge and planning about future applications is desir-
able to build generalized components. The use of parameters helps to makecomponents more flexible, but it also makes testing harder. On the other hand,
once the functionality of such black box is validated, and it is not touched, one
can definitely rely on it in future uses.
To provide a greater flexibility, one can apply grey-box reuse, allowing
controlled modifications. For instance, there may be mechanisms that allow lim-
ited modifications to the original source code without touching it directly. There
-
8/19/2019 Jise98 Unified Approach
41/245
6
should be application rules, validation procedures, or verification methods to
ensure proper functioning.
2.5 Requirements for Reusability
The question "What makes a model reusable?" has already been touched on
in the preceding text. In the following, we transfer a classification done in the
software domain [3] into hardware terms:
• Flexibility —A reusable model must be independent from a special appli-
cation. A methodology should allow the addition of functionality, possi-
bly a modification.
• Portability —The model should be independent from implementation
technology. This favors for instance soft macros over hard macros.
• Understandability —Moderate complexity, good documentation, and a
comprehensible (ideally self-descriptive) interface support reuse.
• Confidence —A reusable model should be reliable and error tolerant; its
proper function should be validated or formally verified. It should ideally
not be touched when reusing it. Note that there are trade-offs between these factors; e.g. white-box reuse pro-
vides most flexibility, but it decreases confidence. Another example is that we
have more confidence in cross-talk resistance using hard macros, but our design
will not be portable to new technological platforms.
As a positive point, there is an interrelation of abstractness and reusability:
An abstract model is more likely to be flexible, portable, and human-under-
standable than a model which provides very detailed information. Vice versa,making a model reusable means generalizing, which is a process of abstraction.
Hence, it is not surprising that the units of abstraction identified in 2.1 are as
well candidates for reuse.
-
8/19/2019 Jise98 Unified Approach
42/245
7
2.6 Points Related to Reuse
Following [4], good reuse metrics do not count as reuse maintenance or the
sharing of models between designers in the same project and within one design
team. The first would distort quantitative measurements, and the latter is consid-
ered as good design practice. Anyway, the means to enhance reuse among the
borders of projects or design teams will as well be helpful to achieve sharing of
models within these borders, and we can be optimistic to obtain a maintainable
system when (re-)using subsystems which are flexible, portable, understand-
able, and reliable. Having in mind the typically long life cycle of products in the
telecommunication and avionics domain, we will have to consider maintenance
when choosing a methodology.
3 Benefits from Object-Orientation
Following Booch [5], every object-oriented methodology must provide a
minimum of features, which include (in our terminology): a class concept , mes-
sage passing , inheritance of classes, and polymorphism. These are applied dur-
ing the different main development phases: analysis (OOA), design (OOD), and
programming (OOP). In the following sections, we will present an outline of
these techniques and discuss their impact on our aims, abstraction and reuse,
starting with the overall design process and then moving to the four basic mech-
anisms.
3.1 Object-Oriented Design Process
According to Rumbaugh [6], object-oriented modeling can be divided intothree main phases:
• Object-Oriented Analysis (OOA)—Requirement analysis, extraction of
objects / classes from an informal problem description.
• Object-Oriented Design (OOD)—Identification of interrelationships
between objects / classes such as composition and inheritance; represen-
tation in a graphical notation. Refinement for the description of function-
-
8/19/2019 Jise98 Unified Approach
43/245
8
ality, data and control flow. Descriptive power due to inclusion of data
flow diagrams, hierarchical state machines, message (event timing) dia-
grams.
• Object-Oriented Programming (OOP)—Implementation of the designed
system in a programming language that supports the object-oriented
mechanisms.
With OOD diagrams one can specify a system graphically. This specification
may be informal and incomplete in the beginning; it can be refined in iteration
cycles until a considerable level of detail is achieved. Object-oriented design has
the potential to result in a complete specification and can be applied to mixed
hardware-software systems [7]. OOD diagrams include concepts well-known to
hardware designers, in particular data flow diagrams, hierarchical finite state
machines, and message interaction diagrams similar to timing charts. Hence an
OOD model should be well comprehensible once its notation is known, and it
can contribute a significant part to documentation.
Object-oriented design can and should be supported by tools. These allow
graphical input, provide consistency checks of the models, and translate graph-
ical specifications into the implementation language. In case of design itera-
tions, they will update the source code according to the changes in the
specification.
In the implementation phase, additional details can be added in a textual
form. The textual description can be compiled and executed. It is possible to re-
turn to the design phase in order to maintain a design or add features for an up-
date. As well, one can skip to implementation in order to produce a prototype at
an early stage of the design and return to the design phase later to complete the
system. Providing such flexibility, object-oriented modeling can also deal with
the evolution of systems over a long period of time.
-
8/19/2019 Jise98 Unified Approach
44/245
9
3.2 Classes
The class is the basic object-oriented concept upon which the other build. It
comprises the definition of data fields (attributes) and functionality (methods).
From a class, objects can be created dynamically or by static instantiation. Each
of these objects has its own local state—storage for values of the data fields.
Since no access other than by the invocation of methods is provided to modify
the local state, the designer of a class can ensure the consistency of the local state
by construction. In other words, objects are encapsulated from their environ-
ment by their method interface.
For (re-)using a class, it is sufficient to understand its interface. Thus,
through the hiding of the internals, its degree of abstraction and its understand-
ability are significantly improved. Moreover, by the convention that, once a
class is designed, implemented, and debugged, its source code should not be
touched, a class provides a very safe way of reuse.
3.3 Message Passing
Objects communicate with each other requesting the execution of methods
by passing messages. A message carries the information which method to in-
voke and the input and output data of the method. On the conceptual level many
object-oriented methods (e.g. Booch [5], OMT [6]) do not deal with details
(whereas HOOD [8] does), e.g.
• whether the sender is blocked during method execution by the receiver,
• how a receiver behaves in case several messages arrive from concur-
rently sending objects at the same time or interleaved with the execution
of another method, or
• with whose resources (thread of computation, control flow, task, process)
a method is executed.
The common sense is only that messages should not be lost. Thus, describing
communication through message passing is a significant abstraction at the de-
sign stage. However, implementation languages mostly constrain the message
-
8/19/2019 Jise98 Unified Approach
45/245
10
passing:
• In sequential OOP languages (e.g. C++) message passing and subpro-
gram call are the same. The sender of a message is blocked while the
requested method is executed with the sender’s resources.
• Some concurrent OOP languages (e.g. Java) add synchronization (e.g.
monitor concept) to the subprogram call mechanism.
• Other concurrent OOP languages (e.g. ALPS) let objects process incom-
ing messages by their own thread of control (active object with "body")
and queue messages in case an object is busy.
3.4 Inheritance
Given a class, inheritance allows to derive subclasses with more specific
properties (specialization). A subclass (descendant) inherits all the data fields
and methods from its superclass (ancestor) and can be defined to have additional
ones. Hence inheritance allows to add functionality without having to touch the
source code of the reused superclass. Another commonplace feature is the pos-
sibility to redefine inherited methods and attributes. This controlled modifica-tion again leaves the original code untouched.
Another question is how the reused superclass will behave as a component
of the new derived class. If a designer of a derived class makes only additions,
no modifications, he can be confident that the inherited methods will retain their
proper function with the inherited attributes. He is responsible only for what he
adds.
To study the effect of redefinitions on the inherited code in the subclass, weneed to know more about redefinition semantics. In case the old version of a re-
defined data field or method is removed and replaced by the new version, the
unchanged inherited parts can be significantly distorted. For instance, a rede-
fined method can implement a completely different functionality, and an at-
tribute redefined with a new type may falsify the invocation of operations with
that attribute in the inherited code. Hence, in most cases redefinition will be in-
-
8/19/2019 Jise98 Unified Approach
46/245
11
terpreted as hiding rather than replacing, so that the inherited parts can continue
to work with the hidden old version, and only the added parts will use the rede-
fined new version.
In summary, provided there are no replacing modifications, inheritance al-
lows to reuse a superclass as a black box. Superclasses can be designed for reuse
as generalized, abstract units. It is not necessary to foresee and implement de-
tails about functionality possibly required by some future application. So the
complexity of a reusable class is reduced. Functionality can be added and mod-
ified in a controlled fashion during reuse, specializing classes for new purposes.
This makes class inheritance a model for flexible IP reuse.
3.5 Polymorphism
Polymorphism is a means to uniformly handle objects of classes related by
inheritance. It allows to send a message to an object without having to know at
compile time about the exact class of the receiver. Hence, the binding of mes-
sages (requests for method invocation) to an implementation of a method is to
take place at run time (dynamic binding).Some languages, e.g. Smalltalk, permit to send any message to any object,
raising a run time exception in case a receiver object does not have the requested
method implemented. However, many typed OOP languages (Ada95, Java)
have a mechanism to prevent such behavior— inclusion polymorphism: The
class of the addressed object is restricted by declaration to a given class, C , and
its descendants, and only the methods of the most general class, C , are allowed
to be requested from the object. Since the methods of C are available—either in-herited or redefined—in every transitively derived class, dynamic binding
works without run-time errors. It only has to dispatch a message to the imple-
mentation of the method in the class of the addressed object.
By its weakened typing, polymorphism provides a program with a greater
flexibility regarding the extension of its capabilities. An existing well-tested
program will be able to deal with new derived classes and call their methods
-
8/19/2019 Jise98 Unified Approach
47/245
12
without having to be modified. Through the uniform handling of related classes,
a program becomes more readable.
Reuse combining inheritance with polymorphism is to be classified as grey-
box because the injection of an object of a new derived class into an existing sys-
tem can change its behavior. However, inclusion polymorphism can provide a
maximum of security to method invocation by static checks.
4 Language Design Considerations
In the previous section we have motivated the usefulness of object-orienta-
tion to increase abstraction and reuse in hardware modeling. It became obvious
that the required modeling power is av