SWL-TR-93-5025

PROPOSED OBJECT ORIENTED PROGRAMMING(OOP) ENHANCEMENTS TO THE VERY HIGHSPEED INTEGRATED CIRCUITS (VHSIC)HARDWARE DESCRIPTION LANGUAGE (VHDL)

9i

a MICHAEL T. MILLS, LT COL

AD-A274 004I211111111ii11ii

AUGUST 1993

FINAL REPORT FOR 05/04/92-08/04/93

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION IS UNLIMITED.

DTIC"�oC 2,I993 ,.

93-30636

SOLID STATE ELECTRONICS DIRECTORATEWRIGH7 LABORATORYAIR FORCE MATERIEL COMMANDWRIGHT-PATTERSON AIR FORCE BASE, OHIO 45433-7331

98 12 17028

NOTICE

When Government drawings, specifications, or other data are used forany pjrpose other than in connection with a definitely Government-relatedprocurement, the United States Government incurs no responsibility or anyobligation whatsoever. The fact that the government may have formulatedor in any way supplied the said drawings, specifications, or other data,is not to be regarded by implication, or otherwise in any mannerconstrued, as in licensing the holder, or any other person or corporation;or as conveying any rights or permission to manufacture, use, or sell anypatented invention that may in any way be related thereto.

This report is releasable to the National Technical InformationService (NTIS). At NTIS, it will be available to the general public,including foreign nations.

This technical report has been reviewed and is approved forpublication.

MICHAEL T. MILLS, LtCol, USAFR JOHN W. HINES, ChiefDesign Branch Design BranchMicroelectronics Division Microelectronics Division

STANLEY E. WAGNER, ChiefMicroelectronics DivisionSolid State Electronics Directorate

If your address has changed, if you wish to be removedfrom our mailing list, or if the adaressee is no longeremployed by your organization please notify WLiELED, WPAFB, OH45433-7331 to help us maintain a current mailing list.

Copies cf this report should not be returned unless return isrequired by security considerations, contractual obligations,or notice on a specific document.

Form Approved

REPORT DOCUMENTATION PAGE oMB No, 004-08o8

=.13e. 1-1*~ -: 8 :' e7 - t ýf 'fC a '~ I,: C -. ec IC esc- tre ! ýe '0, * ';- -t"Mofts Ofl -. n.:; ? ST ý; W4Of.'Cah-;3,: 4-ý ,ta 'ecreo a no ..:'ro evrc a o'e P, -. -Z - at '~~ S e'sd l e a'o '; tt9% b~ldtl ft! -ate :'-3. :tre' j,oej ot I

Sa. .. 10s. 'e 2^4 4 ýtir' W2.4302 J,'d t: ý 0-. 1!~ 't %4ade'ent ana 9ý7e Pgper.C' ReC.'-! C, P':je:t ýC'.1t.188 Aapý e CC ;D503

I AGENCY USE ONLY Leave blanx) 2 REPORT DATE 3. REPORT TYPE AND DATES COVERED

AUG 1993 1 FINAL 05/04/92--08/04/934 TITLE AND SUBTITLE F-):Uk'U~l) UUJ•SLT" UL1L•kI'I'kL)ZS FHOGRUAMM S. FUNDING NUMBERS

(OOP) ENHANCEMENTS TO THE VERY HIGH CSPEED INTEGRATED CIRCUITS (VHSIC) PEHARDWARE DESCRIPTION LANGUAGE (VHDL) PR

6 AUTHOR(S) TAMICHAEL T. MILLS, LT COL WU

