Object-Oriented Modeling

OBJECT-ORIENTED MODELING
OBJECT-ORIENTED
MODELING
Edited by
Jean-Michel Berge
CNET. France
OzLevia
Cadence Design Systems. U.S.A.
and
Jacques Rouillard
ESIM. France
..
KLUWER ACADEMIC PUBLISHERS
BOSTON / DORDRECHT / LONDON
A C.I.P. Catalogue record for this book is available from the Library of Congress.
ISBN-13: 978-1-4612-8581-6 e-ISBN-13: 978-1-4613-1349-6

DOl: 10.1007/978-1-4613-1349-6
Published by Kluwer Academic Publishers,

P.O. Box 17, 3300 AA Dordrecht, The Netherlands.
Kluwer Academic Publishers incorporates

the publishing programmes of
D. Reidel, Martinus Nijhoff, Dr W. Junk and M1P Press.
Sold and distributed in the U.S.A. and Canada

by Kluwer Academic Publishers,
101 Philip Drive, Norwell, MA 02061, U.S.A.
In all other countries, sold and distributed

by Kluwer Academic Publishers Group,
P.O. Box 322, 3300 AH Dordrecht, The Netherlands.
Printed on acid-free paper
All Rights Reserved

© 1996 Kluwer Academic Publishers
Softcover reprint of the hardcover 1st edition 1996
No part of the material protected by this copyright notice may be reproduced or
utilized in any form or by any means, electronic or mechanical,
including photocopying, recording or by any information storage and
retrieval system, without written permission from the copyright owner.
SERIES PRESENTATION
Current Issues in Electronic Modeling is a series of volumes publishing high quality,
peer-reviewed papers dealing with modeling issues in the electronic domain. The
objective is to establish a unique communication channel between academia and industry
which will serve the growing needs in the field of modeling.
PUBLISHED VOLUMES:
• Volume 1: Model Generation in Electronic Modeling
Contents: 1. A Flexible Generator of Component Models. 2. What Makes an ASIC
Library Sign-Off? 3. A Case History in Building Vital-Compliant Models. 4. Modeling
Multiple Driver Net Delay in Simulation. 5. DELPHI: the Development of Librairies of
Physical Models of Electronic Components for Integrated Design Environment.
6. VHDL Floating Point Operations. 7. Symbolic Model Checking with Past and Future
Temporal Modalities: Fundamentals and Algorithms. 8. KRYPTON: Portable, Non-
Reversible Encryption for VHDL. Index.
168 pp. ISBN 0-7923-9568-9
• Volume 2: Modeling in Analog Design

Contents: 1. VHDL-A Design Objectives and Rationale. 2. Modeling in VHDL-A:
Devices, Networks and Systems. 3. Analog Modeling using MHDL. 4. Modeling and
Simulation of Electrical and Thermal Interaction. 5. Modeling of Power MOSFET.
Index.
176 pp. ISBN 0-7923-9569-7
• Volume 3: High-Level System Modeling:

Specification Languages
Contents: 1. Specification-Modeling Methodologies for Reactive-System Design.
2. Survey on Languages for Object Oriented Hardware Design Methodologies.
3. VSPEC: A Declarative Requirements Specification Language for VHDL.
4. Communication Protocols Implemented in Hardware: VHDL Generation from
Estelle. 5. An Algorithm for the Translation of SDL into Synthesizable VHDL. 6. From
LOTOS to VHDL. 7. Using An X-Machine to Model a Video Cassette Recorder. Index.
176 pp. ISBN 0-7923-9632-4
V
VI Object-Oriented Modeling
• Volume 4: High-Level System Modeling:

Specification and Design Methodologies
Contents: 1. A System Specification Model and Method. 2. ADEPT: A Unified
Environment for End-to-End System Design. 3. The Design Cube: A Model for VHDL
Designflow Representation and its Application. 4. A Novel Approach to Guiding
Incremental Specification. 5. An Expert Assistant for Hardware Systems Specification.
6. Integrating Non-Functional Aspects into LOTOS. Index.
192 pp. ISBN 0-7923-9660-x
• Volume 5: Hardware Component Modeling

Contents: 1. The History of VITAL: VHDL ASIC Library Update. 2. Issues in
Efficient Modeling and Acceleration of VITAL Models. 3. Standards for
Interoperability and Portability. 4. Abstract Data Types and the Digital System
Description and Simulation Environments. 5. Modeling highly flexible and self-
generating parameterizable components in VHDL. 6. MELODY: an Efficient Layout-
Based Model Generator. 7. Quality Measures & Analysis: a way to improve VHDL
models. 8. Modem Concepts of Quality and Their Relationship to Design Reuse and
Model Libraries. Index.
150 pp. ISBN 0-7923-9686-3
• Volume 6: Meta-Modeling: Performance and

Information Modeling
Contents: 1. Integrating Operational Specification with Performance Modeling. 2. A
System-Level Performance Model and Method. 3. A View of Information Modelling.
4. A Methodology for the Specification of Transformations between Information
Models. 5. Modeling Design Data and Design Processes in the PLA YOUT CAD
Framework. Index.
207 pp. ISBN 0-7923-9687-1
We hope you will enjoy reading this series. We welcome your suggestions and look
forward to having you as a contributor.
The Series Editors

Jean-Michel Berge, France Telecom-CNET, Email: berge@cns.cnet.fr
Oz Levia, Cadence, Email: ozl@aol.com
Jacques Rouillard, ESIM, Email: rouillard@acm.org
Series & Volume Presentation VII
EDITORS
Series Editors
Jean-Michel Berge - France Telecom - CNET

Oz Levia - Cadence
Jacques Rouillard - ESIM
Principal Advisor to the Editors
Jim Armstrong - Virginia Tech
Advisory Board
Raul Camposano - Synopsys Inc.

Hilary Kahn - University 0/ Manchester
Sabine Maerz-Roessel- Siemens AG
Zain Navabi - University o/Tehran
Wolfgang Nebel- University o/Oldenburg
Alec Stanculescu - Fintronic Inc.
Alain Vachoux - Swiss Federal Institute o/Technology
Ron Waxman - University o/Virginia
Editorial Board
Przemyslaw Bakowski - IRESTE Serge Maginot - Leda SA.
Dave Barton - Intermetrics Inc. Wolfgang Mueller - CADLAB
Bill Billowich - VHDL Technology Group Adam Pawlak - ARTEMISlIMAG
Mark Brown - Compass Bora Prazic - Alcatel
Jean-Paul Calvez - IRESTE Paul Scheidt - Synopsys Inc.
Steve Carlson - Escalade Jean-Pierre Schoellkopf - SGS-Thomson
Simon Curry - Cadence Steve Schultz - Texas Instruments
Tedd Corman - EPS Ken Scott - Synopsys Inc.
Doug Dunlop - Cadence Venkat Venkataraman - IBM
Alain Fonkoua - ESIM Alex Zamfirescu - Intergraph Electronics
Andreas Hohl - Synopsys Inc. Roger Zinsner - Speed SA
Michael Hohenbichler - CEC
VOLUME PRESENTATION
VOLUME 7: OBJECT-ORIENTED MODELING

Object oriented techniques and languages have been proven to significantly increase
engineering efficiency in software development. Many benefits are expected from their
introduction into electronic modeling. Among them are better support of model
reusability and flexibility, a more efficient system modeling, and more possibilities in
design space exploration and prototyping. Therefore, we decided to dedicate a full
ClEM issue to object oriented methods, formalisms and hardware description language
extensions.
In the first chapter, "Object orientation: modeling and design paradigms for the year
2000?", the author studies what has happened in software in recent years to predict a
breakthrough in hardware by the end of this century. Object-Oriented techniques will be
responsible for this breakthrough. Additionally, this chapter contains interesting and
complete references about Object-Oriented modeling.
The second chapter, "Object-Oriented Modeling of Hardware for Embedded Systems",
details the potential advantages of Object-Oriented techniques when applied to
hardware design. It contains many examples using C++ for hardware modeling.
"Object-Oriented and Real Time Techniques:Combined Use ofOMT, SDL and MSC" is
the third chapter. It shows how to use Object-Oriented techniques to address real-time
issues. The presented approach involves OMT (an object-oriented analysis and design
method defined in 1991 by a General Electric team led by J. Rumbaugh ), SDL and
MSC. SDL, Specification and Description Language, and MSC, Message Sequence
Chart, are both ITU-T recommendations widespread in the telecom sector, with more
than 20,000 users. The target here is to analyse, model, validate and design (in software)
a real-time system.
The fourth chapter, "Integrated System Design with an Object-Oriented Methodology",
extends the previous approach to also encompass the hardware aspects of system
design. The INSYDE methodology describes how to use a combination of OMT, SDL
(for software) and VHDL (for hardware) to offer a co-simulation platform.
IX
x Object-Oriented Modeling
The last three chapters focus on the different ways to introduce Object-Oriented
techniques into VHDL. The fifth and sixth chapters propose Object-Oriented
extensions to the languages while the seventh one presents an Object-Oriented approach
to the design.
In "Object Orientation and Structural Design", the fifth chapter, the structural VHDL
description capabilities are detailed and compared with Object-Oriented properties. In
order to allow incremental design by inheritance in VHDL, a language extension is
proposed for VHDL entities, architectures and component declarations.
The sixth chapter, "Abstract Hardware Modelling using an Object-Oriented Language
Extension to VHDL", addresses the problem of reusability of hardware. After discussing
the best gain domains of reuse, the OMT method is briefly presented and Object-
Oriented extensions to VHDL types are proposed to allow a good mapping between the
OMT concepts and this implementation language.
Finally, the seventh chapter entitled "Object-Oriented Generation of VHDL Models",
defines an object-oriented approach to generating a library of VHDL synthesizable
models. The object-oriented analysis and implementation of the VHDL model
generation system is described. An example of the VHDL code generated for a 4-bit
ripple carry adder is included.
Jean-Michel Berge, Co-Editor

CONTENTS
SERIES PRESENTATION v
EDITORS VB
VOLUME PRESENTATION IX
CONTENTS XI
CONTRIBUTORS xvn
1. OBJECT ORIENTATION: MODELING AND DESIGN PARADIGMS
FOR THE YEAR 2000? 1
by Wolfgang Ecker, Michael Mrva
1.1. Motivation 1
1.2. Software design 3

1.2.1. Assembler and Higher Programming Languages 3
1.2.2. Further Developments 3
1.3. Hardware design 5

1.4. The Future of Hardware Design 7
1.5. The Influence of Object Orientation on the Design Process 8
1.6. Summary and Outlook 10
XI
XII Object-Oriented Modeling
2. OBJECT-ORIENTED MODELING OF HARDWARE FOR

EMBEDDED SYSTEMS 15
by Sanjaya Kumar, James H Aylor, Barry W Johnson, Wm. A. Wulf
2.1. Introduction 16
2.2. Data Types 17
2.3. Modeling Hardware Components as Classes 17
2.4. Deriving Specialized Components 20
2.5. Data Decomposition 21
2.5.1. Overview of the Technique 22
2.5.2. Identifying Reusable Components and Managing Change 23
2.6. Arithmetic Logic Unit Example 24

2.6.1. Data Decomposition of the ALU 24
2.6.2. Inheritance Hierarchies 30
2.6.3. Discussion 31
2.7. Type Genericity 32
2.S. Related Work 33
2.9. Conclusions 34
3. OBJECT-ORIENTED AND REAL-TIME TECHNIQUES:

COMBINED USE OF OMT, SDL AND MSC 39
by Philippe Leblanc
3.1.1. Issues Related to Real-Time System Engineering 40
3.1.2. OMT for Real-Time, Strengths and Weaknesses 40
3.1.3. Use of Formalisms Dedicated to Real-Time:
SDLandMSC 40
3.2. The OORT engineering process 41
3.2.1. Typical System Engineering Activities 41
3.2.2. Requirements Analysis 41
3.2.3. Architectural Design 42
3.2.4. Detailed Design 42
3.2.5. Test Design 42
3.2.6. Implementation 42
3.2.7. Testing 43
3.2.8. Iterative Process Model 43
Contents XIII
3.3. Overview of the OMT, MSC and SDL notations 44

3.3.1. The OMT Notation 44
3.3.2. The MSC Notation 45
3.3.3. The SDL Notation 46
3.4. Introduction to a combined use ofOMT, MSC and SDL 48
3.4.1. Positioning of the Three Notations in the OORT Process 48
3.4.2. Requirement Analysis with OMT and MSC 49
3.4.3. Architectural Design with SDL and Test Design
with MSC 50
3.4.4. Detailed design with SDL and OMT 50
3.4.5. Implementation Activity 51
3.4.6. Testing Activity 52
3.5. OORT and the co-design 53
3.6. Conclusions 53
4. INTEGRATED SYSTEM DESIGN WITH AN

OBJECT-ORIENTED METHODOLOGY 57
by E. P. Mariatos, A. N Birbas, M K. Birbas, 1. Karathanasis, M Jadoul,
K. Verschaeve, J-L. Roux, D. Sinclair
4.2. Methodology Outline 59
4.2.1. The Basic Elements of the Methodology 59
4.2.2. The NotationslLanguages 60
4.3. Analysis using OMT 61
4.4. Creating a System Model with OMT* 63
4.5. Paths to Implementation: SDL and VHDL 65
4.5.1. SDL for Software 65
4.5.2. VHDL for Hardware 67
4.6. The INSYDE toolset 68
4.6.1. Tools for Editing 68
4.6.2. Tools for Translation 69
4.6.3. Cosimulation 69
4.7. Case Studies 69
4.7.1. An Image-Reconstruction Chip-Set 70
4.7.2. A Video-on-Demand System 71
4.8. Conclusion 72
XIV Object-Oriented Modeling
5. OBJECT ORIENTATION AND STRUCTURAL DESIGN 77

By Wolfgang Ecker, Viktor Preis, Claus Schneider
5.2. Outline 78
5.3. VHDL Structural Descriptions 79
5.4. Principles of Object Orientation 79
5.5. Structure and Object Orientation 80

5.6. An Inheritance Concept for Structural VHDL 83
5.6.1. Motivation 83
5.6.2. Inheritance Concept 83
5.7. Application Examples 85

5.7.1. Flexible uP-Interface 85
5.7.2. Incremental TimingIFunction Implementation 90
5.7.3. Method Activation by Abstract Message Passing 94
5.8. Genericity 96
5.8.1. Instance 96
5.8.2. Polymorphism 96
5.8.3. Inheritance 97
5.8.4. Generics 97
5.9. Conclusion and Outlook 98
6. ABSTRACT HARDWARE MODELLING USING AN

OBJECT-ORIENTED LANGUAGE EXTENSION TO VHDL 101
by Guido Schumacher, Wolfgang Nebel

6.1.1. Traditional Approaches of Re-Use 102
6.1.2. Software Engineering 103
6.2. Modelling Problems 104
6.2.1. Initial Modelling Cost 104
6.2.2. Cost of Maintenance 105
6.2.3. Cost of Re-Use 105
6.2.4. Cost of Model Disposal 105
6.2.5. Levels of Complexity 106
6.2.6. Initial Specification 106
6.2.7. System Modelling 106
6.2.8. Subsystem Modelling 106
6.2.9. Cell Modelling 107
6.2.10. Best Gain Domains of Re-Use 107
Contents XV
6.3. Object-Oriented Techniques 107

6.3.l. Introduction 107
6.3.2. Objects in Hardware Design 108
6.4. Acceptance of New Design Techniques 110

6.5. Survey on the Object Modeling Technique from Rumbaugh 111
6.6. The Implementation Language 116
6.7. From Specification to Implementation 119
6.8. Parallelism in Hardware Systems 122
6.9. Specification and Implementation of Communication
Mechanisms 125
6.10. Conclusion 129
7. OBJECT-ORIENTED GENERATION OF VHDL MODELS 133

by George S. Powley Jr., Joanne E. DeGroat

7.2. Object-Oriented Paradigm 134
7.2.l. Object-Oriented Analysis 134
7.2.2. Object-Oriented Implementation 134
7.3. Analysis of VHDL Model Generation System 135

7.3.l. Requirements 135
7.3.2. Object Model 135
7.3.3. Digital Component Class 140
7.4. VHDL Model Generation System 141

7.4.l. Attribute Database 141
7.4.2. Model Generation 142
7.5. Example 143

7.6. Conclusions 145
INDEX 147
CONTRIBUTORS
James H. Aylor Barry W. Johnson

University of Virginia, University of Virginia,
Department of Electrical Engineering, Department of Electrical Engineering
Charlottesville, VA 22903, USA. Charlottesville, VA 22903, USA.
Alexios N. Birbas Ioannis Karathanasis

Applied Electronics Laboratory, R&D Department,
Department of Electrical Engineering, INTRACOM S.A.,
University of Patras, Patras, Rio, 19002 Peania, Greece.
Greece.
Sanjaya Kumar,
Michael K. Birbas Honeywell Technology Center,
Electronic Systems Group, 3660 Technology Drive,
Synergy Systems S.A., Minneapolis, Minnesota, USA.
Patras, 26441, Greece.
Philippe Leblanc
Joanne E. DeGroat VERILOG, 150 rue N. Vauquelin,
Department of Electrical Engineering, BP 1310 F-31106,
The Ohio State University, 205 Toulouse Cedex, France.
Dreese Lab, 2015 Neil Avenue,
Columbus, OH 43210-1272, USA. Evagelinos P. Mariatos
Electronic Systems Division,
Wolfgang Ecker Synergy Systems S.A.,
Corporate Research and Patras, 26441, Greece.
Development, ZFE T SE 5,
Siemens AG, MOOchen, Germany. Michael Mrva
Corporate Research and
Marc Jadoul Development, ZFE T SE 5,
ALCATEL Bell Telephone, Siemens AG, MOOchen, Germany.
System Design Methodologies,
Francis Wellenstein 1,
B-2018 Antwerpen, Belgium. ••.1•••
XVII
XVIII Object-Oriented Modeling
Wolfgang Nebel Claus Schneider

Department of Computer Science, Corporate Research and
Carl von Ossietzky University, Development, ZFE T SE 5,
Oldenburg, Germany. Siemens AG, Miinchen, Germany.
George S. Powley Jr. Guido Schumacher

Department of Electrical Engineering, Department of Computer Science,
The Ohio State University, 205 Carl von Ossietzky University,
Dreese Lab, 2015 Neil Avenue, Oldenburg, Germany.
Columbus, OH 43210-1272, USA.
D. Sinclair
Viktor Preis Dublin City University,
Corporate Research and School of Computer Applications,
Development, ZFE T SE 5, Grasnevin Dublin 9, Ireland.
Siemens AG, Miinchen, Germany.
K. Verschaeve
Jean-Luc Roux VUB (Vrije Universiteit Brussel)
VERILOG SA, 150 rue N. Vauquelin, Dept. Informatica, TW,
BP 1310 F-31106 Pleinlaan 2, 1050 Brussels, Belgium.
Toulouse Cedex, France.
Wm.A. Wulf
University of Virginia,
Department of Computer Science,
Charlottesville, VA 22903, USA.
1
OBJECT ORIENTATION: MODELING
AND DESIGN PARADIGMS FOR THE
YEAR2000?
Wolfgang Ecker, Michael Mrva
Corporate Research and Development, ZFE T SE 5, Siemens AG, Milnchen, Germany
ABSTRACT
Taking as its basis the comparison between the development of hardware and software
design technology, this chapter answers the question as to the next quantum leap in
hardware development programatically with "object orientation ".
1.1. MOTIVATION
For decades, the complexity of digital components has been increasing by about a factor
of four every three years. This increase, observed by Moore [1] and postulated as a
condition for the future, still applies today, and there is no reason for assuming it will
not apply in the years to come.
Thus, mass production of the 16-Mb memory has started, the 64-Mb memory chip will
shortly be ready for production, and we already have the first laboratory samples of
256-Mb chips. Today, microprocessors contain something like 1M gates (= 4M
transistors), and processors with 4M gates are expected soon.
From the point of view of design methodology, ASICs are of greater interest. The
number produced is well below that of memory units or processors, but the total
development time spent on the latter is below that spent on all the ASICs produced
throughout the world.
2 CHAPTER 1
ASICs currently being developed have a maximum complexity of about 250K gates and
are about three years behind the complexity of processors [2]. This means that ASICs
with a complexity of 1M gates can be expected in the year 2000.
The introduction of new methods, such as the Register Transfer Synthesis, has made it
possible to manage greater complexities. Nevertheless, it has not increased the
productivity of the individual ASIC developer to a sufficiently high degree. For this
reason, it has only been possible to carry out the necessary design work by increasing
the size of the team entrusted with the task of developing a component.
Nowadays, however, this is becoming increasingly difficult. The reason is not so much
the high cost of wages found in all the so-called industrialized nations, as the
communication overheads. These increase disproportionately with the number of team
members, and thereby limit the size of a team to a maximum of ten to fifteen
developers.
What, then, will be the demands placed on a developer in terms of productivity in the
year 2000?
Currently, the average productivity of a developer over the total development time is
taken to be 12.5 - 25 K gates. Assuming, then, an average ASIC size of 50 - 120 K
gates, it would take teams of 2 - 10 members to develop a component. With the same
productivity, it will require between forty and eighty developers to develop 1M ASICs
in the year 2000 I .
However, the maximum manageable number of developers in a team is taken to be from
ten to fifteen. This means that their productivity will have to rise to 70 - 100 K gates, in
other words by a factor of four.
The central question for design centers and manufacturers of CAD tools is simply this:
What methods and design technologies, and therefore what design tools, could be used
to achieve this end?
To answer this question, we shall first of all analyze the development of software
technology, which has to meet similarly dramatic requirements in terms of complexity
and productivity2. We shall then work out the milestones in hardware design.
By comparing both technologies, and in particular by comparing programming languages
with hardware description languages, we shall then be able to make a prediction about
the next quantum leap in hardware design.
I These figures are taken from [3]. They also agree, however, with the figures quoted by firms such as
Siemens and Philips.
2 Another reason why it is useful to align hardware design technology with software design technology is
that hardware design is nowadays based on hardware description languages that are closely related to
programming languages.
Object Orientation: Modeling and Design Paradigms for the Year 2000? 3
1.2. SOFTWARE DESIGN
1.2.1. Assembler and Higher Programming Languages

In spite of the dramatic developments in hardware technology, the "Von Neumann"
architecture is still the basic computer architecture [3] used today. Even the rapid
increase in clock frequencies, the addition of multistage cache memories, and the
processing of individual commands in several pipeline stages working in parallel should
not conceal the fact that the basic "fetch and execute" approach is still the one currently
in use. In contrast, however, software technology! has made great advances.
At the very beginning, computers were programmed in machine language, that is to say
with ones and zeros. The development of assemblers, however, made it at least possible
to enter commands and jump addresses symbolically, and to have them calculated and
carried out automatically.
The next quantum leap in software technology resulted from the introduction of so-
called higher programming languages. The key here was the invention and mastery of
translator technology. Even today, each translator still consists of "scarmer", "parser",
"symbol table management", and code generation. The latter is subdivided into mapping
in the machine-independent intermediate code, called P code, and the subsequent
generation of the assembler code for the target machine [4].
Typical examples of higher program languages are ALGOL[5], C[6], COBOL[7],
FORTRAN[8], and PASCAL[9], with each language being developed for a more or less
different application branch. C, for instance, was intended originally for developing
operating systems, COBOL for financial applications, and FORTRAN for numerical
calculations in the field of natural science. In addition, there was a multitude of other
problem-specific programming languages; but none achieved widespread use.
Programs produced with higher programming languages no longer had to be in the
language of the individual computers. They were thus computer-independent and could
run on different machines, provided there were suitable compiler and suitable operating-
system interfaces.
The programming languages had some or all of the following characteristics:
• Sequential processing of commands, as in the case of machine and assembler codes.
• Super character formation of commands (= sub-programs) and data structures (fields
and records), just as required.
• Modular and hierarchical composition.
1.2.2. Further Developments

After the introduction of higher programming languages, software technology developed
in widely differing directions:
I It should not be forgotten here, however, that it is only the advent of increasingly powerful computers
that has made the use of modem software technologies possible.
4 CHAPTER 1
• A start was made with the optimization and automatic parallel partitioning of
programs [10]. This did not, however, lead to any great success, particularly in the
case of automatic partitioning. There are problems with NP integrity and dynamic
data structures.
• Languages such as OCCAM [11] and ADA [12] were introduced for the
programming of parallel actions, with the development of OCCAM going hand in
hand with the invention of the transputer [28]. Ada grew out of a research and
development project of the American Department of Defense (DoD), being intended
to provide uniform programming of parallel tasks within the framework of DoD
jobs. Parallel programming, however, is by no means as widely used as sequential
programming.
• A particularly strong point of functional languages [13] is that they make it possible
to hand over functions as parameters. However, the strictly functional view has not
been widely accepted.
• To reduce the error rate in programs, special programming languages based on the
language of mathematical formulae were developed, along with proof systems for
verifying the correctness of these programs [14]. These are not yet suitable,
however, for widespread use, since proof systems normally work interactively, can
only be used at present by specialists, and fail with larger programs. Up to now,
they have only been used in developments where safety is an important factor, such
as in traffic control technology.
• For many years, artificial intelligence was the spearhead of the new software
technology [15]. Although, up to now the hopes placed in artificial intelligence have
not come to fruition, it has given rise to numerous languages, of which the most well
known is PROLOG [16].
• LISP [17] is likewise treated as an artificial intelligence language. Its special feature,
however, is its ability to handle lists with ease. For this reason, it is often used for
processing texts.
• So-called script languages are also discussed in the context of the production of
prototypes. Examples are the already somewhat older AWK [24] and its successors
PEARL [25] and TCLlTK [26], used for generating command interpreters and
graphical user interfaces quickly. What these languages have in common is that they
are all processed interpretively and have a wide range of very powerful in-built
functionalities. However, script languages are of little importance in the production
of software: they are extremely difficult to debug, have relatively long execution
times, and do not guarantee a satisfactory copyright of the program text, since they
are supplied in source format.
• Object orientation has been a well-known paradigm of software technology for some
time. The important principles include:
- data packaging and data hiding
- activation of methods based on messages
- inheritance
- polymorphism
- generic types.
The first example, Smalltalk [18], was developed before 1980' if one disregards Simula,
the "proto-language" of object orientation. Initially, the poor performance of the first
Smalltalk version stood in the way of its widespread adoption. Object orientation was
given a new fillip with the development of C++ [19]. For the first time, it was possible
to produce object-oriented program constructs with an acceptable performance.
Following this, work was carried out on the object-oriented enhancement of a number of
existing languages, such as Lisp [20] and COBOL [21]. Promising new developments
are the languages ADA95 [22] and Eiffel [23].
Looking back over the last few years in the development of software technology, it can
be said that, of all these approaches, the last quantum leap was achieved with the
introduction of object orientation.
However, it did not stop at the development or enhancement of programming languages;
there were also important further developments in design methodology and software
process technology based on object-oriented languages. The most important examples
are:
• Object-oriented design and analysis methods (OOA, OOD) [29-33, 73], which
replaced the structured methods of analysis from the time of higher programming
languages.
• Reuse [34], which is an effective way of increasing design productivity. Although it

can also be used with higher programming languages, it has gained in importance
through object orientation.
• Design patterns [35, 72], which make it possible to aggregate the type concept of
Class in object orientation to still larger units. This means that the designer is better
able to communicate and discuss his designs, and thus, ultimately, to control their
consequences, in a group-dynamic planning process.
• Architectures [36] that are application-specific combinations of classes and design

patterns.
• The V model [37] and the X model [38], which take account of prototyping, reuse,
and domain analysis in the design process.
1.3. HARDWARE DESIGN

There was a dramatic development in hardware technology after the invention of the
transistor. However, design technology also developed hand in hand with this.
The first integrated circuits were developed at the circuit and transistor level. So-called
analog simulators were used for analysis. These continually calculated current and
voltage waveform at the individual nodes and edges.
6 CHAPTER 1
The first quantum leap in design technology was the transition to digital circuit
elements. On the one hand, it was possible to make use of a large number of previously
developed basic components made up of transistors; on the other, before circuits were
produced, they could be analyzed with so-called digital simulators, which handled all
values discretely I . Circuits were developed by hierarchically combining these basic
. more comp1ex ones 2.
components mto
The next quantum leap was the introduction of hardware description languages into the
design process. These made it possible to specify an intended functionality with
description resources well known in programming languages. Gajski represented the
development in his Y model by adding a behavioral aspect to the design process
consisting of physical and structural domains [39].
Examples of hardware description languages are CDL [40], CONLAN [41], DACAPO
III [42], DDL [43], ELLA [44], HILO [45], ISP [46], ISPS [47], KARL/ABL [48], M
[49] PHPL [50], PMS [51], ZEUS [52], and UDLII [53], to name but a few. So great
was the multiplicity of languages and their abstraction feasibility that there was already
talk in 1977 of a tower of Babel [54].
Not until VHDL [55] was a universally accepted standard achieved in this area. Only
VERILOG [56] is used to any extent worth mentioning, and that principally in the
USA.
The development of RTL synthesis tools made it possible to take models formulated
with hardware description languages and turn them automatically into hardware. As a
result, hardware description languages fmally came into their own at the beginning of the
nineties.
Just as in the area of software technology, a series of widely differing developments
were then started, and they are still going on today. For each activity in software design,
there is an analogous developmene in hardware design.
• New synthesis techniques were designed to make it possible to tum more abstract
descriptions directly into hardware [57, 58]. High-level synthesis uses a controller
datapath architecture and supports scheduling and allocation. Whereas high-level
synthesis concentrates on one process, system synthesis tackles the synthesis of
parallel processes.
• Special new specification languages such as Z [59] and ESTERELLE [60] were
developed and proposed for application in hardware design.
• Functional languages [61], familiar in the area of software technology, are intended
for use in the specification process.
I This was the first REUSE approach in hardware and software design methodology fully integrated in
the design process.
2 This composition aspect in the design of digital hardware components was the model for object-
oriented software design. Data hiding and packaging are also basic principles reflected in both design
methods.
• The use of formal methods [62-65] is intended, on the one hand, to prove the
correctness of descriptions, and, on the other, to produce languages formally, so that
their semantics are clearly specified.
• Expert systems are meant to provide assistance to the individual developer in

designing, and interactive synthesis systems [66] are used to share the complexity of
the design task between developer and tool.
• Domain-specific languages such as SILAGE [67] are defined for the data-flow-
oriented description of DSP applications.
• Programmable cores, such as ASIPs and DSP, make it possible to achieve higher
productivity in relation to gates, and, through programmability, to obtain a more
flexible application. However, they shift the problem to the software area.
• Object orientation gains in importance with hardware description languages. In

particular, several approaches have been made with VHDL. An overview can be
found in [68]. An IEEE working group is specially concerned with the object-
oriented enhancement ofVHDL.
1.4. THE FUTURE OF HARDWARE DESIGN

So far, most of the approaches mentioned above have not been promising.
• New synthesis approaches are too domain-specific (high-level synthesis) to result in
any extensive increase in productivity. System and real "behavioral synthesis" I are
still in the research stage. They will therefore not be ready for general use for at least
another fifteen years.
• The great disadvantage of new specification languages is that they represent a

considerable break in terms of generality and methodology from previous hardware
design based on VHDL.
• Hitherto, functional languages have not won wide acceptance in software

development; nor are there any particular grounds or signs for thinking that they will
do so in the field of hardware.
• Exactly the same applies to the use of formal methods in hardware design as in
software design. The only difference is that there are normally no dynamic data
structures in the former, although there is a much greater degree of parallelism.
J The paraJlel is illustrated by the use of the same list numbers. Thus, the development of
optimizing/automatic partitioning compilers can be seen as analogous to activities in the area of high-
level or system synthesis.
I The word "real" is to be interpreted in the sense that nowadays the target architecture can still be easily
read from the description form. "Real" behavioral synthesis would have to produce a result largely
independent of the description form.
8 CHAPTER 1
• Expert systems and interactive systems were already the alternative to synthesis in
[39]. So far, however, there is no sign of a breakthrough.
• Because their area of use is always very small, domain-specific languages are unable
to produce any great increase in productivity.
• Programmable cores shift the problem of productivity from hardware to software.

They demand ever greater integration of hardware and software design, and require
the introduction of software technologies into hardware design. 1
• Object orientation will form the basis of the next quantum leap in hardware design.
This is not just because all other approaches have hitherto proved unpromising in
terms of increased productivity, but also because object orientation has made a
decisive contribution to increasing productivity over a wide area in software
development. In addition, the concepts of object orientation have their origin in the
long-established world of modeling and simulation2 and not in any abstruse
reductionist philosophy intended to describe the cosmos with the aid of its special
thought structure. Modelers and simulators themselves know how important it is to
be able to communicate their model. (Compare what is said at the end of Section 1.2
under the heading 'Design patterns'.)
What has to be done, then, to introduce object orientation into the hardware design
process?
1.5. THE INFLUENCE OF OBJECT

ORIENTATION ON THE DESIGN PROCESS
First of ali, we must have the necessary object-oriented description resources for the
VHDL hardware description language. Efforts must be made to achieve this, so that
these enhancements can be integrated into the next VHDL standard, and appropriate
tools can be developed.
Object-oriented languages alone do not result in greater productivity. For this reason,
new object-oriented design methods must be developed. But here also, we must not try
to reinvent the wheel. Object-oriented design methods for software must be the driving
force behind the approaches adopted.
• Object-oriented design and analysis methods must be adapted to hardware design,
and a common system design must be defined. This seems feasible: for example, as
already mentioned, the approaches in software technology are based on classes that
exchange messages; and this is very similar to the hardware view. Furthermore, in
software design, graphical editors are used to specify hierarchies and automatic
control devices, and these strongly resemble the graphical input tools used in
hardware design.
1 Without jumping the gun too much, we should mention here that this, together with object
orientation, is what we shall later predict as being the future for hardware design.
• Reuse techniques already exist in modern hardware design [69, 70], but they are
concentrated on the synthesis process and, because of the lack of voice or tool
support, are still open to considerable improvement. Providing reuse for prototypes
(see below) and incorporating reuse into the complete object-oriented design process
still represent considerable tasks.
• In hardware design, design patterns have been completely disregarded, and they
represent another range of tasks for the future.
• Interestingly enough, architectures have always featured in hardware design. With

the introduction of object orientation, they "only" require a new system. But how
far the systematic analysis of domains will result in, or require, the discovery of new
architectures remains to be seen.
• Ultimately, the design process must be adapted to hardware requirements in

accordance with the V model and the X model. Abstraction forms for prototyping
have to be clarified, with the design cube [71] at least making it possible to provide a
link with the abstraction forms of the scenarios in software design. In addition,
hardware-oriented domains must be defined.
What can and will be the decisive forces in the next quantum leap under the name of
object orientation?
First of all, of course, the universities, which are in demand as the research
establishments where the theoretical basis and approaches for object orientation are
worked out. Further, it is clear that both simulators for object-oriented languages and (as
in the case of software design) software tools are required for object-oriented design,
with the tool manufacturers being the providers of the "enabling technology" I. The
drawing up of the design methods, however, can only be undertaken by the design
center and the R&D departments of the individual development firms, even though the
major CAD manufacturers are making greater and greater inroads into the support and
methodology markets. The reasons for this are:
• An important point in object orientation is the design domain, on which the product
range of individual firms undoubtedly has a great influence.
• Object orientation is strongly dominated by the design process and less so by design
tools. For this reason, the individual developer, his environment, and even a
"corporate identity" playa much greater role than hitherto.
• When a firm abandons its own design process, outsiders are able to obtain a much
better insight into its products. Confidentiality, features distinguishing it from
competitors, and the use of its own approaches within the design process are
therefore virtually impossible, in spite of non-disclosure agreements. Moreover
2 It should be said that this also includes hardware, but is generally applicable.
I It should again be pointed out that improved synthesis tools are not a basic prerequisite for object
orientation.
10 CHAPTER 1
differences to competitors resulting from a better design process and producing

