OOVHDL: Object Oriented VHDL
Bachir Djafri, Judith Benzakki
Universite d'Evry, LaMI Laboratory
Cows Monseigneur Romkro, 9 1025 Evry, France
{djafri, benzakki} @lami.univ-evry.fr
Abstract
In the last decade, VHDL has played an important role
in the explosive growth of the electronic design automation
industry and, currently, it is widely used by hardware sys-
tems designers in many projects. Howevel; to keep up with
the steady increase in complexity of hardware systems, to
allow reuse of design models, and to reduce development
time and cost, new design methods must be found. Several
documents and publications have proposed to extend VHDL
and add object oriented features both to manage the com-
plexity increase and to augment the capabilities and expres-
siveness of VHDL. In this papel; we describe OOVHDL,
which extends VHDL by adding object oriented features
such as inheritance, polymorphism mechanism, and com-
munication via messages. The object oriented extensions
and the different constructs described in this paper are il-
lustrated through some examples.
1. Introduction
OOVHDL is an extension of VHDL [ 2 ] which sup-
ports object oriented capabilities such as classes, inheri-
tance, polymorphism mechanism, and communication via
messages. These capabilities, described in a previous pa-
per [ l], are highly useful when applied to VHDL and make
it suitable to develop flexible design with a high degree of
re-usability and maintainability. OOVHDL considers hard-
ware components as objects or classes of objects. Each
component or object contains a state and operations that
manipulate this state. These operations represent the inter-
face of the component and replace the ports in the VHDL
entities. A class is represented by an entity with some ex-
tensions, and the class body is represented by the corre-
sponding architecture. Operation bodies are defined in the
architecture and are similar to processes. Within OOVHDL,
entities communicate with each other via messages. Opera-
tions are requested and the messages sent to the same entity
at the same time are not lost. In order to increase the po-
54
0-8186-8180-2/97 $10.00 0 1997 IEEE
Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.
tential for component reuse, entities and architectures are
extended to support the inheritance mechanism. New enti-
ties and architectures can be derived from existing ones and
all elements of the entity and the architecture are inherited.
Operations can be redefined and new operations or instance
variables can be defined. In order to increase the abstrac-
tion of the language, a broadcasting mechanism is incorpo-
rated through the use of a new attribute: 'component. This
mechanism allows the same message to be broadcast to all
entities of the same superclass.
In this paper, we formally describe the OOVHDL lan-
guage by defining its grammar and semantics. Syntax
changes to the different VHDL design units and the asso-
ciated semantics will be given along with some examples
clarifying the different constructs described. All language
description conventions from the VHDL 1076-1993 stan-
dard apply to this paper. Underlining is used to denote the
extensions of the standard. Since OOVHDL is an extension
of VHDL, only additions or modifications are described in
this paper.
The paper is organized in sections. In each section, a
new construct is defined and its syntax is described using
one or more grammar production rules. The description of
the semantics, the meaning and the restrictions of the con-
struct follow. The paper ends with some remarks.
2. Design entities
The design entity, the primary unit of hardware abstraction
in VHDL, is extended to include class aspects by supporting
both inheritance mechanism and communication via object
oriented operations.
2.1. Entity Declaration
An entity declaration defines the interface of the reusable
design entity in terms of ports and operations. An entity
declaration is referred to as the class interface.
en tity-declaration ::= Examples
entity identifier is [ new entityname ] - - An entity declaration with operation declarations only:
en tityheader
oRerafon_declaration_list use Work.Reg-Types.all ;
en tity-declarative-part entity Register is
[begin operation Clear ;
en titystatement-part ] operation Read(Va1: out RegAlem) ;
end [ entity] [ entitysimplemame] ; operation Write(Va1: in RegIlem) ;
end entity Register ;
The optional new clause specifies inheritance from another
entity. The entity using the new clause is called base entity - - An entity declaration using the new clause:
and the entity specified in the new clause is called derived
entity. An entity can only have another entity as its base use Work.Reg-Types.all ;
entity. Only single inheritance is supported. entity Program-Counter is new Register
Inheritance applies to the entity header, the entity declara- operation Increment ;
tive part, the entity statement part, and the operation decla- end entity Program-Counter ;
ration list.
Entity Declarative Part
Entity Header The entity declarative part declares items that are common
The entity header defines the ports and generics of the en- to all the design entities whose interfaces are defined by the
tity. The syntax is unchanged but the following inheritance given entity declaration.
rules apply : entity-declarative-part ::=
{ en tity-declarativeitem }
All ports and generics of an entity are inheritable.