7 PERFORM,!cG ORGAN ZATION NAME(SI AND ADDRESS(ES) 8. PERFORMING ORGANIZATIONREPORT NUMBER

SOLID STATE ELECTRONICS DIRECTORATEWRIGHT LABORATORYAIR FORCE MATERIEL COMMANDWRIGHT PATTERSON AFB OH 45433-7331

9. SPONSORING MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10 SPONSORING MONITORING

SOLID STATE ELECTRONICS DIRECTORATE AGENCY REPORT NUMBER

WRIGHT LABORATORY WL-TR-93-5025AIR FORCE MATERIEL COMMANDWRIGHT PATTERSON AFB OH 45433-7331

11 SUPPLEMENTARY NOTES

12a. DISTRIBUTION, AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION ISUNLIMITED.

l c° ibes an integrated set of Object OrientedProgramming (OOP) enhancements proposed for a future revision ofthe VHSIC Hardware Description Language (VHDL). It offersinheritance with extension for VHDL record, array and private typedeclarations, plus multiple inheritance with extension for entitiesand corresponding architecture bodies, and a class wide dispatchingcapability for all tagged types and tagged entities. If thesethree enhancements are accepted by the IEEE, VHDL based designautomation tools can possess new abstract design capabilities fordeveloping and enhancing electronic hardware. Current softwarelanguages with OOP capability increase productivity and reuse byenabling the design process to inherit and extend existing datastructures and functionality. By selectively inheriting whatalready exists, the designer minimizes duplication. Functionalcapabilities and characteristics can be inherited and extendedwithout affecting existing portions of a design. --

14. SUBJECT TERMS 15. NUMBER OF PAGESVHDL - IEEE 1076 - Design Language - Hardware .; : -Description Language, OOP - Object Oriented 16. PRICE CODEProgramming

17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACTOF REPORT OF THIS PAGE OF ABSTRACT

UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED UL%S- 754.0- 280 5500 Sta-daao :ý-" 298 ' . 2-89,

Table of Contents

1. Introduction .................... ..................... 1

2. Benefits of Adding OOP Capability to VHDL ...... ........ 3

3. OOP in Small Talk, C++, and the Proposed Ada 9X ... ..... 5

4. The Proposed OOP Enhancements to VHDL Types ... ...... 6

5. An Example of Using Tagged and Derived Types in VHDL . 9

6. OOP Enhancements to VHDL Entities and Architectures . . 10Derived Entities .i.................................... 10Derived Architectures .......... ................. I...11

7. An Example of Using Derived Entities and Architectures 14

8. Classes of Types ............... .................... 15

9. Rationale for adding OOP to VHDL ..... ............ .. 16

10. References ............................................. 18

Accesion For

NTIS CRA&IDTIC TABU, ainounced ElJ :ztication

B y ...............Di t ib ,tioi

, i1.itbtiiiy Codes)Diot Ior

iii

m~~~ ~ Dvmcnu mn mmnn Nn.NINNrN m uum u ur r E

1. Introduction

This report describes a proposed Object Oriented Programming(OOP) set of enhancements to VHDL to be considered for the nextor later revision of IEEE-Standard-1076 [1] or IEEE P1076 1992B(2]. First, it incorporates OOP features such as extendedderived types into VHDL type declarations by borrowing somefeatures from Ada 9X, the next revision to the Ada programminglanguage. Second, it incorporates a new OOP technique, developedexclusively for this proposed enhancement, called derivedentities. Third, it uses the class-wide type capability fromAda 9X by proposing a 'CLASS attribute for tagged types tosupport class-wide dispatching of operations. Certain types andall entities can be tagged which specifies that theircharacteristics and functional capabilities can be inherited(derived) and extended.

Record, array, and private type declarations with OOP provide thefirst proposed inheritance features. This allows new signals andvariables to inherit characteristics (such as a data structure orbus width) from existing signals and variables. Any proceduresor functions with parameters of the inherited type are alsoinherited. The designer can add new characteristics, functions,and procedures to the new signals and variables withoutdisturbing the inherited signals or variables. These three OOPtechniques will make VHDL a significantly more powerful abstractdesign language.