better products are decreasing extremly in this case.
1.6. SUMMARY AND OUTLOOK

Using the comparison between the development of design methodology in hardware and
software, we have predicted that the new quantum leap in hardware design will be the
introduction of object orientation.
The enhancement of hardware description languages by the addition of object-oriented
constructs, and the adaptation of object-oriented software design methods to those
required for hardware design, will therefore be the most important goals in further
developments within the field of hardware design in the near future.
REFERENCES
[1] Electronic Engineering Times, Issue 737,1993, Compexity ofIntel Processors
[2] Horbst, E.; Nett, M.; SchwartzeI, H.: VENUS - Entwurf von VLSI-
Schaltungen. Berlin Springer, 1986.
[3] F.Fink, C.Wieser MOTOROLA Deutschland, Festvortrag zum 60. Geburtstag
von Professor Antreich an der TU Miinchen, 1994.
[4] Aho, A.; Sethi, R.; Ullmann, 1.: Compilers - Principles, Techniques and Tools.
Reading Massachusetts: Addison-Wesley Publishing Company, 1986.
[5] Baumann, R.: ALGOL-Manual der ALCOR-Gruppe. Einftihrung in die
algorithmische Formelsprache ALGOL. Oldenbourg 1968.
[6] Kernighan, B.; Ritchie, D.: The C Programming Language, Englewood Cliffs,
New Jersey: Prentice Hall, 1989.
[7] McCracken, D.D.: Cobol. Anleitung zur strukturierten Programmierung.
Oldenbourg 1979.
[8] Loveman, D.: "High Performance Fortran", IEEE Parallel and Distributed
Technology, Vol. 1, 1993, pp 25-42.
[9] Jensen, K.; Wirth, N.: Pascal User Manual and Report, New York: Springer
Verlag, 1985.
[10] Symposium on Principles & Practices of Parallel Programming (PPOPP).
Tagungsband jiihrlich bei ACM Sigplan Notices, ACM Press
[11] May, D.: Occam2 -Language Definition, 1987
[12] Barnes, J.: Programming in Ada plus Language Reference Manual, Workham,
England: Addison-Wesley Publishing Company, 1991.
[13] Simon L. Peyton Jones: The Implementation of Functional Programming
Languages, Prentice-Hall, 1987
[14] Fourman, M.P.: Formal System Design. In J. Staunstrup (Ed.): Formal

Methodsfor VLSI Design, Chapter 5. North-Holland 1990.
[15] Allen, J.: Natural Language Understanding, 2nd Edition, Addison-Wesley,
1994.
[16] Clocksin, Mellish: Einfohrung in Prolog, Springer-Verlag, 1984.
[17] Winston, P.; Hom, B.K.O.: LISP, Addison-Wesley, 1988.
[18] Goldberg, A.; Robson, D.: Smalltalk-80; The Language and its
Implementation, Addison Wesley, 1993.
[19] Ellis, M.; Stroustrup, B.: The Annotated C++ Reference Manual. Addison
Wesley, 1991
[20] Keene, S.E.: Object-Oriented Programming in Common LISP. Addison
Wesley, 1989.
[21] Schnupp, P.: Moderne Programmiersprachen. Oldenbourg 1991.
[22] Intermetrix, Inc. Cambridge, MA, USA. ADA Version 9X Reference Manual,
Language and Standard Libraries, Proposed ANSI/ISO Standard, Draft
Version 4.0 Aufl. 1993
[23] Meyer, B.: Eiffel: The Language. New York: Prentice Hall, 1993.
[24] Aho, A.V.; Kernighan, B.W.; Weinberger, P.J.: The AWK Programming
Language. Addison-Wesley 1988
[25] Wall, L.; Schwartz, R.L.; Programming PEARL. Sebastopol, CA, USA:
O'Reilly & Associates, Inc., 1991
[26] Ousterhout, J .K.: TCL und TK. Entwicklung graphischer
Benutzerschnittstellenfur das X-Window System. Addison Wesley 1995.
[27] Patterson, D.; Hennesey, J.: Computer Architecture: a quantitative approach.
San Mateo, California: Morgan Kaufmann Publishers, Inc. 1990.
[28] Carling, A.: Parallel processing - Occam and the transputer. Sigma Pro 1988.
[29] Carter, C.: Object-Oriented Design: a common sense fusion of methods, Stp
UK User Group Conference, Watford, England, 1990.
[30] Coad, P.; Yourdon, E.: Object Oriented Analysis, Prentice Hall, 1990
[31] Meyer, B. Object oriented Software Construction, Prentice Hall, 1988
[32] Rumbaugh, J.; Blaha, M.; Premeriani, F.; Eddy, F.; Lorensen, W.: Object-
Oriented Modeling and Design. Prentice Hall 1991
[33] Shlaer, S.; Mellor, SJ.: Recursive DeSign, Computer Language 7, 3, 1990
[34] Karlsson, E.-A. (Ed.): SW Reuse - a holistic approach. John Wiley & Sons
1995.
[35] Booch, G.: Entwurfsmuster. OBJEKTspektrum, Mar/Apr 1994, S. 14-18.
12 CHAPTER 1
[36] Gabriel, R.P.: The quality without a name. Journal of Object-Oriented

Programming, September 1993, pp. 86-89.
[37] Ould, M.A.: The Management of Risk and Quality, John Wiley & Sons Ltd.
1990.
[38] Hodgson, R: The X-Model: A Process Model for Object-Oriented Software
Development, Fourth International Conference on Software Engineering and Its
Applications, Toulouse, France, 1991
[39] Gajski, D.; Kuhn, R: New VLSI Tools. IEEEE Computer, 12 1983
[40] Chu, Y.: Introducing CDL, IEEE Computer, 12 1974
[41] Borrione, D.; Piloty, R.: CONLAN: Presentation of Basic Principles,
Applications and Relation to VHDL in Fundamentals and Standards in
Hardware Description Languages, Boston, Kluwer Academic Publishers
[42] DOSIS, DACAPO III - System Users Manual, Dortmund, 1987
[43] Duley,1.; Dietmeyer, D.: A Digital System Design Language (DDL) , IEEE
Transaction on Computer, 9 1968
[44] Morrison, J.; Clarke, A.: ELLA 2000, A Language for Electronic System
Design, New York, McGraw Hill, 1993
[45] Flake, P. Moorby, P.; Musgrave, G.: HILO MARK 2 Hardware Description
Language, CHDL'81
[46] Siewiorek, D.: Introducing ISP, IEEE Computer, 12 1974
[47] Barbacci, M.: Instruction Set Processor Specifications (ISPS): The Notation
and its Applications. IEEE Transaction on Computer, 1 1981.
[48] Hartenstein, R KARLlABL in Fundamentals and Standards in Hardware
Description Languages, Dornbrecht, Kluwer Academic Publishers, 1993
[49] Mentor, M Language Users Guide and Reference
[50] Anlauff, H.; Funk, P.; Meinen, P.: PHPL - A New Computer Hardware
Description Language for Modular Description of Logic and Timing,
CHDL'79
[51] Siewiorek, D. Introducing PMS, IEEE Computer 121974
[52] German, S.; Liebherr, K.: ZEUS: A Language for Expressing Algorithms in
Hardware, IEEE Computer, 2 1985
[53] Yasuura, H.; Nagisa, I.: Semantics of a Hardware Description Language for
Japanese Standardization
[54] Lipowski, G.: Hardware Description Languages: Voices of the Tower of
Babylon, Computer 6 1977
[55] Menchini, P.: VHDL in Fundamentals and Standards in Hardware
Description Languages, Dornbrecht, Kluwer Academic Publishers, 1993
[56] Thomas, D. Moorby, P.: The Verilog Hardware Description Language.

Boston: Kluwer Academic Publishers
[57] Michel, P.; Lauther, U. Duzy, P.: The Synthesis Approach to Digital System
Design. Boston: Kluwer Academic Publishers, 1992.
[58] Gajski, D.D.; Vahid, F.; Narayan, S.; Gong, J.: Specification and Design of
Embedded Systems. Englewood Cliffs, New Jesey, USA: P T R Prentice Hall,
1994
[59] Spivey, J.M.: Understanding Z. A specification language and its formal
semantics. Cambridge Univ. Pro 1988.
[60] Berry, G.; Gomtier, G.: The ESTERELLE Synchronous Programming
Language: Design, Semantics, Implementation. Science of Computer
Programming, Jahrgang 19, Nr. 2
[61] Milner, R.; Tufter, M.; Harper, R.: The Definition of Standard ML. The MIT
Press, 1990.
[62] Umbreit, G.: Providing a VHDL-Interface for Proof Systems,
EURODACNHDL'92
[63] Borrione, D.; Pierre, L. Salem,A.: Formal Verification ofVHDL Descriptions
in the Prevail Environment. IEEE Transactions on Computer, 6 1992.
[64] Bormann, J.; Lohse, J.; Payer, P.; Venzl, G.: Model Checking Industrial
Hardware Design, DAC 1995
[65] Guimale, C.: An Information Model ofVHDL '87
[66] Jerraya, A.A.; Park, 1.; O'Brian, K.: AMICAL: An Interactive High-Level
Synthesis Environment. EDAC '93.
[67] Hilfinger, T.N.: A High-Level Language and Silicon Compiler for Digital
Signal Processing. Proceedings IEEE CUSTOM INTEGRATED CIRCUITS
Conference 1985.
[68] Schumacher, G.; Nebel, W.: Inheritance Concept for Signals in Object-Oriented
Extensions to VHDL, EURODACNHDL'95
[69] Girczyc, E.; Carlson, S.: Increasing Design Quality and Engineering
Productivity through Design Reuse, DAC, 1993
[70] Preis, V.; Henftling, R.; Schlitz, M.; Marz-Rossel, S.: A Reuse Scenario for the
VHDL-based Hardware Design Flow, EURODACNHDL'95
[71] Ecker, W.; Hofmeister, M.: The DeSign Cube - A New Model for VHDL
Designflow Representation. EURODACNHDL'92
[72] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, 1.: Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley Publishing Company,
Reading, Massachusetts, 1995.
14 CHAPTER 1
[73] Jacobson, 1.; Christerson, Mo; Jonsson, Po; Overgaard, Go: Object-Oriented
Software Engineering: A Use Case Driven Approach. Addison-Wesley,
Reading, Massachusetts, 19920
2
OBJECT-ORIENTED
MODELING OF HARDWARE
FOR EMBEDDED SYSTEMS
Sanjaya Kumar*, James H. Aylor**,
Barry W. Johnson**, Wm. A. Wulf***
* Honeywell Technology Center
** University of Virginia, Department ofElectrical Engineering
*** University of Virginia, Department ofComputer Science
ABSTRACT
In this chapter, the application of object-oriented techniques to the modeling and design
of hardware for embedded systems is presented. The use of these techniques is an
example of cross fertilization from the software domain to the hardware domain. This
work brings together several ideas common to both hardware and software, such as
state, information hiding, specialization, reuse, families of components, and virtual
machines. The potential advantages of object-oriented techniques when applied to
hardware design are discussed and illustrated on several examples using C++, which
supports user-defined data types and inheritance. It is shown that data decomposition, a
decomposition technique based on abstract data types, can be applied recursively to
hardware components, supporting complexity management and refinement. A
representation that captures this decomposition technique, referred to as the
decomposition graph, is also presented.
15
16 CHAPTER 2
2.1. INTRODUCTION
In this chapter, cross fertilization (also known as technology transfer [1]) refers to the
application of software engineering concepts and principles to hardware engineering, or
vice-versa. An example of cross-fertilization is the use of software engineering concepts
in high-level, hardware synthesis systems [2]. In the process of synthesis, compiler
optimizations and techniques are employed, such as dead code elimination, loop
unrolling, and register allocation using lifetime analysis. Efforts in cross-fertilization also
address the differences between the software and hardware design processes. A related
area is hardware/software codesign [3], which attempts to integrate these currently
separate domains.
The application of object-oriented techniques to hardware design is an example of cross
fertilization from software engineering to hardware engineering. There are several
motivations for exploring these techniques. With the advent of hardware description
languages and the increased use of simulation and modeling in hardware design, it makes
sense to look at programming techniques that can improve the modeling process. In
many circumstances, individuals that model hardware take on the role of software
programmers. Object-oriented techniques can also aid in the management of hardware
complexity. Hardware complexity management and change management issues are
becoming increasingly important [1].
Although object-oriented techniques may seem foreign to hardware designers, many of
the underlying concepts and principles are familiar. In particular, it is natural to think of
hardware resources as components which consist of state and a collection of associated
operations that can manipulate this state. In addition, the construction of systems using
reusable library components, a highly touted advantage of object-oriented techniques,
manifests itself in the hardware domain as design using off-the-shelf building blocks
[4][ 5]. The use of hardware building blocks allows systems to be constructed quickly,
lowers overall design cost, and increases reliability.
The potential advantages of object-oriented techniques when applied to hardware design
include:
• improved modifiability and maintainability of models;
• easy component instantiation with different parameters;
• tailoring of general purpose components to more specialized components;
• quick composition of new components;
• the ability to identify and reuse common components;
• and the possibility of employing existing software synthesis and verification
techniques.
Data abstractions, which form the basis for object-oriented techniques, also provide a
uniform way of representing both hardware and software [3]. A unified representation
for hardware and software allows techniques from one domain to be applied to the other
domain. For example, existing software techniques, such as those used to verify the
correctness of abstract data type implementations, can be utilized for hardware.
Object-Oriented Modeling ofHardware for Embedded Systems 17
The examples presented in this chapter are written in C++ [6], which supports user-
defined data types and inheritance. The reason for utilizing C++ is to demonstrate the
benefits of object-oriented techniques, not to provide arguments for or against the use of
the language for hardware modeling. Section 2.2 provides an overview of data types. In
Section 2.3, the class concept is used to model hardware, and in Section 2.4, inheritance
is utilized to derive specialized components. Section 2.5 describes a refinement
technique called data decomposition. Several examples are presented to illustrate this
decomposition technique in Section 2.6. Type genericity is the subject of Section 2.7. In
Section 2.8, some related work is presented. A summary of the chapter is provided in
Section 2.9.
2.2. DATA TYPES

Before illustrating the application of object-oriented techniques to hardware design, it is
worthwhile to briefly discuss some fundamental ideas behind data types [7]. A data
type consists of a domain of values and a set of operations. An example of a data type is
the programming language type "integer". The type integer has the domain of values
{... , -2, -1, 0,1,2, ... } and the set of operations (among others) multiply, add, subtract,
and divide. An operational specification (or abstract model) is used to define data types.
Such a specification for a data type has two parts: a domain specification, which is an
abstract description of the type, and a specification of the abstract operations that can
be performed on objects of that type.
Data types are present in both software and hardware. Programming languages generally
provide a set of built-in data types, such as integer, character, boolean, and real. In the
same way, machines also support data types. Bit, integer, and float are certainly
common, although machines which support vector computations and string
manipulations also exist.
Some programming languages support the creation of abstract data types (data
abstractions), user-defined data types that represent some abstraction of a real life
entity. In the same manner that new functions, such as square root, can be added to
extend the virtual machine defined by a programming language, new data types, for
example, queues and lists, can be added to the virtual machine as well [8]. This point
will become more clear later.
2.3. MODELING HARDWARE COMPONENTS

AS CLASSES
Data abstraction can be used to represent hardware [9]. C++ supports data abstraction
through the concept of a class. In general terms, a class corresponds to a set of elements
with common characteristics. Thus, a hardware component can be treated as a class
containing state along with a collection of associated operations that can manipulate this
state. For example, a register can be viewed as a class with the operations read and
write. The contents of a register correspond to its state, which can be accessed and
manipulated using the operations read and write, respectively. Although combinational
18 CHAPTER 2
elements do not possess state, the concept of a class can still be used to capture the
common properties of these devices. Thus, an arithmetic logic unit (ALU) class may
define the operations add, subtract, logical AND, and shift. At a higher level of
abstraction, a processor contains state, consisting of the values of the program counter
and other internal registers, which is manipulated by its supported instructions. These
three hardware classes are shown in Figure 1.
read~
write~
Register
a
Arithmetic Logic Unit
sub d d .
land
shift
mUI.
div
load
store
Processor
Figure 1: Examples of Hardware Classes