New port and generic definitions can be added by the en tity-declarativeitem ::=
derived entity. su bprogramdeclaration
su bprogram-body
o Port and generic definitions cannot be redefined type-declara tion
through inheritance and should be unique. subtype-declara tion
constan t-declaration
Operation Declarations signal-declaration
shared-variable-declaration
Operations are used to specify a public message interface instance-variable-declaration
to an entity. Their formal parameters are signals, similar to file-declaration
ports. alias-declaration
attribute-declaration
operationdeclaration-list ::= attribu tespecifica tion
{ operation-declaration } disconnectionspeci fication
use-clause
operation-declaration ::= group-template-declaration
operationspecification ; group-declaration
operationspecification ::=
operation identifier [ (portlist ) ] The entity declarative part has been extended to allow
for the declaration of instance variables and the following
The following inheritance rules apply to operations: inheritance rules apply:
All entity declarative items are inheritable.
0 All operations of an entity are inheritable.
o New entity declarative items can be defined by the
o New operations can be defined by the derived entity. derived entity.
0 Operations may be redefined by declaring an opera- Subprograms can be redefined by the derived entity
tion having exactly the same name in the derived en- by declaring a subprogram having exactly the same
tity. name.

55

Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.
 0 Declarations cannot be overridden by the derived en- Architecture Declarative Part
tity since they are required for the defined operations.
The architecture declarative part declares items that are
available for use within the block defined by the design en-
Example tity.
- - An entity declaration with instance variable architecture-declarative-part ::=
- - declarations also: { block-declarativeitem }

use Work.Reg-Types.all ; block-declarativeitem ::=

entity Register is subprogram declaration
operation Clear ; I subprogram-body
operation Read(Va1: out RegHem) ; I type-declaration
operation Wnte(Va1: in RegXlem) ; I subtype-declaration
Instance variable Contents :RegMem ; I constant-declaration
end entity Register ; I signal-declaration
1 shared- variable-declara tion
I instance-variable-declaration
Entity Statement Part
I ohject_component_declaration
The entity statement part is unchanged and the inheritance I file-declaration
rules for the entity statements are the following: I alias-declaration
I component-declaration
0 All concurrent statements are inheritable. I attributedeclaration
I attributespecification
0 New statements can be defined by the derived entity. I disconnectionspecifica tion
I use-clause
As in VHDL, all such statements must be passive. I group-template-declaration
I group-declaration
2.2. Architecture Bodies The architecture declarative part has been extended to allow
for the declaration of objects and instance variables.
The architecture body defines the behavior of a design en- Instance variables are a subclass of the variable class of ob-
tity. An architecture declaration is referred to as a class jects which may be accessed by more than one operation or
body definition. process (see section 3.1).
Objects are instances of entities. They are analogous to
architecture-body ::= entity component declaration with component intantiation
architecture identifier of entitymame is (see section 3.2).
new architecturename 1 The same inheritance rules for the entity declarative part
architecture-declarative-part apply to the architecture declarative part (see the Entity
[ begin Declarative Part in section 2.1).
architecturestatement-part ]
end [ architecture ] Architecture Statement Part
[ architecturesimpleaamme ] ;
The architecture statement part contains statements that de-
The optional new clause specifies inheritance from another scribe the internal organisation of an architecture.
architecture. It must specify an architecture body from the
architecturestatement-part ::=
same entity.
{ concurren tstatement }
As for entities, only single inheritance is supported and an
architecture can only have another architecture as base. The set of concurrent statements has been extended to allow
The architecture declarative part has been extended to allow for the concurrent message send statements and the opera-
for the declaration of instance variables and object compo- tion body statements (see section 4.1 and section 5.1).
nents, while the statement part has been extended to allow The inheritance rules are the following:
for the definition of operation bodies and messages.
0 All concurrent statements are inheritable.
Inheritance applies to both the declarative part and the state-
ment part of an architecture. 0 New concurrent statements can be defined.