Derived entities provide the second proposed inheritance featurewhich uses syntax similar to Ada 9X but allow declarations andconcurrent statements to be inherited from multiple entities.The designer can selectively modify, leave alone, or extendentities resulting in new capabilities created with minimalspecification. If something other than what is inherited isdesired, the designer specifies what is different from theinherited entities and their corresponding architectures. Thedesigner still has to code complete concurrent statements,including whole process statements.

As a goal, this proposed set of language changes should stayupward compatible and minimize impact on existing VHDL tools.OOP normally incorporates inheritance to a class of objects w~tha set of operations associated with each class. The proposed OOPfeatures for VHDL borrow derived types from Ada [3] andextensions of derived types from the proposed Ada 9X [4]. Thisproposal treats signals and variables as candidate VHDL objectsto incorporate inheritance. Procedures and functions withsignals and/or variables as its parameters or function returnsserve as operations associated with these signals and variables.Since signal and variable declarations include the type construct(i.e., type_mark), adding extended derived types and a 'CLASSattribute for tagged types to VHDL will provide inheritance to

1

signals and, to a lesser extent, variables (including sharedvariables in VHDL-92B). Since the basic operations on signalsand variables are assignment statements, in order to inheritsuch operations, the designer must encapsulate such assignmentstatements into procedures and (possibly) functions. Inheritancethrough derived types can only impact the type portion of asignal or variable. However, when used with other OOP featuresin this report, such inheritance can add significantly to theabstractness of VHDL and make VHDL designs more easily modifiableand reusable. By using the proposed extendable derived typesfor signals and variables and incorporating them into VHDLprocedure and function parameters, operations such as signal orvariable assignments can be inherited from existing subprogramsinto new subprograms and extended to provide new data structures.The designer can add new functional capabilities of inheritedsubprograms without affecting the existing subprograms.

2

2. Benefits of Adding OOP Capability to VHDL

As microelectronic designs continue to grow in complexity,design descriptions become overwhelmingly large. VHDL descriptionsof this complexity could be simplified if new entities could inheritthe characteristics and functionalities of existing entities andextend the characteristics and functionality without requiring anyreanalyzing (or recompilirg) of the old entities. Rather thanduplicating a significant portion of existing entities into newentities, only differences between existing and new entities wouldneed specification. For designs with the majority of its structureand behavior nearly regular (i.e., built with somewhat similarentities), such a VHDL enhancement could reduce complexity of VHDLcode significantly.

If any existing entity, architecture, or signal were modified,the current VHDL would require that they be reanalyzed (i.e.,recompiled). If new entities and architectures could inheritcharacteristics of existing ones and extend them without affectingtheir structure or behavior, designs could be expressed asdifferences from the existing entities and architectures which wouldno longer require reanalyzing. Both VHDL code size and design timewould decrease significantly for most large designs. Theappropriate Object Oriented features added to VHDL could make thisa reality. Such VHDL changes would impact design, reuse,extendability and maintenance of the design description while addingsignificant design abstraction capability to the language. Existingdesigns are more adaptable for reuse if increased signalcharacteristics can be expressed in extendable derived types thatleave these existing designs untouched. Such modifications reduceany degrading impact on the reliability of existing designs. The OOPcapability described in this report is proposed for this purpose.

By adding OOP capability to the type declaration in VHDL,signals and variables can inherit characteristics from existingtypes. By modifying a signal declaration by changing its type,procedures which contain operations on these signals and variablescan also be used with the new signals and variables. As a result,adapting procedures to modified signals with derived types becomesautomatic.

With the following steps, the designer can develop proceduresassociated with signals and variables as building blocks to increaseabstraction characteristics of VHDL design. (1.) Initially, developa class of types and signals which have these types. Then, (2.) asthese signals are more defined or specific, develop more specificprocedures which are used by the more specific signals. When newsignals are developed, which fall within the original class ofsignals, then procedures which were developed for that class can beused for the new signals without any modification. With extendedderived types discussed below, large VHDL descriptions can be leftintact without recompilation.