A portion of a C++ description of the class register (class reg) is shown in Figure 2. An
abstract description of a register is contained in the region labeled "protected". The label
"protected" allows classes which are derived from class reg to access this information
directly. Other classes must utilize the member functions (operations) found under the
label "public", which indicates that the functions are accessible by anyone. All member
functions are not shown.
class reg { II class register

protected:
int contents; II integer contents of register
int num_bits; II number of bits in representation
BitString bitrep; II bit representation of contents
public:
reg(int size = 16) II default size of 16 bits
{
contents = 0; II initialize contents to zero
resize (size); II create a particular size register
}
void resize(int size)
{
bitrep.clear(O, size-1); II clear all of the bits
num_bits = bitrep.length(); II obtain number of register bits
}
int READ ( ) II read the register contents
{
return(contents);
}
void WRITE(int newval) II write a value into the register
{
contents = newval; II update the contents
write_regbits(newval); II write the bit representation
}
Figure 2: Portion of a C++ Description of a Register Class

Object-Oriented Modeling of Hardware for Embedded Systems 19
A stronger level of data hiding is provided by treating the abstract description as

"private". By considering the data as private, even derived classes cannot access the
abstract description directly. Regardless, the abstract description and the member
functions collectively constitute what is common to all registers.
There are three pieces of "protected" information contained in this class: contents,
num_bits, and bitrep, which indicate the integer contents of the register, the number of
bits associated with the register, and the bit representation of the register, respectively.
The data item bitrep is an object of class BitString [10] whose instantiation (creation) is
performed by the third line under the "protected" label. More precisely, bitrep is
instantiated only when a register object is instantiated.
The most important member functions are READO and WRITEO. These member
functions allow the protected information to be read or written, respectively. The regO
member function is called a constructor and is executed when a register object is
instantiated. By convention, a constructor has the same name as the class. The member
function writeJegbitsO accepts an integer, converts the integer into a bit representation,
and assigns this value to bitrep.
In the constructor, a default size of 16 bits is assumed if no size is specified for an
instance. When an object of class reg is instantiated, the constructor initializes the
integer contents of the object to zero and calls the member function resizeO. ResizeO
initializes the bit representation to all zeros and sets the number of bits for the object
using the member function invocations bitrep.clearO and bitrep.lengthO, respectively.
The description in Figure 2 is a specification of a register. Nothing is said about how the
register is implemented. For example, the implementation of the register would consist
of some collection of gates and flip-flops.
An object of class reg must be created before being used. As demonstrated with bitrep,
object instantiation occurs in the same manner as variable declaration. In Figure 3, three
register objects are created within the mainO program: the condition code register
(CCR), the memory address register (MAR), and the memory data register (MDR). The
size of the registers in bits is specified in parentheses. Thus, the same code can be
reused to create different sizes of registers with the same basic properties. Once the
objects are created, various operations can be performed, such as the reading of the
memory address register (see Figure 3).
main ()
(
reg ccr(3); II create a 3-bit CCR
reg mar ( 16) ; II create a 16-bit MAR
reg mdr (16) ; II create a 16-bit MDR
int contents mar.READ(); II read contents of MAR
Figure 3: Creating Register Objects through Instantiation

Although not shown in Figure 2, it may be desirable to parameterize the model with the
physical attributes of the register. Some possible attributes may include read/write
20 CHAPTER 2
delays, area, and power consumption. If necessary, this information could be extracted
using additional member functions, such as read_delayO, write_delayO, areaO, and
powerO. Note that a kind of software abstraction, namely data abstraction, has been
used to describe a hardware abstraction at the register-transfer level. It is also possible
to use data abstraction to describe hardware at other levels of detail, such as the logic
level.
2.4. DERIVING SPECIALIZED COMPONENTS

Starting with a collection of base classes, it is possible to derive more specialized classes
of components through inheritance. As shown in Figure 4, the register class can be used
to derive more specialized registers. Specifically, a program counter is a register with an
increment (incr) operation, and a stack pointer is a register with an increment (incr) and
decrement (decr) operation. An instruction register can be viewed as a special register in
which the contents are divided into various fields which represent the opcode, the
source operands, and the destination of the result. Additional member functions would
be required to extract these individual pieces of information from the instruction
register. These newly derived classes obtain the abstract description and member
functions of class reg. Thus, all of these registers have an integer contents and a
corresponding bit representation.
Register Processor
add
read sub
write load
add.
store
-. reoo. Program Stack Digital Signal

Counter Pointer Processor
sub
wnte
~rite load
incr
IOcr decr ~o::
Figure 4: Deriving Specialized Components

Deriving specialized processors suited for a particular application is commonly
performed in embedded systems design [11]. To support such specialization, several
design automation tools [12][13] have been developed for creating application specific
processors. Through inheritance, this specialization is accomplished in the same manner
as described above.
As an example, a processor containing a collection of basic, "core" instructions can be
used to derive a more specialized processor, such as a digital signal processor or a
graphics processor. Referring to Figure 4, in a digital signal processor, the special
Object-Oriented Modeling of Hardware for Embedded Systems 21
instructions may include the multiply-add-accumulate (mac) instruction. Graphics

processors may contain special instructions for bit manipulation.
The derived class spJeg (stack pointer register) is shown in Figure 5. Although the
READO and WRITEO member functions do not appear in Figure 5, it is still possible
tb manipulate the contents using these functions. In other words, these operations are
implicit within spJeg. Note that the constructor for class spJeg invokes the
constructor for class reg.
In a similar manner, a memory array class with operations read and write can be used to
derive other hardware components. For example, a memory module can be derived from
this base class. Also, a register file can be derived with some special operations, such as
clear and increment.
These examples illustrate the reuse of code, for example, that of class reg, and the ability
to create more specialized components (program counter and stack pointer) from
general purpose ones (register). Therefore, new classes of components can be composed
quickly and easily, reducing the amount of modeling effort and the time required to
validate the models. Also, the close conceptual relationship to libraries should be
evident from this discussion.
class sp_reg: public reg II derive stack pointer from reg

pUblic:
sp_reg(int size): reg(size) II initialize class stack pointer
{
}
void INCREMENT() II increment stack pointer
{
contents++; II increment contents
write_regbits(contents); II write the bit representation
}
void DECREMENT() II decrement stack pointer
{
contents--; II decrement contents
write_regbits(contents); II write the bit representation
}
Figure 5: Derived Register Class: Stack Pointer
2.5. DATA DECOMPOSITION

Software developers utilize data decomposition as a means of refining (deriving
implementations for) abstract data types. This section provides an overview of data
decomposition and discusses how this technique can be used to identify reusable
elements. When modeled as data abstractions, hardware components can also be refined
using this decomposition technique. The application of data decomposition to hardware
components is explored further in the next section.
22 CHAPTER 2
2.5.1. Overview of the Technique

In a system developed using functional decomposition, the functions contain intimate
knowledge of the data structures. Therefore, extensive modifications can result due to
changes in the data structures. Also, because of the tree-like structure of the
decomposition, identification of common, reusable functions is difficult.
As illustrated in Figure 6, data decomposition is a different refinement technique that
manages complexity and addresses the problems mentioned above. In this approach, a
high level abstract data type (ADT) is decomposed into a collection of more primitive
ADTs whose operations are invoked by one or more transformation functions (see [14]
also), that is, algorithms. This decomposition technique can be applied recursively to
each of the primitive ADTs.
High Level ADT

Operational
} Specification
Transformation
Function(s)
invocations
.. toADT
.. A
L
G
invocations o
~
toADT
... R
I Implementation
T
H
invocations M
.. toADT
... S
(Concrete
Representation)
Figure 6: Data Decomposition

More precisely, data decomposition is equivalent to deriving an implementation for the
operational specification of the high level ADT. An implementation for a data
abstraction consists of a concrete representation for the data type and implementations
for its associated operations. In a data decomposition, the primitive ADTs constitute a
concrete representation for the high level ADT. The operations of the high level ADT
are implemented in terms of an algorithm that invokes the operations defined on the
primitive ADTs.
Referring to equations (1)-(3), a data decomposition of an ADT can be described as a
decomposition graph DG consisting of a set of nodes N and edges E. The
decomposition takes the form of a directed acyclic graph (DAG). Each of the nodes
nk E N corresponds to an ADT. An edge eij E E within DG represents an ordered
pair (ni,nj), where ni "consists of' nj. In Figure 6, the high level ADT consists of the
three primitive ADTs shown. As in a DG representation of a functional decomposition,
the algorithm associated with a data decomposition is implicit within the representation.
DG = (N, E) (1)
2.5.2. Identifying Reusable Components and Managing Change

Most complex systems are hierarchical, being composed of a common collection of
"subsystems" at each level [15]. This idea applies to both software and hardware. In
software, common data types may be employed, such as lists, stacks, and matrices. In
hardware, the common "subsystems" may be registers, multiplexers, and arithmetic
logic units. At a lower level, AND, OR, and XOR gates may be utilized.
Data decomposition can be used to expose these common subsystems. As illustrated in
Figure 7, the data decomposition of several different ADTs (in this example, two
different ADTs A and B) "points to" a common collection of more primitive ADTs.
This ability to identify common, reusable elements stems in part from the DAG
structure of the decomposition in which a node can have multiple predecessors. For
example, the data decomposition of two processors being designed by different teams
may reveal common, reusable components, such as arithmetic logic units, multiplexers,
caches, and register files.
A B
e High level ADT
• Primitive ADT
lei Common, reusable component
Figure 7: Identifying Common, Reusable Components

Change management concerns are also addressed using this approach. Specifically,
change is localized to an ADT. As long as implementation changes do not affect the
operational specification of an ADT, transformation functions which use the ADT do
24 CHAPTER 2
not require change. Thus, this approach allows reusable components to be identified and
supports change.
2.6. ARITHMETIC LOGIC UNIT EXAMPLE

In this section, the concepts and ideas presented earlier, particularly data
decomposition, are demonstrated on an example. The example is an arithmetic logic unit
(ALU) of a processor. The instruction set architecture of the processor is based on one
developed by Williams [16].
2.6.1. Data Decomposition of the ALU

Conceptually, the instruction set architecture of a machine is a specification which
serves as a contract between those who write programs and compilers for the machine
and those who implement the machine. This view of a specification is no different than
a specification for other abstract data types. Since it is possible to represent hardware
components as abstract data types, formal specifications for these components can be
expressed in a similar manner.
Given an operational specification of a processor, an implementation can be derived in
terms of more primitive classes of hardware components and a transformation function.
Several possibilities exist. For example, the transformation function may consist of a
fetchO and an executeO procedure, and the classes would correspond to hardware
components, such as a register file, a program counter, a hardware stack, and an
arithmetic logic unit. The transformation function invokes the member functions of
these classes. More details can be found in [3].
Data decomposition can be continued recursively down to any level of detail, with each
abstract data type serving as an operational specification for a lower level
implementation. To illustrate the decomposition technique, consider the ALU of the
processor. The operations defined on the ALU consist of add and subtract along with
those used to perform logical operations and shifting. As depicted in Figure 8, an ALU
can be decomposed into a collection of one-bit arithmetic logic units with some
additional gates (not shown) and a corresponding transformation function. The one-bit
arithmetic logic units can then be further decomposed into a collection of AND gates,
OR gates, inverters, a one-bit full adder, and multiplexers along with a transformation
function, and so on. The reusable elements are the classes employed at a given level.
Each operation associated with the AL U can be implemented as a sequence of
invocations to more primitive classes of objects. As shown in Figure 9, the add
operation (ADD _OP) accepts six parameters represented as bit strings (left, op 1, right,
op2, cin, and alu_oper) and produces a result which is also a bit string. The inputs opl
and op2 correspond to the operands to be added. The inputs left and right are bits that
are employed during shift operations using combinational logic within the ALU. The
input cin represents the carry in bit, and alu_oper is the ALU operation to be
performed. This description of the add operation provides a specification for one who
wishes to use the add operation of the ALU, isolating the user from implementation
changes. As the design of the ALU progresses, common components can be identified
as reusable entities.
add
sub
land
lor
Inot
Arithmetic Logic Unit Irs
lis
ars
ric
rrc
~
Arithmetic Logic Unit
D
classes~ Transformation
I-Bit ALU~S~ .. .. Funwon
Classes \ Transformation
@:;r: ....
Function
OR gates
ANDgates@ . . . .
Inverters @:;r: ....

I-Bit Adder @ ....
Multiplexers @:;r: ....

Figure 8: Data Decomposition of an Arithmetic Logic Unit
26 CHAPTER 2
class arithmetic_unit II class description for ALU

BitString result;
int num_bits;
public:
arithmetic_unit(int size_alu) II constructor for ALU
(
BitString ADD_OP(BitString left, BitString opl, BitString right,\

BitString op2, BitString cin, BitString alu_oper)
II code for performing add
BitString SUB_OP(BitString left, BitString opl, BitString right,\

II code for performing subtract
BitString LAND_OP(BitString left, BitString opl, BitString right,\

II code for performing logical AND
BitString LOR_OP(BitString left, BitString opl, BitString right,\

II code for performing logical OR

}
II other operations supported by ALU defined similarly
Figure 9: Portion of Class Definition of an Arithmetic Logic Unit

Suppose that it is decided to implement the ALU using a multiplexer, an OR gate, and
an interconnection of one-bit ALUs. This design decision is reflected in the description
of the ALU shown in Figure 10. The function newO in the constructor allocates
memory for the one-bit ALU array at the time that an object is instantiated and returns
a pointer to the array.
A portion of the transformation function used to implement the operation ADD_OP is
shown in Figure 10. A loop is used to accumulate the sum using a series of one-bit
additions, similar to a ripple carry adder. This code invokes the operations eval_aluresO
and eval_alucoutO, which compute the sum and carry out, respectively, within a one-bit
ALU. Similar transformation functions are used to implement the other operations of
the ALU.
class arithmetic_unit II Implementation for ALU

multiplexer muxl; II multiplexer
or_gate orl; II OR gate
onebit_alu *alu_array; II array of l-bit ALUs
int num_bits;
BitString result;
public:
arithmetic_unit(int size_alu, int size_mux, int size_or) : \
muxl(size_mux), orl(size_or)
num_bits = size_alu;
alu_array = new onebit_alu[size_alu]; II array of l-bit ALUs
}
BitString ADD_OP(BitString left, BitString opl, BitString right,\
II variable declarations & some code here (not shown)

II main loop
for (int i = opl.length() - 1; i>= 0; i--) {
II NOTE: i = 0 corresponds to MSB
xinput[i] opl[i];
yinput[i] op2[i];
i f (i == 0) II MSB (most significant bit) I-bit ALU
II gets input called left
xlinput = left;
else II all other I-bit ALUs get left neighbor's x value
xlinput = opl[i-I];
tmp = alu_array[i] .eval_alures(xlinput, xinput, xrinput,\
yinput, carry_in, alu_oper); 1/ use l-bit ALU
tmp_result += tmp;
carry_in = alu_array[i] .eval_alucout(xlinput, xinput, \
xrinput, yinput, carry_in, alu_oper);11 use l-bit ALU
xrinput = xinput;
}
II some code here (not shown)
return(result);
}
II other operations supported by ALU defined similarly
Figure 10: Portion of the ALU Implementation

At this point, the one-bit ALU can be decomposed into more primitive elements (see
Figure 11 and Figure 8). The inputs x and y correspond to one bit input operands. The
xl and xr inputs are obtained from neighboring left and right one-bit ALUs, respectively.
These inputs are employed during shift operations. The cin bit is obtained from a
neighboring one-bit ALU on the right, and the carry_out bit is sent to a neighboring one-
bit ALU to the left.
28 CHAPTER 2
xl x y xr
result
class onebit_alu ( II class description for onebit_alu

and_gate andl;
or_gate orl;
not_gate not1;
not_gate not2;
multiplexer ffiux1;
multiplexer ffiux2;
onebit_adder add1;
BitString result;
BitString carry_out;
public:
onebit_alu(int size_ffiux1 = 2, int size_mux2 = 7): \
mux1(size_mux1), mux2(size_mux2) II constructor for onebit_alu
result = atoBitString(UO");
carry_out = atoBitString(UOU);
BitString eval_alures( BitString xl, BitString x, BitString xr,\

BitString y, BitString cin, \
BitString alu_op)
II code which computes and returns result (not shown)
BitString eval_alucout( BitString xl, BitString x, BitString xr,\

BitString y, BitString cin, \
BitString alu_op)
BitString inv_out = not2.evaluate(y);

BitString sel_muxl = alu_op;
sel_mux1 = sel_mux1 » alu_op.length() - 1;
II strip off last bit
BitString mux1_out =muxl.evaluate(y + inv_out, sel_muxl);
BitString carry_out add1.evalcout(x, rnux1_out, cin);
II use 1-bit adder
return(carry_out);
Figure 11: One-bit ALU Implementation

The operational specification for one of the elements of the one-bit ALU, a one-bit full
adder, is shown in Figure 12. One formal method for specifying modules consists of
using pre- and post-conditions [17]. Pre-conditions are logical assertions on the input
state, and post-conditions are logical assertions on the output state. Thus, pre- and
post-conditions reflect what is assumed to be true upon entry and exit from a module,
respectively. Using pre- and post-conditions, the operations performed on the one-bit
adder, evalsumO and evalcoutO, can be specified as shown below.
I-Bit Adder
eValsum~
evalcout~
evalsum(BitString x, BitString y, BitString cin)

returns BitString
pre length(x) = length(y) = length(cin) = I
post result f- x ffi y ffi cin
evalcout(BitString x, BitString y, BitString cin)

returns BitString
pre length(x) = length(y) = length(cin) = I
post result f- xy v xcin v ycin
Figure 12: Operational Specification for a One-Bit Full Adder

One possible implementation of the one-bit adder is shown in Figure 13. In this
example, the one-bit adder is concretely represented as a collection ofXOR gates, AND
gates, and an OR gate. Each operation is implemented as a sequence of invocations to
these more primitive classes. These primitive classes have only a single operation,
evaluateO, which accepts a bit string of length two and returns a bit string of length one.
The '+' symbol in the parameter for the evaluateO operation indicates concatenation.
Upon evaluating the sum or carry out, the result is returned to the calling transformation
function.
It is also possible to specify the one-bit adder in terms of a single operation, evaluateO,
similar to the gates described above. Given this specification, the evaluateO operation
would accept x, y, and cin, and would return a single bit string which would contain
both the sum and cout. The use of two operations allows each computation, sum and
cout, to be considered independently.
30 CHAPTER 2
X -----r---4rl
y ---,--1---+-1 sum
cout
cin------------------~
class onebit_adder II class description for onebit_adder

and_gate andl;
and_gate and2;
xor_gate xorl;
xor_gate xor2;
or_gate orl;
BitString sum;
BitString carry_out;
public:
onebi t_adder ( ) II constructor for onebit_adder
(
sum = atoBitString(MO");
carry_out = atoBitString(MO");
BitString evalsum(BitString x, BitString y, BitString cin)

(
BitString out_xorl = xorl.evaluate(x + y);
BitString sum = xor2.evaluate(out_xorl + cin);
return (sum) ;
BitString evalcout(BitString x, BitString y, BitString cin)

(
BitString out_xorl xorl.evaluate(x + y);
BitString out_andl andl.evaluate(x + y);
BitString out_and2 and2.evaluate(out_xorl + cin);
BitString carry_out = orl.evaluate(out_and2 + out_andl);
return(carry_out);
Figure 13: One-Bit Adder Implementation

Note that existing software verification techniques [7][ 17][ 18] can be applied to
hardware components. Because the processor is modeled using data abstractions,
techniques for verifying the correctness of abstract data type implementations with
respect to their operational specifications can be utilized. By recursively applying these
techniques, the correctness of the processor implementation can be established with
respect to its operational specification.
2.6.2. Inheritance Hierarchies

A description of the inheritance hierarchies employed in this model is depicted in
Figure 14. Each of the nodes in the hierarchy designates a class. The top node in each
hierarchy is the base class, and the lower nodes are derived classes. For example, the
class gate is used to derive the classes AND gate, OR gate, XOR gate, and inverter. In
the same way, a register class is used to derive a program counter class, a stack pointer
class, and an instruction register class.
Gate Register
/I~
AND OR XOR Inverter
/+~
Program
Stack Instruction
Counter Pointer Register
Memory Array
/~
MemoryRegister File
Figure 14: Inheritance Hierarchies Employed

Although not developed as part of the model, there are other classes of components that
are useful. Flip-flops and latches are fundamental sequential devices used in the design
of digital systems. Thus, one can construct a class called flip-flop and derive D flip-
flops, JIK. flip-flops, and SIR flip-flops. Although the model did not develop the control
unit for the processor, the register class could have been used to derive the
microprogram counter, and a control memory for storing microinstructions could have
been derived from the memory array class (assuming a writable control store). Also,
specialized devices can be derived from existing classes depending upon the application.
As an example, application specific processors may utilize specialized arithmetic logic
units.
2.6.3. Discussion
Some points are worth mentioning about a model developed using data decomposition.
The resulting model resembles a data path/control decomposition. When a processor is
instantiated, the components constitute the elements of the data path, and the
transformation function represents the control, that is, the sequencing of the operations
to be performed. Each machine instruction is implemented as a collection of invocations
to the components required for execution. As an illustration, in order to fetch and
execute a subtract instruction, operations are performed on the memory address register,
the memory data register, the register file, the arithmetic logic unit, the condition code
register, and the program counter. Thus, the transformation function represents the
register transfers to be initiated by a microcoded or a hardwired control unit.
Data decomposition illustrates a fundamental idea within the context of virtual
machines. Specifically, a virtual machine at level N is implemented in terms of a program
running on a machine at level N-J [19]. For instance, the ISA level model of the
processor can be considered a virtual machine which is implemented as a microprogram
32 CHAPTER 2
running on a lower level machine (micromachine), consisting of arithmetic logic units,

register files, and so on. One can extend this analogy to lower levels of the virtual
machine hierarchy. From a conceptual standpoint, each abstract data type (class) may
be considered a virtual machine, a reusable element with a corresponding virtual
instruction set. Thus, using this technique, a virtual machine is decomposed into more
primitive virtual machines, each of which "executes" a portion of an abstract program.
Note that the abstract data types within a data decomposition do not necessarily have
to coincide one-to-one with our intuitive notion of a component. The abstract data
types utilized at any given level may be based on complexity considerations. Consider a
one-bit full adder. A full adder can be expressed directly in terms of AND gates, XOR
gates, and an OR gate. Alternatively, a full adder may be implemented in terms of half
adders and an OR gate. Then, at the next level, the half adder class can be expressed in
terms of an AND gate and an XOR gate. Although this is a simple example, the point
being made is that the abstract data types employed to implement a component depend
on the amount of complexity that can be managed at that level.
2.7. TYPE GENERICITY

Type genericity [20], a form of polymorphism [21 ][22], is the ability to parameterize a
software element, such as a procedure or a data type, with one or more types. Type
genericity makes programs more general. To illustrate this point, a swap procedure can
be parametrized with a type, allowing either two integers, two reals, or two strings to
be swapped. In the same manner, data types can be parameterized with types as well.
Thus, one can have a data type called list which is parameterized with another type.
Using the three types mentioned above, it is possible to create a list of integers, a list of
reals, or a list of strings. Several languages, such as Alphard [23] and CLU [8], support
this parameterization of types. This kind of polymorphism is particularly useful when
dealing with objects which act as "containers" for other elements, such as queues, lists,
and arrays.
In hardware, several components, such as registers, stacks, and register files, act as
containers. Thus, as shown in Figure 15, one can utilize templates in C++ to construct a
hardware stack which stores integers or floating point numbers. In the same manner, a
register file class can be created to represent an integer register bank or a floating point
register bank. Also, memory stores instructions, which can also be treated as a type.
One of the benefits of type genericity is reuse of code. The same code can be employed
to construct containers for different data types.
The notion of type genericity is closely associated with Parnas's concept of program
families [24]. A program family (or design family) corresponds to a set of programs
with common characteristics. The hierarchical structuring of program families addresses
design change and can help reduce the cost of design development and maintenance. The
fundamental idea behind program families is to emphasize those properties that are
common to a family of designs before considering special properties which distinguish
between individual family members. This idea can also be applied to the development of
families of hardware components, such as families of processors.
main( )
{
stack<int> stkl(10); II stack of 10 integers
stack<float> stk2(15); II stack of 15 floats
stkl.push(3) ; II push the integer 3 onto the integer stack

stk2.push(4.5) ; II push the float 4.5 onto the float stack
Figure 15: Type Genericity

As an illustration, consider the MC68000 family of processors. One may initially focus
on the common aspects between various family members, such as common hardware
components and instructions. These descriptions could then be specialized into, for
example, an MC68020.
2.8. RELATED WORK

Previous work in the application of object-oriented concepts to hardware modeling and
design has appeared in several forms. Giloi [25] presents a taxonomy of computer
architectures using machine data types, which are based on descriptions of abstract data
types. Langdon [26] has noted the active-passive duality which exists throughout digital
systems and has related this idea to elements within a computer system. He describes
the decomposition of problems into an active part and a passive part. Within a
processor, components such as registers and arithmetic units constitute the objects
(passive part), and control (active part) provides the actions which change the state of
the objects.
Gross [1] addressed the problem of change management concerns in the VLSI design
process using Parnas's information hiding principle. Muller and Rammig [27] describe a
hardware description language which models hardware components as classes and
supports single inheritance. Chung and Kim [28] have also used class concepts for
describing VHDL design entities. Nelson, Fontes, and Zaky [29] have developed
"generic" classes of hardware components to aid in the modeling and simulation of
computer architectures at the microarchitecture level, as well as families of computer
architectures. More recently, object-oriented extensions to VHDL have been developed
[30] to support rapid prototyping, performance modeling, and hardware/software
codesign. These extensions incorporate the capability of expressing components as
classes and employing inheritance.
The use of object-oriented concepts and ideas has also been discussed in system
modeling and electronic design automation systems. Newton, Vaughn, and Johns [31]
and SES/Workbench [32] have used these ideas within the context of queuing-based
system level modeling environments. Yokote and Tokoro [33] have utilized object-
oriented design techniques for modeling distributed and fault-tolerant systems. More
generally, several individuals [22][34][35] have promoted the use of object-oriented
techniques in electronic design automation.
34 CHAPTER 2
Ledbetter and Cox [36] discuss the notion of software-ICs (integrated circuits). They
describe the need to incorporate ideas associated with hardware reusability into
software. Some of these ideas include developing appropriately "packaged"
components that provide well defined services and hide the internal operation of an IC.
The concept of IC foundries, which produce standard and custom ICs, is also
promoted.
This work is different from previous object-oriented hardware modeling efforts in
several respects. Through its emphasis on cross fertilization from the software
engineering domain to the hardware engineering domain, the work brings together several
common hardware and software ideas such as state, complexity management,
information hiding, specialization, reuse, families of components, and virtual machines.
The decomposition graph captures many of these common ideas. Also, the use of data
decomposition as a refinement and complexity management technique for hardware
design and its relationship to virtual machines are unique aspects of this work.
2.9. CONCLUSIONS
This chapter has presented and illustrated several potential advantages of employing
object-oriented techniques in hardware modeling and design. Some of these advantages
include complexity management, specialization, and model reuse. Data decomposition,
the decomposition of abstract data types into more primitive abstract data types,
supports the identification of common, reusable hardware components and change
management.
Several insights have been gained as a result of modeling hardware components through
data abstraction. By modeling hardware components as abstract data types and
employing data decomposition as a refinement technique, the conceptual model of
virtual machines is readily exposed. In such a model, abstract data types can be
considered virtual machines whose operations correspond to a virtual instruction set.
Therefore, in the same manner that a functional decomposition defines a virtual machine
with a virtual instruction set, a data decomposition does so as well. Also, type
genericity in hardware modeling and design supports Parnas's concept of program
families.
Some aspects of hardware design have not been discussed. For example, given a
specification of a hardware component described as an abstract data type, it may be
possible to use software synthesis techniques [37][38] as a means of generating an
implementation. Also, the aspect of concurrency, which is fundamental in hardware
modeling, is addressed elsewhere [30][33].
Further work is required in the areas of applying data abstraction to hardware modeling,
particularly at the system level. Specifically, as the complexity of systems increases, it
may be desirable to provide more abstract descriptions of processors. For example,
these processors may only provide the operations send and receive, for communication
with other processors, and execute, which would be utilized to perform either "virtual"
instructions or specific machine instructions. Given such descriptions, two problems
that need to be addressed are the refinement of the abstract description (system level) to
a more detailed one (instruction set level) and the ability to mix these descriptions
within a single model (see [3]). Because data abstraction can be used as a basis for a
unified representation for both hardware and software, another area for further
investigation is hardware/software codesign.
Acknowledgments
This work was performed while the first author was at the University of Virginia. The
authors would like to acknowledge the partial support provided by the Semiconductor
Research Corporation under contract number 93-DJ-152 and the National Science
Foundation under grant number CDA-8922545.
We would like to thank Sanjay Srinivasan, Gnanasekaran Swaminathan, Richard
MacDonald, and Lori Kaufman for their comments and suggestions. Thanks also to
Ronald Williams, Ronald Waxman, Robert Klenke, and Joanne Dugan for their support
of this effort. Thanks is extended to John Knight for discussions regarding object-
oriented concepts. We would like to thank the reviewers as well for their critique of the
manuscript and helpful suggestions.
REFERENCES
[1] Smith, C. u., R. R. Gross, "Technology Transfer between VLSI Design and
Software Engineering: CAD Tools and Design Methodologies," Proceedings of
the IEEE, Vol. 74, No.6, June 1986, pp. 875-885.
[2] McFarland, M. C., A. C. Parker, R. Camposano, "The High-level Synthesis of
Digital Systems," Proceedings ofthe IEEE, Vol. 78, No.2, 1990, pp. 301-318.
[3] Kumar, S., J. H. Aylor, B. W. Johnson, W. A. Wulf, The Codesign of
Embedded Systems: A Unified Hardware/Software Representation, Kluwer
Academic Publishers, Dordrecht, The Netherlands, 1996.
[4] Tobias, J. R., "LSINLSI Building Blocks," IEEE Computer, August 1981, pp.
83-101.
[5] Peels, A. J. H. M., "Designing Digital Systems - SSI and MSI vs. LSI and
VLSI," IEEE Micro, April 1987, pp. 66-80.
[6] Stroustrup, B., The C++ Programming Language, 2nd Edition, Addison-
Wesley Publishing Company, Reading, Massachusetts, 1991.
[7] Wulf, W., M. Shaw, P. N. Hilfinger, L. Flon, Fundamental Structures of
Computer Science, Addison-Wesley Publishing Company, Reading,
Massachusetts, 1981.
[8] Liskov, B., 1. Guttag, Abstraction and Specification in Program Development,
MIT Press, Cambridge, Massachusetts, 1986.
[9] Kumar, S., J. H. Aylor, B. W. Johnson, W. A. Wulf, "Object-Oriented
Techniques in Hardware Design," IEEE Computer, Vol. 27, No.6, June 1994,
pp.64-70.
36 CHAPTER 2
[10] Gnu C++ library.

[11] Wynia, T., "RISC and CISC Processors Target Embedded Systems,"
Electronic Design, June 27, 1991, pp. 55-70.
[12] Wolfe, A., J. P. Shen, "Flexible Processors: A Promising Application-Specific
Processor Design Approach," Proceedings of the 21st Annual Workshop on
Microprogramming and Microarchitectures, 1988, pp. 30-39.
[13] Mulder, H., P. Stravers, "A Flexible VLSI Core for an Adaptable
Architecture," Proceedings of the 22nd Annual Workshop on
Microprogramming and Microarchitectures, 1989, pp. 223-231.
[14] Jalote, P., An Integrated Approach to Software Engineering, Springer-Verlag,
New York, 1991.
[15] Booch, G., Object-Oriented Analysis and Design with Applications, 2nd
Edition, Benjamin/Cummings Publishing Co., Inc., Redwood City, California,
1994.
[16] Williams, R. D. "Class Project Fall 1990," University of Virginia.
[17] Hoare, C. A. R., "An Axiomatic Basis for Computer Programming,"
Communications of the ACM, Vol. 12, No.3, March 1969, pp. 335-355.
[18] Shaw, A. C., "Reasoning About Time in Higher-Level Language Software,"
IEEE Transactions on Software Engineering, Vol. 15, No.7, July 1989, pp.
875-889.
[19] Davidson, J. W., J. V. Gresh, "Cint: A RISC Interpreter for the C
Programming Language," SIGPLAN '87 Symposium on Interpreters and
Interpretive Techniques, St. Paul, Minnesota, June 24-26, 1987, pp. 189-198.
[20] Meyer, B., "Genericity versus Inheritance," Proceedings of the Object-
Oriented Programming Systems, Languages, and Applications Conference
(OOPSLA '86), September 1986, pp. 391-405.
[21] Cardelli, L., P. Wegner, "On Understanding Types, Data Abstraction, and
Polymorphism," Computing Surveys, Vol. 17, No.4, December 1985, pp.
471-522.
[22] Khoshafian, S., R. Abnous, Object Orientation: Concepts, Languages,
Databases, and User Interfaces, John Wiley and Sons, Inc., New York, 1990.
[23] Wulf, W. A., R. L. London, M. Shaw, "An Introduction to the Construction
and Verification of Alphard Programs," IEEE Transactions on Software
Engineering, Vol. SE-2, No.4, December 1976, pp 253-265.
[24] Parnas, D. L., "On the Design and Development of Program Families," IEEE
Transactions on Software Engineering, Vol. SE-2, No.1, March 1976, pp. 1-
9.
[25] Giloi, W. K., "Towards a Taxonomy of Computer Architectures Based on the
Machine Data Type View," 10th International Symposium on Computer
Architecture, 1983, pp. 6-13.
[26] Langdon, Jr., G. G., Computer Design, Computeach Press Inc., San Jose, Ca.,
1982.
[27] Miiller, W., F. Rammig, "ODICE: Object-Oriented Hardware Description in
CAD Environment," Proceedings of the Ninth International Symposium on
Computer Hardware Description Languages and their Applications, J. A.
Darringer and F. J. Rammig, eds., Elsevier Science Publishers B. V. (North-
Holland), IFIP, 1990, pp. 19-34.
[28] Chung, M. J., S. Kim, "An Object-Oriented VHDL Design Environment,"
27th ACMlIEEE Design Automation Conference, 1990, pp. 431-436.
[29] Nelson, M. L., K. A. Fontes, A. Zaky, "An Object-Oriented Approach to
Computer Architecture Simulation," Proceedings of the 25th Annual Hawaii
International Conference on System Sciences (HICSS-25), Vol. 1: Architecture
and Emerging Technologies, January 7-10,1992, Kauai, Hawaii, pp. 476-485.
[30] Covnot, B. M., D. W. Hurst, S. Swamy, "OO-VHDL: An Object-Oriented
VHDL," Proceedings of the fall 1994 VHDL International User's Forum.
(VIUF'94), Tyson's Comer, Virginia, 1994.
[31] Newton, D. E., P. W. Vaughn, R. P. Johns, "PRISM: An Object-Oriented
System Modeling Environment with an Embedded Symbolic Spreadsheet,"
Proceedings of the 1991 (23rd) Summer Computer Simulation Conference,
July 22-24, 1991, Baltimore, Maryland, pp 81-86.
[32] Scientific Engineering Software, Inc., SES/Workbench User's Guide, Austin,
Texas, April 1989.
[33] Yokote, Y., M. Tokoro, "Concurreni Programming in Concurrent Smalltalk,"
in Object-Oriented Concurrent Programming, A. Yonezawa and M. Tokoro,
eds., MIT Press, Cambridge, Massachusetts, 1987.
[34] Wolf, W., "Object-Oriented Programming for CAD," IEEE Design and Test of
Computers, March 1991, pp. 35-42.
[35] Gupta, R., W. H. Cheng, R. Gupta, I. Hardonag, M. A. Breuer, "An Object-
Oriented VLSI CAD Framework," IEEE Computer, Volume 22, May 1989,
pp. 28-37.
[36] Ledbetter, L., B. Cox, "Software-ICs," BYTE, June 1985, pp. 307-316.
[37] Setliff, D., E. Kant, T.Cain, "Practical Software Synthesis," IEEE Software,
May 1993, pp. 6-10.
[38] Jalote, P., "Synthesizing Implementations of Abstract Data Types from
Axiomatic Specifications," Software-Practice and Experience, Vol. 17, No. 11,
November 1987, pp. 847-858.
3
OBJECT-ORIENTED AND
REAL-TIME TECHNIQUES:
COMBINED USE OF OMT,
SDL AND MSC
Philippe Leblanc
VERILOG, 150 rue N. Vauquelin, BP 1310 F-31J06 Toulouse Cedex, France
ABSTRACT
Starting from the assessment that general-purpose, object-oriented techniques 'Such as
OMT address specific real-time issues only partially, this chapter presents the OORT
(Object-Oriented Real-time Techniques) method which has been defined especially for
real-time system. engineering. This method combines OMT with two formal description
techniques, SDL and MSC, which are widespread in the telecom area. OMT is usedfor
capturing user requirements andfor designing data, whereas SDL is used to design the
system and formally define its behavior. MSCs playa central role in this approach: at
the analysis stage, they support the use case modeling, and at the development stage they
are used to produce the test sequences for testing and validating the system design and
the actual implementation.
A combination of notations is relevant only if the different models produced are

complementary and coherent. For this purpose, OORT includes a set of consistency
rules to apply when building the models.
OORT also proposes a complete engineering process which covers all the phases of a
development project, from system requirements to delivery. The OORT process is based
on the iterative process model in order to take advantage of all the expected benefits of
using object-oriented andformal description techniques such as rapid prototyping, early
verification and validation, immediate reuse, code generation and test generation
automation.
39
40 CHAPTER 3
3.1. INTRODUCTION
3.1.1. Issues Related to Real-Time System Engineering

Real-time systems include specific constraints which make them harder to develop and
test. It is necessary to monitor tasks (dynamic creation, inhibition, resuming, deletion),
to provide inter-task communication (e.g. through mailbox or rendez-vous), to handle
time (e.g. by means of timers), etc. Such constraints are commonplace in distributed
telecom systems or in embedded systems developed in industrial sectors like
aeronautics, ground transportation, defence or electronics. New constraints can also be
added in relation to the expected quality of service, such as robustness and performance.
In the case of safety-critical or mission-critical systems, as a failure could lead to either
human casualties (aeronautics, nuclear, etc.), or huge overcosts (telecoms, electronics,
etc.), it is of the utmost importance to verify that the system has no default, e.g.
through simulation and testing.
3.1.2. OMT for Real-Time, Strengths and Weaknesses

Object-oriented techniques seem to provide an efficient solution in mastering
development costs by facilitating reuse at all development stages, from the problem
analysis to the system implementation. OMT (Object Modeling Technique) is today
the leading 00 method. Its success comes from the notations involved which are
graphical and relatively simple and concise, from the proposed process which is clearly
defined, and from its reference book [Rum91] which is easy to read and provides the
reader with numerous concrete examples. OMT is also easy to introduce in new
projects and is supported by many off-the-shelf tools.
On the other hand, as it is now, OMT is not easily applicable to real-time systems. No
construct is proposed for architecture design, task monitoring, time management or
software distribution. The proposed behavioral modeling is a purely graphical notation
which neither explains how objects actually communicate nor specifies actions to be
performed when receiving stimuli (except by means of free text). As a consequence,
only code skeletons can be automatically generated, and model simulation is not
supported.
3.1.3. Use of Formalisms Dedicated to Real-Time: SDL and MSC

As a consequence, OMT must be complemented by formalisms purely dedicated to
real-time systems. SDL, Specification and Description Language, and MSC, Message
Sequence Chart, are ITU-T recommendations widespread in the telecom sector, with
more than 20,000 users. These two complementary notations allow us to design the
system, describe its behavior without ambiguity, simulate and validate the obtained
models, and generate the executable code which is implemented on the actual target.
This chapter will detail how to make joint use of these three notations in each phase of
the engineering process, depending on the nature of the elements to develop.
Object-Oriented and Real-Time Techniques: Combined Use o/OMT. SDL and MSC 41
3.2. THE OORT ENGINEERING PROCESS

Our purpose is not to invent new engineering activities to replace traditional practices,
but rather to provide the reader with clear and commonly accepted definitions of what a
system engineering process consists of. The presentation of the OORT method will be
based on the generic framework described here.
3.2.1. Typical System Engineering Activities

The typical engineering process has been identified in terms of activities, as illustrated
in Figure 1. This framework is generic and flexible enough to be compatible with the
traditional processes used by the industrial community, where the most widespread
types are the waterfall life cycle, the V-life cycle, the spiral life cycle and the new X-life
cycle (an extension of the V -life cycle including reuse activities). In addition, this
framework supports iterative (or incremental) development and rapid prototyping. It
also embraces the processes promoted by the main existing 00 methods, i.e. [Rum91],
[Jac92], [SeI94], [Sh188]-[Sh192] and [SDL92b].
Figure 1: System Engineering Activities
3.2.2. Requirements Analysis

Requirements analysis is the initial study of the system to be developed. It involves
modeling both the user requirements and the real-world environment with which the
system will interact. In real-time system development, system analysis focuses on the
expected reaction of the system to stimuli produced by the set of actors composing the
environment. This reaction is described by means of two models:
• the object model for identifying the influential actors related to the system and the
exchanged data; l
• the dynamic model for defining the control flows exchanged between the system and
the actors.
42 CHAPTER 3
3.2.3. Architectural Design

The objective of the architectural design activity is to define the logical architecture of
the system (the term "logical architecture" is used here to refer to the software
architecture of the application, as opposed to the term "physical architecture", which
means the architecture of the real hardware target on which the application runs).
In addition to the requirements originating from the analysis, the architectural design
must also consider technical and economical aspects for thoroughly new systems, as
well as the interfaced elements of cooperative systems (e.g. communication means and
data format). When creating variants of standard products, reuse considerations
influence system design to make·the reuse of validated architectures or of available
software components possible.
3.2.4. Detailed Design

Once the architectural design is complete, software objects composing the architecture
must be refined in order to be easily implemented. Two categories of objects are
identified:
• concurrent objects, which contain their own thread of control running concurrently
inside the system;
• passive objects, which act as computational resources used by concurrent objects.
For example, a Unix process is a concurrent object, whereas a C++ class is a passive
object.
3.2.5. Test Design

Different types of tests are commonly defined:
• Unit tests: allow developers to ensure separate system components behave as
intended before integration.
• Integration tests: allow developers to check operation of the software obtained by
gradual integration of the implemented components.
Test design can be a time-consuming activity, especially when dealing with safety-
critical or mission-critical systems. The efforts spent designing tests can be equivalent
to those related to the analysis and design phases. As a consequence, the notations
selected for OORT provide a significant help in the testing activities such as automating
test generation, for example.
3.2.6. 1m plementation
The implementation of real-time systems (e.g. embedded systems) greatly depends on
the physical architecture of the environment in which the system is immersed. In
particular, concurrent objects must be designed to operate flawlessly, with both the
distributed architecture of the target and the underlying real-time operating system.
Passive objects are less target-dependent, and the programming language chosen merely
affects the implementation phase.
Object-Oriented and Real-Time Techniques: Combined Use ofOMT, SDL and MSC 43
Using formal methods throughout the process greatly improves the implementation
activity, formal descriptions being automatically translated into fully executable code.
3.2.7. Testing
Testing consists in executing the developed software following test sequences defined in
the analysis and design phases, first on the development site, then on the target
equipment. People in charge of testing must verify that the application passes the unit
and integration checks and that it meets the requirements expressed by the user. For
these purposes, testing activity uses the results of the test design phase as inputs, as
well as the dynamic modeling produced at requirement analysis time.
This activity can be partly automated, depending on the notations selected during
analysis and design. For example, producing test suites in a language such as TTCN in
combination with a design notation automates testing and result analysis.
3.2.8. Iterative Process Model

The most common of life cycles in industry is currently the V-life cycle. According to
it, activities are carried out sequentially: the application must be completely analyzed
before design can take place and completely designed before being implemented. Such a
unidirectional life cycle prevents developers from checking the general technical
feasibility of the application at the beginning of the project and hampers the reuse of
components early in the development phases.
In order to better master application development activities, it is recommended to
follow an iterative process, as shown in Figure 2.
As all activities are performed on a separate part of the application early on in the
development process, technical difficulties are generally detected so that appropriate
answers can be provided. Also, team members are trained more progressively to use the
various methods and tools selected for the project. Iterative processes facilitate the
reuse of external components or of components developed in previous iterations.
Lastly, early on in the project schedule, parts of the application can be executed
(manually or automatically).
Reauirel1)ent Design Targeting Testing Validation
aha YSIS
Application
- - Iteration L
-----------=-~-~-~-~
- Iteration 2...
....
------------=_:=""'_.._......_-......
- Iteration
--------------------
.....
3.....
- -Iteration N--_ _ _ _ _ _ _..........

..
Figure 2: Iterative Process
44 CHAPTER 3
3.3. OVERVIEW OF THE OMT, MSC AND SDL

NOTATIONS
3.3.1. The OMT Notation
OMT is an object-oriented analysis and design method defined in 1991 by a General
Electric team led by J. Rumbaugh [Rum91]. In analysis, this method proposes three
types of modeling: object, dynamic and functional. A second version of OMT is
expected by the end of 1996, which will be merged with the Booch [Bo093] and
Jacobson [Jac92] notations to form the Unified Method. The main extensions will
concern the object and dynamic modeling to meet software design issues better.
Functional modeling is being abandoned. Therefore, this type of modeling will be
ignored here.
3.3.1.1. Object Modeling
This is the core of the method. Class and instance diagrams are referred to by the other
models, and OMT analysis usually starts there. Object modeling uses:
• Class diagrams: they describe the problem space in terms of classes, attributes,
operations, associations, aggregations and inheritance links. Figure 3 shows a typical
class diagram.
• Instance diagrams: they may be regarded as snapshots of the system in its operating
environment. They describe expected system configurations in terms of instances of
classes, associations and aggregations.
Person I
I
name: stnng
address: string
/\
I Coshler I
emplOyeeNO: SIring
I.
1+ employer
I Customer I
name: stnng
Bank
Clientele .I~(account : Accounl,amounl : inleger)
1 + withdraw(accooot: Account,amount : integer)
I
bankNo : string
createAccount(cuslomer : Customer) : Account
closeAccount{account : Account)
•
createCard(customer : Customer)
deleleCard(card: c.sheard) 1+
Account
I I
I
CashCard
accountNo : integer
1+ creditLimit: integer
balance: integer accessedAccount
bankNo : string
cardNo: string I
{balance> creditUmil}
Figure 3: Typical OMT Class Diagram

3.3.1.2. Dynamic Modeling
It describes the system behavior by means of two types of diagrams:
• Event traces: they describe scenarios the system should provide. Scenarios are made
of class instances and exchanges of events. This is similar to the use case modeling
defined by Jacobson (event traces are interaction diagrams).
• State transition diagrams: they describe the system in terms of state machines. The
graphical notation used in OMT is based on the Harel Statecharts. Only concurrent
objects are concerned by this modeling technique.
3.3.1.3. Software Design

Only class diagrams are used at this step. Classes are refined, and inheritance links are
introduced for reuse purposes. New classes are added for implementing management of
persistent data, user interfaces or complex algorithms.
3.3.2. The MSC Notation

The MSC (Message Sequence Chart) formalism is described in Z.120 ITU-T
recommendation [MSC92]. It has been defined to complement SDL for specifying
system behavior. It is used both by analysts for specifying the behavior expected at the
system level (similar to use case modeling and OMT event traces) and by designers for
specifying the behavior expected at system object level (equivalent to the definition of
unit and integration test sequences).
3.3.2.1. Structure of MSCs
The dynamic modeling at the system level is carried out first by identifying the
expected scenarios, then by detailing these scenarios by means of chronologies of
interactions (unitary MSCs). The combination of MSCs to form a more complex
scenario is defined through predefined operators: sequence, alternative, parallel and
repetition.
3.3.2.2. Unitary MSC
A unitary MSC is formed of a set of instances and a set of interactions exchanged
within these instances. At the analysis step, instances correspond to the system and the
actors (Figure 4). At the design step, instances correspond to objects forming the
system and the interactions correspond to messages exchanged within these objects and
the environment. Detailed real-time constructs can be added such as timers and creation
and deletion of instances (Figure 5).
Max TLS02 YeUowCard
I Customer I I ATM
I lConsortiumJ
cardlnserted(card) ....
r
!J enterPassword
passwordEntered(7628)
r authorizeCard(card,7628)
IYI/lonzeeardResult(card,762s: )
selectOperation r'
,
.I
Figure 4: Analysis MSC

46 CHAPTER 3
7256
Figure 5: Design MSC
3.3.3. The SDL Notation

The SDL (Specification and Description Language) formalism is described in Z.lOO
ITU-T recommendation [SDL92a]. It has been created for describing the architecture of
distributed systems and for designing their behavior in the form of finite state machines.
It involves asynchronous point-to-point communication. Also, SDL includes the usual
00 genericity and inheritance features. Lastly, as SDL is formally defined, such
descriptions can be simulated and executable code generated.
3.3.3.1. System Architecture
This is defined by means of a hierarchy of elements (usually blocks), the root being the
system. The architecture obtained is then very modular, as sub-elements cannot directly
access external elements. The architecture is complete when the terminal level is only
composed of processes.
3.3.3.2. Description of the Communication
Communication between the system objects (blocks, processes, etc.) is described by
means of interconnection diagrams (Figure 6). Channels between dialoguing objects must
be created with their list of authorized messages. Children objects communicate with the
environment through channels connected to their parents (modularity criterion).
Object-Oriented and Real-Time Techniques: Combined Use ojOMI', SDL and MSC 47
ystemATM
1
[ cardln.8Itod] [~wafJo~a1]
spitCardOul
CardReadef
ButhOrizeCBrd
authorizeWilhdrawal
ackWithdrawal [CBShT'ken]
getBalanC6
[dispenseCash]
1
LogBook. report X25Unk CashBox [u ••reard]
userlnput
Central
[uthor~.cardR.sun
authorizeWithdrawalResult
Manager
[diSPlay]
CashPoint
Customer
getBalanceResutt Screen
dumpLogBook
cleanLogBook
Ke"" rd
[userlnp:] ~enabIeK.yboard]
inhibit Keyboard
Figure 6: Typical SDL Interconnection Diagram

3.3.3.3. Description of the Dynamics
The terminal level of the SDL hierarchy is formed of processes. A process is a
concurrent object described by means of a finite state machine. A mailbox (or queue)
stores the received messages. Compared with other methods like OMT, Booch, ROOM
or Shlaer-Mellor, SDL includes a complete set of graphical constructs for detailing the
actions performed when a message is consumed: message output, decision, assignment,
procedure call, timer set and reset, instanciation of brother objects, etc. (Figure 7).
( TRUE ) ( FALSE
~
(
mour:
TRUE )(
}
Figure 7: Partial SDL Process Diagram

3.3.3.4. Data Description
Processes also manage local data. Data can comprise complex types and operations can
be associated to them. Complex data is declared by means of Abstract Data Types
(ADT). ADTs are equivalent to passive classes. They are also a means for
encapsulating external components which are not described in SDL.
48 CHAPTER 3
3.4. INTRODUCTION TO A COMBINED USE OF

OMT, MSC AND SDL
3.4.1. Positioning of the Three Notations in the OORT Process

For a given stage of the application development, choosing between OMT, MSC and
SOL depends, first, on the current phase of the engineering process and, second, on the
nature of the software parts to be studied.
In the requirement analysis phase, OORT recommends a combined use of OMT for
object modeling and MSC for dynamic modeling. MSCs are created to specify the
interactions scenarios between the system and the actors modeled as classes in the
OMT model.
The architectural design is made by means of SOL interconnection diagrams. In parallel,
MSCs are created by refining the analysis MSCs according to the identified architecture.
Behavioral design
SDL process diagrams
Figure 8: Overview of the OORT Engineering Process

Once the architecture is complete, the terminal concurrent objects are described in the
form of SOL processes. Passive objects identified during the analysis phase and those
Object-Oriented and Real-Time Techniques: Combined Use oi0MT, SDL and MSC 49
identified during the architectural design phase are detailed by means of design class
diagrams. New classes are added to solve implementation issues.
The implementation and testing activities are greatly automated by exploiting the
models and descriptions produced in previous phases.
Figure 8 presents the general positioning of OMT, MSC and SDL within the generic
OORT engineering process.
3.4.2. Requirement Analysis with OMT and MSC

3.4.2.1. Problem Modeling with OMT
The use of OMT at this stage is limited to class and instance diagrams, the dynamic
modeling being carried out by means of the MSC notation.
Instance diagrams allow us to present objects of the system in particular operational
situations, like initialization or shutdown. Objects are then classified by means of class
diagrams.
Classes created in analysis can represent: physical entities of the system environment
(corresponding to actors), physical entities included in the system (architectural
constraints), or information exchanged between the system and its environment. Classes
are also introduced to represent concepts which are commonly accepted in the system
domain.
A widespread error is to introduce assumptions on the system architecture at this step.
How the system works should be tackled in design phase only. Analysis classes must
be relevant in the problem domain. This way, they can be reused in similar contexts.
Attributes and operations are added in the classes for capturing the exchanged data and
the expected services. Associations can represent physical supports, like a network
connection, as well as logical dependencies like the employer-employee relationship.
Multiplicities are added, as well as class roles if needed for clarification purpose.
The object model is complete when all the requirements in terms of exchanged data,
expected services and access to data and entities are supported in the model.
3.4.2.2. Dynamic Modeling with MSC
Requirements related to the system dynamics are captured through MSCs. An initial
step is to identifY the scenarios expected from the system, then they are refined, and
unitary MSCs are identified. These MSCs are detailed by exploiting the object model
according to the following rules: entities in dialogue generally correspond to concurrent
classes in the object model (actors), interactions between these entities generally
correspond to class operations, and the data exchanged by these interactions generally
correspond to class attributes.
3.4.2.3. Transition to the Architectural Design
Concurrent classes identified in the object model will guide the building of the initial
system architecture. Messages identified in the MSCs will serve to define the
communication at the first hierarchical levels.
50 CHAPTER 3
3.4.3. Architectural Design with SDL and Test Design with MSC
3.4.3.1. Refinement of the System Architecture with SDL
The initial architecture built with the analysis concurrent classes is refined according to
rules such as: consideration of existing operational architectures, constraints due to
interfacing the system with external hardware or software elements, making modular,
making reusable, etc. The refinement is achieved when all the identified terminal
elements can be described by means of independent finite state machines. This implies
having a clear interface with its environment for each terminal element and no
dependency between terminal objects except through message exchange (e.g. there are no
common variables or states which are interrelated).
3.4.3.2. Description of the Communication with SDL
The communication is described by means of interconnection diagrams. At the first
levels, it comes from the analysis MSCs. Nevertheless, there is not necessarily a total
equivalence between MSC messages and SDL messages (called signals in the SDL
recommendation). Some messages seen in analysis MSCs can be implemented in the
SDL architecture in the form of ADTs, or even in the form of a more or less complex
protocol designed by a set of SDL blocks with its associated set of internal messages.
During the refinement process, new internal messages are introduced; they have no more
correspondence with the messages seen in analysis.
3.4.3.3. Description of Test Sequences with MSC
While building the system architecture, it is recommended to refine in parallel the
analysis MSCs. Design MSCs specify at each intermediate level the interactions
expected between the internal objects composing the system at this level. The upper-
level MSCs form the "contract" which must be respected by the lower level in the SDL
hierarchy. Thus, when the refinement process is achieved, the designer possesses a
complete set of test sequences describing the expected behavior at the terminal level.
3.4.3.4. Transition to Detailed Design
In the final architecture, all the concurrent objects are identified, as well as some passive
objects, those ones corresponding to data exchanged through messages.
3.4.4. Detailed design with SDL and OMT

Detailed software design is performed using SDL and OMT to describe:
• terminal concurrent objects by means of process diagrams, and
• passive objects by means of class diagrams.
3.4.4.1. Design of Concurrent Objects with SDL

Terminal concurrent objects are the leaf elements in the SDL hierarchy. They are
described by means of SDL process diagrams. Their expected behavior is specified by
the terminal design MSCs. This behavior is implemented by using the graphical SDL
constructs: state, input, output, etc. Complex data processing appears only in the form
of operators of abstract data types.
Object-Oriented and Real-Time Techniques: Combined Use of OMT, SDL and MSC 51
3.4.4.2. Design of Passive Objects with OMT

Passive objects come both from analysis class diagrams and from ADTs declared in the
SDL description. These initial passive objects are refined into more detailed passive
objects in order to simplify the implementation of the class operations. Usually,
passive objects correspond to data management (e.g. through database systems),
sequential algorithms (e.g. mathematical algorithms) or wrapping objects (e.g. software
interface of physical elements).
The set of test sequences built during system design can be completed if needed when
performing the detailed design activity.
3.4.5. Implementation Activity

Building the final application requires the various outputs of the design activity.
Figure 9 illustrates how to build the application before implementation on the target by
using: the physical architecture, SDL design, OMT classes, possibly user-provided
code. MSCs can be used for testing purposes, as detailed in the next section.
,
r:tJ ~~ t3 00 ~
e
""(It)
C/C++ Application Application
~ Testing
Figure 9: Application Building

When targeting, developers transform the software design into executable code, integrate
the characteristics of the operational environment and apply the resulting code to the
target system. The targeting activity includes the following steps:
• Generating the SDL dynamic semantics using the SDL run-time library (SDL RTL)
and, when required, the RTOS (Real-Time Operating System).
• Translating the ADT definitions into the corresponding function declarations, then
implementing the ADT operators by translation of the object model. User-written
source code is also added here.
• Translating the SDL processes into fully executable code to form the bodies of the
RTOS tasks.
• Mapping the concurrent objects onto the physical elements of the target system.
52 CHAPTER 3
The structure of the code generated is detailed in Figure 10. The generated application is
based on the SDL run-time library. Optional user-provided code can also be integrated
as tasks that are external to the generated application. It can use the SDL RTL, the
RTOS or the hardware directly, this code being dynamically integrated at run-time. In a
distributed configuration, inter-node communication can be based on the TCP/IP
protocol.
TCP/IP
Hardware
• Generated C code ~ SDL Run-time library m User-provided Code 0 RTOS Task
Figure 10: Generated Application in a Distributed Configuration

Using appropriate tools allows us to automate the translation of the SDL and OMT
descriptions into code executable on the target RTOS.
A notation like SDL really improves portability and scalability, the key issues in real-
time development, thanks to the automatic code generation it provides and to the SDL
RTL, which makes the generated application independent of the target architecture.
3.4.6. Testing Activity

The testing activity consists in verifying and validating the application actually
implemented, first on the development site, then on the real target system.
Whatever the engineering process used for the project (V -life cycle, iterative process or
another), the final system implementation is obtained according to the following
bottom-up pattern:
• Software modules are tested independently by running the unit tests;
• The separately tested software modules are progressively integrated, and the
resulting software goes through the integration test cycle.
This two-step procedure is generally not performed in strict chronological order. It is

possible, for instance, to test a number of selected software components, integrate them
and test the result, then test more new software and integrate in the current version of
the code.
Object-Oriented and Real-Time Techniques: Combined Use ofOMr, SDL and MSC 53
Testing is over when all the software pieces have been integrated and tested. The
resulting application must then pass the acceptance tests to be agreed by the system
customer. Generally speaking, acceptance tests do not take the system architecture into
account. They are focused on the functions provided by the actual application and on
the quality and performance of the system (i.e. robustness, efficiency, safety, security,
etc.). Acceptance tests rest mainly on the use case modeling elaborated in the
requirements analysis phase.
The role of OORT in testing activity is restricted to transforming into executable tests
(concrete tests) the tests defined in parallel to application design (abstract tests). OORT
can also be helpful for the analysis of test results. Basically, test results are analyzed to
appraise the actual quality of the implemented system. In OORT, such analyses can be
carried out at design level (i.e. assessments are applied to the SDL and OMT
descriptions). To sum up, OORT will assist in the testing process in two different
ways: first by helping to generate concrete tests from abstract tests, and second by
helping to analyze test results.
3.5. OORT AND THE CO-DESIGN

Some parts of a system are generally implemented in the form of hardware elements,
e.g. for performance purposes. We have seen earlier in this chapter how OORT helps
the designer deal with the software elements, and how the hardware characteristics are
considered at the targeting stage. Some works in relation to the OMT and SDL
notations have already been carried out to address hardware-specific issues also, like
[INS96] for example. The main idea is to have a unique model at the conceptual level
(expressed in OMT) or at the architectural level (expressed in SDL), which integrates
both the system part which will be actually implemented as software and that which
will be actually implemented as hardware. The hardware part of the model is then
transformed into VHDL code. Co-simulation now becomes possible: the software part
of the model can be simulated in parallel with the generated VHDL executed on an
appropriate hardware simulator. Hardware synthesis is also possible from the obtained
VHDL code. Another co-design approach including SDL for system modeling has been
investigated in [Ben95].
These R&D studies were started recently, and more solid results are expected in the
next two or three years. As these studies are based on the combination of OMT and
SDL, their findings could be integrated in the OORT approach.
3.6. CONCLUSIONS
OORT is a method consistently combining notations most suited for real-time
development. Rather than inventing new notations, OORT is based on industry-proven
standards in order to provide the analyst and designer with a complete solution covering
the development process, from requirements to implementation. This method also
provides a strong traceability throughout the development process thanks to a set of
consistency rules governing the transitions from phase to phase. In addition to this, all
54 CHAPTER 3
the included notations make reuse easier as they integrate 00 concepts such as
encapsulation, inheritance and genericity.
The coding activity is also greatly automated thanks to the formal basis of SDL. The
generated code is portable thanks to the SDL run-time library. A last benefit is early
validation of software architecture which can be carried out through SDL simulation.
Acknowledgements
The results presented in this chapter are partially based on work carried out in the
RACE II Project, ref. 2017, Service Creation in an Object-oriented Reuse Environment
(SCORE), and in the ESPRIT III Project, ref. 8641, INtegrated methods for evolving
SYstem DEsign (INSYDE). I would also like to thank Vincent Encontre, who was the
leader of this initiative, as well as all the ObjectGEODE team members for their efforts
to offer an industrial support to this methodology and Christophe Joubel for his
valuable remarks.
REFERENCES
The reference books of the methods OMT, Booch, Jacobson, Shlaer-Mellor and
ROOM are respectively: [Rum91], [Boo93], [Jac92], [ShI88]-[ShI92] et [SeI94]. An
introduction to OMT is available in [Rum95a], [Rum95b] and [Rum95c]. Regarding the
MSC and SDL formalisms, [MSC92] and [SDL92a] form the reference documentation,
whereas [SDL92b] and [0Is94] describe the practical use ofSDL and MSC for software
engineering. [Leb93] and [MiI95] are first investigations about the combined use of
OMT, SDL and MSC, and [Leb95] presents a case study. We will find also in [Cho95]
real-time extensions proposed for OMT.
As far as co-design is concerned, [INS96] and [Ben95] present particularly interesting
results in relation to OMT and SDL.
[Ben95] Ben Ismail T., Jerraya A. A., Synthesis Steps and Design Models for
Codesign, IEEE Computers, Feb. 1995.
[Boo93] Booch G., Object-Oriented Analysis and Design with Applications, Addison-
Wesley, 1993.
[Cho95] Chonocles M., Gillian C., Real-time object-oriented system design using the
object modeling technique (OMT), JOOP, Vol. 8 No.3, Jun. 1995, pp.
16-24.
[INS96] INSYDE Project, Methodology, P86411HUB/INF/DS/P/D1.31b2, ESPRIT
III publication, Jan. 1996.
[Jac92] Jacobson 1., Christerson M., Jonsson P., Overgaard G., Object-Oriented
Software Engineering - A Use Case Driven Approach, ACM Press,
Addison-Wesley, 1992.
[Leb93] Leblanc Ph., Enrichment of 00 Methods with Formal Description

Techniques for developing Real-time Systems, NATO RSG.03 Workshop,
The Hague, The Netherlands, 19-21 Oct. 1993.
[Leb95] Leblanc Ph., Practise OMT, SDL and MSC with a Case Study, 00lS'95,
Proceedings of the Industry Day, Dublin, Ireland, 18-20 Dec. 1995.
[Mi195] Milsted K., OMT Object Models of Telecommunications Services, IS&N'95
Conference, Crete, Greece, Oct. 1995.
[MSC92] ITU-T, Draft Recommendation Z120, Message Sequence Chart (MSC),
COM X-R 22-E, Geneva, March 1992.
[01s94] Olsen A., Faergemand 0., Moller-Pedersen B., Reed R., Smith J.R.W.,
Systems Engineering Using SDL-92, North Holland, 1994.
[Rum91] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W., Object-
Oriented Modeling and Design, Prentice Hall, Inc., 1991.
[Rum95a] Rumbaugh 1., OMT: The object model, JOOP, Jan. 1995.
[Rum95b] Rumbaugh 1., OMT: The dynamic model, JOOP, Feb. 1995, pp. 6-12.
[Rum95c] Rumbaugh J., OMT: The functional model, JOOP, Mar.-Apr. 1995, pp.
10-14.
[SDL92a] ITU-T, Recommendation ZJOO, Specification and Description Language
(SDL), COM X-R 17-E, Geneva, March 1992.
[SDL92b] ITU-T, SDL Methodology Guidelines, Appendix I to the Recommendation
ZIOO, COM X-R 21-E, March 1992
[Se194] Selic B., Gullekson G., Ward P., Real-Time Object-Oriented Modeling, J.
Wiley, 1994.
[Shl88] Shlaer S., Mellor S., Object-Oriented Systems Analysis, Modeling the World
in Data, Yourdon Press, Prentice Hall, 1988.
[Shl92] Shlaer S., Mellor S., Object-Oriented Systems Analysis, Modeling the World
in States, Yourdon Press, Prentice Hall, 1992.
4
INTEGRATED SYSTEM DESIGN
WITH AN OBJECT-ORIENTED
METHODOLOGY
E. P. Mariatos A. N. Birbas\ M. K. Birbas
i, i,
I. Karathanasis 3, M. Jadoul\ K. Verschaeve 5,

J-L. Roux D. Sinclair 6, 7•
J Formerly Univ. of Patras, now SYNERGY SYSTEMS S.A.

2 University of Patras, Greece
3 INTRA COM S.A
< ALCATEL Belgium
5 Free University of Brussels, Belgium
6 VERILOG France
7 Dublin City University, Ireland
ABSTRACT
The development of systems that integrate hardware and software components, using
Object Modelling and formal description languages is the aim of the INSYDE
methodology and toolsl. This chapter introduces INSYDE and shows how this
framework offers the designer an intuitive approach to system analysis and design as
well as a direct path to high-level validation and links to implementation. This is
achieved through the combination of the software-industry-standard OMT method with
the SDL language for software and VHDL for hardware, in conjunction with a system
co-simulation platform.
I This work has been partially supported by the INSYDE (ESPRIT 8461) project and a grand from
Intracom S.A. to University ofPatras.
57
58 CHAPTER 4
4.1. INTRODUCTION
As the complexity of electronic systems has been rapidly increasing, it has become
more and more difficult to efficiently treat the hardware and software parts of an
application as separate entities. Moreover, the demand for short time to market calls for
improved reusability of components [13] and for first-time correct methodologies. This
has resulted in the requirement for advanced and integrated design methodologies, which
can handle the development of large complex systems from specification to end
implementation and are widely known by the term "Hardware/Software Codesign"
[1,2,3,4,5,6 etc.].
In the domain of Software Engineering, the increase of complexity has been successfully
handled by the introduction of a new modelling paradigm that replaced/enhanced older
methods like functional decomposition and structured analysis [7]: the Object Paradigm.
Several researchers have proposed the application of Object Oriented principles to
hardware development [14, 15, 16] expecting to get significant benefits like better
control of complexity, increased reusability and improved design-data management.
Recently, the value of an object oriented system specification notation for driving
hardware/software codesign has been realised and efforts are made towards this
direction [17, 2].
The development of a framework for hardware/software Codesign, has been the target
of INSYDE [9, 18]. INSYDE was a project funded by the European ESPRIT
framework. It involved companies from the tools domain (VERILOG), users of the
produced Codesign technology (ALCATEL, INTRACOM) and universities (Humbold
University of Berlin, Free University of Brussels, Dublin City University) that
supported the methodology. The project terminated successfully in March 1996 with a
one-day workshop. The results of this project are presented in this chapter.
The main points proposed by INSYDE can be summarised in the following:
• Introduction ofOMT*, a variant of the well-known OMT method [11] for system
analysis, which aspires to become a successful Object Oriented system specification
notation for Codesign.
• Use of OMT* as input to SDL and VHDL translators, providing the INSYDE
framework with a viable path to implementation; a weak point in other high-level
system development frameworks.
• Cosimulation of hardware and software before and after translation to SDLNHDL.
The ability to simulate an OMT* model and verify the system after it is has been
partitioned gives the designer confidence and eliminates major redesign loops.
INSYDE has not proposed automatic partitioning in SW and HW. Instead, it leaves this
part open for the designer to use hislher experience, or for a future tool [12] to be
embedded in the framework.
Two systems that validated INSYDE's applicability during the development of the
framework are a Video on Demand server and a chip-set for image reconstruction. The
diversity of the domains shows the wide area covered by the methodology.
Integrated System Design with an Object-Oriented Methodology 59
The chapter is organised in eight sections. Section 4.2 outlines the INSYDE
methodology and is followed by three sections that describe the three steps of INSYDE
development: Analysis, design and code Generation. The tool-set that supports the
methodology with editing and simulation tools is presented in Section 4.6. Section 4.7
presents two applications that have been used as benchmarks for the framework, and
the chapter concludes with Section 4.8.
4.2. METHODOLOGY OUTLINE

The INSYDE methodology is built around three powerful description methods: OMT,
SDL and VHDL. The abstract, non-executable, free style ofOMT modelling is linked to
the detailed, formal syntax of SDL and VHDL through OMT*, an OMT dialect
(variation) proposed in INSYDE for system description. In the following paragraphs,
the methodology is outlined and the specific notationsllanguages are discussed.
4.2.1. The Basic Elements of the Methodology

In Figure 1, the INSYDE methodology is shown. The various phases, the produced
models and the supporting tools are indicated.
Figure 1: The Complete INSYDE Methodology

The analysis phase, which produces the analysis model, is a typical OMT procedure
that starts from user requirements and rough knowledge of the problem to identify
major objects, roles, associations and restrictions. By converting this model to a specific
system description, the design phase shifts emphasis from conceptual analysis to
specification. Various "design" decisions are made at this step like e.g.
Hardware/Software partitioning, architecture selection etc.
60 CHAPTER 4
The rest of the INSYDE methodology is more-or-Iess automated. Software objects are
described in SDL while VHDL code is generated for hardware entities. The detail of the
produced code depends on the degree of refinement of the OMT* system model.
INSYDE allows for modifications and enhancement of SDLNHDL descriptions in a so-
called "detailed design" phase, but extra care has to be taken to prevent those changes
from creating inconsistency with the previous models; INSYDE tools do not
automatically trace design consistency at this point. INSYDE stops at the point where
SDL and VHDL are co-simulated. Further development of software is possible through
C or C++ generation from SDL. On the hardware path two options exist: either use
some behavioural synthesis tool or re-generate VHDL using a different set of translation
rules that produce synthesizable descriptions.
4.2.2. The NotationslLanguages

As already mentioned, the Object Modelling Technique [II] is the notation used for
analysis and (through it's OMT* derivative) for system design. OMT models contain
three types of diagrams.
The class diagram is a representation of classes, linked by associations or through
inheritance and aggregation links. It is the starting point for all the models since
everything has to refer to objects derived from classes shown in it.
The state-transition diagrams model the behaviour of the system and its objects.
Various states, actions and conditions are expressed, as well as transitions and the
events that trigger them.
Functionality is depicted in the data-flow diagram. A weak point of OMT (due mainly
to its loose connection to the other two diagrams) is the data-flow diagram which
consists of processes, actors and data stores that are connected with flows of data. To
improve data-flow representation, proposals to merge this diagram with instance
diagrams (an instance-specific view of class diagram) have recently been made.
OMT is very informal, but (or probably because of that) it is also very intuitive, and is
therefore well suited for conceptualising the problem. However, when the designer
wants to be more specific, this freedom of expression must be restricted. Thus, OMT*
has been introduced [23]. The main restrictions imposed on OMT by OMT* are the
following:
• Inheritance and Aggregation have precise semantics. An inherited class derives all the
attributes and operations of the parent. Inheritance flows only from more abstract to
less abstract descriptions (no "generalisation" inheritance concept is supported).
• Associations represent control or data-flow links. Other types of links are either
ignored or represented through inheritance and aggregation structures.
• Classes are either active or passive. A class with a state-transition diagram is active.
• All objects are contained in a "System" object. This aggregation relationship is
implicit and is not shown in any diagram. Other similar aggregations (e.g.: "Hardware
Part") have to be explicitly modelled.
• Inheritance of behaviour for active classes is limited. Only addition of new
operations (without altering the rest of the state diagram) can be supported.
• Data-flow diagrams are not a part of OMT*. They are allowed as "NOTES" that
clarify the model. Data-flow connections are represented on the class diagram by
attribute naming (an attribute can be IN or OUT, writing or reading to another
attribute with the same name in another class).
• Data types, events etc. have to be declared on the class representation.
To summarise, an OMT* model is a hierarchy of connected objects, each object having

its own state-transition diagram. This structure ensures that an OMT* model is a
consistent specification for the system, which can be readily partitioned in hardware
and software and translated to SDL and VHDL.
The two languages ofINSYDE (SDL,VHDL) do not need any special introduction. SDL
is the ITU-T standard for specification description [8] and has been widely and
successfully used for high-level description of telecommunication systems.
Furthermore, after it's last (1992) enhancement [10] SDL supports 00 features like
inheritance. If inheritance and hierarchy are flattened, the underlying paradigm of SDL is
a number of communicating processes, each of them containing a state machine. Various
methods for exchanging messages through channels and queues are supported.
VHDL has been an international standard for hardware specification since 1987 [19].
Apart from specification, VHDL has found extensive usage for hardware synthesis.
INSYDE views VHDL at two levels: At the simulation level, it generates high-level
behavioural code, while (at the synthesis level) a second set of rules has been proposed
that can directly create synthesizable code. The reason for this scheme is that
synthesizable VHDL is too complex to Co-Simulate with SDL in reasonable times.
4.3. ANAL YSIS USING OMT

INSYDE proposes a development approach that has it's origins in software engineering.
As with software application development, the first phase (and probably the most
crucial) is the conceptualisation of the problem to be solved. The user's needs and
requirements are correlated with the relative knowledge base to produce a number of
very informal models; i.e. a set of sketches that outline the main entities of the system
to be designed and their roles and associations. In many cases, traditional co-design
approaches consider analysis outside the scope of research, focusing more on
partitioning, design representation and co-simulation. In practice, analysis is necessary,
since the most important requirement is that the system "works". And the word
"works" expresses the need for a system that meets the market needs.
The analysis procedure proposed by INSYDE is based on the Object Modelling
Technique [11] . In brief, the steps required to capture the conceptual model of the
system are:
• Problem Statement: A known-to-be-wrong statement of the problem as. the user
describes it. While that statement is completely informal, with many requirements
implied, with many requirements posed by some implementation that the user has in
mind, with many incomplete or badly expressed definitions etc., it is still the best we
can get as a starting point. And it is better to know that we start from something that
may be wrong (and try to correct it) which requires that the user provides us with a
62 CHAPTER 4
correct description (what the user will more probably say when the end system was
not exactly as he wanted it to be is: "you should have corrected me if I was wrong").
• Use Cases: This is a method for experimenting with the initial problem statement.
Use cases are generalised scenarios, which help us identity what the system should
be and how it should respond to external events. There are some notations for
expressing use cases in software engineering. INSYDE judged that it should not
select one of them but rather allow the designer to apply any technique (including
simple informal text).
• Identification of Objects and Classes: The analysis produces its first results as the
various objects that compose the system are identified. In [11] Rumbaugh proposes
some guidelines for finding classes in the problem statement, but it is more likely
that after hislher first few modelling efforts the designer will know better how to do
this.
• Modelling: Usually modelling refers to a formal procedure where the system is
described and simulated. But this is modelling of precise specification. When we
need to model abstract requirements, it is more important to present the results of
analysis in a manner that is as clear and as implementation-independent as possible.
The OMT notation is used by INSYDE to describe these models.
We have already talked about OMT in the previous section; a complete description of
the technique can be found in [11]. The following figure shows the basic elements of the
notation used in class diagrams.
Class Name Class Name
S·
associatio
Atrtributes Atrtributes
l .4
Operations Operations
---'~" .. ~.'
/\ ii.....,-""·~Ii
(Multiplicity) :
I(inheritance) L_rc~~. _j . ( Instantiation)
2-4,8 (aggregation
Class Name
Instance
Atrtributes
( Class Name)
Operations Attribute Values
Figure 2: Basic Notation for OMT Class Diagram

An analysis model can have as many class diagrams and as many dynamic and data-flow
diagrams as required. There is no restriction imposed by need for consistency or
completeness. Thus, a system's analysis model may have several views, and classes of
one view can be associations of other views. For example if we model a communication
protocol stack, it's services can be viewed as classes at each layer describing multiple
ways to feed data into this layer from higher layers, while they may also appear as
associations that link the various data-units from different layers when some specific
use of the protocol stack needs to be modelled.
There are some requirements that are not possible to be captured in OMT since it was
originally intended to be used for software systems. Such requirements, like speed or
cost, and others like "reuse this component because we already have it" or "we need
this part to be difficult to copy for our competitors", have not been ignored by
INSYDE. A special notes scheme has been developed, that adds in every class and in
every action three optional notes fields: Speed, Cost and Misc. These notes are used in
the following design phase to guide partitioning and system architecture. They may
even be carried down to translation to instruct the generator tool to select a rule for
"high-speed" or "small size".
There are some features of the system that should not be included in the analysis model,
especially those that imply some specific implementation. For example, the designer
must be careful not to include:
• Controller classes. The controller is part of the solution, not the problem. If the user
thinks that a central controller is needed he could simply have missed (failed to
examine) the case of local control for each object. If a central control unit is really
required, this will become visible in the analysis model by a "strong" global dynamic
model.
• Decisions on whether a class will be instantiated in software or hardware.
• Communication protocols between objects. At the analysis phase, objects need only
to exchange data. The specific ways for this exchange are to be decided later.
In conclusion, the analysis mode is a graphical form of the "non-executable-English"

where system design starts from. The task of the next phase is to convert this· model
into an "executable" form, adding implementation decisions, like hardware software
partitioning and system architecture definition.
4.4. CREATING A SYSTEM MODEL WITH

OMT*
The design phase uses the analysis model as input material to which it has to add form
and functionality. The classes of the conceptual analysis model must be modified, split
in groups and possibly combined in super-classes. The behaviour must be allocated to
objects since there is no stand-alone behaviour in the system specification and someone
has to generate it. Data flows between objects must be specified as links between ports
on each object; the functions inside each class will know how to handle them only
locally.
Design (at the notation level) is the transformation of OMT to OMT* (The basic
differences between the two notations were discussed in Section 4.2). An OMT* model
is a hierarchy of classes, as shown in Figure 3.
To convert OMT to OMT*, the designer can follow his/her experience, or/and some
generic guidelines created by INSYDE. Some of these guidelines are:
• Categorise objects as "Passive" and "Active". Passive objects are more likely to be
implemented as memory or signals of a specific complex type.
64 CHAPTER 4
• Active objects can be further categorised as having "Control" or "Functional"

complexity, based on whether they have complex or simple state-transition
diagrams.
• If an object is both "Control" and "Functional" or if it is Active and needs data
storage, it may be worth breaking it in two or more objects.
• Try to find "patterns" in the models. Example patterns are "Client-Server", "Bus-
Controller" etc. It is easier to find an implementation for known patterns than for a
structure that is met for the first time.
• Experiment with some initial HW-SW partition before taking communication into
account. Then find the created communication overhead. (This could be reversed:
partition according to communication; then try to optimise each part by moving
objects to HW or SW).
• In some cases, it may be necessary to create a first OMT* model before partitioning
that will be simulated to find paths that generate delay or errors. Partitioning will
then be guided by the results of this simulation.
System
connectedb
Class
Ports
Inheritance
State Diagram
Figure 3: Structure of an OMT* Model

Various levels of refinement of the system model will be required. The two main
mechanisms for refinement are: Hierarchy (specified as aggregation) and Abstraction
(specified as inheritance).
• Hierarchy groups classes in super-classes through aggregation. A class that is
described at some level can be refined by breaking it in a number of smaller ones that
undertake different parts of the functionality and the behaviour.
• Abstract classes at one level can be refined if a new class that adds more detail to
their content is derived. Inheritance ensures that the effort for modelling the parent
class will not have to be repeated, only new features need to be modelled.
In a complex system, some parts may be reused from previous designs to save design
and manufacturing cost. INSYDE supports reusability in both ways:
• From existing designs to a new one. In this case, existing models ofVHDL entities or
SDL blocks can be converted to OMT*. Although INSYDE has proposed ways to
achieve this reverse translation, no tool has yet been developed.
• Making objects in the design reusable. This is accomplished by the correct use of
inheritance. A class is reusable by itself since it encapsulates all the attributes and
operations that characterise it. However, abstraction allows us to re-use parts of a
design that are not exactly the same in the two models. A great improvement of
reusability will be achieved when multiple inheritance is added to OMT* (the
current definition supports only single inheritance mechanisms).
When the system model has reached the required level of refinement, it can be used to
generate the separate specifications for the software and the hardware parts. In the next
section, the generation of SDL and VHDL for the two parts is discussed.
4.5. PATHS TO IMPLEMENTATION:

SDLANDVHDL
4.5.1. SDL for Software

INSYDE has proposed the use of SDL for the specification of the software parts. SDL
has been successfully used in the past for the development of telecommunication
systems. With the latest version (SDL 92) object oriented features have been added.
Some research works [4] propose the use of SDL not only for the software but also for
the hardware part of a Codesign methodology. SDL can indeed be a very good notation
for describing systems that are based on the Communicating Sequential Processes (CSP)
computation model. However, SDL has very limited (or not at all) features to support
the description of a system's data flow and functionality. Although this is sufficient in
software development (in this case functionality can be added later, in C or C++) most
hardware components cannot be described in sufficient detail without the use of such
constructs (which are available in VHDL). In [4,24] this part of a system specification
is added in C, VHDL or some other language. This approach limits the solution space of
the designer since processes described in C are usually biased towards software
implementation and those described in VHDL are committed to hardware 1.
Translation of OMT* to SDL is a rather straightforward procedure. If SDL'88 is the
target, then inheritance links have to flattened, if SDL'92 is required then inheritance
need not be flattened since SDL'92 supports this feature as well as some other object
oriented concepts. The SDL generation algorithm can be outlined as follows:
I A combination of INSYOE with those approaches is a very interesting idea that should be further
explored: OMT and OMT* could be used for analysis and design, the complete system can be translated
to SOL (where behavioural simulation can take place even before partitioning) and the processes can be
internally described in VHOL (using a subset of the INSYOE translation rules) or C (using existing
translators) depending on their implementation target. Some incompatibility of semantics as well as
some tool integration problems have to be solved before experimenting with this alternative.
66 CHAPTER 4
1. IfSDL'88 is used: Flatten Inheritance

2. Find any links that are hidden in aggregation trees and bring them up, through
containing objects, so that the corresponding channels can be created.
3. Implement Aggregation trees as block hierarchies, with "leaf' objects converted to
processes.
4. Create channels that allow blocks and processes to exchange messages. The channels
to be created are determined by links on the OMT* class diagram or by the events
that are found in the OMT* state-transition diagrams.
5. Within each object, flatten the state diagram and generate an SDL state machine that
corresponds to this diagram.
To implement the details of this procedure, a number of "Algorithms"

(flatten_inheritance, find_hidden_Iinks etc.) and a set of "Rules" (SDL92--process,
SDL88_transistion etc.) have been defined. For instance, the translation rule that
generates blocks for SDL'88 is:
Let c = (id, st, V, 0, s, G, sd) be an OMT* class, such that
- Attributes(c) = {vl, ... ,vk}
- operations(c) = {ol, .... ,ol)
... etc.
then sdl-class(c) is constructed by
block<id>;
substructrure
signal sdl-event-declaration(ev I ), ... ,sdl-event-declaration(evp);
block <gl> referenced;
block <id>-intem;
process <id>-process;
del <sdl-attribute(vl»;
<sdl-operation(0 I »
<sdl-state-diagram(sd,Attributes(c))>;
endprocess <id>-process;
endblock <id>-intem;
endsubstructure
end block <id>;
Software implementation after the SDL step, is supported by SDL to C and SDL to
C++ translators which are available as commercial tools. The SDL to C path is a mature
process, that can support features like interrupts (not readily supported by SDL), Real
Time Operating Systems (RTOS), code optimisation etc.
4.5.2. VHDL for Hardware

For the hardware path of the INSYDE methodology, the VHDL language has been
chosen. Since it's first standardisation VHDL has gained a large part of the HDL market
(actually, together with Verilog, they are the only tool-independent hardware
description languages). Although VHDL was not defined to be a formal language in the
strict mathematical sense, it is certainly more exact than OMT. As with SDL, VHDL
has been proposed as an input specification language' for system design. However,
mainly due to the fact that it does not have specific constructs for describing behaviour,
system-level VHDL models tend to be rather complex, with explicit description of the
communication and synchronisation schemes. VHDL is ideal for data-flow systems, or
systems where a number of processes communicate through zero-transmission-delay
messages. But, when messages line up into queues, when processes have to be created
and destroyed and in cases where control is the main part of the application, VHDL is
too weak.
To generate VHDL, a similar approach with this used in the SDL case is followed. The
procedure is supported by a number or algorithms and two alternative sets of rules 20].
One set of translation rules aim to the generation ofVHDL for simulation and produces
fast, high-level code while the other targets synthesizable VHDL and produces code
that describes a synchronous, detailed implementation of the system's hardware
components. The basic guidelines followed by the translator are:
1. Each active class is converted to a VHDL entity. By the term active, we refer to the
classes that have dynamic behaviour (a state-transition diagram).
2. The architecture of each component consists of one main process that models an
extended state machine, and a number of smaller processes and functions that
correspond to the actions performed by the object.
3. Signals, ports, etc. are created according to the events and the data-flow attributes of
each class.
4. Instantiation of objects in other objects (aggregation) is coded as PORT MAP
statements. The port mapping is determined by the names of the classes attributes.
5. As with SDL'88, VHDL also needs flattening of OMT inheritance since the
language does not support such a feature.
The following example, is the translation rule that converts passive classes to VHDL
types.
Let c = (id, st, V, 0, sc, G, sd) be a passive class, such that:
- Attributes(c) = {vl,... ,vk}

- operations(c) = {ol, .... ,ol)
... etc.
1 Recently, discussions and research projects [25, 26, 27, 28, 29] on Object Oriented extensions to
VHDL have also proposed the addition of behaviour constructs, as well as means to describe the life-
cycle of a process or a component. Such an extended version of VHDL could include many of the
characteristics required by a system specification language for Hardware Software Codesign.
68 CHAPTER 4
then vhdl-data-type(c) is constructed by:
TYPE name(c)record IS RECORD

<vhdl-parameter(vl»;
END RECORD;
<vhdl-data-type-operation(0 1,c»;
The path to end implementation initially proposed by INSYDE is that of VHDL

synthesis. However, this seems to limit the applicability of the method to only one
target architecture: One processor and a number of ASICs and memory chips. INSYDE
is not actually so limited. Many alternative architectures can be modelled and the
VHDL code can correspond to custom hardware whether it is an ASIC that works off-
line (on the same data as the processor) or a customised extension to the processor's
instruction set. This procedure of architecture selection, and the corresponding
implementation path for hardware can be found in more detail in [12]. The basic idea, is
that for each target architecture, we built an OMT* model of the corresponding
architecture pattern. Selection is made by mapping the application's OMT* model on
the various patterns to find the best match.
4.6. THE INSYDE TOOLSET

The tools that support the INSYDE methodology belong to three categories: editing,
generation and simulation tools. Some of them are existing commercial products,
suitably adapted to include new features required by INSYDE. Others are in a
prototype form, validated through a number of small case studies and demonstrated
through two industrial applications. These tools include:
4.6.1. Tools for Editing

Editing is required to enter the system description and change/enhance/modify the
generated models at various levels.
The OMT editor which is used during analysis is not a simple design-entry tool. It is a
powerful application that helps the designer capture the system. The OMT editor has
to be able of allowing maximum freedom (so that the user feels as he is working on a
draft piece of paper) while maintaining links between the various diagrams. Features like
hidden classes, multiple views, links from the object model to the corresponding state-
transition diagrams of each class etc. are essential.
The same editor, must also be able of supporting the strict modelling style of the design
phase. When the system is specified in OMT*, consistence must be ensured. A special
checker that verifies that a design is OMT*-compliant and points out any parts that are
not-yet finalised, helps the designer to convert the conceptual analysis model to an
exact design model. An additional feature for OMT* editing is the support for pre-
defined notes that guide generation of SDL and VHDL.
Although SDL and VHDL are generated by automatic tools that follow specific sets of
rules, the produced OMT* specification cannot always be directly used for
implementation. For VHDL a common text editor can be used. SDL has a graphic
notation that can be alternatively used in place of (or together with) the textual
representation, therefore an SDL editor can significantly help, not only for modification
of the generated code but also for visualising the structure of the SDL model.
4.6.2. Tools for Translation

The current version of the INSYDE toolset uses prototype tools for the generation of
VHDL and SDL (A limited commercial version of the SDL generator also exists). The
translators (or code-generators) are embedded directly in the OMT* editor, as two
commands on the "Generate" pull-down menu (actually three commands since both
versions of SDL are supported - 88 and 92). For each generator, a dialogue box appears
that prompts the user to enter some options (e.g. selection of rule-set, output file names
etc.). New sets of rules can be added and new languages can be supported through the
editor's generation templates (G-templates).
4.6.3. Cosimulation
The system can be validated in two phases.
• At the System Level
At system level, the C and C++ code generation capabilities of the OMT* editor are
used to create a model of the system. Specific G-templates must be written since the
produced code is not oriented towards implementation but towards simulation. The
user interface of the system level simulation is very simple; the development of a more
user-friendly validation is still required.
• After Translation
After the generation of the SDL and VHDL models, the two parts can be simulated
independently using the corresponding SDL and VHDL simulators. Co-simulation is
performed by linking the simulators through a special Coupling Module. The coupling
module is implemented on a "software bus" and can support various synchronisation
schemes [30]. The timing model of the cosimulation can be as simple as the "zero-time"
approach that assumes instant cause-effect relationships between hardware and
software, or as complicated as a clock-model approach for both parts where neither
hardware nor software is allowed to increment it's local clock until all events and data
that should be exchanged are received.
4.7. CASE STUDIES

The INSYDE framework has been tested through the development of a large number of
small case studies that were used to examine the capabilities of the methodology and the
tools in handling various codesign problems. In addition to those small experiments, two
industrial systems have been developed, so that the strengths and weaknesses of
INSYDE can be identified in real-world cases. These two experiments, tested INSYDE
at what were initially identified to be its limits to the software and to the hardware
70 CHAPTER 4
sides. The first system was a chip-set that will be used for a specific image processing
task; a system which is hardware-oriented characterized by functional complexity and
an underlying data-flow computational model. The second, is a server for Video-on-
demand applications; a software-intensive system with a behavioural (state-transition)
underlying model.
4.7.1. An Image-Reconstruction Chip-Set

Within the context of this case study a chip-set for the reconstruction of damaged
images has been developed based on an edge-preserving smoothing algorithm which
applies the Markov Random Fields theory [21].
4.7.1.1. Description of the System.
The MRF system is going to be a part of larger image processing systems. The main
objects that construct it, are three image fields: One that holds the input image, another
that contains the points of discontinuities (edges) and a third which is used to store the
final reconstructed image. The three fields are accessed by two active objects: the edge
detector and a smoothing operator. The overall control of the system is handled by a
controller object.
4.7.1.2. Phases of Development.
"""....
""" "'"
x.r:A.w...sr
Cftl.. l1~
Wrir,,~)
I.-Jy;.t}
Figure 4: MRF System's Class and State Diagrams.

During the analysis phase, the main objects that construct the system were identified
and the basic control behaviour was produced. The outcome of analysis was an OMT
model which was converted to OMT* during design. The design phase started by
making some implementation decisions, like e.g. the decision to put the controller on
Software, the image fields on memories and the edge detector and smoothing objects on
specially designed chips. The OMT* description was then translated to SDL (for the
SW part) and VHDL (for the HW part). The two descriptions were refined with some
more detail and the first co-simulation ofSW and HW was performed. For SDL we used
the GEODE simulator from Verilog, while for the VHDL part we used the VHDL
simulator of Mentor Graphics (QuickVHDL). The connection between the two tools
was based on the Verilog Software Bus and on Mentor's BLMs.
4.7.1.3. Conclusions and Lessons Learned

Through this application, the INSYDE methodology has proven that the use of high-
level Object Oriented analysis and design is not suitable only for software applications
but can significantly aid the designer of hardware-oriented systems to capture the
requirements and sketch an initial architecture for the system. However, the proposed
approach and the developed toolset cannot replace lower-level procedures for high-level
hardware synthesis. The final level of HW description, and the produced VHDL code
are not synthesizable and therefore the development of the final ASICs has still to go
through a number of steps.
4.7.2. A Video-on-Demand System

This case study regards the development of a subsystem of a Video-on-demand Server
employing the INSYDE methodology [22].
4.7.2.1. Description of the System.
The developed subsystem handles video distribution (through the Video Server) and
service control (through the Video Server Control Station). The Video Server (VS) puts
the video streams on the network, and can be seen as a file-system containing a large
collection ofprograrnmes (movies). These programmes contain (multiplexed) video and
audio information and are stored in compressed form (MPEG-l) on digital storage
devices, and are 'pumped' into the network via a Media Control Board (MCB). The
VSCS receives programme play-back requests from individual subscribers and
subsequently initiates and controls the video-session (over semi-permanent A TM
connections) between the VS and the requesting subscriber.
Figure 5: The Complete Video-On-Demand System

72 CHAPTER 4
4.7.2.2. Phases of Development.

As described in previous sections, the main stages of INSYDE methodology are
Analysis, Design and Validation through SDL and VHDL. The result of the application
of these stages to the designed Video on Demand subsystem is described in the
following:
The major goal of the Analysis phase has been to get a thorough understanding of the
system under development, and culminates in an OMT model. The System Design
phase has resulted in an OMT* model, which has served as a starting point for Detailed
Design of hardware and software subsystems, respectively in VHDL and SDL88. The
transformation of the SDL and VHDL related OMT* descriptions into SDLNHDL has
been achieved by software tools as automatically as possible, with human intervention
where appropriate, and has resulted in a system description consisting of parts
described in SDL and parts described in VHDL. The detailed design of the target system
has been simulated by an SDL simulator (Verilog Geodesim) for the software
components and a VHDL simulator (Cadence Leapfrog) for the hardware. Both
simulators have been connected and validation of the system has proceeded through co-
simulation.
4.7.2.3. Conclusions and Lessons Learned.
The experience gained through this case study proved that INSYDE framework indeed
shifts some of the effort for efficient integration of hardware and software from the
implementation phase to the early design stages. More specifically, it has provided
some valuable advances for telecommunications systems development, mainly related to
the definition of OMT* as a viable system design language allowing a smooth transition
to lower level design work in SDL and VHDL. Moreover, although no concrete figures
can be provided for the reduction in resources consumption, the general impression is
that it was significant. On the other hand, users of the INSYDE technology must be
aware of its limitations and should be careful to apply it in projects that are well suited
to it.
4.8. CONCLUSION
The INSYDE framework is one of the first attempts to create a complete set of tools
and methodology for object oriented Hardware Software Codesign. It's major strengths
are:
• The OMT* notation, a high-level specification language for integrated systems that
is directly compatible with the industry-standard OMT technique.
• The system analysis phase, which is often overlooked by other codesign
approaches. An organised analysis step becomes crucial to the success of a project
as complexity of user requirements has increased.
• The usage of standard languages (VHDL and SDL) makes it easier to introduce
INSYDE in a development environment and minimises the risks of such an
integration.
• The INSYDE toolset is available now. Even if some tools are still prototypes, they
are completely functional and supported by a number of commercial tools.
Some weak points ofINSYDE are:

• Although INSYDE provides a direct path to implementation, this path is not
optimised for various target architectures and the designer has to specify the target
architecture (or select it from a "library").
• INSYDE wanted to be functional as a whole. Therefore no automatic
partitioning/architecture selection tools were included since they still are at a
premature research level.
• Some tools are still prototypes and some time may elapse before INSYDE is offered
commercially as a complete CoDesign solution. Anyway, compared to other
codesign frameworks INSYDE is quite advanced in this point.
In it's current form INSYDE cannot be introduced as a whole in a development

environment. It can rather be introduced gradually, starting from those parts of the
framework that are more valuable like analysis, OMT* or CoSimulation.
The future directions of work in this area are: Finalisation of the toolset so that it can be
usable by others (not just for members of the INSYDE project consortium). This
finalisation will include more reliable and user friendly translators and system
simulators. Better links to implementation is another topic where INSYDE can be
improved; the automatic mapping on various architectures or tools that provide
guidelineslhints to partitioning can be elements of this enhancement.
REFERENCES
[1] A. Sarkar, R. Waxman, 1. Cohoon, "Specification-Modelling Methodologiesfor
Reactive-System Design ", Current Issues in Electronic Modelling vol.3 (High-
Level System Modelling: Specification Languages), page 1-34, Kluwer
Academic Publishers 1995.
[2] J-P. Calvez, "A System Specification Model and Method", Current Issues in
Electronic Modelling vol.4 (High-Level System Modelling: Specification and
Design Methodologies), page 1-54, Kluwer Academic Publishers 1995.
[3] D. Gajski, F. Vahid, S. Narrayan, "A Design Methodology for System
Specification Refinement", Proc. EDAC 94, Paris, France, Febr. 1994
[4] T. Ismail, M. Abid, K. 0' Brien and A. Jerraya "An approach for Hardware-
Software Codesign ", IEEE Intern. Work. on Rapid System Prototyping,
Grenoble, France, pp.73-81, June 94.
[5] R. Ernst, J. Henkel and T. Benner, "Hardware-Software Cosynthesis for
Microcontrollers", IEEE Design and Test of Computers, pp.64-75, December
1993.
[6] R.Gupta , G.De Micheli, "Hardware-Software Cosynthesis for Digital
Systems", IEEE Design and Test of Computers, pp.29-41,
September 1993.
[7] E. Yourdon, "Modern Structured Analysis", Yourdon Press, 1989.
74 CHAPTER 4
[8] CCITTITU, "Specification and Description Language ", SDL,

Recommendation Z.1 00 (Blue Book) Geneva 1988.
[9] WWW page: ''http://info.vub.ac.be:8080users/isyde/insyde.html''
[10] O. Faergemand, A. Olsen, "Introduction to SDL '92", Computer Networks
and ISDN Systems, (26), 1994.
[11] J. Rumbaugh et al. "Object Oriented Modelling and Design ", Prent. Hall,
1991.
[12] E. Mariatos, M. Birbas, A. Birbas, N. Petrellis, "Object Oriented Prototyping
at the System Level", to be presented at RSP'96, Thessaloniki, Greece, June
1996.
[13] E. Girczyc, E. Carlson, "Increasing Design Quality and Engineering
Productivity through Design Reuse ",30th Design Automation Conference,
Dallas, 1993
[14] E. P. Mariatos, P. Merakos, M. K. Birbas, A. N. Birbas, "Hardware
Programming Using C+ +", Journal of Microprocessing and
Microprogramming (40) 1994, pp. 817-820
[15] A. 1. Van den Hoeven, P. Van Prooijen, E. F. Deprettere and P. M. Dewilde
"A Hardware Design System based on Object-Oriented Principles ", IEEE
ISCAS 1991, pp. 459-463
[16] S. Kumar, H. Aylor, B.W. Johnson, W. A. Wulf, "Object oriented Techniques
in Hardware Design", IEEE Computer, June 94, pp. 64-70
[17] N.S. Woo, A.E. Dunlop, and W.Wolf, "CoDesign from CoSpecijication ",
IEEE Computer, pp.42-47,January 1994
[18] INSYDE (INtegrated SYstem DEsign, ESPRIT Project: P8641)
[19] IEEE, "IEEE Standard VHDL Language Reference Manual", 2nd Edition,
1991. Std 1076-1987.
[20] "Translation ofOMT* to VHDL: A Simple Case Study", Maciek Wasowski,
E. Mariatos, presented at the 1995 Euromicro Conference, Italy September
1995.
[21] J.A. Vlontzos, H.C. Karathanasis, and I.e. Karathanasis, "Fast MRF
Algorithms and Architectures for Image Restoration, Segmentation and
Cod i ng ", in Proc. of the Eighth IEEE Workshop on Image and
Multidimensional Signal Processing, Sept. 1993
[22] M. Jadoul, J. Peeters et. al. "INSYDE Deliverable D3.2.: Design of the
Telecommunications Application ", 1995
[23] INSYDE Document: "The Complete OMT*", Humbold University of Berlin,
1995
[24] R. J. O. Figueiredo, I. S. Bonatti, "An Algorithm for the Translation of SDL

into Synthesizable VHDL ", Current Issues in Electronic Modelling vol.3
(High-Level System Modelling: Specification Languages), page 99-110,
Kluwer Academic Publishers 1995.
[25] G. Schumacher, W. Nebel, "Inheritance Concepts for Signals in Object
Oriented Extensions to VHDL ", Proc. Of EURO-DAC'95 with EURO-
VHDL'95, IEEE Computer Society Press 1995.
[26] B. Convot, D. Hurst, S. Swamy, "OO-VHDL Extensions to VHDL", IEEE
Computer, October 1995.
[27] E. Mariatos, J. Kikidis, "Hardware Object Description Language
Extensions", Report available from Synergy Systems S.A., January 1996.
[28] Douglas D. Dunlop, "Object-Oriented Extensions to VHDL ", VHDL
International Users Forum, Fall 1994
[29] OMIIESPRIT Project REQUEST (OMI 20616).
[30] E. Holtz, et. al. "INSYDE report on Cosimulation ", Humbold University of
Berlin 1996.
5
OBJECT ORIENTATION AND
STRUCTURAL DESIGN
Wolfgang Ecker, Viktor Preis, Claus Schneider

Corporate Research and Development, ZFE T SE 5, Siemens AG, Miinchen, Germany
ABSTRACT
This chapter presents an analogy between structural and object-oriented properties with
the intention of showing a migration path for the introduction of software methodology
object-orientation in the hardware design process.
First, VHDL structural description capabilities and object-oriented principles are

explained. Afterwards, structural VHDL is analyzed under the aspect of object-oriented
description methods. It is shown how a configuration can support "static"
polymorphism. Incremental development and implementation as included in inheritance
mechanisms can be modeled with structural statements. However some overhead is
required.
Thus, an inheritance mechanism, already known from real-time object-oriented

modeling and similar to ADA tagged types, is proposed for VHDL entity, architecture
and component declarations. Application examples and an outlook on genericity
conclude the chapter.
77
78 CHAPTER 5
5.1. INTRODUCTION
The motivation for comparing structural VHDL description capabilities with object-
oriented properties is many-sided and influenced by a set of computer science domains.
Object-oriented analysis and design methods [Mey88, CoY090, ShMe90, Hod91,
RBPEL91, JCJ092] dominate current software design methodology. Their application
to hardware design is one possibility to improve the current hardware design and
specification process. Object-oriented description capabilities, however, are required for
all approaches. Additionally, new trends in software design as well as new reuse
approaches are using domain- specific architectures [Gab93] and patterns [GHJV94].
These are also based on object orientation. The study of architectures is an old-
fashioned but still very important hardware topic.
Modularity and composition of structural hardware design were often mentioned as a
model of object-oriented software design. Also, object orientation is primarily based on
communicating concurrent objects, which are closely related to interconnected
concurrent hardware units.
A dualism between objects and units which are required for the implementation of more
abstract objects is shown in [GKRM93]. Another object-oriented design strategy, a
very promising reuse approach as described in [PHSR95], is mainly based on structural
descriptions.
Several approaches for object-oriented extension of VHDL already have been made
[CoHS94,Dun94,Per92,ScNe95,ScNe95a,SWMC95,ZiMG92], and an object-oriented
extension study group is currently working towards object-oriented VHDL. Moreover,
object orientation as description paradigm of the year 2000 was postulated in
[EcMr96], based on the comparison of hardware and software design methodologies.
An approach for object-oriented hardware description using C++ like formulations was
described in [KAJW94]. A vice versa view, the analogy between structural and object-
oriented methods, would help also to introduce the software methodology object
orientation in the hardware design process.
5.2. OUTLINE
The chapter is organized as follows: first, structural capabilities of VHDL and object-
oriented description paradigms are enumerated. Afterwards a link between VHDL
structural statements and object-oriented programming paradigms is made. Due to the
fact that incremental design and implementation of inheritance need some overhead
when using structural descriptions only, an inheritance mechanism for entity,
architecture, and component declarations is shown next. A set of application examples
and an outlook on genericity conclude the final section.
Object Orientation and Structural Design 79
5.3. VHDL STRUCTURAL DESCRIPTIONS

An ideal picture of VHDL structural description is a socket on a board into which a
chip is put[BFMR]. This board again may be part of a subsystem and connected to a
backplane via a connector. The VHDL component relates in this picture to the socket,
the entity/architecture pair to the chip, and the chip, board, subsystem to hierarchy.
The component instantiation can be seen as connection of the socket's pins, whereas
ports may be left open, assigned a constant value, or adapted to other types.
The (probably implicit) configuration specifies the relation of one entity/architecture
pair with the socket and allows for flexible connection also. In relation to object-
oriented paradigms, it is important to note that different architectures as well as
different entities (with probably different interfaces) may be assessed to one
component.
The binding of the entity/architecture can be made in three ways:
• directly in the unit where the component instantiation occurs (configuration
specification),
• in an additional unit, which allows for more flexibility (configuration declaration), or
• implicitly using VHDL default binding rules.
VHDL'93 also supports entity instantiation which relates to a chip directly connected
to a board. Moreover, VHDL allows for iterative as well as alternative structural
description styles by using generate statements.
The comparison with object orientation is restricted in this chapter to structural
description style where bit values or composite bit values are used mostly. The VHDL
concept of unconstrained arrays or the generic specification of vector bounds allows the
specification of vectors of bit in a very flexible way.
5.4. PRINCIPLES OF OBJECT ORIENTATION

An overview of object-oriented principles can be found e.g. in [KoMG90]. The main
principles and features of object orientation are:
• Classes, which allow an object to be composed of a set of sub-elements. The
elements are called the state or attribute of the class and carry all information about
the object. The collection of elements is also called abstraction.
• Encapsulation, which only allows access to and manipulation of the elements of an

object via a well-defined interface.
• Methods, which describe how elements of the object can be modified. They are
activated by so-called messages or invocation.
• Instance, which describes the incarnation or construction of an object. In most cases

the destruction of an object can be specified also.
80 CHAPTER 5
• Inheritance, which allows a class of an object to be derived from an existing class.

Here all elements and all methods are part of the derived class. Methods, however,
may be modified.
• Polymorphism, which allows unique handling of objects possessing similar methods.

In most cases polymorphism is restricted to objects of inherited classes.
• Genericity, which allows a part of an object to be flexibly specified.
• Early or late binding, which describe the tasks associating operations to objects at
compile or execution time, respectively.
Alternative and iterative constructs are also part of most object-oriented languages.
They are not part of object-oriented features but they ease implementation of classes
by omitting overhead of object-orientation, which is not required in a lot of cases.
5.5. STRUCTURE AND OBJECT ORIENTATION

Structural VHDL description correlates with object-oriented features in that the
structural view of hardware is static and thus staticity must be involved in some sense
with the dynamic execution of software. In our approach the analysis of VHDL code
relates to compilation, and elaboration to execution.
The VHDL entity/architecture pair is equivalent to a class, whereas the entity specifies
the interface only and thus supports encapsulation. The architecture describes the
implementation of the class. It explicitly declares signals, which partially relate to states
or attributes. It is important to note, however, that signals may be used also to carry
interim information.
entity regN is
port ( d : in bit_vector;
q : out bit_vector;
clk: in bit;
res: in bit );
end RegN;
entity incN is
port ( x in bit_vector;
y : out bit_vector );
end incN;
The entity declarations shown above allow either direct access to the status of the
object by declaring the state in the interface (e.g.: q, y) or by allowing the activation of
methods via physical lines (elk, res, x).
Encapsulation is also ensured by the fact that no internal object and no implementation
detail is externally, i.e. outside the entity, visible.
A component is, from an object-oriented point of view, a declaration of a link or of a
container for a set of classes. The component concept of VHDL allows thus 'static'
polymorphism as the entity/architecture pair associated with a component need not be
known at analysis time.
component storeN
port ( d in bit_vector;
q out bit_vector;
c in bit;
r in bit );
end component;
component processN
port ( i : in bit_vector;
o : out bit_vector );
end component;
The components storeN/processN may be associated with the entities (or classes
in our comparision) regN/incN. But either different architectures of these entities or
different entity-architecture pairs with the same or nearly the same interface (e.g.
latchN/shiftN, see subsequrent listing) may be plugged in instead.
entity latchN is
port ( d : in bit_vector;
q : out bit_vector;
c: in bit;
rs: in bit );
end latchN;
entity shiftN is
port ( x : in bit_vector;
y : out bit_vector );
end latchN;
A configuration is required in this case to associate shown design entities with the
component storageN/processN.
The instance of a component specifies in this sense a link to a set of classes and the
instance of an entity the derivation of methods.
Structural statements describe the behavior of a class. They derive state and methods of
instantiated (and bound) units and thus allow for modeling inheritance. Moreover,
instantiation of different components supports multiple inheritance.
entity pipeStage is
port ( pi: in bit_vector;
po : out bit_vector;
clock: in bit;
reset: in bit );
end pipeStage;
architecture structural of pipeStage is
signal int : bit_vector ( pi'range );
begin
P: processN port map ( pi, int );
S: storeN port map ( int, po, clock, reset);
end structural;
configuration Incrementer of pipeStage is

for structural
for P: processN use WORK.incN( behavior); end for;
for S: storeN use WORK.regN( behavior ); end for;
end for;
end Incrementer;
82 CHAPTER 5
Here, the configuration Inerementer binds the unit regN to storeN and ineN to
proeessN. The behavior for storing and initialization (e.g. level, edge) of the unit
storeN is derived from regNo Similarly, the incremental behavior of proeessN is
derived from ineN.
Generic parameters facilitate among other things the specification of variant bit vector
widths. This can also be achieved by using unconstrained arrays. Both relate under the
assumption of weak typing to the object-oriented principle of genericity.
Bit chains with variant length may be processed by the element pipeStage and thus
allow for genericity. However, these bit chains may represent different behavior (e.g.
number, bit map, command, character, ... ) even if they are interpreted as number when
the incrementer is used.
Methods in structural design are activated or invoked by protocols. They consist of a
o physical part, which is related to a set of signals and a
o logical part, which consists of waveforms.
Considering regN,
o the physical part consists of the signals d,q,ekl, res and the
o logical part of
- a rising edge at elk to activate the method "store"
- a high value at res to activate the method "reset" and
- an event at q, which is a message to units connected to q, activating their
methods.
As analysis is compared with compilation and elaboration with execution hard binding
is specified by configuration specification or entity instantiation and soft binding by
configuration declaration.
The configuration Incrementer is thus an example of soft-binding. Hard-binding is
shown in the listing below:
architecture hardbinding of pipeStage is
begin
P: entity incN port map( pi, int );
s: entity regN port map ( int, po, clock, reset );
end structural;
VHDL generate-statements relate to alternative as well as iterative constructs in

software technique.
5.6. AN INHERITANCE CONCEPT FOR

STRUCTURAL VHDL
5.6.1. Motivation
Assume that the pipeline stage described above should be extended by a zero flag. The
behavior of the storage element and the processing element can be inherited again. Their
composition, however, must be rewritten completely.
entity pipeStageZero is
port ( pi: in bit_vector;
po : buffer bit_vector;
zero : out bit;
clock: in bit;
reset: in bit );
end pipeStageZero;
architecture structural of pipeStageZero is

begin
P: processN port map ( pi, int );
S: storeN port map ( int, po, clock, reset );
Z: zeroDetect port map ( po, zero );
end structural;
This need not to be done if the model is derived by extending the pipestage model by
inserting the line
zero: out bit;
in the port map and

Z: zeroDetect port map ( po, zero );
in the statement part.

This simple example shows that a huge overhead is required for incremental extensions
when inheritance is based on structural constructs only: Either all internal signals or
states are visible at the interface, which conflicts with the principle of encapsulation, or
already described declarations and instantiations must be repeated, which leads to
overhead and is error-prone.
5.6.2. Inheritance Concept

To overcome this problem, a method for incremental extension of structural
descriptions was presented in [SwMC95]. Here an entity and an architecture can be
derived from an existing entity by using the VHDL key word "new".
In [SwMC95] additionally the concept of EntityObjects is proposed. Here a state
called instance variable and a set of methods called operations can be declared and
inherited. The methods are activated by executing a send command out of a sequential
statement outside the object.
84 CHAPTER 5
We developed a very similar approach influenced by object-oriented real time analysis

[SeGk94] and by ADA95 [ADA95]. The keyword "tagged" is used in general to
specify a root node for inheritance but in the examples to show that a declaration is still
incomplete. The listing below shows this for an entity and component declaration of a
register.
entity registerN is tagged
generic(width : natural
port ( clk : in bit );
d : in bit_vector ( width - 1 downto 0);
q : in bit_vector( width - 1 downto 0) );
end entity registerN;
component registerN is tagged

generic(width : natural)
port ( clk : in bit );
d : in bit_vector( width - 1 downto 0);
q : in bit_vector( width - 1 downto 0) );
end component registerN;
To incrementally extend a declaration, the keyword "new", which already exists in

VHDL, is also used. A finalized declaration with extension, as shown below, a finalized
declaration without extension, or another incomplete declaration can be derived. All
declarations, interface clauses, and statements which are part of the incomplete and
probably tagged unit are implicitly part of the derived unit and may be extended.
However, an extension which contains an identifier in the same naming scope of the
tagged unit overwrites the declaration or structural statement of the tagged unit.
entity lr_registerN is new registerN
port ( load: in bit;
reset: in bit );
end entity lr_registerN;
component lr_registerN is new registerN

port ( load: in bit;
reset: in bit );
end component lr_registerN;
Similarly, an architecture can be marked with the keyword "tagged". It also can be
derived from existing probably tagged architectures. This is shown below.
architecture behavior of lr_registerN is tagged
begin
pO:process( clk )
begin
if clk = '1' then
if reset = '1' then
q <= (others => '0');
end if;
if load = '1' then
q <= d;
end if;
end if;
end process;
end behavior;
architecture check of lr_registerN is tagged

begin
p1:process( clk )
begin
if clk = '1' then
assert load = '0' or reset = '0'
report "concurrent load and reset"
severity WARNING;
end if;
end process;
end behavior;
architecture simulation of 1r_register is new

behavior, check
begin
-- empty
end simulation
In the final architecture multiple inheritance is used. This is also possible for entities
and components. If identical identifiers are used in units, then the declaration occurring
in the later enumerated unit (here: check) remains visible for multiple inheritance. This
implies also that identical declarations occur only once.
It is important to note that architectures may be derived from architectures of the same
(probably tagged) entity, and also from architectures from derived entities, from which
the entity of the architecture is derived. It should be mentioned also that only tagged
architectures may be associated with tagged entities. However, both extended and
unextended architectures may be assigned with not tagged entities.
5.7. APPLICATION EXAMPLES

5.7.1. Flexible uP-Interface
The uP-interface (see Figure 1) of an ASIC generally consists of a microprocessor-
specific synchronization interface to the CPU-bus (uP _synchro), an address decoder
(addr_decoder), a data multiplexer (data_mux) and a set of ASIC-specific registers.
One possibility for flexible modeling of the interface is the encapsulation of each of the
blocks (i.e. uP_synchro, addr_decoder, data_mux, register) in a separate unit.
86 CHAPTER 5
mP-lnterface
'~"'~","IIIIII''''II,,''IIII'''''''''IIII''''~
I
I
I
I
I
uP _synchro ~
I
cntrl
Figure 1: Structure of a uP-Interface Component.

entity up_synchro is
port(cs in bit;
rd in bit;
wr in bit;
rdy out bit;
addr_decoder_cntrl out bit;
data_mux cntrl out but;
register_cntrl out bit) ;
end up_synchro;
entity addr_decode is
port (addr_decoder_cntrl in bit;
addr_from_up in bit_vector(width -1 downto 0);
register_select out bit_vector(2 ** width - 1 downto 0));
end addr_decode;
entity data_mux is
port (data_mux_cntrl in bit;
data_from_to_up inout bit_vector(width -1 downto 0);
data_from_to_regs inout bit_vector(width -1 downto 0);
end data_mux;
entity reg is
port (register_cntrl in bit;
regselect in bit;
data_from_to_up inout bit vector (width -1 downto 0) ;
cntrl from_asic in bit;
data from_to a s ic inout bit - ve ctor (width -1 downto 0) ;
end reg;
The different functionalities of the blocks are designed within the architectures, e.g:
architecture sparc of up_sunchro is
begin
end sparc;
architecture intel of up_sunchro is
begin
end intel;
A template with a default constellation eases the design of the uP-interface.

entity mp_interface_for_asic_xyz is
port (clock : in bit;
reset : in bit;
up_bus -----------------------
cs in bit;
rd in bit;
wr in bit;
rdy out bit;
addr_from_up in bit_vector( ... );
data_from_to_up inout bit_vector( ... );
-- asic_bus ---------------------
-- must be added manually
data_from_to_regl inout bit_vector( ..... I;
cntrl_from_regl : inout bit;
end mp_interface_for_asic_xyz;
architecture arch_mp_interface_for_asic_xyz
of mp_interface_for_asic_xyz is
begin
A:up_synchro
port map (cs,rd,wr,rdy,addr_decoder_cntrl,data_mux_cntrl,
register_cntrl);
B:addr_decode
generic_map (8) ,
port map(addr_decoder_cntrl,addr_from_up,register_select);
C:data_mux
generic_map (8) ,
port map(data_mux_cntrl,data_from_to_up,data_from_to_regs);
-- Add the asic specific registers here.
AI: reg generic_map (8) ,

port map(register_cntrl,regselect(ll,data_from_to_mp,
cntrl_from_regl,data_from_to_regl);
The problem of this solution is that the designer can rearrange and compose the whole
template. But the components up_syncro, addr_decoder, and data_mux work only for a
specific timing constellation. Any change in the constellation can lead to redesign cycles,
i.e. the productivity of reusing the design decreases.
88 CHAPTER 5
A very elegant way to overcome this problem is to describe the core of the interface
inside a tagged architecture. ASIC-dependent uP-interfaces with a set of ASIC-specific
registers can then be derived from that description. The example of the mP-interface is
also extended to contain an interrupt signal.
The tagged components for the mP-controller are:
entity up_synchro is tagged
port(cs in bit;
rd in bit;
wr in bit;
rdy out bit;
addr_decoder cntrl out bit;
data_mux cntrl out but;
register_cntrl out bit) ;
end up_synchro;
entity up_synchro_with_interrupt is new up_synchro
port(cntrl_interrupt : out bit)
end up_synchro_with_interrupt;
The tagged components for the mP-interface cores are:

entity mp_interface_core is tagged
generic (addr_width natural;
data_width natural) ;
port (clock : in bit;
reset : in bit;
up_bus -----------------------
cs in bit;
rd in bit;
wr in bit;
rdy out bit;
addr_from_up in bit_vector(addr_width -1 downto 0);
data_from_to_up inout bit_vector(data_width -1 downto 0));
end mp_interface;
entity mp_interface_with_interrupt is new mp_interface_core
generic(interrrupt_data_width: natural);
port (interrupt_data in bit_vector
(interrrupt_data_width -1 downto 0);
int out bit;
The corresponding architectures are:

architecture arch_mp_interface_core of mp_interface_core is tagged
begin
A:up_synchro
port map (cs,rd,wr,rdy,addr_decoder_cntrl,data_mux_cntrl,
register_cntrl);
B:addr_decode
generic_map (addr_width) ,
port map(addr_decoder_cntrl,addr_from_up,register_select);
C:data_mux
generic_map (data_width) ,
port map(data_mux_cntrl,data_from_to_up,data_from_to_regs);
end arch_mp_interface_core;
architecture arch_mp_interface_with_interrupt
of mp_interface_with_interrupt is
new arch_mp_interface_core
function calc int ( ..... )
begin
end calc_inti
begin
A:up_synchro_with_interrupt
port map (cs,rd,wr,rdy,addr_decoder_cntrl,data_mux_cntrl,registe
r_cntrl,
cntrl_interrupt);
int <= calc_int(interrupt_data,cntrl_interrupt);
end arch_mp_interface_withy_interrupt;
The designers' work to design a uP-interface for a specific ASIC would be:
entity mp_interface_for_asic_xyz is new mp_interface_core
port (data_from_to_regl inout bit_vector();
cntrl_from_regl : in bit;
end mp_interface_for_asic_xyz;
architecture arch_mp_interface_for_asic_xyz
of mp_interface_for_asic_xyz is new
begin
AI: reg
generic_map (8) ,
port map(register_cntrl,regselect(I),data_from_to_mp,
cntrl_from_regl,data_from_to_regl) ;
To design a uP-interface with an interrupt looks like follows:
entity mp_interface_with_interrupt_for_asic_xyz is
new mp_interface_with_interrupt
port (data_from_to_regl inout bit_vector();
cntrl_from_regl in bit;
end mp_interface_with_interrupt_for_asic_xyz;
architecture arch_mp_interface_with_interrupt_for_asic_xyz
of mp_interface_with_interrupt_for_asic_xyz is new
arch_mp_interface_with_interrupt
begin
AI: reg
generic_map(8) ,
port map(register_cntrl,regselect(l) ,data_from_to_mp,
cntrl_from_regl,data_from_to_regl);
There are many scenarios, which can be designed efficiently with this method. One
example is system-specific uP-interfaces, i.e. all ASICs of a system contain a specific
core with the up-controller, addr_decoder, data_ mux, and a set of specific registers (e.g.
version register, interrupt register). This application-specific implementation can of
course be derived from the uP specific implementation.
90 CHAPTER 5
Moreover, user-specific ASIC derivates with an extended register set can be derived
from the system-specific implementation. Multiple inheritance can be employed
additionally to derive a uP-interface for ASICs supporting more than one standard
application.
Driver software, i.e. the interface to application software, can also be implemented
incrementally going hand in hand with this derivation scheme ofthe hardware interface.
5.7.2. Incremental TiminglFunction Implementation

Performance analysis is one of the key points in early system design. Currently, either a
separate tool or a special VHDLdescription is used. Afterwards, a new model must be
developed for integrated timing and functional analysis and verification.
In [ScEc96] a method for separated synchronization and function description is
presented. First, synchronization is implemented and a cycle-based performance
analysis performed. In the second step, a dummy implementation of the functionality is
added to the synchronization. Again, performance analysis and a first verification of the
data flow are done with this description. In the last step, the dummy implementation of
the functionality is replaced by a fully functional model, and a final evaluation is
performed. All models are structurally composed and thus behavior is inherited as
described in Section 5.5.
Controller
Dummy Fully Functional

Datapath Datapath
The process of inheritance by structural composition is demonstrated by using a small

example of an operation buffered by an input and output queue. The model is embedded
in a testbench to show how the testbench is growing together with the model.
In the first step, the example entity only consists of the controller part, which is
modeled by an operation scheduler (OS) and two queue controllers (QC). The OS
receives ready signals if the input queue has source data available and the output queue
can accept result data. The operation in the datapath is then activated with a start
signal, which is left open in the first step. Depending on the schedule, which can be a
static generic parameter of the OS or a dynamic return value of the operation, the OS
strobes the input queue after all source data are read, and the output queue when the
result data are written. The QCs in this example implement the interface to the
testbench. A request for either reading or writing data is signaled by the QCs and
acknowledged by the OS after a number of cycles, depending on their schedule. In the
first step only a constant (C) schedule is considered for the operation inside the model.
In the testbench, a dynamic schedule (processing time) is modeled by adding a ramp
function to the OSs.
In the second step, a dummy implementation of the datapath is added to the controller.
The datapath consists of two queue memories (QM), each indexed by a read and write
address from the corresponding QC, and an operation (OP), that passes the input data
to the output when it receives a start signal from its OS. In the testbench, the dummy
methods STIM (generate stimuli) and CHK (check result data) are added to the OSs. In
addition, the entity is incrementally extended by data ports. For data flow analysis,
serial data (e.g. integer data type) is generated at the input and checked for causality at
the output.
r .., r -.., r -.., r ..,

ISTIM QM~OP~QM
CHK 1
0.1.2 ... 0,1.2 ...
L _ .J L _ .J L _.J
In the third step, the integer data type is replaced by an application-specific data type
(e.g. record), and the dummy operation is replaced by a fully functional one. In the
testbench, the methods stimulate (STIM) and check (CHK) are redefined to read real
source and result data for a fully functional verification. For analyzing the effects of
data-dependent processing time, the constant schedule of the operation is replaced by a
dynamic schedule, calculated by each execution of the operation.
92 CHAPTER 5
The following VHDL code example shows the extensions to the model made in the
second step and the locations for redefinitions in the third step. The architecture
declarative part and port maps in the statement part were omitted to keep the example
readable.
{ package my-pack is
subtype my_data_t is
end my-pack;
entity example is
Y
port ( elk, reset: in bit;
{ re~in, re~out: out bit;
stb_in, stb_out: in bit;
data_in: in my_data_t;
data_out: out my_data_t );
end example;
CD
~~c~~~~cture structural of example is redefine
~ gQ~:
datapath
QueueCtrl port map ( .. ); architecture
QO: QueueCtrl port map ( .. );
os: OpSched port map ( .. );
DP: DataPath port map ( .. );
end structural;
configuration dummy of example is
The behavior of the controllers can be inherited from the first step by instantiation, but
the composition for the second step must be rewritten completely. This includes the
extension of the port map by data ports, instantiation of the datapath and its
configuration. By using a package to define the data type for datapath operations, the
entity/architecture pair does not have to be modified in the third step. However, the
overhead of rewriting and configuring the model composed of controller and functional
description in step two remains (see Section 5.6.1).
The overhead could be omitted by using structural inheritance, as proposed in
Section 5.6.2. First, an entity control is declared, which abstracts from the
functionality by describing the controller part only. The controller consists of OS and
QC instances and the control signals for the handshake between them. All control
signals leading to the datapath are declared and connected to the controllers as well, but
left open to the datapath. For the OS, a constant value cons t_sched is assigned to
the dynamic schedule input dyn_sched.
entity control is tagged
port ( clk, reset: in bit;
re~in, re~out: out bit;
stb_in, stb_out: in bit );
end control;
architecture structural of control is tagged

signal ctrl, ....
begin
QI: QueueCtrl port map ( .. );
QO: QueueCtrl port map ( .. );
os: OpSched port map ( .. , dyn_sched, .. );
DS: dyn_sched <= const_sched;
end structural;
configuration structure of control is

for structural
for all: QueueCtrl use WORK. QueueCtrl( behavior ); end for;
for os: OpSched use WORK. OpSched ( behavior); end for;
end for;
end structure;
Second, an entity d_control is derived from control, which contains an instance

DataPath representing dummy functionality only. The derived entity is incrementally
extend by data ports using the integer data type.
entity d_control is new control
port ( data_in: in integer;
data_out: out integer );
end d_control;
architecture structural of d_control is tagged

begin
DP: DataPath port map ( .. );
end structural;
configuration structure of d_control is

for structural
for DP: DataPath use WORK.DataPath( dummy); end for;
end for;
end structure;
Finally, another entity ffa_control is derived from the first one, which contains full
functionality. In most of the cases, the full functional model can not be derived from the
dummy functional one, because it needs an application specific data type
appl_data_t, rather than integer for the data ports. If both models, the dummy
and the fully functional one, use the same data type, the fully functional model
ffb_control can be derived from d_control. The relationship between the
models is shown in the following inheritance graph.
As in the second step, in step 3 the ports are incrementally extended, and a datapath is
instantiated. The datapath instance implements full functionality and in addition returns
a data- dependent schedule dd_sched, which is assigned to the dynamic schedule
dyn_sched, by overwriting the DS statement from the control architecture.
entity ffa_control is new control
port ( data_in: in appl_data_t;
data_out: out appl_data_t );
end ffa_control;
94 CHAPTER 5
architecture structural of ffa control is tagged

signal dd_sched : schedule_t;
begin
DP: DataPath port map ( .. , dd_sched, .. );
DS: dyn_sched <= dd_sched;
end structural;
configuration structure of ffa_control is

for structural
for DP: DataPath use WORK. DataPath( fullfunctional ); end for;
end for;
end structure;
If only the dummy datapath has to be redefined to implement full functionality, the
data type remains the same, and no dynamic schedule is required, the new model
ffb_control can be derived from d_control.
entity ffb_control is new d_control
end ffb_control;
architecture structural of ffb_control is tagged

begin
end structural;
configuration structure of ffb_control is

for structural
for DP: DataPath use WORK. DataPath( fullfunctional ); end for;
end for;
end structure;
The benefit of this approach is not only the reduced writing effort at each refinement
step, which is less error prone than rewriting the whole model, but the fact that
improvements to the base (control) architecture become improvements to all derived
architectures automatically.
5.7.3. Method Activation by Abstract Message Passing

Abstract method activation as presented in [SwMC95] can be modelled using abstract
communication mechanisms as described in [BaEc93]. For this, the entity consists of at
least one interface signal to pass messages.
entity abstractObject is
port ( messageActivation : inout master_slave_communication );
end abstractObject;
As shown in the figure below, the state of the abstract object is declared inside its
architecture as well as a set of processes, each responsible for one method. The methods
can be externally activated by sending a possibly parametrized message to the process.
The execution of the process may then modify the state of the object, return
information to the caller, send informtion via other communication channels or modify
other port signals.
The state of the object as well as the methods can easily be extended by using structural
inheritance as shown above. A brief example is shown below. Given an object with an
integer state and methods to set or get values, the interface can be taken directly from
the abstract object:
entity Object is
port ( messageActivation inout master slave communication );
end Object;
The architecture consists of one signal (state) and two processes implementing
functionality.
architecture PutGet of Object is
signal state: register integer;
constant GetMethod MethodType.- 1;
constant PutMethod : MethodType := 2;
begin
process
variable dummy : Integer;
begin
slave_inquire ( GetMethod , dummy);
slave_response ( GetMethod , state );
end process;
process
variable value Integer;
begin
state <= null;
slave_inquire ( PutMethod , value );
state <= value;
slave_response ( PutMethod , 0 );
end PutGet;
An extension of the object shown above by the method Increment requires the addition
of a new channel in the entity declaration for sending an overflow message in the entity
declaration and a process for implementing the method.
96 CHAPTER 5
entity IncObject is new Object

port ( oveflow : inout channellxl );
end Object;
architecture IncPutGet of IncObject is new PutGet is

constant IncMethod : MethodType .- 3;
constant MAX: Integer := 1000;
begin
process
variable dummy: Integer;
begin
state <= null;
slave_inquire ( IncMethod , dummy);
if state = MAX - 1 then
send( overflow, dummy);
else
state <= state + 1;
wait for 0 ns;
state <= null;
end if;
slave_response ( IncMethod , dummy);
end process;
end IncPutGet;
5.S. GENERICITY
Several ways exist to achieve generic modeling: Instance, polymorphism, inheritance,
generics and generate statements. This shall be discussed for different modelling and
application cases via a register model.
5.8.1. Instance
Registers sensitive to different edges and reacting to different reset modes shall be used
for the component storageN in the pipe Stage example of Section 5.5. The behavior
could be derived from different entity/architecture pairs, but the architecture hard-
binding must be modified for each register type.
5.8.2. Polymorphism
A very elegant way to do so is by using the static polymorphism capabilities of a
configuration as described in Section 5.5.
configuration Incrementer_Rising_High of pipeStage is
for structural
for P: processN use WORK.incN( behavior); end for;
for S: storeN use WORK. regN ( rising_high ); end for;
end for;
end Incrementer_Rising_High;
configuration Incrementer_Falling_Low of pipeStage is

for structural
for P: processN, use WORK.incN( behavior); end for;
for S: storeN use WORK.regN_FL( behavior); end for;
end for;
end Incrementer_Falling_Low;
The configurations shown above bind either the same entity with another architecture
implementing the required behavior or another entity/architecture pair.
5.8.3. Inheritance
The overhead using different instances (see 5.8.1) can be omitted by structural
inheritance. This approach, however, is not as elegant as using configuration based
polymorphism.
5.8.4. Generics
The most compact modelling style invokes the use of generics for the selection of
different register types.
type storeModeType is ( NoMemory, High, Low, Falling, Rising );
type resetModeType is ( NoReset, AsyncHigh, AsyncLow, SyncHigh,
SyncLow );
component regNgeneric is
generic storeMode: storeModeType;
resetMode : resetModeType );
port (d in bit_vector;
q out bit_vector;
clk: in bit;
res: in bit );
end RegNgeneric;
The generic parameters can be used in behavioral models directly or to control generate
statements for synthesis purposes. Generic capabilities of current VHDL, however,
cannot be used if values of different types must be handeled. An elegant way to
overcome this problem is to use inheritance as shown below.
entity regN is tagged
port ( elk: in bit;
res: in bit );
end RegN;
architecture core of regN is tagged

signal di,qi : bit_vector ( maxsize downto 0 );
begin
C : regNbit_vector port map ( di, qi, clk, res );
end core;
entity regNinteger is new regN

port ( d : in integer;
q : out integer );
end regNinteger;
architecture full of regNinteger is new core

begin
CI: Int2Bv port map ( d , di );
co: Bv2Int port map ( qi, q ) ;
end full;
98 CHAPTER 5
Here, the interface to clock and reset is part of the entity only. A register storing variant
length bit chains is instantiated in the architecture. For each type, the interface is
extended by d as well as q, and the internal registers are connected to type conversion
units.
Generic types as defined in ADA would allow for a very compact modelling in this
purpose.
5.9. CONCLUSION AND OUTLOOK

An object-oriented view of structural VHDL descriptions and structural inheritance
mechanisms was presented. A set of different application examples shows additionally
the applicability of object oriented features, structural description capabilities, and the
object-oriented view of structural VHDL. Current work is concentrating on the
discussion of the usefulness of tagged entities, generic types to overcome the problem
of weak typing, application of extendable units to other VHDL constructs like packages
or configurations, and evaluation of the proven inheritance mechanisms towards non
configuration-based polymorphism. We are also working on the application of object-
oriented ADA95 features in behavioral descriptions.
REFERENCES
[Ada95] Information technology - Programming languages - Ada, Annotated Ada
Reference Manual. International Standard ISO/lEC 8652: 1995(E).
Intermetrics, 1995.
[BaEc93] Bauer, M.; Ecker, W.: Communication Mechanisms for VHDL
Specification and DeSign starting at System Level, Proceedings of the
Spring'93 Meeting of the VHDL-Forum for CAD in Europe, Innsbruck,
1993.
[Bar91] Barnes, J.: Programming in Ada plus Language Reference Manual,
Addison-Wesley Publishing Company, Workham, England, 1991.
[BFMR] Berge, J-M.; Fonkoua,A.; Maginot, S.; J. Rouillard, 1.: VHDL Designer's
Reference, Kluwer Academic Publishers
[CoHS94] Covnot, B. Hurst, W. Swammy, S.: OO-VHDL: An Object Oriented
VHDL. Proceedings of the VHDL International User's Forum, 1994.
[CoY090] Coad, P.; Yourdon, E.: Object Oriented Analysis. Prentice Hall, 1990.
[Dun94] Dunlop, D.D. Object-Oriented Extensions to VHDL. Proceedings of the
VHDL International User's Forum, 1994
[EcMr96] Ecker, W.; Mrva, M.: Object orientation: Modeling and Design Paradigms
for the Year 2000?, ClEM, Issue #7, Kluwer Academic Publishers, 1996.
[Gab93] Gabriel, R.: The quality without a name. Journal of Object-Oriented
Programming, September 1993, pp. 86-88.
[GHJV94] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Design Patterns -
Elements ofReusable Object-Oriented Software. Addision Wesley, 1994.
[GKRM93] Glunz,W., Kruse,T., Rossel, T., Monjau,D.: Integrating SDL and
VHDL for System-Level Hardware Design. Proceedings CHDL'93,
Ottawa, Canada, 1993.
[G1PV92] Glunz, W., Pyttel, A., Venzl, G. System-Level-Synthesis in Design,
Michel, P., Lauter, U., Duzy, P. (eds): The Synthesis Approach to digital
System. K1uwer Academic Publishers, 1992.
[GlUm91] Glunz, W.; Umbreit, G.:VHDL for High-Level Synthesis of Digital
Systems.Proceedings of the EuroVHDL'91, Marseille, September 5-7,
1991.
[Hod91] Hodgson, R.: The X-Model: A Process Modelfor Object-Oriented Software
Design, Fourth International Conference on Software Engineering and Its
Applications, Toulose, France, 1991
[JCJ092] Jacobsen, I.; Christerson, M.; Jonsson, P.; Overgaard, G.: Object-Oriented
Software Engineering: A Use Case Driven Approach. Addision-Wesley,
Reading, Massachusetts, 1992.
[Jor94] Jorgensen, 1.: A Comparison of the Object Oriented Features ofAda9X and
C++. "from the net". March, 1994.
[KAJW94] Kumar, S.; Aylor, J.; Johnson, B.; Wulf, W.: Object-Oriented techniques in
Hardware Design. IEEE Computer, June 1994.
[KoMG90] Korson, T.; McGregor, J.: Understanding Object-Oriented: A Unifying
Paradigm, Communications of the ACM, Vol. 33, No.9, September 1990
[Mey88] Meyer, B.: Object oriented Software Construction. Prentice Hall, 1988.
[Per92] Perry, D.: Applying Object-Oriented Techniques to VHDL. Proceedings of
the VHDL International User's Forum, 1992.
[PHSR95] Preis, V.; Henftling, R,; Schlitz, M.; Marz-Rossel, S.: A Reuse Scenario for
the VHDL-based Hardware Design Flow, Proceedings of the
EURODACNHDL' 95
[RBPEL91] Rumbaugh, J.; Blaha, M.; Premeriani, F.; Eddy, F.; Lorensen, W.: Object-
Oriented Modeling and Design, Prentice Hall, 1991.
[ScEc96] Schneider, C.; Ecker, W: Stepwise Refinement of Behavioral VHDL
Specifications by Seperation of Synchronization and Functionality.
EURODACNHDL'96. submitted.
[ScNe95] Schumacher, G.; Nebel, W.: Survey on Languages for Object Oriented
Hardware Design Methodologies. Berge,J-M.; Levia, 0., Rouillard, J.
(eds): High-Level System Modeling: Specification Languages. Kluwer
Academic Publishers, 1995
[ScNe95a] Schumacher, G.: Nebel, W.: Inheritance Concept for Signals in Object-
Oriented Extensions to VHDL, Proceedings EURODACNHDL '95
100 CHAPTER 5
[SeGW94] Selic, 8.; Gullekson, G.; Ward, P-T.: Real-Time Object-Oriented Modeling.
1994
[ShMe90] Shlaer, S.; Mellor, S.: Recursive Design. Computer Language 7, 3,1990
[Str91] Strounstrup, B.: The C++ Programming Language, Second Edition.
Addison Wesley PublishThe C++ Programming LAnguage,ing Company,
1991.
[SwMC95] Swamy, D.; Molin, A.; Burton, M.C.: OO-VHDL Externsions to VHDL,
IEEE Computer, October 1995.
[VhdI87] IEEE Standard VHDL Language Reference Manual, IEEE Std 1076-1987.
[VhdI93] IEEE Standard VHDL Language Reference Manual, IEEE Std 1076-1993.
[ZiMG92] Zippelius, R.; Muller-Glaser, K.: An Object-Oriented Extension ofVHDL.
VHDL-Forum for CAD in Europe, Spring'92 Meeting, Santander/Spain,
1992
6
ABSTRACT HARDWARE
MODELLING USING AN OBJECT-
ORIENTED LANGUAGE EXTENSION
TOVHDL
Guido Schumacher, Wolfgang Nebel
Department of Computer Science, Carl von Ossietzky University Oldenburg,
26111 Oldenburg, Germany
ABSTRACT
Reusability of hardware models becomes more and more important in the design of
complex systems. This is explained for different modelling problems. Methods for re-use,
which successfully use abstraction as a key to manage the design complexity in the
software domain, are analysed with respect to their applicability to hardware design.
Object-oriented modelling is stated as a technique which potentially increases design
productivity. Attempts to adapt such techniques for hardware specification and design
are presented The lack ofsupport for object-oriented modelling in the current version of
VHDL is explained. Possible subjects for object orientation are discussed We illustrate
how an object-oriented extension to the hardware description language VHDL could be
used to describe hardware systems at a high level ofabstraction. An explanation is given
that it is not sufficient to introduce object-oriented language constructs into a parallel
hardware description language, it is also necessary "to provide high-level
communication constructs for the data exchange between the parallel processes. Such
missing language concepts of VHDL for abstract modelling with special regard to the
object-oriented language extensions are discussed
101
102 CHAPTER 6
6.1. INTRODUCTION
The non-saturating integration density of integrated circuits (despite of earlier
assumptions) provides sufficient motivation to investigate further possibilities to
increase design productivity. The increase of complexity can be estimated at about ten
every seven years. It cannot be compensated by the increase of computing power,
which on the one hand does not achieve an increase in intellectual value addition without
a change in design methodology, while on the other is consumed mostly by complex
data management systems and user-friendly graphical interfaces.
As keys to manage the design complexity and the increase of design effort typically the
terms hierarchy and abstraction are mentioned. A hierarchical, structural decomposition
of the design problem reduces the complexity by isolating subproblems and hence
makes the global design problem accessible for a solution. This achievement has to be
paid for with a suboptimal total solution due to the local optimization of the
substructures.
Abstraction should be looked at from different points of view. First, it allows us to
encapsulate existing components which can be described by an abstract model
containing only that information which is required at the higher level of abstraction.
Examples of this kind of abstraction are cell libraries of ASIC vendors. Here abstraction
allows the re-use of hardware components. They do not need to be redesigned for each
application, i.e. the design cost (measured in terms of transistors) is reduced.
On the other hand, abstraction can be used for reducing design effort if design detail can
automatically be attributed to less detailed design specifications using synthesis tools.
Application examples are: logic synthesis, technology mapping, place and route. Here
the reduction in design effort is due to a re-use of automated design strategies and
architectures.
At the system level, abstraction is required to describe a first specification without
confusing and often unknown implementation details. It allows a first check of the
system description for inconsistencies and errors and therefore reduces the risk of re-
design steps in further design phases.
6.1.1. Traditional Approaches of Re-Use

In the past, the method of design data encapsulation was developed in an evolutionary
way in the direction of higher levels of abstraction. The steps low level design,
encapsulation and re-use were first applied to transistors, then to cells and finally to
macros. On the macro level, however, the limits became obvious. To design a
comprehensive library of complex parameterized macro cells has turned out not to be
cost efficient for general purpose applications. The reasons are the high initial and
maintenance costs of the library whose elements are possibly only seldom used and
additionally are not optimal for the particular application. Today, in general purpose
ASIC libraries there are usually only memories and analogue cells as macro cells.
Generators which were typically provided for arithmetic functions, etc. a couple of
years ago have been replaced by synthesizable models. Some exceptions can be found in
the domain of signal processing and other special purpose libraries.
Abstract Hardware Modelling using an 00 Language Extension to VHDL 103
One can conclude that the necessary further increase in level of abstraction cannot be
achieved by aggregating physical representations of larger functional units and
abstracting them. A more promising approach is to reduce the effort of high-level
modelling and to build on automatic synthesis. The state of the art is behavioural
synthesis, which allows for an automatic netlist generation of single (VHDL) processes.
Because of the common association of a process with a hardware unit, the traditional
structural way of thinking in terms of functional units, which communicate via signals,
is maintained.
Moving the creative part of the design process to those levels which are covered by
hardware description languages of course also moves the largest potential of design
productivity increase to those levels. According to [20] already in 1993, almost 60% of
the US designer community used logic synthesis, and more than 50% used hardware
description languages. The large number of simulation and synthesis iterations [1]
emphasizes the need to improve the modelling productivity. The current effort in this
domain is due to necessary debug phases and the need to steer the synthesis process
into the intended direction. Different aspects of modelling cost and productivity will be
discussed in Section 6.2.
6.1.2. Software Engineering

Software engineering is frequently cited to be comparable to the problem of complexity
in hardware design. This is even more the case with the Ie-designer's day-to-day work
being more and more dominated by hardware description languages. Abstraction and
hierarchy have been applied to manage design complexity and design effort in software
engineering, too. The most important steps were, again in an evolutionary bottom-up
approach: machine code, assembler, structured higher level programming languages,
fourth-generation languages and object-oriented languages. In parallel to the language
design, or more precisely analysis and design, methodologies have been developed.
To effectively use such methodologies in the design process, they have to match the
implementation language. Especially for re-use, methodologies are necessary, which
allow the propagation of modifications in the specification through all design phases
down to the implementation level without losing consistency of the model. While fourth
generation languages (comparable to macro cell generators) are applied only to dedicated
application domains, object-oriented programming together with object-oriented
analysis and design methodologies have become widely accepted. It is remarkable that
the migration from a non-object-oriented imperative programming language to an object-
oriented one demands a significant shift in paradigms even for a software programmer.
He or she has to switch from a procedural structure of thinking to an object structure.
This way of structuring at first glance seems to be closer to how hardware designers
tend to work, i.e. a structure of communicating hardware entities. However, as we will
see later, the differences between these classical hardware entities and the objects of the
software world which act like agents are still significant.
Section 6.3 will introduce into techniques which are typically called object-oriented.
The acceptance problem usually coming together with a shift in paradigms and the
current state of standardization of object-oriented extensions to VHDL will be explained
in Section 6.4. The interdependence between the specification technique and the
104 CHAPTER 6
implementation language is described in this context. Section 6.5 gives a survey on an

object-oriented analyse and design technique developed by James Rumbaugh. This
technique is used in Section 6.7 to illustrate how object-oriented hardware specifications
can be translated into an object-oriented extension to VHDL as an implementation
language, which is presented in Section 6.6. Section 6.8 explains how to introduce
parallelism in an object-oriented specification and implementation. In Section 6.9
mechanisms for high-level communication between objects are discussed.
6.2. MODELLING PROBLEMS

A careful analysis of the problems is required before a technique which has proven to
show good results in one domain is applied to another domain. This principle has to be
obeyed for object-oriented methods before recommending them as a panacea.
Considering the special objective of reusability, modelling costs arise during different
phases of the design. Their relevance and whether reusability is feasible certainly also
depend on the complexity of the models. It is further necessary to identify those
aspects of the design which shall be subject to re-use. Table 1 structures these questions
w.r.t. the modelling phases and the level of abstraction of the respective models. The
modelling phases and their particular problems will be explained in the following.
subs stem cell level

initial modellin cost low
maintenance cost moderate low
cost of re-use moderate low
cost ofmo n.a. high
moderate ve hi h
Table 1: Importance of Modelling Cost and Re-Use
6.2.1. Initial Modelling Cost

In this taxonomy, initial modelling costs covers all cost which arise in the specification
phase of a particular model until it is accepted without syntactical and obvious semantic
and functional errors by an analyzer (simulator). The task starts with the interpretation
and analysis of a specification, which may be informal, covers structuring and coding
and ends with the fixing of syntactical, semantic, and functional errors. The result is a
baseline model of further design phases.
The initial modelling cost depends not just on the target to be modelled and the user-
friendliness and equipment of the workplace, but also on how well the modelling
language fits the application, the objects to be modelled and the level of abstraction. The
better the language fits the problem, the less code needs to be written; the modelling
productivity increases. Another factor is the organization of and extent to which
previously acquired design knowhow can be exploited.
6.2.2. Cost of Maintenance

Typically, after the initial modelling phase some disturbances occur requiring changes of
the initial model. These include, e.g., changes of the specification, functional errors
detected late or changes of constraints. These changes necessitate becoming acquainted
with the model and implementing the modifications in such a way that only the
intended changes are made and no others. In particular, it is necessary to minimize the
impact of the amendments to other members of the design team. The effort depends on
the structure and documentation of the initial model, but also on the structuring
capabilities of the hardware description language used. An extensive encapsulation of
data and functionality and the avoidance of having to consider the impact of local
changes in non-local entities helps to increase productivity.
6.2.3. Cost of Re-Use

Re-use of models is certainly an important aspect to increase modelling productivity.
Re-use is especially advantageous in the following situations [6]: frequently used
modules, e.g. memories; standard functionality, e.g. protocols; evolutionary design
(about 80% of all designs are re-designs). However, as correctly stated in [6], a pure re-
use of an existing module does not achieve any added value. For innovations, the
modules have to be adaptable to, e.g., new technologies or extended functionality.
Technology migration can be achieved by synthesizable models. A certain flexibility in
the application can be gained by parameterized models; however, it is limited if the
basic functionality of the model needs to be extended or modified.
An analysis of the cost of re-use is required in order to decide whether the re-use of a
model for a certain application is feasible. The cost is composed of the additional cost
of a reusable model compared with a non-reusable model. This includes the requirement
for better quality assurance measures and possibly increased cost of more flexible
modelling. Secondly, cost of re-use includes the cost of actually re-using a model. This
covers the search for the required model, the necessary modifications for the actual
purpose, and the possibly increased hardware cost which is due to overheads compared
with an optimized full-custom model.
6.2.4. Cost of Model Disposal

At first glance, it may sound strange to think about a disposal problem in the context of
models. Cost of disposal here is cost of pruning the repertoire of maintained models
inside an organisation. Such situations can arise when, e.g., software licences or
hardware maintenance contracts cannot be cancelled because they are needed to
maintain, update, etc. design data including models. It is realistic to assume that many
systems need to be supported although they are technically obsolete just because they
are required to fulfil long-term delivery contracts of certain ICs.
Disposing of these models requires an inventory in which these models are used and a
replacement of the model instances by functionally equivalent alternatives. As in the
other cost domains, getting acquainted with the models and their modification form part
of the disposal cost.
106 CHAPTER 6
6.2.5. Levels of Complexity

The level of complexity of a model certainly has a major impact on the modelling cost
and the feasibility of re-using such a model. Rather than defining the complexity of the
different levels in absolute terms, e.g. number of equivalent logic gates, it is more
appropriate to define a generic taxonomy of complexity which is independent of the
current integration capabilities of microelectronics technology. While the number of
gates which today build a complete system will in few years be needed for a subsystem,
the generic characteristic of a system to be composed of subsystems is time-invariant.
6.2.6. Initial Specification

Each design process with the exception of minor re-designs will start with the capture
of the global functionality of the system. In many cases, there exists only a vague
concept as to how the system to be developed should look like. An informal description
of the first ideas very often provides the starting point for the specification process.
Success on further system development depends on the ability to transform the
imprecise ideas into a more formal and precise description. To detect errors and
inconsistencies in a system specification as early as possible, it is necessary to have an
initial understanding of the planned system's basic concept. In many cases, this
specification is not yet based on a hardware description language. This model is the
interface between marketing/customer and designer.
6.2.7. System Modelling

The next step of the design is the formal specification of the system behaviour in terms
of a hardware description language. The result is a simulatable, but generally not yet
synthesizable specification. Often different specification mechanisms are used to create
the model or parts of the system, e.g. state transition diagrams, time diagrams, etc. The
model consists of one or more behavioural level processes. It is subject to validation by
simulation and builds the baseline of the next design step, the structural decomposition
into subsystems, and their communication. In some cases, a previous system model will
be re-usable for specification of next generation subsystems, although it had not been
designed for re-use in the first place.
6.2.8. Subsystem Modelling

A subsystem comprises a major functional unit of a system. Again, different methods
may be used to generate the models. In contrast to system models, however, the
probability of re-using subsystem models is much larger. Different combinations of
cores and periphery subsystems may be useful for different applications, and a value
addition may be created simply by new combinations of subsystems into systems. In
order to enhance the reusability, functional modifications should be possible at low
cost, and the functionality should be completely encapsulated in order to support
getting easily acquainted with the model. In many cases, subsystems will be modelled
for re-use from the beginning. Even if not achievable with current synthesis technology,
subsystem models should be targeted to synthesizability.
6.2.9. Cell Modelling

The basic building blocks targeted during logic synthesis and technology mapping are
standard cell models. A cell library is a relatively fixed repertoire of simple logic gates,
latches and registers, supplemented by memory generators and a large variety of
periphery blocks. The functional modelling of these cells is straightforward. The
maintenance is limited to the (semiautomatic) characterization of new processes and the
adaptation to new design frameworks, the latter hopefully becoming less frequent with
standards like VITAL. Of course, these cells are only designed for re-use, but the effort
to really re-use them is minimal due to their simple functionality. Furthermore, the cell
re-use is usually done by tools rather than by designers.
6.2.10. Best Gain Domains of Re-Use

From the previous ideas about the different importance of modelling cost and the
relevance of re-use at the different levels of complexity, it can easily be concluded that
the reduction in cost of re-use at the subsystem level is most promising. Subsystems are
likely to be re-used, hence they inhibit the potential of significant total design efficiency
increase. At the same time, the cost of re-using subsystems is regarded as high because
they are functionally complex, expensive in initial modelling, shared in design teams, and
subject to functional modifications and technology migrations. Additionally, applying
new tools and design methodologies to this level is a natural extension of the bottom-up
evolution of the design automation process.
From the modelling efficiency point of view, a reduction in cost and development time
of the initial specification is also of high priority, and their suitability for efficient re-use
is very important.
6.3. OBJECT-ORIENTED TECHNIQUES

The results of the analysis of modelling cost as given in Section 6.2 suggest checking to
what extent the modelling cost can be reduced by applying object-oriented methods to
hardware design.
6.3.1. Introduction
The fundamental concept of object-oriented programming is a system of communicating
objects. This is antagonistic to the concept of hierarchically structured sequential
algorithms of non-object-oriented imperative programming. Each object is characterized
by attributes whose values define the state of the object. The attributes' values can be
modified by a repertoire of methods. The communication amongst the objects is done
by invoking respective methods of the target object. Object-oriented programming
techniques are usually characterized with buzz-words: class, inheritance, object,
polymorphism, method, encapsulation and message passing.
Objects are instances of a class. Inheritance allows us to create a class hierarchy in
which common features of several classes are specified in a parent class. This class
hierarchy and the inheritance concept allows us to specialize and generalize objects.
108 CHAPTER 6
Both support the re-use of models. Creating variants of objects in non-object-oriented

modelling techniques is usually done by copy, modify and paste. This results in a
multitude of versions which differ in details only, contain a lot of redundancy and are
difficult to administrate. In particular, problems occur when modifications are needed in
parts of the models which are common to all different versions. The consistency of the
model database can only be maintained at high cost and risk, because such modifications
need to be made in many models, and it is difficult to prevent introducing side effects. A
clear advantage of a class hierarchy and an inheritance concept is the better re-usability
of objects, through the easier administration of the version multitude.
Polymorphism is the capability of an object-oriented language to handle several versions
of a method, i.e. operations in different classes of a class hierarchy, with the same name.
In contrast to the VHDL type of operator overloading the particular instance of the
method to be invoked is determined at run time of the model (late binding). The criterion
for this selection is the actual class of the target object. In VHDL operator overloading,
the binding is done statically at elaboration time depending on the number of parameter
associations, the types and order of parameters, the names of formal parameters, and
the return type of function calls. This early binding neither allows us to dynamically
compute the target object during run time nor to have non-static parameter types.
As stated earlier, an object can be viewed as a finite state machine with state attributes
(instance variables) and state transition and output functions (methods). The instance
variables can be accessed by sending externally visible methods of the object to the
target. If this is the only possible access, the instance variable is encapsulated, since the
client of the object does not need insight into the internal structure of the object.
Modelling objects without the encapsulation of attributes and functions allows a
specification style in which the control and data flows are separated. If the data flow
has to be changed in the specification, even if the change is limited to a small part of the
design, then probably one or several affected controllers distributed somewhere else in
the system, even in other levels of the description hierarchy, have to be identified and
changed. A small change in the data flow can cause a major re-design of a global
controller. For example, if an additional storage element is introduced in a dataflow, then
probably the whole clocking scheme has to be re-designed. This interpretation explains
why it is much easier to re-use data-driven designs like, for example, filters without
global controllers than to re-use control-oriented designs. Therefore, encapsulation not
only provides an abstraction, but reduces implementation dependencies between objects
to the set of visible methods.
6.3.2. Objects in Hardware Design

It is the intention of this section to elaborate on what are suitable objects in hardware
design for the application of object-oriented modelling methods. As stated earlier,
physical objects have traditionally been the subject of the design process. This has been
obvious, because each single design step has been a bottom-up design step, even in a
globally top-down design flow. This statement is at least valid for the lower levels of
design at which a design step is usually a structural composition of predefined elements.
These may be available partly in abstract form, e.g. as DesignWare, CAD algorithm, etc.
Even a RT-level model is a structural model of elements of a fixed repertoire of

predefined operators.
An object orientation of a design flow which is based on physical components suggests
considering VHDL entities as objects. They would have to be provided with the
respective capabilities of object-oriented programming. Inheritance could support the
derivation of one entity from another with the addition of new services (methods).
Encapsulation could be supported by an additional interface concept to allow for the
invocation of methods. Polymorphism would allow the dynamic activation of different
entities during runtime. A respective approach has been proposed [5,19] as part of the
us RASSP program.
This is an algorithmic model which for the first time allows a designer to specify a
circuit without any forecast of the hardware components to be used later. It is not the
goal of synthesis to map the algorithmic specification into an isomorphic hardware
structure; the algorithm is rather a possible example solution for the design problem.
Hence, the subjects of the intellectual design process from the algorithmic level upward
are not existing hardware components, but rather abstract concepts for solving the
design problem. This point of view requires a radical change in paradigms, since a real
top-down design process becomes possible. The objects of the design process are now
abstract processes running on a simulation engine. Each process is characterized by its
state space and its 110 behaviour. The later hardware structure is not implied by the
structure of the algorithmic specification, but may be chosen freely as long as the
functional correctness is maintained. This freedom is currently not yet fully exploited
by high-level synthesis tools, but could lead to better manually optimized results even
today.
An object orientation of this view of the design process would require supporting
object-oriented modelling of data structures. Objects are abstract containers, which can
accommodate extendible (inheritance, class hierarchy) data types. The values of these
containers could be manipulated via method calls (messages). An encapsulation could be
achieved by an exclusive access via visible methods [17].
In conclusion, one can state that there are at least two different paradigms of object
orientation in hardware design. The evolutionary design is based on existing physical or
synthesizable design objects and suggests an encapsulation based on structure [5,19].
The implementation is the re-usable intellectual property right here. The shift in
paradigms required from the designer is moderate, because he/she can stay with the
traditional bottom-up way of designing. If, however, a real top-down design is
envisaged which does not utilise existing physical or synthesizable hardware
components, a shift in paradigm towards a data-type-driven object orientation provides
more abstract modelling power. Here abstract algorithms and data concepts for solving
the design problem are the re-usable intellectual property rights. An increase in
productivity is expected during the specification and high-level design phase. pue to the
consistency between this paradigm and the object orientation as used in software
engineering, a good support of hardware/software co-design is expected. A
corresponding concept has been developed by Oldenburg University and OFFIS [17].
110 CHAPTER 6
6.4. ACCEPTANCE OF NEW DESIGN

TECHNIQUES
Introducing new design techniques and CAD tools only seldom leads to an
instantaneous increase in designer productivity; in contrast, about 70% of the designers
expect a temporary decrease of productivity [20]. The extent and duration of this
decrease compared with the expected medium and long-term increase are important
parameters in the decision process of whether to introduce changes in the design
process.
In many cases, a compromise between a smooth transition and an optimal final goal is
sought. An example is the success of C++ compared with Smalltalk. Smalltalk had been
developed and implemented in a research environment. Smalltalk may be regarded as the
mother of object-oriented programming languages. It was a complete new development
implementing the concepts of object orientation in their purest form. Still, Smalltalk
could not compete with C++ in software industry. One reason is certainly the close
relationship between the industry standard C and C++ which promises low transition
cost and compatibility. This statement is supported by a survey of the US EDA-user
organisation USEIDA [20], according to which 75% of the designers mention
insufficient compliance with standardized hardware description languages as reason for
changing a CAD vendor.
Several languages exist in the domain of hardware specification which partly support
object-oriented modelling [16]. One of them is SDL-93 [3], which is CCITT standard
and used in the telecommunication domain. Because of this limited user community, it is
insufficiently supported by tools. In particular, a link to further synthesis steps is
missing. Hence, SDL only supports the specification phase. In the course of the design
process, the designer has to use other languages. An automatic translation of SDL
models into VHDL has to fail due to some concepts of SDL, e.g. the dynamic creation
of processes [16]. This example demonstrates that just the standardization itself does
not provide a sufficient user base which finances the development and maintenance of
the required tool set.
Hence, an object-oriented hardware description language needs to be standardized and
target a large user community to be successful. Today, VHDL has the largest user
community in Europe and US even compared with Verilog. A standardization of object-
oriented extensions is possible if they are compatible with the fundamental concepts of
VHDL, allow for an upward compatibility of models, and whose cost introduction and
tool development are less than the expected gain in productivity.
Both proposals mentioned [5,17,19] use constructs of Ada [9] and have links to the
analysis methods by Booch [2] and Rumbaugh [11( A detailed comparison of both
proposals has been published in [10]. They are currently under discussion in the
corresponding standardization committee2 •
I Meanwhile a unified notation and concept is under development

2 DASC Study Group on 00 Extensions to VHDL
Additionally, it is important to understand that an object-oriented modelling language

by itself can only provides a limited gain. Its full power can only be utilised if linked
with an adapted design methodology, as proposed in the ESPRIT project 8641,
INSYDE [8]. A basic idea of the concept is the combination of object-oriented analysis
and design techniques with an appropriate implementation language. The methodology
has to provide a clear technique for the translation of the model into a hardware
description language, especially in case of re-use of a modified specification together
with an existing implementation. The next section gives a survey on such an analysis
and design technique.
6.5. SURVEY ON THE OBJECT MODELING

TECHNIQUE FROM RUMBAUGH
A variety of object-oriented specification methods already exists[2,4, 11,18]. They
differ mainly in their notation and the design steps from a first specification model to an
implementation. A compact overview can be found in [8]. One of the well-known
methods is the Object Modeling Technique (OMT) from Rumbaugh[ll]. It serves as a
specification method for the examples in this chapter and is used to illustrate the design
step from the specification to the implementation in an object-oriented language. This
section gives a brief overview of OMT.
OMT is an object-oriented specification technique which makes it possible to describe a
system at a very abstract level. The design process in OMT starts with an analysis. It
characterizes the system and its problems. The result of this step should be an abstract
and compact description of what the system does. It is not necessarily complete, and
some of the details have to be added later on. It is important that the main ideas of the
system are not hidden by too many details in that early stage of the development. While
not constricting the design space, no decision restricting a further implementation
should be taken at that time. This means in the analysis phase that the model should not
contain implementation details. In further design steps, additional information is added
to the description in the form of refinement steps[15]. Such a description consists of up
to three different views, called models. The basic view is called object model[12]. It
characterizes the static structure of the system in terms of objects and classes and their
relation to each other. Each object and class is described by its attributes and
operations. As objects are instantiations of classes, the attributes of objects contain
concrete values. As an example, an object model for a simple processor is shown in
Figure 1. Each class is drawn in the diagram as a rectangular box, consisting of three
parts. The name of the part is written in the top part, the middle part contains the
attributes and the bottom part contains the operations. In the processor, for example,
the class processor system has the operation execute operation. The structural relations
between the classes are drawn in the diagram as lines between the boxes. Mainly three
different relations can be distinguished. An association is a relationship that contains
information that is relevant for a certain time during the existence of the described
system. A role belongs to each member of an association, which is a class or an object.
It describes how a member of an association is viewed by the other members. Each role
can be named by a rolename. The role also indicates how many instances of the class
112 CHAPTER 6
can be associated in a binary association with one instance of the other class. This can
be denoted by a number as in the example in the association between the processor
system class and the operand class. A special form of an association is an aggregation.
As a class can be a member of different associations, the role is not assigned directly to
a class but to the corresponding end of an association. It describes a whole-part
relationship. It is marked by a diamond. In the example, an instantiation of the class
memory is part of the whole processor system. A third relationship is called
generalisation. This is the most important relationship concerning the re-use of the
system. It describes the relationship between superclasses and subclasses. A subclass
inherits all attributes, operations and associations of a superclass. The notation for this
relationship is a triangle. In the simple processor, for example, the class load is a
subclass of the superclass instruction. This means it inherits the operation
execute instruction from the class instruction as well as the aggregation
between processor system and instruction together with the role
instruction register. Ifa new class without additional relations is derived from
the class instruction to extend the system specification, then no changes appear in
the rest of the object model. For a more detailed description of the classes, their
attributes and associations, a data dictionary completes the diagrams of the object
model. It contains information about the entities of the object model as text. The
dictionary of the processor, for example, contains the entry: Accu: store for
the operands and results of instructions.
Processor system
execute instruction
<>
0
?
Memory
V
write(datum,address)
y
read(datum ,address)
I Datum
l
A
value 2 I I I instruction register
Address Operand Instruction
value value execute instruction(processor system)

increment
I
I I I
I Load
Ir Store l r Addition l r Subtraction I
Figure 1: Object Model
Another view is the dynamic model[13]. In this view, objects are considered as entities
having a state which is detennined by the value of its attributes. As a reaction to certain
events caused by other objects of the model, an object can change its state by changing
its attributes. In particular, the attributes that are affected by the change of the states
are described in the dynamic model. They are called state variables. The dynamic
behaviour of the objects is described by state diagrams in a notation adopted from
David Harel[7]. Such a state diagram can be seen in Figure 2.
idle
write (write_address: address; write_datum: datum);
\decode address
Asender of
read event.
write access
return datum
(datum)
Asender of write event (acknowledge)

do\ datum := mem(address)
Figure 2: State Diagram of Memory

It describes the life of the object memory of the simple processor example. The states
of the object are the nodes, and the transitions are the directed arcs. The object starts its
life by entering the state idle. If a read event is caused by another object in the model
with the parameter read address, then memory changes its state to read. The
event is annotated to the transition arc. When changing the state, an operation decode
address is executed. In the new state read an activity datum : == mem (address)
is started. An activity is an operation within a state which consumes time. When the
activity in the state read has finished, the object memory changes its state back to
idle. In the latter transition, an event is sent to another object in the model. The target
is the sender of the read event, and the event is return datum with the parameter
da t urn. An event flow diagram is used to describe which objects are interacting by
sending each other events. Figure 3 shows an excerpt of such a diagram, which describes
the interaction of the object memory. For example, the object store can send an event
read with parameter address or an event write with parameters address and
datum to the object memory. Memory in tum can send an event return datum
with parameter datum to the object store. As can be seen from the small example,
this view is useful to describe the control flow in a system.
The operations which alter the entities of the system are described in a third view called
the functional model[14]. Different techniques are used to describe the operations in a
system. One method describes the state before and after the execution of the operation.
In the simple processor, the operation increment of the class address, for example,
is specified by describing the value of the attribute address value as x E A before
the operation and x + 1 E A after the operation, being A the address space of the
processor system. The operation is not defined for x + 1 !2: A (see Figure 4).
114 CHAPTER 6
instruction register: Store
write : read(address) : 1: return datum(datum)

(datum,address)
main memory: Memory read(address) processor
______ ~e~~r~ .?~~u~(~~t~r:n! __ . .

L -______- . . -__________________~ ~------~
,read(address) , return datum(datum)
instruction register: Load I
Figure 3: Event flow diagram of memory
Operation: increment
Responsibilities: increments the address value of an address
Inputs: address value
Returns: none
Modified objects: address values
Preconditions: address value is a valid address x E A , A is the address space
Postconditions: address value is a valid address x + I E A
Figure 4: Operation Specification

To explain how an operation affects the objects and their attributes in a particular state
of the system, an object-oriented dataflow diagram (OODFD) can be used. An example
is given in Figure 5.
The example shows the data flow for the execute instruction operation of the
class processor system. It describes the data flow between the objects and the
transformation of the attribute values in that flow by the operations regarded as
functions. The value of the attribute address value of the object address register,
which is an instantiation of class address, is an input of the operation read
memory of the object main memory. The result of the operation is an input for the
operation execute instruction of the object instruction register. The
further data flow depends on the instruction performed by the system. The shown
OODFD describes a store operation. The address value of the address
register is incremented. The result is a new address value. It is marked by a
tick. The new value replaces the old value of the attribute. Finally, the value of the accu
is written into the memory.
A second technique is the procedural description of the operations. This means that the
operations are described by invocations of other operations in various objects of the
system. To specify the sequence of invocations and the corresponding messages
between them, an object interaction diagram (OlD) as can be seen in Figure 6 is used.
address register: Address processor: Processor system
Iaddress value I
C2ncrement"
Iaddress value' I
,
main memory: Memory accu 1 : Operand
\Imemory array I write

~
t T
read memory array I
memory array' I
instruction register: Store
execute instruction
Figure 5: Object-Oriented Data Flow Diagram for Operation Execute Instruction of

Object Processor
I
processor: Processor system
I
~ 1.3: Y.1. 1.4:
<> .1.1.2:
<> .1. 1.1:
<>
load ( I execute instruction read memory
(address value) :=
read address value
instruction) (instruction) := address value
instruction
instruction 1'[ instruction main memory : address register: accu1 : Operand

register: register: '- _ _ _ _ Memory Address
Instruction Store: ...., 1.4.4: write(
...: address, L -_ _ _ _---I
operand)
L _______________ ~
-> 1.4.1: increment

-> 1.4.2: read address value := address
L _______________________ J
...., 1.4.3: read accu := operand
Figure 6: Object Interaction Diagram for Operation Execute Instruction of Object

Processor
116 CHAPTER 6
The diagram characterizes the same situation as the OODFD in Figure 5, but from a
procedural point of view. It shows that the processor system sends a message to
the object of class address to get an address value. This value is used to send a
message to the memory to read the memory. The numbers define the sequence and the
hierarchy of the operation invocations. The non-permanent associations which are
established by sending a message are drawn as dotted lines. The latter technique
provides models which are closer to an implementation than the functional views. This
means that a first analysis model probably contains OODFD, which are supplemented
during the further refinement steps by OID. The specification of operations in a very
abstract functional view is transformed in further design steps to a procedural
implementation, which is a sort of algorithmic description and therefore close to an
implementation in an appropriate computer language. The following section gives an
overview of a proposal [17] to extend the hardware description language VHDL by
object-oriented concepts to provide an appropriate implementation language in the
sense mentioned above.
6.6. THE IMPLEMENTATION LANGUAGE

The basic idea behind the object-oriented extension to VHDL is to identify and enhance
existing concepts for classification and generalisation in the language. It must provide
constructs to establish associations like an aggregation between classes. Such language
capabilities allow a mapping of the corresponding OMT constructs into the
implementation language. A powerful mechanism for classification in VHDL is the type
concept. It allows for a category of types specialisation by subtype construct, which is
the counterpart to generalisation. However, only constraints can be added to existing
type definitions. An incremental specialisation which adds information to existing
definitions is not possible. The type concept of VHDL knows aggregation in the form
of record types. Because of the existing properties of the type concept, the heart of the
language extension is a new record type, which can be incrementally specialised.
Enabling classification in a hardware description language not only for existing real
world components but also for more abstract classes makes sense, as can be seen from
the processor example presented in the previous section. For classification of an
abstract object like an address, a data type is well suited.
To support these extended requirements, a new kind of record could be introduced in
VHDL. A keyword tagged distinguishes the new record type from the existing one. The
new record type can be used to build up a type hierarchy. In that type hierarchy tagged
record subtypes can be derived from existing tagged record types, but in contrast to the
known subtype concept, the derived subtypes are not specialised by constraints but by
adding additional properties to the subtype. This establishes an inheritance mechanism
in the language. Each tagged record has a tag which determines the position of the record
in the hierarchy. To build the hierarchy and derive new types from existing ones the
keywords new, and wi th are introduced into the language extension. New is followed
by the record derived from and wi th specifies the record elements added in the
specialisation. Listing 1 gives an example. The type da t um is an empty tagged record.
To specify some abstract types, it makes sense to allow the declaration of empty
records. The type address value is derived from datum and contains the
additional record element address value. According to each record definition,

procedures can be declared containing at least one parameter of the tagged type and of
mode in or inout. The declaration of the tagged records and the procedures always has
to occur in one package. This ensures that the procedure is visible whenever the tagged
type is visible. Together with the record elements, the according procedures are
inherited by derived tagged records. By adding new procedures to derived tagged records
or overwriting existing ones, the tagged types also can be specialised. An example is
given in Listing 2. Without re-specifying the procedure execute instruction, the
type load would inherit the procedure from the type instruction. This approach
is similar to the tagged types from the programming language Ada 95[9]. It is possible
to create types which are compatible with the types within an inheritance hierarchy by
appending the attribute 'CLASS to a type mark of a tagged record. Such a compatible
type is called class-wide. Objects of class-wide types can contain values of the tagged
record and all records derived from it. An example can be seen in Listing 3. The record
element instruction register of the tagged record processor system is of
class-wide type instruction'CLASS. It can contain all types derived from
instruction, for example, the derived type load. Such an object which can contain
different types is called a heterogeneous object container. As mentioned above, the
actual type of a tagged record (in this case of the instruction register's)
content can be determined by its tag. This concept is different to Ada 95 because no
access types are necessary to create such object containers. Class-wide types offer the
possibility to specify behaviour in a very abstract and general way. This is illustrated
by an example in Listing 4. It describes how an instruction is performed by qbjects
of the class processor system. An instruction is read from the main
memory into the instruction register. Then a procedure execute
instruction is called with the instruction as parameter. The according
procedure matching the actual parameter type is determined during runtime, and the
corresponding procedure is executed. It is not necessary to distinguish different
instructions and to describe which concrete version of this procedure has to be invoked.
The general algorithm describes the execution of an instruction for the derived type
load as well as for any other type derived from the parent's type instruction.
Expressed in object-oriented terminology, this means the procedures are polymorphic
methods of the classes defined by the tagged type definitions. After the survey of the
OMT and an introduction into the language extension to VHDL (E-VHDL), the next
step is to show how OMT models of hardware systems can be transformed into E-
VHDL.
type datum is tagged record

null;
end record;
type address is new datum with

address_value: integer;
end record;
Listing 1
118 CHAPTER 6
type processorsystem; -- incomplete type definition for interface

-- specification of execute_instruction
type instruction is new datum with
record
null;
end record;
procedure execute_instruction(command : in instruction;

processor : inout processorsystem
) ;
type processorsystem; -- incomplete type definition for interface

specification of execute_instruction
type load is new instruction with
record
null;
end record;
procedure execute_instruction(command : in load;

) ;
Listing 2
type processorsystem is tagged record

main_memory: memory 'CLASS;
instruction_register: instruction'CLASS;
address_register: address 'CLASS;
accu : operand'CLASS;
accu2 : operand'CLASS;
end record;
Listing 3
already visible:
use work.memory-package.all;
use work.instruction-package.all;
use work.address-package.all;
use work.operand-package.all;
use work.datum-package.all;
package body processorsystem-package is
procedure execute_instruction(system : inout processorsystem) is

variable tmpdatum : datum'CLASS;
begin
read_memory (system.main_memory, system. address_register, tmpdatum);

system. instruction_register := tmpdatum;
execute_instruction (system. instruction_register, system );
end;
end processorsystem-package;
Listing 4
6.7. FROM SPECIFICATION TO

IMPLEMENTATION
The translation of OMT models into a E-VHDL description is the last refinement step
in the object-oriented design flow in which information about the desired behaviour and
functionality is added to the system description. Although the different OMT models
cannot be translated independently into an E-VHDL description, it is quite useful to
start with one model and then supplement the description when translating the other
models. It is practical to start with the object model as it is the core of the OMT. This
model can be translated to some extent straightforwardly into a data structure. Each
class becomes a tagged record type with the attributes as record elements. Aggregations
are transformed into record elements of the corresponding tagged record type. Often the
role name can be used as the element's name. Generalisation in the object model is
turned into a corresponding inheritance hierarchy of tagged records. It has to be noted
that a subclass inherits all the associations of its parent's class. As a consequence,
aggregations with a parent's class have to be expressed by record elements of a class-
wide record. Multiplicity has to be modelled by an appropriate number of
instantiations.
An example of such a translation is given in listing 3. The processor system with
its four aggregation associations is described as a tagged record with five record
elements. The elements are all of class-wide type, so that the association exists for
derived classes, too. The role instruction register of the aggregation between
processor system and instruction is inherited by the class load (see
Figure 1). The class-wide type instruction CLASS of the record element
I
instruction register realizes the association for the type instruction as

well as for the type load and any other derived type. The multiplicity two of the role
accu as part of the association between the class processor system and operand
is described by two record elements.
The processor example illustrates an unproblematic situation. There are, however, some
specification constructs which are difficult to translate. For example, if the memory is
modelled as aggregation of memory cells with a multiplicity of many without an exact
range specification, the translation causes problems. A possible solution would be to
constrain the multiplicity in the model by a fixed range and to describe the aggregation
with an array. However, this solution does not always work. If dynamic behaviour was
intended by such a description containing mUltiplicity of many, the translation does not
meet the original intention of the specification.
Another similar problem with dynamic behaviour arises when recursive structures are
used in a model. An example is given in Figure 7. A s t a c k consists of a s t a c k
e 1 emen t and probably of a s t ac k. The implementation causes problems because a
record element cannot be of the same type as the record to be defined. A solution would
be the use of incomplete type definitions and pointers. Its disadvantage for hardware
systems is that pointers can not efficiently be synthesized. If possible, the recursive
structures have to be replaced by equivalent non-recursive specifications. Generally,
objects which are to be implemented as hardware components cannot be used in the
specification with a dynamic behaviour. Dynamic in this context means the creation and
120 CHAPTER 6
destruction of an arbitrary number of objects, which IS not exactly defined at

specification time, during runtime.
Figure 7: Recursive Stack Specification

A structure of the object model which has no equivalent in the implementation language
is the parallel generalization. It would require a mechanism for multiple inheritance in
the language. Such a mechanism would allow the inheritance of record elements and
procedures from two or more tagged records at once. This requires complex rules for
cases in which naming conflicts arise by deriving from two or more classes
simultaneously within the same inheritance hierarchy.
There is a variety of different translation possibilities for the implementation of the
dynamic model. One possibility is to use modelling techniques known from VHDL. The
states are encoded by an enumeration type. A next state function uses a case statement
to distinguish between different current states and inputs and determines the next state.
The state variables which are attributes of the classes are modelled by record elements
and the next state functions by methods. Another possibility would be to model each
state in a separate class, derived from a common parent's class. Each class has its own
next state function as a polymorphic operation. Such a state can contain a sub-state-
machine as an attribute. This machine could be started when the state-machine enters
the composite state, consisting of a state machine. The state machine is then
implemented by an instantiation of an object of class-wide type, which contains the
actual state. Especially for state machines with operation calls as events and activities,
dynamic models can be implemented by a procedural description of the activities. The
different states belong to different places in the procedural description. As an example,
an implementation of the dynamic model of the memory (Figure 2) is given in listing 5.
A call of the operation wr i teas an event causes a state transition. The generated event
is implemented as a method call of the target object of class address. The activity of
the state wr it e is modelled as an access to a record element. In the example, several
events are generated. The acknowledgement that a wr i t e operation is performed is
implicitly included in an implementation of a message as a sequential procedure call.
The calling procedure is blocked until the write operation is performed. The
precondition to implementing these events is that the targets of the events be visible at
the place where they are generated. In contrast to the classes and objects in the OMT,
the tagged records and instantiations are introduced into the model in a sequence. To
enable operations of classes to trigger events for targets of classes defined later in the
sequence, it is permitted in the implementation language to use incomplete-type
definitions of tagged records as parameters in operations.
package body memory-package is
procedure write_memory(mem : inout memory;

write_address: in address'CLASS;
write_datum: in datum'CLASS
) is
variable tmpinteger : integer;
begin
address2integer(write_address,tmpinteger);
mem.memory_array(tmpinteger) .- write_datum;
end;
procedure read_memory(mem : in memory;

write_address: in address 'CLASS;
read_datum: out datum'CLASS
) is
variable tmpinteger : integer;
begin
address2integer(write_address,tmpinteger);
read_datum .- mem.memory_array(tmpinteger);
end;
end memory-package;
Listing 5
An example is given in Listing 4. The sequence of declaring processor system and
load is determined by the implementation of the aggregation between them. (The
aggregation is described in Figure 1.) Instruction and derived classes like load have
to be declared before processor system to become part of it. To use processor
system as a parameter of the procedure execute instruction, its type can be
defined incompletely. As the encapsulation concept of VHDL is very strict, it is often
necessary to make the target of the events visible within the scope of the triggering
object by passing the objects as parameters. This is illustrated in the example. Although
the operation loa d is executed within the pro c e s so r s y stem and the
instruction register containing the load is part of the processor
system, it is necessary to pass the processor system as a parameter to the
operation execute instruction to make it visible within the procedure. This
parameter passing can become very cumbersome. To determine the required visibility of
objects within scopes, an event flow diagram can be quite useful. It shows the objects
and the events sent to each other. The example in Figure 3 shows that the object main
memory has to be visible in the operation of class load. This is realized by passing a
parameter of type processor system, which contains the object main memory
as record element, as shown above.
As in the object model, there are some constructs in the dynamic model which cannot be
easily implemented into E-VHDL. There exists no simple equivalent in the
implementation for the specification of a composite state containing several parallel
working state machines.
The implementation of the operations described in the functional model consists of
transforming the non-procedural high-level specification into a procedural description.
122 CHAPTER 6
Transformations from the non-procedural view, describing the state before and after an
operation, to the procedural view can already be applied in the functional model. The
implementation in E-VHDL is the continuation of this action. As an OODFD shows
the effect of an operation across many operations, it is useful among other things to
determine the visibility between the objects. The techniques to establish the required
visibility in the implementation is the same as described for event flow diagrams. If an
object interaction diagram exists, then the sequence of messages it describes can be
transformed into the corresponding sequence of procedure calls. Again, visibility
aspects have to be considered, including transient links between objects. The functional
model of the operation execute instruction shown in Figure 4 and 5 is
implemented in Listing 4. The messages 1.1 to 1.4 are implemented as procedure calls
and read/write operations on attributes in the procedure execute operation. The
effect on the objects instruction register, main memory, address
register, and accu for the instruction store as a result of message 1.4 is described
by messages 1.4.1 to 1.4.4. That means that the latter messages are sent in the operation
execute instruction of the class store.
It has been outlined and illustrated by an example how an OMT model can be
transformed with some limitations into an implementation. The major restrictions are
the lack of unconstrained multiplicity, the missing constructs for multiple inheritance,
and the difficult implementation of composite states with parallel working sub-state
machines. The model consists of objects implemented as tagged records and
polymorphic procedures. All messages are realized as sequential procedure calls. Some
effort has to be made to make objects visible to each other. This is achieved by passing
the concerned objects as parameters into the operations. Re-use of the OMT model by
deriving new objects from existing ones is supported by the implementation.
6.8. PARALLELISM IN HARDWARE SYSTEMS

The modelling presented in the previous section is based on a sequential description of
the model in the implementation language. Parallelism has to be introduced in further
design steps, when the scheduling is done automatically to improve the performance of
the system. The idea is that the order of execution of sequential statements between
two wait statements is only determined by dependencies caused by variable
assignments. The automatically introduced concurrency is fine-grain on small parts of
the system. To introduce a coarse-grained concurrency at system level, it has to be
explicitly specified in the model. The OMT offers several constructs to express
parallelism. For example, it would be possible in Figure 6 to specify a concurrent
sending of messages 1.4.2 and 1.4.3 by re-indexing both messages as 1.4.2. The
implementation language offers two notions of parallelism which are strongly correlated.
For simulation, both are based on a discrete simulation time. One concurrency concept
is based on parallel running processes which are synchronized by wait statements. A
second concept can be found in the parallel update of signals. This allows us to express
parallelism within one process. For example, ifin Figure 6 the messages 1.4.2 and 1.4.3
are specified to be sent in parallel, as mentioned above, then the implementation of the
address value and the operand as signals together with a wait statement allows
updating of the values as a result of the messages in parallel. As can be seen from the
example, this kind of implementation for concurrency is limited to special cases. It only
makes sense if the effect of the messages has to be a parallel update of attributes of
objects. For specification concurrency at system level, the concept of parallel running
processes is appropriate in most cases.
In the specification of synchronous hardware systems, control messages are often based
on a clocking schema. The processing time of the hardware components executing the
operations invoked by the control messages has to be considered by the control units as
senders of the messages. The problem is that the information about the processing time
of complex operations is not known until implementation. It is possible to annotate
processing times as constraints in a specification, but there is not guarantee that they
are met by an implementation. As most operations are specified in a non-procedural
view at system level, it is not possible to guess realistic processing times. Even during
further refinement steps, it is difficult to predict processing times for operations which
are performed by sending messages to other objects, which themselves send messages.
If the sequence of control messages sent to other objects is based on a fixed clocking
schema, then the invocation of polymorphic operations is only possible if they fit into
the same schema. The constraints given by the schema are inherited by derived objects
even if the operations are re-defined. This is an obstacle for re-use.
For example, ifin Figure 1 the operation execute instruction of the processor
system is implemented based on a fixed clocking schema which expects the operation
execute instruction of the object instruction register to be performed
within ten clock cycles, then all derived instructions have to implement the operation
with a processing time of ten clock cycles.
A quantitative specification to define the time when a message has to be sent by
counting clock cycles is in most cases not appropriate for re-usable operations. The
synchronisation should be specified in a more abstract way by describing the timing
dependencies between the operations relative to each other. Parallel running objects can
be implemented by the declaration of objects as variables in different VHDL processes.
The processes may be declared in the same or different architecture of different entities.
The declaration of the classes as tagged record types in packages can be used in several
entities. As objects can be instantiated in different processes or entities aggregated
objects can be modelled by a connection between the processes or entities, instead of
tagged records containing other tagged records as record elements. Depending on the
specification, a mechanism has to be implemented for the synchronisation of the
objects. A similar concept can be applied in some cases to implement a specification
which allows parallel access to an object and its methods. It can be modelled as an
object consisting of an aggregation. The attributes are modelled as separate objects in
different processes. These objects contain operations to solve access conflicts.
The memory of the example can be used to illustrate the concepts for objects in parallel
running processes. If the memory and the rest of the processor system are both
modelled as an object running in parallel, then the implementation consists of two
processes. In the implementation, a link in the form of signals has to be defined between
the processes which enables the processor system to invoke the operations of the
memory and enables the memory to send back the results of the operation. This is
described in more detail in Section 6.9. Listing 6 shows an implementation of the
124 CHAPTER 6
operation execute instruct ion in the sequential model. In a parallel design, the
object memory can be modelled together with a new implementation of the operation
read memory in a process running in parallel to another process, which implements
the rest of the processor system. The procedure call read memory in the
operation execute instruction then has to be replaced by an invocation
mechanism for a new implementation of the operation read memory of the object
memory, which is now implemented in a different process. The procedure execute
operation, which invokes read memory, has to be blocked until the new
implementation of the operation, which consumes time, has finished and a result is
returned. But there is no advantage of such a mechanism based on blocking the caller of
an operation over the sequential implementation of all objects in one process. To
enhance the model, the increment operation has to be invoked after sending the
message to start the read operation. The read operation has to be divided into two
parts: one starting the read operation and one receiving the results. In the example, the
result has to be received before it is written to the accu. If several results are returned
by the operation at different times, then the operation has to be split up into even more
parts. The problem is that such split operations performing accesses to objects at
different points of time cannot be polymorphic. The number and the time of accesses of
a polymorphic operation may differ in the various actual operations. A pragmatic
solution would be to divide each operation into only two parts, one to send parameters
and one to receive all results at once. For the invocation of the first part, the earliest
possible time is chosen and for the second part, the latest. The presented problem is
independent of the chosen implementation language. As a consequence, the best thing is
to choose a sequential implementation for those objects which are not explicitly
specified to run in parallel and to perform the transformation into parallel components
automatically during resource allocation in a further design step.
use work.address-package.all;
use work.processorsystem-package.all;
use work.memory-package.all;
use work.datum-package.all;
package body load-package is
procedure execute_instruction(command in load;

) is
variable tmpdatum : datum'CLASS;
variable tmpaddress : address 'CLASS;
begin
increment(processor.address_register);
read_memory (processor.main_memory, processor. address_regi ster,
tmpdatum) ;
tmpaddress := tmpdatum;
read_memory(processor.main_memory,tmpaddress,tmpdatum);
processor.accu := tmpdatum;
increment (processor. address_register) ;
end;
end load-package;
Listing 6
Until now, the mechanism for invoking operations across process scopes has not been
discussed because it is not trivial. Some additional considerations have to be made to
understand the problem. A declaration of a class in an entity would not allow us to use
it in another entity, because there is no concept in VHDL to make it visible outside the
entity. The same restrictive encapsulation concept hinders making objects visible across
entity boundaries or in case of object instantiations as variables across process
boundaries; in other words, the mapping of transient links between parallel running
processes in an OMT model to an implementation causes problems. Ideas on how to
solve the problems arising from the different scopes are given in the next section.
6.9. SPECIFICATION AND IMPLEMENTATION

OF COMMUNICATION MECHANISMS
The introduced implementation concept for operations is based on procedures. An
operation is implemented as procedure, and a message to an object is performed by a
procedure call with the target of the message as parameter. Thus the only precondition
to sending a message is that the target object be visible in the operation sending the
message. In a sequential model consisting of only one process, this can be achieved by
parameter passing of the affected objects. The situation is different in a concurrent
model, when the sender and the receiver of the message are instantiated in different
processes. In that case, a simple procedure call does not work. The objects are not
visible to each other. The only way to exchange information between processes in
VHDL is to use signals. As these signals are only low-level communication constructs,
it makes sense to use them as modules to build a more complex communication
mechanism. The idea is to specify an abstract class channel which can perform
operations needed for communication. The instantiations of the class are signals
performing the data exchange. Such a class could be specified, for example, as shown in
Figure 8. The class channel consists of attributes for synchronisation purposes and
an aggregation with a class datum. This class is used as a superclass in a generalization
consisting of all types of messages which can be sent on the channel. This makes the
channel re-usable for different kinds of messages. Two operations can be invoked by
other objects: a send operation and an accept operation. This is illustrated in
Figure 9. For simplification, datum is considered as an attribute of channel. The
sender sends a datum into the channel and waits until the receiver invokes the
operation accept. Together with a datum from the recei ver as input, another
operation accept is performed. The results of this operation are sent back to the
sender and the recei ver. Then both objects continue their operations. An object
invoking an accept operation before a send operation is performed is blocked until
the send operation is invoked. New channels can be derived from the existing one.
126 CHAPTER 6
Channel
request
acknowledge
send(datum)
accept(datum)
Figure 8: Object Model of Channel

sender
Figure 9: OODFD of Channel Operations

For example, a read and a write channel could be specified for the messages, which can
be sent to the memory of the processor system. The second accept operation is
re-specified in each channel to perform the desired operations. The split of accept
into two operations separates the part dealing with control information like reques t
and acknowledge information, which can be re-used by every channel, and the part
dealing with the channel-specific behaviour, which can be re-specified for each channel.
In the example, a message is sent from the process containing the rest of the
processor system to the memory by selecting the read or the write channel. Then
the operation send is invoked with an address and probably a value to store as datum.
If the memory performs an accept, the corresponding operation is performed. The
implementation of the channel is a tagged record, and the instantiation of a channel
object consists of two signals, which are visible in the scope of both processes.
Information has to be exchanged in two directions between the processes. To avoid
resolved signals in such a situation, two signals are necessary, one for each direction. A
language extension would be quite useful which allows us to encapsulate such two
signals in one record and to split up the drivers of the elements in different processes,
even when the record is passed as a parameter to procedures. The messages for the send
and accept operations consist of a simple procedure call of a send or an accept
procedure. Both procedures have to have the signals as parameters. This is the only
way to perform an assignment to the signals from inside the procedures, because the
procedures are declared for visibility and re-use purposes in packages, as explained in
Section 6.7. For the implementation of several different channels between the same
objects, only two signals of a class-wide type channel are necessary if all channels are
derived from the class-wide-type. In the example of the processor system, only two
signals are necessary to implement the read channel and the write channel. As explained
above, the objects implemented as tagged records in different processes are not visible
to each other even as the processes are not visible. They are only linked together by the
channels implemented as signals. As a consequence, the objects cannot assign
operations directly to objects but only to channels.
Like the target objects of a message in a sequential implementation, as explained in
Section 6.7, the channels have to be made visible within the operations by parameter
passing. This makes it difficult to extend an implementation by adding objects running
in parallel which are connected to the existing model by new channels or anything else
based on signals. For example, if in an implementation of the processor system
(Figure 1) a new type is derived from the type instruction to implement a new
instruction, and the operation execute instruction which performs this new
instruction consists of a message to a new object instantiated in a separate process, then
the signals representing the channel which connects these objects have to be passed as
parameters to the procedure execute instruction. This is not the only change in
the implementation. The procedures calling the operation execute instruction
have to be changed. Their parameter list has to be extended by the signals implementing
the channels. This change of the parameter list can have similar consequences in other
procedures and so on.
The previous paragraphs described the situation in which two objects running in parallel
send messages. In most concurrent specifications, there are more than two objects
running in parallel. In corresponding implementations, more than one channel has to be
passed as parameter to the procedures. This stops re-use. The number and names on
the passed channels depend on the procedures called by the operation. If in case of
polymorphic procedures another realisation is implemented, the channels might fit no
longer. One solution would be a language construct which allows implementation of
channels, making them accessible in a procedure declared in a package without passing
them as parameters to the procedure. Such a language construct could be something like
a global signal. The difference to existing global signals would be the possIbility to
assign values to such signals in a procedure without passing the signals as parameters to
the procedure.
128 CHAPTER 6
Another possibility to build the communication between several objects would be to

implement one abstract channel per process realized as class-wide type. A complex
communication mechanism could be designed for the tagged record signals implementing
the abstract channel. It consists of several processes which run polymorphic procedures
of the channel. The procedures could be used to solve access conflicts or to implement a
queuing mechanism for messages. Such a situation is illustrated in Figure 10.
sender
channelobject: Channel1
I
1 channelobject : Channell
C send
•
channelobject : Channel'CLASS
J channel: Channell
route channel
another channelobject : Channell I •

channelobject : Channell
~ I
-I---- + channel: Channell
determine priority
--.
channelobject: Channell
I
•
-- ----
channel: Channel2 channel: Channell
Ie accept channel
--.
~
Ie accept channel
..-
I I
r
openchannel : Channell I Iopenchannel : Channell II channelobject : Channell
I
I
/ openchannel : Channell
c accept
T I
T receiver ~
channelobject : Channel1 I Ichannelobject': Channel1
Figure 10: OODFD of Communication Mechanism between more than Two Processes
An object channelobj ect is sent and routed through the net. The routing is
determined by the actual class of the object. In the example an object of class
channell is sent. If several objects of channell are sent at the same time from
different objects in different processes, then a priority function has to select the
one which is to be sent. A receiver sends an object openchannel of the class
channell. In this case, the function accept channel of channell sends the
object channelobj ect to the recei ver. The function accept channel of
channe12 does not propagate the accept because of the different classes. It is not a
problem to introduce new channels into the existing mechanism because the new
channels inherit all procedures necessary to run in the mechanism. As the mechanism
for the routing is based on the class of the channel, it is necessary to derive a new
channel for each target of a message, which is in another process. Inside the process,
which invokes the send or accept operations of the channels, only one abstract channel
of a class-wide type has to be passed as parameter to the procedures. The actual type
of the parameter can then be the implementation of any channel. One channel per
process is sufficient in most cases as after a message send or accept, the calling
operation is blocked until the send or accept is performed. An implementation for such
a communication mechanism could be put into a library. Instead of being part of the
language, constructs for high-level communication between processes as part of a library
become modifiable and re-usable.
6.10. CONCLUSION
This chapter has analysed the suitability of object-oriented modelling techniques as a
mean for increasing productivity in the domain of hardware system design. The
modelling cost during different phases of design has been investigated. The largest
possible gain is expected in the initial specification and debugging phase of complex
systems as well as in the re-use of subsystems. As an important decision criterion for
the kind of language extensions, the subject of object-orientation has been elaborated.
One kind of object might be physically existing objects, which could be modelled in an
abstract, encapsulated and reusable way and hence support a bottom-up design
approach. On the other hand, object orientation could be applied to abstract concepts if
these are synthesizable down to the circuit level. In that case, concepts based on
abstract data types are subject to re-use, and a more efficient specification and high-
level design phase are expected. It has been illustrated how such a concept in form of an
object-oriented extension to VHDL can be used as an implementation language in an
object-oriented design methodology. Possibilities and limitations of translation
techniques from the specification into the implementation have been presented.
Different scopes of visibility of objects in the specification model and in the
implementation have been discussed. As an implementation problem in concurrent
systems, missing high-level communication constructs have been identified. An outline
of a solution has been given in which high-level communication constructs by
generalisation become re-usable for several interconnection situations. Although there
'are still several unsolved problems, object-oriented techniques promise to be successful
in the area of object-oriented hardware design, too, after being acknowledged in the
software domain.
130 CHAPTER 6
REFERENCES
[1] Bergamaschi, R. A.: Productivity Issues in High-Level Design: Are Tools
Solving the Real Problems? 32nd. Design Automation Conference, San
Francisco, 1995
[2] Booch, G.: Object-oriented design: with applications. Redwood City, Calif.,
Benjamin/Cummings, 1991
[3] CCIlT Revised Recommendation Z.1 00 CCITT Specification and Description
Language (SDL), 1992
[4] Coad, P.; Yourdon, E.: Object-oriented analysis. Yourdon Press, 1991
[5] Covnot, B. M.; Hurst, D. W.; Swamy, S.: OO-VHDL An Object Oriented
VHDL. Proceedings of the VHDL International User's Forum, 1994
[6] Girczyc E.; Carlson S.: Increasing Design Quality and Engineering
Productivity through Design Re-use. 30th. Design Automation Conference,
Dallas, 1993
[7] Harel, D.: Statecharts, A visual formalism for complex systems. Science of
Computer Programming 8, 1987
[8] Holz, E.; Witaszek, D.; Wasowski, M.; Lau, S.; Fischer, J.; Roques, P. ;
Cuypers, L.; Mariatos, V.; Kyrloglou, N.: INSYDE Integrated Methods for
Evolving System Design Technology Assessment. Report. Alcatel Bell
Telephone, Dublin City University, Humboldt Universitat zu Berlin, Intracom
S.A., Verilog S.A., Vrije Universiteit Brussel, 1994
[9] ISO/IEC 8652: 1995(E) Ada Reference Manual, Language and Standard
Libraries, Version 6.0, 1994
[10] Nebel, W.; Schumacher, G.: Konzepte objektorientierter Hardware-
Modellierung. invited talk: 2. GIIITG/GME-Workshop
"Hardwarebeschreibungssprachen und Modellierungsparadigmen", Darmstadt,
Feb. 15-16, 1996
[11] Rumbaugh, 1.; Blaha, M.; Premeriani, W.; Frederick, E.; Lorensen, W.: Object-
oriented modeling and design. Prentices-Hall International, 1991
[12] Rumbaugh, J.: OMT: The object model. in Journal of Object oriented
Programming, January, 1995
[13] Rumbaugh, J.: OMT: The dynamic model. in Journal of Object oriented
Programming, February, 1995
[14] Rumbaugh, J.: OMT: The functional model. in Journal of Object oriented
Programming, March-April, 1995
[15] Rumbaugh, J.: OMT: The development process. in Journal of Object oriented
Programming, May, 1995
[16] Schumacher, G.; Nebel, W.: Survey on Languages for Object Oriented
Hardware Design Methodologies. Current Issues in Electronic Modeling,
Issue 1, Kluwer Academic Press, 1995
[17] Schumacher, G.; Nebel, W.: Inheritance Concept for Signals in Object-Oriented
Extensions to VHDL. Proceedings of the EURO-DAC '95 with EURO-VHDL
'95. IEEE Computer Society Press, 1995
[18] Shlaer, S.; Mellor, J., S.: Object-Oriented System Analysis Modeling the World
in Data. Yourdon Press, 1988
[19] Swamy, S.; Molin, A.; Covnot, B. M.: OO-VHDL Extensions to VHDL. IEEE
Computer, Oct. 1995
[20] USEIDA (User Society for Electronic Design Automation). Results of the 1993
USEIDA Standards Survey. Feb., 1994
7
OBJECT-ORIENTED GENERATION
OF VHDL MODELS
George S. Powley Jr., Joanne E. DeGroat
Department ofElectrical Engineering, The Ohio State University, 205 Dreese Lab, 2015
Neil Avenue, Columbus, OH 43210-1272, USA
ABSTRACT
To allow the rapid prototyping of application specific signal processors, an extensive
VHDL library of architectural building blocks is needed. In this chapter, we present an
object-oriented approach to generating a library of VHDL synthesizable models. The
object-oriented analysis and implementation of the VHDL model generation system is
described. By using an object-oriented development method, the model generation
system has been designed to be easily extended, allowing new components to be added to
the component library without changing the system code. An example ofthe VHDL code
generatedfor a 4-bit ripple carry adder is included
7.1. INTRODUCTION
To allow the rapid prototyping of application specific signal processors, an extensive
VHDL library of digital architectural building blocks [5] is needed. The digital
component library should include behavioral models of off-the-shelf parts, as well as
VHDL synthesizable models. This library could be used by hardware designers to
develop behavioral models of signal processing systems, and also by high level
synthesis systems to verify behavioral synthesis results [3]. In this chapter, an object-
oriented approach to developing a synthesizable VHDL model generation system for
digital building blocks is described.
By using an object-oriented development method, a software system can be designed
that will be easier to maintain and extend, as opposed to using a conventional structured
133
134 CHAPTER 7
analysis approach. This notion has been emphasized in the development of the VHDL
model generation system. The key advantage of taking an object-oriented approach is
that the library of models supported by the tool can be extended without changing the
code for the model generation system.
In this chapter, the advantages of the object-oriented paradigm are highlighted. The
object-oriented analysis of the VHDL model generation system is described, including
the digital component class, which facilitates the extendible component library. Finally,
some of the implementation details are presented, and a short example is provided.
7.2. OBJECT-ORIENTED PARADIGM

Object-oriented development methods provide a systematic approach to the analysis,
design, and implementation of computer software systems. In the object-oriented
paradigm, objects provide a unifying model to integrate these development phases. For
the VHDL model generation system, the main object of interest is a digital component.
Since objects are closely identified with the real world concept they model, object-
oriented development is an excellent method for creating the VHDL model generation
system.
7.2.1. Object-Oriented Analysis

The goal of object-oriented analysis is to capture the system requirements in a
complete, consistent, and unambiguous fashion. By using analysis methods, the system
requirements are converted into an abstract model of objects and object interactions.
This model is used throughout the development cycle to guide the design and
implementation of a software system.
From the rapidly expanding field of object-oriented analysis and design[9], we have
chosen the Fusion [2] method of object-oriented development. Fusion provides a
comprehensive object-oriented development method, from analysis to implementation,
based on previous methods developed by Rumbaugh [10], Booch [1], and Wirfs-Brock
[II]. In Section 7.3, the results of the Fusion analysis on the VHDL model generation
system will be described.
7.2.2. Object-Oriented Implementation

A major advantage of a well designed object-oriented system is reduced maintenance
costs. Maintenance costs include the cost of fixing incorrectcode, as well as the cost of
enhancing the existing code. By using the inheritance concept of the object-oriented
paradigm, the digital component object is implemented with a hierarchical class
structure. This allows new components to be added to the library of supported models,
without changing any of the existing code.
The object-oriented paradigm also addresses the issue of software reuse. By building
software systems based on commonly used objects, the amount of programming effort
is greatly reduced as previously implemented objects are reused. The only drawback of
this concept is that class libraries of must be widely available to take advantage of code
reuse. During the development of the VHDL model generation system, a class for digital
Object-Oriented Generation ofVHDL Models 135
components has been developed with the idea of code reuse in mind. In Section 7.3.3,
the digital component class is described.
7.3. ANALYSIS OF VHDL MODEL

GENERATION SYSTEM
During the object-oriented analysis of the VHDL generation system, the requirements
of the system, represented in natural language format, are converted into an abstract
model of objects and object interactions. This object model is used as a guide for the rest
of the software development process. In this section, the requirements for the VHDL
model generation system and the results of the object-oriented analysis are presented.
7.3.1. Requirements
The VHDL synthesis model generation system will be used to generate synthesis and
simulation models of digital components. The VHDL models produced by the
generation system must be portable across synthesis systems, therefore the use of
generics is prohibited. The synthesis system should be portable across computer
platforms, and the system should be designed so the component library can be extended
by the user. In addition, each model should provide a data book style of documentation
for the model.
7.3.2. Object Model

The description of the object model is prefaced by stating that the object-oriented
analysis of the system was performed after a prototype of the VHDL model generation
system had been implemented. In [4] Graham states that "understanding the problem
domain also entails simultaneously apprehending frameworks, components,
computational models and other mental constructs which take account of feasible
solution domains." Without this prior experience in developing a VHDL model
generator, the quality of the object-oriented analysis would not be as high, since the
knowledge of the problem domain was not as detailed.
From the beginning of the system development, the concept of easily extending the
model library has been a key issue. During the prototype development of the VHDL
model generator, the idea of using one object tor epresent all digital components was the
foundation for building a system that could be easily extended. By using this common
object representation, code for the model generator was developed which will remain
useful for all future components added to the library.
In the Fusion analysis method, the object model is a graphical representation of classes
and relationships. Classes are represented by rectangles and relationships are
represented by diamonds. A data dictionary is used to hold definitions of terms and
concepts used throughout the development process. The object-oriented analysis of a
system is an iterative process. By iteratively proposing classes and their relationships,
an object model capturing all requirements of the system is obtained.
136 CHAPTER 7
Name Kind Description

GUI class I araphical user interface
Database Client class class that can read Component Model DB
Person class human that manipulates GUI
DBResult class class of objects returned from Component
Model DB
Model Designer class Person that maintains Component Model DB
Model DBlnterface class GUI used to maintain ComDonent Model DB
Component Model DB class container of Diaital Components
DigitalComponent class AttributeList, Generic VHDL, and
Documentaion for a diaital component
Attribute List class list of attributes for a diaitalcomponent
Generic VHDL class preprocessed VHDLdescription of digital
component
Documentation class documentdescribina diaital component
User class Person that uses Model Generation System
Attribute InterfaceGenerator class DB Client which constructs Attribute Interface
VHDL Model class VHDL code representina diaitalcomponent
Component List class list of Digital Component contained in
Component Model DB
uses relationship Person manipulates GUI
accesses relationship Database Client sends query to Component
Model DB
reads relationship Database Client looks at values of DB Result
returns relationship ComponentModel DB returns a DB Result
updates relationship Model DB Interface write a Digital
Component to the ComponentModel DB
binds relationship Attribute Interface stores actual values in
Attribute Values
builds relationship Attribute Interface Generatorconstructs an
Attribute Interface based on the Attribute
List
generates relationship Model Generator produces VHDL Model
based on the Attribute Values and the
Generic VHDL
starts relationship User Interface initiates the Model Generator
Figure 1: Data Dictionary for Object Model

Figure 1 shows the data dictionary for the object model. At this stage of development,
the data dictionary contains the classes and relationships used in the object model. The
data dictionary provides the semantic content that is not present in the graphical object
model.
The object model for the VHDL model generation system is shown in Figure 2. This
figure, along with the data dictionary, describes the object classes and relationships that
exist in the VHDL model generation system. Two important classes contained in the
object model, the Attribute Interface Generator and the Model Generator, are described
below. The Digital Component class, which is the key to the system, is described in
Section 7.3.3.
The Attribute Interface Generator object is used to build a user interface based on the
Attribute List object contained in the Digital Component object. The Attribute List
contains a list of all attributes and their types for a given component. By using one class
to represent all digital components, the Attribute Interface Generator can be used for all
future component models.
The Model Generator object is used to bind the Attribute Values, specified by the user,
to the Generic VHDL description contained in the Digital Component class. The output
of the Model Generator will be as ynthesizable VHDL Model. Using the Model
Generator to bind the attribute values to a "generic" VHDL model is a key factor in
making the system extendable. Since the Model Generator performs the same task for
all digital components, the Model Generator code will remain unchanged as new models
are added to the component library. Implementation details of the model generator are
discussed in Section 7.4.2.
Aftrt)uM V.1un
VHDL Mod-'
Compon.m: lial
.......
Figure 2: Object Model for VHDL Model Generation

138 CHAPTER 7
The object model for the library maintenance system is shown in Figure 3. This figure,
along with the data dictionary, describes the object classes and relationships that exist in
the library maintenance system. The library maintenance system is used to update and
extend the database of digital component models. This system allows the model
designer to change existing models in the library, or to add new models to the library.
By using an object-oriented approach to implementing the database interface, the Model
Designer can be isolated from changes in the format of the database. A graphical user
interface to the Component Model Database also helps maintain the integrity of the
database. By using software to change the contents of the database, many problems can
be avoided that might occur if the designer made changes to the database by hand.
Implementation details of this system are described in Section 7.4.1.
Model DB Interface Component Mod.. Database
EJ
EJEJEJ
Figure 3: ObjectModel for Library Maintenance
Figure 4 shows generalization diagrams for the classes used in the object model.
Generalization is used to indicate inheritance relationships. In this case, generalization is
used to allow classes to inherit common relationships. For the GUI class, all derived
classes will inherit the relationship of being manipulated a Person. The descendants of
the Database Client class will inherit the ability to send queries to the database and read
the results returned by the database, which are contained in the Database Result class.
Database Clients do not inherit the ability to change the database. This relation is only
provided to the Model Database Interface.
During the development of the object model, it is apparent that the Digital Component
class is a key member of the whole system. By generically specifying the representation
of all digital components, an object-oriented system can be built. In the next section, we
will describe the digital component class used by the VHDL model generation system.
GUI Database Client
I I I
Attribute Interface
Model DB Interface User Interface Attribute Interface
Generator
Human DB ResuH
~ ~
I I I I
Component List
Model Designer User Component
Figure 4: Generalizations Used in Object Model
Digital Component
A
Combinatorial Sequential TYPE
A A
Logic .Gates Counters Regi~ters CLASS
Ripple Carry Carry ARCHITECTURE

Carry Lookahead Save
Figure 5: Inheritance Graph for Digital Component Class

140 CHAPTER 7
7.3.3. Digital Component Class

In the specification of a generic class for digital components, a hierarchical
representation is used to indicate the inheritance of attributes. The inheritance graph is
shallow, containing only four levels, and siblings at each level differ in the same
respects. Figure 5 shows part of the inheritance graph.
At the root of the graph, level 0, the class contains no attributes. At levell, the graph is
divided into combinatorial and sequential circuits. The clock attribute is the identifYing
factor at this level of the graph. The siblings at level 2 of the graph represent a class of
digital component. These classes range from logic gates and multiplexors to
floating-point adders and multipliers. Each of these classes will have a set of attributes
associated with the component its represents. All attributes at this level will be
inherited by the children of these nodes.
Control Inputs
...
Data Digital Data

Inputs Component Outputs
...
Control Outputs
Figure 6: Generic Digital Component

The leaf nodes of the inheritance graph are used to represent architectures of a
component class. An example of the hierarchy for the adder class is shown in Figure 5.
The architecture nodes inherit all attributes defined by the parent class node, and define
any new attributes required for the component architecture. Based on an
implementation decision, only leaf nodes of this inheritance graph will be instantiated.
That means, objects used in the VHDL model generation system will come from the
architecture level of the inheritance graph.
A generic digital component can be represented by a black box with inputs and outputs.
These inputs and outputs can be divided into data and control 110, as shown in
Figure 6. The operation performed by the digital component is determined by the class
of the component, and the design implementation is determined by the architecture. In
the Appendix, a list of commonly used digital components, and their representative
attributes is given. This taxonomy of digital components provides the basis to build the
VHDL model synthesis library.
The collection of digital models listed in the appendix is by no means exhaustive. The
focus of the VHDL model generation system is to make the library easily extendible. By
including models of commonly used components, the foundation is laid for model
designers to add new components to the library. These new models might include new
architectures for a previously defined class, such as a carry save adder, or models for a
newly defined class, such as an IIR filter. In the next section, the procedure for adding
new models to the VHDL model generation library is described.
7.4. VHDL MODEL GENERATION SYSTEM

The VHDL model generation system uses the hierarchical description of all digital
components, described in the previous section. The hierarchical description is used to
develop a database of digital component attributes, and these attributes are incorporated
into synthesizable VHDL models for each component. The VHDL models are written
using 'C' preprocessor directives [7] to reflect unique functionality for different
attribute values. A graphical user interface for the attribute database has been developed
using TCLlTk [8]. The interface provides an easy method to maintain and upgrade the
component attribute database. Another graphical user interface has been developed to
allow the designer to bind attribute values to a component instance. The attribute values
from the user interface and the preprocessed VHDL model are passed to the 'C'
preprocessor, which generates the component instance model. The component instance
model is targeted for synthesis, but it can be used for behavioral simulations as well.
7.4.1. Attribute Database

The attribute database is used to store the attributes identified by the digital component
classification. Therefore, the database holds the attribute representation, not the
attribute values. The database is designed to hold attributes from the lowest two levels
of the component hierarchy, referenced as the class and subclass. This greatly reduces
the complexity of the database and the model generation interface. In this section, we
describe the data types used to represent the attribute information.
7.4.1.1. Attribute Types
While identifying the attributes of the digital components, it was determined that the
attributes could be represented by three types: integers, Booleans, and enumerated
types. Integers are used to represent attributes that take on a numeric value, such as the
word length of an adder. Boolean values are used to determine, the presence or absence
of some attribute, such as the carry out signal from an adder. Enumerated types are used
to set an attribute to one choice from a predefined set of values. An example of an
enumerated type would be the look ahead length in acarry lookahead adder. Even though
the lookahead length could be represented by an integer, the VHDL synthesizable model
will only support a predefined ranges of values. By using an enumerated type, the need
for error checking code in the model generation interface is eliminated.
142 CHAPTER 7
Information based on the attribute values is passed to the model generator using define
scripts, written in Tcl. The define script may use information from entry boxes, check
boxes, and radio buttons. For each define script, a #define directive corresponding to the
specified define name is passed to the model generator. The value of the define is the
result of executing the Tcl script. The define script provides the model designer with a
very powerful method of passing information to the model generator, thereby reducing
the complexity of the VHDL models.
7.4.2. Model Generation

Model generation is required in order to bind attribute values to a generic component
model. By fixing the attribute values in the VHDL code, the models should be portable
across all synthesis tools. A model generation interface has been developed, which
allows the user to specify attributes for a component model. After the attributes are
specified, the 'C' preprocessor is used to substitute the specified attributes into the
generic VHDL model. In this section, we will discuss the format of the preprocessed
VHDL code, and describe the model generation interface.
7.4.2.1. Preprocessed VHDL Format
The most straightforward method to write VHDL synthesizable code for varying word
sizes, is to use loops with the length defined by a variable or a generic. Unfortunately,
most VHDL synthesis tools require constant values where the variable values would be
used, and some tools do not support generic values. In order to keep our VHDL models
portable across synthesis systems, we use a model generation methodology that allows
us to bind variable values to a fixed value at model generation time, using 'C'
preprocessor directives. The #define directive is used to replace "generic" values with
integers or constants, thereby meeting the requirements of synthesis tools. This
methodology also provides more powerful features when used in conjunction with the
define scripts described in Section 7.4.1.1.
7.4.2.2. Model Generation Interface
The model generation interface is used to bind attribute values to a VHDL model. The
model generation interface presents the designer with a list of component subclasses for
a chosen class. When the component subclass is selected, a dialog box containing the
attributes for that class and subclass is opened. After the attributes are designated, the
model generator sends a file of define directives together with the preprocessed VHDL
model to the 'C' preprocessor. The output of the 'C' preprocessor is a VHDL
synthesizable model of the desired component.
The attribute dialog box used by the model generation interface is created based on the
values in the attribute database. Employing the concept of creating a dialog box from
entries in a dynamic database is a very powerful technique. Now that the code to
produce the dialog box is completed, new components can be added to the database
without changing the model generation interface code.
7.5. EXAMPLE
In this section, we will show the results of generating and synthesizing a 4-bit ripple
carry adder. The first step of the process is to select the attributes for the adder. The
contents of the files sent to the C preprocessor are shown in Figure 7. The VHDL code
produced by the model generator is shown in Figure 8. This is a behavioral VHDL
model of a 4-bit adder, which is targeted for logic synthesis.
#define_IN1TYPE bit_vector(3 DOWNTO 0)

#define _IN2TYPE bit_vector(3 DOWNTO 0)
#define _BIT bit
#define _VECTOR bit_vector
#define _MAXOUT 3
#define ZEROS "0000"
#ifdef STD
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
#endif
ENTITY adder IS
PORT ( Inputl IN _IN1TYPE;
Input2 : IN _IN2TYPE;
#ifdef _CIN
Cin : IN _BIT;
#endif
#ifdef - COUT
Cout OUT _BIT;
#endif
#ifdef ZERO
Zero OUT _BIT;
#endif
Output : OUT _OUTTYPE ) ;
END adder;
ARCHITECTURE ripple OF adder IS
SIGNAL sum _VECTOR(_MAXOUT DOWNTO 0);
#ifdef _COUT
SIGNAL carry _VECTOR(_MAXOUT+1 DOWNTO 1);
#e1se
SIGNAL carry _VECTOR(_MAXOUT DOWNTO 1);
#endif
BEGIN
all bits : FOR i IN 0 TO _MAXOUT GENERATE
#ifndef _CIN
lsb : IF (i = 0) GENERATE carry(i+1) <= Input1(i) ANDInput2(i);
sum(i) <= Input1(i) XOR Input2(i);
END GENERATE lsb;
#else
lsb : IF (i = 0) GENERATE
carry(i+1) <= (Input1(i) AND Input2(i)) OR (Input1(i)AND Cin)
OR (Input2(i) AND Cin);
sum(i) <= Input1(i) XOR Input2(i) XOR Cin;
END GENERATE lsb;
#endif
#ifndef _COUT
msb : IF (i = _MAXOUT) GENERATE
sum(i) <= Input 1 (i) XOR Input2(i) XOR carry(i);
END GENERATE msb;
rest : IF (i > 0 AND i < _MAXOUT) GENERATE
144 CHAPTER 7
carry(i+1} <= (Input1(i) AND Input2(i}} OR

(Input1(i) AND carry(i}} OR
(Input2(i) AND carry(i}};
sum(i} <= Input1(i} XOR Input2(i} XOR carry(i};
END GENERATE;
#else
rest : IF (i > O) GENERATE
carry(i+1} <= (Input1(i) AND Input2(i}} OR
(Input1(i}AND carry(i)} OR
(Input2(i) AND carry(i}};
END GENERATE;
#endif
END GENERATE all_bits;
Output <= sum;
#ifdef _COUT
Cout <= carry(_MAXOUT+1};
#endif
#ifdef _ZERO
Zero <= '1' WHEN sum ZEROS ELSE '0';
#endif
END ripple;
Figure 7: File Sent to C Preprocessor for a 4-bit Ripple Carry Adder
ENTITYadder IS
PORT ( Input1 IN bit_vector(3 DOWNTO OJ;
Input2 IN bit_vector(3 DOWNTO OJ;
Cin : IN bit;
Cout : OUT bit;
Zero : OUT bit;
Output: OUT bit_vector(3 DOWNTO O} };
END adder;
ARCHITECTURE ripple_carry OF adder IS
SIGNAL sum: bit_vector(3 DOWNTO O};
SIGNAL carry: bit_vector(3+1 DOWNTO I};
BEGIN
all_bits : FOR i IN 0 TO 3 GENERATE
Isb : IF (i = O) GENERATE
carry(i+1} <= (Input1(i) AND Input2(i}} OR (Input1(i}AND Cin)
OR (Input2(i) AND Cin};
sum(i} <= Input1(i} XOR Input2(i} XOR Cin;
END GENERATE Isb;
rest : IF (i > O) GENERATE
carry(i+1} <= (Input1(i) AND Input2(i}}
OR (Input1(i}AND carry(i)}
OR (Input2(i) AND carry(i}};
END GENERATE;
END GENERATE all_bits;
Output <= sum;
Cout <= carry(3+1};
Zero <= '1' WHEN sum "0000" ELSE '0';
END ripple_carry;
Figure 8: VHDL Code Generated for a 4-bit Ripple Carry Adder

Object-Oriented Generation of VHDL Models 145
7.6. CONCLUSIONS
We have described an object-oriented approach to the development of a synthesizable
VHDL model generation system. By taking an object-oriented approach, the system has
been designed to be easily extended, therefore new models can easily be added to the
component library. The design and implementation of this system shows that
object-oriented development methods are useful, even if the final system is not
implemented within an object-oriented language.
Future work on this system will include defining an external tool interface to the model
generator. This will allow a high level synthesis tool to directly access the model
generator. Models obtained from the model generator could be used by the synthesis
system to perform a behavioral simulation, and then sent to a logic synthesizer to
obtain a gate level implementation. Also, new component models will continue to be
added to the model library, to improve the usefulness of the VHDL model generation
tool.
REFERENCES
[1] Booch, G., Object-Oriented Design with Applications, Benjamin
Cummings,1991.
[2] Coleman, D., Arnold, P., Bodoff, S., Dollin, c., Gilchrist, H.,and Jeremaes, P.,
Object-Oriented Development - The Fusion Method,Prentice Hall, 1994.
[3] Dutt, N.D., "GENUS: A Generic Component Library for High LevelDesign",
Technical Report #88-22, University of California at Irvine,Sept 1988.
[4] Graham, 1., Object-Oriented Methods, Addison-Wesley, 1991.
[5] Hayes, J. P., Computer Architecture and Organization,McGraw-Hill, 1988.
[6] Korsen, T. and McGregor, 1. D., "UnderstandingObject-Oriented: A Unifying
Paradigm", Comm of the ACM 33, 9 (Sept 1990), pp. 40-60.
[7] Kernighan, B. W. and Ritchie, D. M., The C ProgrammingLanguage, Prentice
Hall, 1988.
[8] Ousterhout, J. K., Tel and the Tk Toolkit, Addison-WesleY,1994.
[9] Pronk, C. and Tercero, C., "Methods and Techniques forObject-Oriented
Analysis and Design", Technical Report #94-107, DelftUniversity of
Technology, December 1994.
[10] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., andLorensen, W., Object-
Oriented Modeling and Design, Prentice Hall, 1991.
[11] Wirfs-Brock, R., Wilkerson, B., and Wiener, L., DesigningObject-Oriented
Software, Prentice Hall, 1990.
INDEX
A
Abstract Data Type 17; 22; 24; 32 Classes 79; 111
Abstract Model 17 CLU32
Abstraction 20; 102 Co-Design 53
Activated 82 Co-Simulation 53
Activation of Methods 4 Commands 3
Active 63 Communication Overheads 2
Active-Passive Duality 33 Compilation 80
ADA9584 Complexity 16; 32
Aggregate 5 Complexity Management 16
Aggregation 112 Computer-Independent 3
Alphard 32 Concrete Representation 22
Analysis 80 Concurrent Objects 42
Architectural Design 42; 48 Constructor 19; 21
Architectures 5; 9 Container 32; 80
Artificial Intelligence 4 Corporate Identity 9
Assemblers 3 Cross Fertilization 16
Association 111
Attributes 107; 111 D
Automatic Parallel Partitioning 4 Data Abstraction 7; 16; 17; 20
Data Decomposition 21; 24; 34
B Data Description 47
Behavioral Aspect 6 Data Dictionary 112
Data Hiding 4
c Data Packaging 4
C++ 17; 110 Data Structures 3
Change Management 23; 24; 33 Data-Flow Diagram 60
Channel 125 Decomposition Graph 22
Class 5; 17; 80; 107 Derivation of Methods 81
Class Diagram 60 Design Cube 9
Class for Digital Components 134 Design Domain 9
Class-Wide 117 Design Family 32
147
148 Index
Design Methodology 1 Hardware Technology 5

Design Patterns 5 Hardware/Software Codesign 33; 58
Design Process 9 Heterogeneous Object Container 117
Design Tools 9 Hierarchical Composition 3
Digital Circuit Elements 6 Hierarchy 102
Digital Signal Processor 20 High-level Synthesis 6; 7
Disposal Problem 105 Higher Programming Languages 3
Domain Specification 17
Domain-Specific 8 I
Domain-Specific Languages 7 Implementation 19; 22; 24; 42
Dynamic Model 113 Incremental Extensions 83
Dynamic Modeling 44 Incremental Specialisation 116
Information Hiding 33
E Inheritance
E-VHDL 117 5; 17;20;30;33;60;80;96; 107
Elaboration 80 Instance 19; 79; 96; 111
Embedded System 20 Instance Variables 108
Encapsulation 79; 80 Instruction Set Architecture 24; 31
Event Flow Diagram 113 INSYDE 58
Events 113 Interconnection Diagrams 46
Execution 80 Iterative Constructs 43; 80
Expert Systems 7; 8
L
F Late Binding 80; 108
Families of Computer Architectures 33 Level of Abstraction 18
Formal Methods 7 Library 133
Functional Decomposition 22; 34 Link 80; 81
Functional Languages 4; 6; 7
functional Model 113 M
Maintenance Costs 134
G Markov Random Fields 70
G-Templates 69 Mathematical Formulae 4
Generalisation 112 Member Function 18
Generate Statements 96 Messages 4
Generic Modeling 96 Methods 79; 82; 107
Generic Types 5 Micromachine 32
Genericity 80; 82; 96 Microprogram 31
Migration Path 77
H Modelling Costs 104
Hard-Binding 82 Moore 1
Hardware Description Language MSC, Message Sequence Chart 40
6; 16; 33 Multiple Inheritance 81
Index 149
o R
Object Interaction Diagram 114 Rapid Prototyping 33; 133
Object Model Ill; 135 Re-Use 102
Object Modeling 44 Reconstruction of Damaged Images 70
Object Modeling Technique III Register Transfer Synthesis 2
Object Orientation 4; 7; 8; 58 Relation III
Object-Oriented Analysis 134 Requirements analysis 41
Object-Oriented Data Flow Diagram 114 Reusability 58
Object-Oriented Design 5; 8; 16; 33; 133 Reuse 5; 9; 16; 19; 21; 23; 25; 32; 78
Object-Oriented Extension 78 Role 111
Object-Oriented Languages 8 Rolename III
Object-Oriented Paradigm 134
Object-Oriented Real Time Analysis 84 s
Object-Oriented Techniques 40 Script Languages 4
Objects 107 SDL, Specification and Description
Off-the-Shelf 16 Language 40
OlD 114 SDL-93110
OMT 40; 58; III Sequential Processing 3
OMT* 58 SES/Workbench 33
00A5 Simulation 16
OOD 5 Smalltalk 110
OODFD 114 Soft-Binding 82
OORT 41 Software Bus 69
Operational Specification 17; 22; 24 Software Design 45
Software Technology 3
p
Software-ICs 34
Parallel Processes 6 Specification 17; 19; 24
Parent Class 107 Specification Languages 6; 7
Passive 63 State 16; 17
Passive Objects 42 State Diagrams 113
Patterns 9; 64 State-Transition Diagrams 60
Polymorphism 5; 32; 80; 96; 108 Staticity 80
Pre- and Post-Conditions 29 Structural Description 79
Process 47 Subclasses 112
Program Family 32; 34 Super Character Formation 3
Programmable Cores 7; 8 Superclasses 112
Programming of Parallel Actions 4 Synthesizable Models 133
Proof Systems 4 System Architecture 46
System Development 135
System Synthesis 6
150 Index
T v
Tag 84; 116 V ModelS; 9
Tagged Record Types 116 Verification 30
Technology Transfer 16 VHDL 33; 65; 133
Template 32 VHDL Model Generation System 134
Test Design 42 Video-On-Demand Server 71
Testing 43 Virtual Instruction Set 34
Tower of Babel 6 Virtual Machine 17; 31; 34
Transformation Function 22; 24
Transistor LevelS w
Type Genericity 32; 34 Weak Typing 82
Whole-Part Relationship 112
u
uP-Interface 85 x
Use Cases 45; 62 X ModelS; 9

Object-Oriented Modeling

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object-Oriented Modeling

Uploaded by

Copyright:

Available Formats

OBJECT-ORIENTED MODELING

ISBN-13: 978-1-4612-8581-6 e-ISBN-13: 978-1-4613-1349-6

Published by Kluwer Academic Publishers,

Kluwer Academic Publishers incorporates

Sold and distributed in the U.S.A. and Canada

In all other countries, sold and distributed

Printed on acid-free paper

All Rights Reserved

• Volume 2: Modeling in Analog Design

• Volume 3: High-Level System Modeling:

• Volume 4: High-Level System Modeling:

• Volume 5: Hardware Component Modeling

• Volume 6: Meta-Modeling: Performance and

The Series Editors

Jean-Michel Berge - France Telecom - CNET

Principal Advisor to the Editors

Jim Armstrong - Virginia Tech

Raul Camposano - Synopsys Inc.

VOLUME 7: OBJECT-ORIENTED MODELING

Jean-Michel Berge, Co-Editor

1.2. Software design 3

1.3. Hardware design 5

2. OBJECT-ORIENTED MODELING OF HARDWARE FOR

2.6. Arithmetic Logic Unit Example 24

3. OBJECT-ORIENTED AND REAL-TIME TECHNIQUES:

3.3. Overview of the OMT, MSC and SDL notations 44

4. INTEGRATED SYSTEM DESIGN WITH AN

5. OBJECT ORIENTATION AND STRUCTURAL DESIGN 77

5.4. Principles of Object Orientation 79

5.5. Structure and Object Orientation 80

5.7. Application Examples 85

6. ABSTRACT HARDWARE MODELLING USING AN

6.1. Introduction 102

6.3. Object-Oriented Techniques 107

6.4. Acceptance of New Design Techniques 110

7. OBJECT-ORIENTED GENERATION OF VHDL MODELS 133

7.1. Introduction 133

7.3. Analysis of VHDL Model Generation System 135

7.4. VHDL Model Generation System 141

7.5. Example 143

James H. Aylor Barry W. Johnson

Alexios N. Birbas Ioannis Karathanasis

Wolfgang Nebel Claus Schneider

George S. Powley Jr. Guido Schumacher

1.2. SOFTWARE DESIGN

1.2.1. Assembler and Higher Programming Languages

1.2.2. Further Developments

• Reuse [34], which is an effective way of increasing design productivity. Although it

• Architectures [36] that are application-specific combinations of classes and design

1.3. HARDWARE DESIGN

• Expert systems are meant to provide assistance to the individual developer in

• Object orientation gains in importance with hardware description languages. In

1.4. THE FUTURE OF HARDWARE DESIGN

• The great disadvantage of new specification languages is that they represent a

• Hitherto, functional languages have not won wide acceptance in software

• Programmable cores shift the problem of productivity from hardware to software.

1.5. THE INFLUENCE OF OBJECT

• Interestingly enough, architectures have always featured in hardware design. With

• Ultimately, the design process must be adapted to hardware requirements in

differences to competitors resulting from a better design process and producing

1.6. SUMMARY AND OUTLOOK

[14] Fourman, M.P.: Formal System Design. In J. Staunstrup (Ed.): Formal

[36] Gabriel, R.P.: The quality without a name. Journal of Object-Oriented