56

Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.
Examples Instance variables may be accessed by more than one oper-
ation or process at a time, and the conflict of this multiple
- - An architecture declaration with instance van'able access is resolved by means of shared variables with a pro-
- - declarations and operation bodies: tect mechanism [31.

use Work.Reg-Types.al1 ; 3.2. Object Component Declarations

architecture RegBehavior of Register is
Instance variable Contents :RegMem ; Like signal and variable declarations, an object component
begin declaration defines an object which is an instance of an en-
operation Clear do tity (class). Such an object is an explicitly declared compo-
begin nent.
Contents := (others => '0') ;
object-componen t-declaration ::=
end operation Clear ;
component identifier-list :
operation Read( Val : out Regxlem) do
ins tan tiated-en tity
begin
[ genericmap-aspect ]
Val <= Contents ;
end operation Read ;
[ portaap-aspect 3 ;
operation Write( Val : in RegXlem) do The object component declaration includes the generic map
begin aspect and the port map aspect (if present). This instantia-
Contents := Val ; tion associates signals or values with the ports of the object,
end operation Write ; and associates values with generics of that object (analo-
end architecture RegBehavior ; gous to the way in which a signal or a variable is initialized).

- - An architecture declaration using the new clause: Examples

use Work.Reg-Typesall ; component RI, R2 :Register ;

component C : Counter generic map ( max-value => 16 ) ;
architecture PCBehavior of Program-Counter is
begin
operation Increment do
begin 4. Sequential Statements
Contents := Contents + 1 ;
end operation Increment ; Sequential statements are used to define algorithms for the
end architecture PCBehavior ; execution of a subprogram, a process or an operation body.
They are executed in the order in which they appear.
3. Declarations sequence-ofstatemen ts ::=
{ sequentialstatement 1
OOVHDL, like VHDL, defines several kinds of 'entities'
that are declared explicitly or implicitly by declaration. sequentialstatement ::=
wait-statemen t
Two object declarations are added: the instance variable
declaration and the object component declaration.
1 assertionstatement
I reportstatement
I signal-assignmentstatement
3.1. Instance Variable Declarations I vm'able-assignmentstatement
I procedure-callstatemen t
Instance variable declarations declare variables which are I message-sendstatement
visible to all operations and processes defined in the same I if-statement
architecture body. I case-statement
An instance variable can be declared in the entity declara- I 1oop.statement
tive part or in the architecture declarative part. I nextstatement
I exitstatement
variable-declaration I:= I returnstatement
[ shared I instance ] variable identifierJist : I null-statement
subtypeindication [ := expression] ;

57

Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.
The message send statement has been added to the set of begin
sequential statements to specify a message sent to an object. operationstatemen t-part
end operation [ identifier] ;
4.1. Message Send Statements
operation-declarative-part ::=
A message invokes the execution of an operation body in { process-declarativejtem }
the architecture of a specified Entity.
operationstatement-part ::=
messagesend-statemen t ::= { sequentialstatement }
object_name.operationaame
[ ( actual-parameter-list ] ; The execution of an operation body statement consists in
the repetitive execution of its sequence of statements.
Since operation bodies are similar to processes (i.e., con-
The object name specifies the entity instance (i.e., object) current), an entity can execute more than one operation at a
and the operation name specifies the operation body to be time.
invoked. Operations are requested when a message is sent. Messages
When an entity E invokes one of its own operations, i.e. sent to the same entity at the same time are queued in the
sends a message to itself, the keyword self is used in place entity in case they invoke the same operation. When the
of the object name. operation is performed, the next message in the queue is
removed and executed. If there is no message in the queue,
the entity waits for a new message.
Examples
Messages have the same priority level and are queued in a
R 1.Read( Data ) ; first-in-first-out (FIFO) order.
C.1ncrement ;
6. Lexical Elements

5. Concurrent Statements The new keywords that have been added to the lexical ele-
ments of VHDL are the following:
Concurrent statements describe the overall behavior or do, instance, operation, and self.
structure of a design. They execute asynchronously with
respect to each other.
7. Predefined Language Environment
concurren tstatement ::=
blockstatemen t Only one predefined attribute has been added to the prede-
I processstatement fined attributes of VHDL.
I operation-bodysta temen t
I concurrentmessagesendstatement 7.1. Predefined Attributes
I concurren tprocedure-call-statement The ’component attribute has been added to express a
1 concurrentassertionstatemen t broadcasting mechanism. It allows the same message to be
1 concurrentsignal-assignmentstatement broadcast to objects of the same base class. The description
I componentinstantiationstatemen t of this attribute is given bellow:
I generatestatement
entityname’component
Two new concurrent statements have been added to VHDL. Kind: List of entity names
Prefix: An entity name
5.1. Operation Body Statements Result: A list of messages

The operation body statements are similar to process state- Example

ments. They differ by the usage of the keywords operation
operation ClearAI1 do
and do.
begin
operation-bodystatemen t ::= Register’component. Clear ;
operationspecification do end operation ClearAll ;
operation-declara tivepart

58

Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.
8. Conclusion

In this paper, we have described OOVHDL, an object

oriented extension to VHDL. We have presented the dif-
ferent object oriented features added to the language and
all the syntax extensions with their respective semantics.
These extensions preserve the concurrency of VHDL and
ensure upward compatibility. Communication using signals
has been simplified by extending the design entity to sup-
port operations that enable the sending of messages. The
use of design models within new designs is enhanced by al-
lowing the reuse through the inheritance mechanism. This
has been achieved by adding only four new keywords to the
language.
Work is in progress to incorporate new extensions for
data modeling and to implement the different extensions
within a preprocessing tool which translates OOVHDL into
VHDL.

References

[ l ] J. Benzakki and B. Djafri. Object Oriented Extensions to

VHDL, The LaMI proposal. Proceedings of Conference on
Hardware Description Lunguages’97, pages 334-347, April
1997.
[2] IEEE Standard VHDL Language Reference Manud. IEEE
Std 1076-1993,Revision of IEEE Std 1076-1987, 1994.
[3] IEEE DASC P1076a Working Group. Shared Variable Lan-
guage Change Specification (PAR 1076a). 1996.

59

Authorized licensed use limited to: Consortium - Algeria (CERIST). Downloaded on April 21,2021 at 21:05:03 UTC from IEEE Xplore. Restrictions apply.