If this approach is implemented into a future VHDL revision and

3

corresponding design automation environments, productivity, reuse,reliability and maintainability of resulting microelectronic designscould potentially increase significantly. When new entities can bedesigned by specifying differences from one or more existingentities, productivity is likely to escalate. The more capabilitiesthat new entities can inherit from existing entities, the greaterreuse is implemented. Since existing entities are untouched and notreanalyzed, the original reliability remains high when adding newfunctionality and structure through derived entities, andarchitectures, and extendable derived types. Maintainability isenhanced by reducing duplicate specification and keepingcapabilities of several entities localized to a few rather than manyentities and corresponding architectures.

The late binding features of these proposed languageenhancements provide a more dynamic language that opens newopportunities for implementations. Such language enhancements cansignificantly reduce impediments to faster, more dynamic designtools of the future approaching near instantaneous compilation andbinding as the designer adds extended features to existing portionsof his or her design.

The proposed OOP features in this report require the followingreserved words to be added to the VHDL standard:

newis newwith recordwith arraywith privatetagged (followed by record, array, private, or entity)

(also, tagged is in the phrase is tagged.)in derivedwith nullwith delete

Since most of these reserved words are only allowed inrestricted locations within the language and are usually accompaniedwith another reserved word, chances of these new reserved wordscausing the proposed OOP changes to be nonupward compatible isexpected to be zero.

4

3. OOP in Small Talk, C-+, and the Proposed Ada 9X

Determining an appropriate OOP approach for VHDL began byexamining OOP implementations of existing software languages suchas Small Talk, C++ and the current draft revision of Ada, called Ada9X. After looking at these OOP approaches, considering advantagesand disadvantages of each, and considering appropriateness withexisting VHDL features, I selected Ada 9X as the most appropriatebaseline from which to develop OOP enhancements to VHDL. As amember of the Ada 9X Distinguished Reviewer Team, I had up to theminute access on the current state of Ada 9X and was most familiarof its OOP approach compared to the other languages.

Small Talk's approach to OOP is to allow everything to beinherited. This approac;. has a tremendous implementation cost whichis unacceptable for large and complex designs normally implementedby VHDL.

The C++ approach to OOP, although well known by a largesoftware community, had several drawbacks when compared to Ada 9X.[3] contains a technical report on Ada 9X vs. C++. Due to itsevolution from C, a language with unsafe features and with littleto offer from which to build abstractions, C++ had to implement newfeatures to do what already existed in the Ada language, such asinformation hiding. The unsafe characteristics of C, especially forlarge complex programs, is still an irritant for C++.

Ada 9X was the best approach because of several reasons. VHDLwas originally designed using Ada as a baseline. As a result, VHDLbecame very Ada like. The Ada 9X OOP approach works well withlarge, complex programs. It also builds from features already inthe Ada language.

The OOP approach, proposed for VHDL in this report, borrowssome of the OOP features from Ada 9X, such as derived and taggedtypes. It also contains some unique OOP features, which are Ada 9Xlike in syntax, but were developed exclusively for VHDL. These arederived entities and architectures. This feature was necessary toapply OOP where it could have its biggest impact, on the VHDLentity, the key to VHDL abstraction. Ada 9X derived types used bythis approach apply only to the type portion of declared signals andvariables. The VHDL derived types are proposed for record, array,and private types.

Another proposed OOP feature borrows class-wide types from Ada9X which provides polymorphic dispatching of operations to class-wide types which are tagged. A 'CLASS attribute is proposed toprovide classes of tagged types and their derivitives. This willprovide a more complete abstraction capability to VHDL whenintegrated with the other two proposed OOP enhancements.

5

4. The Proposed OOP Enhancements to VHDL Types

By adding derived types (from Ada 83) with extended parts(like those proposed for Ada 9X), VHDL can incorporate ObjectOriented Programming capability within its data types.

In current VHDL, signals can reside in Architecture Bodies,Blocks, Packages, Entities, and Parameters of Subprograms.Variables are restricted to Processes and Subprograms. Thisproposed OOP approach treats VHDL signals and variables asobjects. Signal Assignments and Variable Assignments, whetherconcurrent or sequential, are operations on signals andvariables. Procedure calls can be overloaded based on theirparameter types. Signals and variables are declared with typesand, therefore, can be used as formal parameters of subprogramsto differentiate which overloaded subprogram can be used as oneof its operations.

The following changes are proposed to VHDL types in orderto add object oriented programming with inheritance to VHDLsignals and variables and the procedures and functions associatedwith them.

1. Add a derived type to the type definition as follows:

type_definition ::=scalartype-definitionI composite...typedefinitionI accesstype__definitionI filetype-definitionI derived-type_definition

derived-typedefinition ::=new subtype-indication (typeextensionpart]

typeextension-part ::=record_extensionpartI arrayextension partI privateextensionpart

record_extensionpartwith record

elementdeclaration {,element_declaration)end record

arrayextension~partwith array

[ modifiedindex_constraint ][ of modifiedelement_subtypeindication I

end array

privateextensionparttype identifier is now

6

ansistersubtypejindication with private

The reserved word new is added to the language to designate thatthe type is derived from an existing type. Thetypeextensionpart is only allowed for tagged types discussedbelow.

2. Add tagged types to the language by adding the reserved wordtagged to the array and record type definition. Adding thisreserved word to the compositetype definition provides extendedinheritance for record and array types.

composite_typedefinition :.=[tagged] arraytype definitionI [tagged] record-type_definition

The tagged feature can provide the OOP polymorphism (i.e.,dynamic binding) to the language. In Ada 9X, this featureincludes dynamic (run-time) polymorphism. Tagged types providedynamic binding and dispatching of inherited features at runtime. The implementation may provide static checking at compile(or analysis) time for some OOP binding. However, when essentialOOP binding information is only known at simulation time, dynamicbinding capability is required.

The proposed Ada 9X includes only record and private types astagged [4]. An early version of the Ada 9X design proposed arraytypes as tagged but was later dropped to keep the languagecomplexity and implementation costs to a minimum. Since arraytypes in VHDL are used heavily, this proposal currently includestagged and derived types for arrays as well as records. Ifimplementation costs are too high for VHDL as well, then thatpart of the proposed enhancement could be dropped withoutimpacting the rest of this OOP enhancement to VHDL.

Assuming private types either survive the IEEE balloting processfor the VHDL-92 standard or appear in a future revision, this OOPproposed enhancement also includes tagged and derived types forprivate types (as in Ada 9X) for added abstraction capability.

3. This proposal adds a class concept for tagged types to thelanguage. Ada 9X contains this feature by adding a 'CLASSattribute for class-wide types. An Ada 9X class specifies a basetype plus all its derivatives which can have commoncharacteristics and operations. Class-wide types provide theinternal dispatching capability of tagged types for late binding.

Record, Array, and Private declarations with tags added:

record type_declaration[tagged I record

element_declaration( element_declaration I

end record

7

constrained~array-definitiontagged I array index_constraint of

element-subtype indication

unconstrained-array~definition:=tagged I array ( index_subtype-definition

index-subtype-definition ) ) ofelement-subtype_indication

private_type declaration ::type identifier is [ tagged

private [contractual-details

8

5. An Example of Using Tagged and Derived Types in VHDL

package ABSTRACT istype BUSSSMALL is tagged array (0 to 15) of BOOLEAN;

entity SOMETHING is

end ... ;

architecture DATAFLOW of SOMETHING issignal SMALLSIG : BUSSMALL;

begin

SMALLSIG <= ...

end ... ;

use package ABSTRACT;package MORE_SPECIFIC is

type BUSLARGE is derived BUSSMALLwith array (16 to 31) of ...

-- This type inherits.

signal LARGERSIC BUSLARGE; -- New signal-- indirectly inherits from old-- signal through derived type-- inheritance.

end ... ;

9

6. OOP Enhancements to VHDL Entities and Architectures

Add a new capability for new entities to be derived from existingentities and to inherit all characteristics from the existingentities and their corresponding architectures. Add an optionaltagged indicator (a new reserved word tagged) to the originalentity declaration to specify inheritance at simulation time.

entity_declaration ::=[tagged] entity identifier is

entityheaderentity_declarative_part

beginentity-statementpart ]

end entity [encity simple name];

Derived Entities:

Add a new VHDL construct called a derived entity which referencesany existing entity declaration and specifies any modifications.The derived entity inherits all the functional, structural, anddeclared object (signal, variable, and constant) characteristicsof the entity it references. The entity..extensionpart of thederived entity contains any added or modified parts that aredifferent from the existing (or referenced) entity. This givesthe designer a capability of creating new entities that aresimilar to existing entities by only specifying changes. None ofthe existing entities are corrupted and, therefore, should nothave to be reanalyzed when analyzing and linking the derivedentities. The new key word tagged is added to existing entitiesto specify inheritance at simulation time (often calledpolymorphism). This feature tells the tool environment to do allthat is necessary to prepare the entity for inheritance atsimulation time. Only specify one inherited_entityidentifierunless inheritance is desired from more than one entity (referredto as multiple inheritance). When multiple inherited entitiesare specified, the first one listed is the default to resolveconflicting declarations and concurrent statements from differentinherited entities. To selectively deviate from the default,explicitly write the declaration of the concurrent statement.Note: Derived entities can also be tagged so that theircharacteristics and functionality can be inherited by entitiesderived and extended.

derived_entitydeclaration[tagged] entity identifier is new

inheritedentityidentifieris new inherited_entity_identifier }

I entityextension__part

entityextensionpart ::=with entity

entityextensions_list

10

end [entity] [entitysimple-name];

entity-extensions_list[entityheader_changes][entitydeclarative.part-changes]

C beginentity-statementpartchanges]

Include in the entity-extensionslist all added or modifieddeclarations, stater ýs, generics, or ports. To copy items fromthe derived entity iout adding extensions specify with thereserved words "wit.: .-ull" at the beginning of the item.

entity-headerchanges ::=[ (with null] formal_generic_clause ][ [with null) formalportclause I

entitydeclarativepartchanges ::={ [with null] entitydeclarative_item }

entity-statement-part-changes ::={ [with null] entitystatement }

The above new VHDL features allow the designer to specifydifferences (additions or modifications) between a new derivedentity and the existing entity it references without having torewrite any significant portion of the existing entity.

Note: An earlier design of entitystatementpart changesrevealed that diminishing returns might be reached if too manychanges are specified. In this case, single inheritance would bemore appropriate than multiple inheritance. For some entitiesand architectures, no inheritance would be more appropriate.This approach provides controlled single or multiple inheritanceeither statically (by the analyzer) or dynamically (by thesimulator). Derived entities and architectures can be inheritedby other additional derived entities and architectures. As aresult, abstraction can be implemented extensively in a design.

For declarations and concurrent statements within nested blockstatements, the block structure is specified by rewriting theblock statements. Respecifying the block, or nested block,structure is normally a minimal effort and avoids added syntaxcomplexity.

Derived Architectures:

The following new VHDL features perform similar functions asabove for derived architectures. This allows designers tospecify differences (additions, modifications, and deletions)between an architecture body of a new derived entity and thereferenced architecture of an existing entity. For simulationtime inheritance, only the entity of the referenced architecture

11

is tagged. Although changes are specified within the derivedarchitecture, all inheritance is accomplished through the entity,the chief VHDL building block for abstraction.

derived_architecture_declaration ::=architecture identifier of derivedLentityname

in [tagged]new inherited_architecture_name

{ is new inherited_architecture_name }[architecture_extensionpart]

end [architecture][architecture-simplename];

The architectureextension-part includes items to be added ormodified. Items to be deleted are designated "without".

architectureextensionpart ::=(architecture_declarative-partchanges]

[begin[architecturestatementpartchanges]

architecturedeclarativepart-changes ::={ [without] block-declarative_item }

architecturestatement-partchanges ::={ [without] concurrentstatement

Both blockdeclarativeitems and concurrent statements within thederived architecture can repeate exactly in the architecture ofthe inherited entity, modified (using the name of the item orstatement and changing what is desired), added as a new item orstatement, or deleted using a with delete at its beginning.Existing items or statements which are not changed do not need tobe repeated. The analyzer will include them as part of the newarchitecture. To reference nested parts of an architecture,repeat the surrounding nested constructs and anything elsenecessary to resolve any conflicting names, etc.

Note: Since derived entities can be tagged, there is no reason tohave a tag for the corresponding derived architecture (forfurther inheritance).

Note: An earlier design of architecture_statementpart-changesprovided the capability to selectively change the defaultinherited entity for each (or a group of) block_declarative_itemsor concurrentstatements. However, this feature complicated thesyntax. Therefore, in order to avoid complexity, the syntax waschanged so that the designer would rewrite or modify thedeclaration or concurrent statement that deviates from thearchitecture of the defaulted inherited entity. Uniquedeclarations and concurrent statements are still inherited fromtheir respective architectures (or entities), whether it is thedefault or not. The earlier draft syntax forarchitecture_declarativepartchanges andarchitecture_statement__partchanges was

([of inheritedentity_identifier]([with null] entity_statement }

12

The "inherited_entity_identifier" changed the default for asingle or a group of declarations or statements. The"inheritedentity_identifier" rather than the"inherited_architecture_name" was used as a selection mechanismsince multiple inheritance consists of inheriting fromarchitectures of corresponding multiple entities rather thanmultiple architectures.

Note: The number of changes made within a derived entity orarchitecture should be limited to a reasonable number to maintainreadability of the VHDL source code. If the number of changesexceeds this, then best engineering practice dictates that thenew entity and its architectures be written as actual entitiesand architectures that are not derived. The purpose of derivedentities and its corresponding derived architectures andinheritance is to reuse what exists, adapt these entities, andincorporate a limited number of changes without having to createbehaviors, structures, and objects that already exist in theinherited entities or their respective architectures.

13

7. An Example of Using Derived Entities and Architectures

Existing entity and architecture body:

tagged entity FullAdder isport (X, Y, Cin: in Bit, Count, Sum: out Bit);

end FullAdder;

architecture Data_Flow of Full_Adder issignal A, B: Bit;

beginA <= X xor Y;B <= B and Cin;Sum <= A xor Cin;Cout <= B or (X and Y);

end DataFlow;

Derived entity and architecture body (only specifying changes):

entity Modified_Adder is new FullAdderwith entitygeneric (newstuff : integer) -- This is added.

-- This port is unchanged, therefore unspecified.begin

New_Object : BIT; -- only extensionsend entity ModifiedAdder;

-- Statements from inherited-- entity are implicitly

-- coppied here.

architecture WorpFlow of ModifiedAdder isnew DataFlow

beginwith nullSum <= A xor Cin;

Intermediate <= A xor Cin; -- addedSum < Intermediate and A; -- modified

-- Note: The remaining declarations and-- statements remain unchanged.

end architecture WorpFlow;

Note: More complic.,týd examples would show more obvious reuse anddesign time/cost savings. Note that the original entities andarchitectures are untouched and, therefore, remain error free.Since the changes are mininimized and the bulk of design is localizedin existing entities and architectures, the resulting code is highlyreliable and maintainable compared to code that duplicates asignificant portion of predesigned code.

14

8. Classes of Types

This proposed VHDL enhancement provides dispatching onpimitive operations of tagged types. It borrows this from Ada9x.

Ada 9X provides the following:

"Ada 9X provides dispatching on the primitive operations oftagged types. When a primitive operation of a tagged type iscalled with an actual parameter of a class-wide type, theappropriate implementation is chosen based on the tag of theactual value. This choice is made at run time and represents theessence of dynamic polymorphism. ... In some cases, the tag canbe determined at compile time." [4]

15

9. Rationale for adding OOP to VHDL

Since concurrent procedure calls can be called fromarchitecture bodies, entities (if passive), and blocks, and sincenonconcurrent procedure calls can be called from processes andsubprogram bodies (functions and procedures), then procedures aregood candidates for primitive operations. Since procedures (andfunctions) can be overloaded and, therefore, selected by theirparameter and return types, these operations can be associatedwith objects of the same type. Formal parameters and returns ofprocedures and functions can be constants, signals, or variables.Since constants cannot be changed, signals and variables are theremaining objects which can be operated on by procedures. Sincethe scope of which variables are visible is limited to processesand subprograms, their application as objects for inheritance islimited. However, they may have some value for abstraction forobjects confined within its scope. Global variables with theirincreased scope offer additional objects for inheritance but areonly an added convenience. None of the OOP features in thisreport depend on global variables. The remaining and most likelyobjects associated with procedures and candidates for OOP aresignals. Signals can be operated on from within architecturebodies, blocks, processes, and subprogram bodies. The commonoperation which affects signals is the signal assignmentstatement. Since procedure calls can be located anywhere signalassignment statements are present, one or more signal assignmentstatements can be placed in procedures (subprogram bodydeclarations). Then, such procedures can be overloaded andassociated with signals that are formal parameters of a giventype. If the types of such signals contain inheritancecapabilities, then adapting processes containing such procedurecalls to modified types of signals is made easier as a result ofincreased abstraction within VHDL.

As procedures accumulate in a design, they can be placed inpackages and imported from a library. These procedures providesuch operations reusable. Signals with inheritance capabilitycan be declared abstractly and be associated with a set of commonprocedures as its operations. As a design progresses, newsignals with types derived from more abstract types can use theoriginal procedures plus new ones specific for the new (derived)signals. Characteristics of these signals can be extended in apolymorphic manner by designating its base type as tagged. Thus,stepwise refinement in signal definition with its associatedoperations (signal assignment statements embedded in itsassociated procedures) offers a method of providing greaterdesign abstraction within VHDL design descriptions andsimulations.

The following example illustrates the above concept.

-- Declaring abstract types:

type A is tagged array (Al : BOOLEAN) of BOOLEAN;

16

type B is new A with ......

type C is tagged record

end record;

signal X : A;

signal Y : B;

signal Z : C;

procedure M (X:A) procedure M (Y:B)

begin; begin;

A 1 <= transport X; M_1 <= transport Y;

A_2 <= ... ; M-2 <= . ;

end; end;

process

"M (X:A);

"M (Y:B);

end;

17

10. References

1. The Institute of Electrical and Electronic Engineers, Inc.,IEEE Standard VHDL Language Reference Manual. IEEE Std 1076-1987.

2. The Institute of Electrical and Electronic Engineers, Inc.,IEEE Standard VHDL Language Reference Manual - Draft (The 1992Draft Revision currently being balloted). IEEE Proposed Std VHDL1992B Draft.

3. American National Standards Institute, Reference Manual forthe Ada Programming Language. ANSI/MIL-Std-1815a edition, 1983.

4. Ada 9X Mapping/Revision Team, Intermetrics, Inc., AnnotatedAda 9X Reference Manual - Draft, Version 2.0, 29 March 1993.

18