Critique of the Objective VHDL Language Definition

Submitted to Design Automation and Test in Europe 2000. Critique of the Objective VHDL Language Definition Peter J. Ashenden Department of Computer Science University of Adelaide, SA 5005 Australia petera@cs.adelaide.edu.au Philip A. Wilsey and Dale E. Martin Dept. ECECS, PO Box 210030 University of Cincinnati Cincinnati, OH 45221-0030, USA phil.wilsey@uc.edu dmartin@ececs.uc.edu ommend which proposal best serves as the basis for standardised extensions to VHDL. The findings of the panel will be reported elsewhere. We introduce our critique of the Objective VHDL language definition by presenting some views on language design principles that lead to high-quality languages. While many of the principles presented here may appear to be common sense or general “motherhood and apple pie” statements, it is important to bear them in mind when designing language extensions, as they are all too often overlooked. As Brooks notes, “Conceptual integrity does require that a system reflect a single philosophy and that the specification as seen by the user flow from a few minds” [5, page 49]. The foremost principle is that language design should focus on semantics first and syntax second. The semantics of language features embody the meaning of the features, and determine what design intent can be expressed in the language. The benefits of a semantics-based language design methodology are illustrated by Tennent [9]. He comments that a methodological approach based on semantics is “intended to help a designer cope with the detailed problems of achieving consistency, completeness, and regularity in the design of specific language features,” and “has the effect of drawing [the designer’s] attention to deeper structural issues” in a language. Syntax, on the other hand, is the concrete expression of semantic features. While poor syntax may obfuscate the design intent, it does not prohibit expression of the intent. Good syntax design allows the designer to think about and communicate design intent clearly. In determining semantic features to be included in a language, sufficient simple semantic mechanisms should be preferred over more complicated general solutions; the simple mechanisms can then be used to build applicationspecific solutions. The semantic mechanisms should, as Abstract This paper provides a critical analysis of Objective VHDL, an object-oriented extension to VHDL. It is demonstrated that several design decisions lead to unnecessary complexity in the language and consequent modelling difficulty for designers. The SUAVE object-oriented extensions to VHDL, on the other hand, avoid these problems by more careful selection of language features. 1. Introduction The design of a programming language or a hardware description language is a difficult task. Since the language is the vehicle for expression of design intent, a good language can greatly help the design process, whereas a poor language can significantly hinder it. A language should conform to a set of ideals or philosophies to make it coherent, easy to learn, and easy to read and understand. This is what Brooks refers to as “conceptual integrity” [5]. Recently, two language designs have been proposed to the IEEE Object-Oriented VHDL (OOVHDL) Study Group as candidates for standardisation: SUAVE [2, 3] and Objective VHDL [8]. Both extend the VHDL hardware description language to include features for object-orientation. SUAVE also adds features for type-genericity, abstract communication, and dynamic process creation. As part of a process of review of the two proposals within the study group, we, the authors of the SUAVE proposal, have prepared this critique of the Objective VHDL proposal. The Objective VHDL proposers have likewise prepared a critique of the SUAVE proposal. The language descriptions, critiques and other material are to be examined by a panel of distinguished experts, who will rec- 1 much as possible, be orthogonal to each other. As Hoare suggests [6], “concentrate on one feature at a time,” and “reject any that are mutually inconsistent.” By choosing simple orthogonal semantic mechanisms, interaction between mechanisms is reduced and easier to understand. Simplicity of mechanism and reduced interaction make it easier for tool builders to optimise their implementation of language features. In the remainder of this paper, we demonstrate that several features of Objective VHDL violate the design principles introduced above. We contrast the features of Objective VHDL with those of SUAVE. 2. Class Types Objective VHDL uses class type definitions to provide data abstraction, encapsulation and inheritance in a single language construct. A class definition defines encapsulated data and operations for a type, and allows specification of a superclass from which data and operations are inherited. When extending an existing language, the preceding principles should be applied to the extensions. Simple semantic mechanisms should be chosen to augment the existing mechanisms, not to replace them. The new features should conform to the same design philosophies that were followed in the original language design so as to maintain architectural coherence. Careful consideration must be given to interactions between new features and existing features. While the semantics of new features are of primary concern, integration of new syntax is also important. Extensions should aim for stylistic consistency with the existing language. New features that are just syntactic rewrites of existing features (“syntactic sugar”) should only be included if they significantly enhance the expressiveness of the language. As Wirth puts it [11], “distinguish ... between what is essential and what ephemeral.” 2.1 Class Types and Information Hiding A class in an object-oriented language can be considered as an ADT with inheritance. VHDL already provides a partial facility for defining ADTs, based on the package construct. The user declares the concrete type in a package, and provides operations in the form of subprograms taking parameters of the concrete type. While the implementation details of the operations can be hidden (they are declared in the package body), VHDL provides no mechanism to hide the implementation details of the concrete type. Thus the security of ADTs in VHDL is weak. Given the importance of integration of new features with existing features, we need to identify existing features that relate to object-oriented modelling. VHDL already includes many features that relate to the principles cited by Booch as necessary for object-orientation: data abstraction, encapsulation, and inheritance with polymorphism [4, page 181]. Subprograms, entities, and packages support abstraction and encapsulation (albeit weak encapsulation in the case of packages); and overloading provides a limited, ad-hoc form of polymorphism. In the terminology of Wegner [10], these features are sufficient for VHDL to be called “object-based.” Objective VHDL addresses this weakness by adding a new language construct, class type definition, that provides secure forms of ADTs. A class type definition allows declaration of data elements and operations to be encapsulated by the ADT, and ensures that the implementation details are not visible outside the class type definition. Our first criticism is that the class type definition feature replicates much of the encapsulation facility provided by packages. This adds complexity to the language and its implementation. It forces a user to make a decision between two similar language mechanisms (packages or classes) when there ought not to be a need for such a choice. The choice is not always clear, and requires the designer to project the future evolution of the design. If the designer initially chooses to use a package for and ADT, and in subsequent development of the design discovers that features of a class type are required, the designer is forced to undertake significant re-engineering of the ADT and its use. The main issues for object-oriented modelling that are not addressed by the existing VHDL language are: inheritance-based hierarchy (for data types and hardware structures); the form of dynamic polymorphism that goes with inheritance (namely, dynamic binding); a stronger form of abstraction and encapsulation for abstract data types (ADTs); and a more flexible form of static polymorphism, such as that represented by generics in Ada and templates in C++. We maintain that language extensions to support object-oriented modelling should address these issues without subverting or replacing existing language features. Rather, they should build upon the existing language features that make VHDL object-based. Furthermore, there should be a clear separation of concerns between language features, so that a given feature does not attempt to serve multiple underlying modelling requirements. The interactions between language features should be well defined and understandable to language users. A further consequence of the Objective VHDL class mechanism is that will frequently lead to “double encapsulation.” Consider the common case of a class being declared so that it is visible in multiple design units. The class must be encapsulated in a package, as illustrated by the following example. package T_pkg is type T is class class attribute A : ... ; 2 procedure op_1 ( ... ); ... end class T; The problem that arises in Objective VHDL is that, in a class definition, it is not known whether the class will be instantiated as a memory location (constant or variable) or as a signal. The object on which a method is invoked is passed implicitly to the method, rather than being explicitly part of the method’s interface. Hence, for each method in the class, it is not known whether to use memory location or signal semantics for assignment and reading of the encapsulated data. Objective VHDL solves this problem with the mechanism of object configurations within a class definition. Object configurations for constants, variables and signals group method definitions that are to be used should the class be instantiated as a constant, variable or signal object respectively. A method with a given name and signature can appear in one or more of the following places: the common part, a constant object configuration, a variable object configuration, or a signal configuration. The kind of storage object on which the method is invoked determines which version of the method is called. Each version of the method must only use semantics appropriate for the kind of storage object implicitly passed to it. While this approach seemingly solves the problem, it does not integrate with the existing VHDL models of declarative regions and scope and visibility of names. The closest analogs of class definitions in VHDL are record and protected type definitions, each of which define a single declarative region in which homographs are disallowed. In contrast, a class definition defines three declarative regions, one each for constant, variable and signal objects, each consisting of the union of the common part and the corresponding object configurations in the class definition. This is a significant complication and departure from the existing language. There is significant potential for confusion in a model where names might be homographs and cause hiding in some configurations of a class and not in others. A further complication arises in methods in the common part of a class definition. Such methods may only read the values of class data. While the syntax of reading a value is the same for constants, variables and signals, the semantics differ between storage locations and signals. Thus the kind of read to use must be dynamically determined, making analysis, simulation and synthesis more complex. Alternatively, separate versions of the common methods must be generated, corresponding to the separate object configurations. The problem of dealing with objects of different storage kinds naturally arises with SUAVE also. However, it is easily dealt with using existing language mechanisms. Since the object on which a method is invoked is passed as an explicit parameter to the method, the storage class of the parameter (constant, variable or signal) determines the applicable semantics for update and reading. Multiple dif- end package T_pkg; The package serves no purpose other than to contain the class type, in which the data types and operations are declared. This extra layer of encapsulation adds unnecessary complexity to the model. SUAVE avoids these difficulties by making use of the existing mechanism (packages) to provide encapsulation for classes. Information hiding for the encapsulated data is provided through private types, and inheritance is provided through type derivation. (These features in SUAVE are adopted from the Ada-95 programming language [7].) Thus the choices of language features needed for particular application problems are clear, and no unnecessary encapsulation is required. 2.2 Encapsulated Storage v. Encapsulated Type A class in Objective VHDL encapsulates class attributes that denote the storage of a class instance. This leads to two problems, discussed in this section. 2.2.1 Variables and Signals In conventional imperative object-oriented programming languages, there is only one kind of storage for objects, namely, abstract memory locations with simple storage semantics. A location is updated by assignment, and its value can be read by naming the location in an expression. In imperative programming languages where storage is encapsulated within a class definition, the semantics of assignment and reading of encapsulated data are clearly those of storage locations. In VHDL, however, there are two kinds of storage: memory locations (constants and variables) and signals. The semantics of memory locations are the same as those of iterative programming languages. However, the semantics of signal storage are significantly different and more complex. Signal assignment involves editing transaction lists on drivers (which itself involves comparison and assignment of values), resolution of driving values, evaluation of nets (including invocation of type conversions and conversion functions) to determine driving and effective values, comparison of old and new values to determine events, and evaluation of dependent implicit signals. Because of the significant difference in semantics, VHDL uses separate assignment operations for memory location update (”:=”) and signal transaction scheduling (”<=”). The semantics of reading the values of memory locations and signals also differ. Compare use in an expression, association with parameters of different class, inclusions in sensitivity lists, etc. 3 function imag_part return real is begin return im; end function imag_part; ferently-named versions of methods for different storage classes are required, however, the semantics of declarative regions and scope and visibility of names are preserved. In the design of the SUAVE extensions, consideration was given to allowing parameter storage class to be taken into account as part of the signature of a subprogram to determine homographs. This would have allowed overloading versions of a method differing only in parameter storage class. However, the change was not included as it is a significant departure from the existing language. Should it be necessary to add this overloading, the SUAVE language design could easily be modified for it’s introduction. function cons ( real_part, imag_part : real ) return complex is variable temp : complex; begin temp.set( real_part, imag_part ); return temp; end function cons; function add ( augend : complex ) return complex is variable temp : complex; begin temp.set( re + augend.real_part, im + augend.imag_part ); return temp; end function add; 2.2.2 Pure Abstract Data Types and Operator Overloading The second problem stemming from encapsulation of storage in Objective VHDL classes relates to definition of what we will call “pure” abstract data types (ADTs). By pure ADTs we mean those that define a set of values, and for which all methods are pure functions on values of the type. Such ADTs simply serve as user-defined extensions to the language’s type system, in much the same way that types defined using type constructors (array and record definitions) do. ... -- other operations for variable procedure set ( real_part, imag_part : real ) is begin re := real_part; im := imag_part; end procedure set; end for; An example of a pure ADT is a complex number type, in which the set of values is 9 ¢ 9 (Cartesian representation) and all methods are arithmetic functions with arguments and/or results of the type. In Objective VHDL, such an ADT would be defined as follows: for signal procedure set ( real_part, imag_part : real ) is begin re <= real_part; im <= imag_part; end procedure set; end for; type complex is class end class body complex; class attribute re : real; class attribute im: real; Ideally, the arithmetic operation methods should be declared as overloaded operators. However, Objective VHDL does not allow a sensible means of doing so. The rules for overloading operators require that overloaded versions of unary operators have exactly one parameter, and overloaded versions of binary operators have exactly two parameters. In Objective VHDL, the only means of invoking class methods is using the prefix notation, where the prefix is passed to the method as an implicit parameter. Thus a unary-operator method effectively has two parameters, and a binary operator method effectively has three parameters. This is counter to the intention of operator overloading. The alternative, shown in the complex number example above, is to declare the arithmetic methods with ordinary identifiers as names. The add method, for example, would be invoked to perform a := b + c + d as: function real_part return real; function imag_part return real; function cons ( real_part, imag_part : real ) return complex; function add ( augend : complex ) return complex; ... -- other operations for variable procedure set ( real_part, imag_part : real ); end for; for signal procedure set ( real_part, imag_part : real ); end for; end class complex; a := b.add(c).add(d); type complex is class body A further problem arising from the approach to defining pure ADTs required in Objective VHDL is that there is no way to construct a value, other than by declaring an object and invoking methods upon it. This is because the storage function real_part return real is begin return re; end function real_part; 4 is encapsulated in the class, rather than being external. To illustrate this problem, consider how we must implement package body complex_numbers is a := b + (1 + 2i) function real_part ( C : complex ) return real is begin return C.re; end function real_part; Since the representation of complex numbers is hidden, we must use a method to construct the value (1 + 2i). However, since method invocation requires a prefix object of the class type, we must create a dummy object for this purpose. The value of the dummy object is not otherwise used. function imag_part ( C : complex ) return real is begin return C.im; end function imag_part; constant dummy : complex; ... a := b.add( dummy.cons(1.0, 2.0) ); function “&” ( real_part, imag_part : real ) return complex is begin return complex’(real_part, imag_part); end function “&”; Note that we are not actually using or attempting to update the value of the constant here; the constant simply exists for use as a prefix in the method call. An alternative is to declare a variable, and to set it to the value required: function “+” ( L, R : complex ) return complex is begin return complex’( L.re + R.re, L.im + R.im ); end function “+”; variable value : complex; ... value.set(1.0, 2.0); a := b.add(value); ... -- other operations end package body complex_numbers; However, this approach cannot be used in contexts where it is illegal to declare a variable. Both of these approaches add irrelevant detail and complexity to models. Examples of use of the ADT are: use complex_numbers.all; constant i : complex := complex’(0.0 & 1.0); variable a, b, c, d : complex; ... A corollary of being unable to construct values of a pure ADT is that it is not possible to initialise a constant of the ADT, other than by use of a dummy object. For example, to create a constant complex number with the value i, we would write a := a + b + c; a := b + complex’(1.0 & 2.0); 2.3 Assignment and Equality constant dummy : complex; constant i : complex := dummy.cons(0.0, 1.0); In the Objective VHDL Language Definition, the semantics of signal assignment and update are not well defined. Hence we must make some assumptions about the intent. In Section 4.5.2 of the Language Definition it is stated that processes that cause update of any class attribute of a classtype or classwide-type signal have a driver for the whole signal. We interpret this to mean that the process has a single driver, and that each transaction contains a complete value of a class type. Section 4.6.2 of the Language Definition describes the semantics of signal assignment as involving elementwise assignment from each class attribute of a waveform element to the corresponding class attribute of the target. We interpret this to mean assignment to each class attribute of the new transaction value created in the driver. The definition of signal assignment semantics is incomplete, in that it does not specify how transaction list editing is performed, especially given the absence of a predefined “=” operator for class types and classwide types. For class types, we assume elementwise comparison is used for testing equality, as this corresponds to elementwise assignment. For classwide types, it is not clear how Objective VHDL defines equality for the purposes of transaction list Pure ADTs are expressed much more simply in SUAVE, and avoid all of the problems identified here. The difference is that the storage is not encapsulated in the class definition; only the type is encapsulated. Furthermore, since the objects on which methods are invoked are passed as explicit parameters, it is possible to overload operators as methods. To illustrate, the complex number ADT can be expressed in SUAVE as follows: package complex_numbers is type complex is private; function real_part ( C : complex ) return real; function imag_part ( C : complex ) return real; function “&” ( real_part, imag_part : real ) return complex; function “+” ( L, R : complex ) return complex; ... -- other operations private type complex is record re, im : real; end record complex; end package complex_numbers; 5 editing. It may be that the language uses the same approach as SUAVE, namely, first comparing the tags, and if they are equal, then comparing the corresponding elements defined for the specific class type. However, this is not stated. The same concerns about the definition of equality arise in determination of events on signals of class and classwide types. language and with the SUAVE extensions for objectorientation. The topic of abstract communication, however, is out of scope for the OOVHDL Study Group, so the issue are not addressed further in this critique. Instead, we simply point out concerns with the basic mechanisms added in Objective VHDL. In VHDL, the declarations in the declarative part of an entity are not visible outside the entity and corresponding architecture bodies. Objective VHDL, on the other hand, makes subprogram bodies visible in class body entity configurations that name the entity. Presumably this extended visibility could be defined in terms of visibility by selection. The intention is that subprograms declared in the entity declarative part be treated as methods of the entity. Such subprograms thus form part of the interface to the entity, along with its generic and port lists. That the interface can be dispersed over an entire declarative part, interspersed with other non-interface declarations, potentially makes the entity’s interface obscure. It would have been better to collect the interface subprograms together with the generic and port lists. The rules described in Section 4.3.8 of the Objective VHDL Language Definition imply that the declarative region structure described in Section 4.4.1 is a simplification. The three declarative regions for constant, variable and signal configurations appear, in the presence of class body entity configurations, to have subregions for each entity named in class body entity configurations. The relationship between a name declared in the main part of a region and a homograph in a subregion is not clear. Is the subregion nested within the main region, or is it viewed as a branch of some form? If the subregion is nested, then the subprogram names declared within it must be exported in to the enclosing region in some way to be visible when prefixed by an object name when called. Alternatively, does the presence of class body entity configurations imply replication of the triple of declarative regions, once per entity named in the set of class body entity configurations. A further issue relating to class body entity configurations is the time of binding a subprogram body to a call. If the binding were to be made statically, then a calling entity must depend on the design unit containing the class body definition. That design unit must depend on the entity declaration, since the entities declarations are made visible. Thus a circular dependency would be created. VHDL does not allow circular dependencies, so the binding cannot be made statically. Instead, the binding can only be performed at elaboration time or dynamically. This is a departure from VHDL semantics, and a significant complication for analysers and elaborators. The rationale stated in Section 4.5.1 of the Language Definition for not predefining equality and inequality for class types and class wide types is that to do so “would break their encapsulation” (or more correctly, their information hiding). We presume this means that to do so would expose whether elementwise or deep comparison of dynamically allocated structures is used, or whether the implementation of a type admitted multiple representations of logically indistinguishable values. If this understanding of the rationale is correct, then it fails in both cases. In the first case, the information hiding can be broken by an attempt to declare a signal of the type. If the declaration is allowed, the type contains no access type elements and so elementwise comparison would be appropriate. If the declaration is disallowed, the type contains at least one access type element and so deep comparison is required (overriding elementwise comparison) or reference semantics for the type is used (with elementwise comparison being appropriate). Thus in the first case, there is no point in avoiding predefined equality. In the second case, multiple representations of logically indistinguishable values would be exposed by event detection on a signal. If a signal changed from one representation to another representation of the same logical value, an event would occur, thus breaking the information hiding of the representation. So in this case also, there is no point in avoiding predefined equality. 2.4 Class Body Entity Configurations The introduction of class body entity configurations in Objective VHDL complicates the scope and visibility rules further than the complications discussed in Section 2.2.1 of this critique, and does so in a way that is totally at odds with the existing language design. Class body entity configurations, together with changes to visibility rules for subprograms in an entity declarative part, were added to support implementation of remote-procedure-call interfaces to entity instances. The way that this is done is very clumsy. It would have been better to support remote procedure call as a first-class language construct, rather than to synthesise it in an ad hoc fashion. Elsewhere [1, 2], we have argued that message passing is a more appropriate form of abstract communication than remote procedure call, and have described the SUAVE language extensions to provide message-passing communication. The SUAVE features are much more general and integrate cleanly with the existing 3. Design Entity Inheritance Objective VHDL allows a design entity to inherit the interface and implementation from a parent design entity. A de- 6 rived design entity inherits generics, ports, declarations and concurrent statements, and possibly adds further generics, ports, declarations and concurrent statements. In the case of a derived design unit declaring a homograph of an inherited declaration, the inherited declaration is hidden. In the case of a derived design unit including a concurrent statement with the same label an inherited concurrent statement, the inherited statement is replaced. ple, the Q port of the DREG entity had to be declared as a buffer port to support the subsequent inheritance. Normally the port would be declared as an out port, preventing the simple form of inheritance shown.) This form of composition would be better expressed using the existing language features for component instantiation. In the example, the DREGN design entity is simply a composition of a DREG instance and an inversion statement. The only effective reuse achieved in the example is the reuse of the port list from the DREG entity. The intention of design unit inheritance is to support reuse. A derived design entity reuses the interface, declarations and concurrent statements of the parent. While this is a laudable goal, the amount of reuse that can be achieved in practice is limited, especially when compared to the reuse achieved through inheritance in data classes. In a data class, methods are somewhat independent of one another. A derived class can add functionality by adding methods, and the addition of new methods does not affect the functionality of inherited methods. A derived class can also modify functionality by overriding inherited methods, but care must be taken that the overriding method integrates with the functionality of the remaining inherited methods. These considerations make it necessary to question the need for design entity inheritance. The existing language mechanisms of component composition and configuration serve well in many of the cases where design entity inheritance might be used. It is questionable whether the small degree of reuse achieved in the remaining cases warrants the complexity added to the language. A collection of examples and cases studies, showing how design entity inheritance can afford significant reuse and make modelling more tractable, would be persuasive. 4. Genericity In the case of design entities, concurrent statements are not independent of one another; they are interconnected by the signals and ports that they sense and drive. Except in trivial cases, addition of functionality through addition of concurrent statements would normally require the new concurrent statements to be “spliced in” to the signal/port interconnection structure. This would require deleting inherited port mappings and adding new ones. Objective VHDL does not support this form of modification to the inherited interconnection structure. Object-oriented programming languages include typegenericity (parameterisation of classes with formal types) as a significant means of achieving reuse. Examples of language features for type genericity include generics in Ada and templates in C++. The designers of Java recognise the importance of type genericity and intend to add genericity features in a future revision of Java. Given that much of the use of VHDL is in the nature of programming (for example, complex test benches and behavioural models), and that supporting reuse was a major goal of Objective VHDL, it is surprising that type-genericity was not included. To add it now would be a significant language design exercise. Augmentation of functionality can be achieved, however, if the parent model has been designed to support it. The parent must be only partially interconnected, or have “dummy” statements that are intended to be overridden. Such a design entity would normally be non-instantiable, and be designed as part of an inheritance hierarchy in a single design exercise. Contrast this with reuse of a design entity designed separately, for example, as part of an earlier project. Such reuse is not well supported by the mechanisms in Objective VHDL. Inherited statements in such cases must be overridden by statements that largely replicate the inherited statements, but with minor differences in interconnection or functionality. The register examples in Section 3 of the Objective VHDL Language Definition illustrate this. The corresponding language design has already been done in SUAVE. SUAVE extends the existing feature of generic lists on components and entities by allowing them to include formal generic types. Actual types are specified when the components or entities are instantiated. Thus a given component or entity can be reused for several different actual types. SUAVE further extends the genericity features by allowing generic lists to be specified in package, subprogram and process declarations. This allows definition of reusable ADTs, classes and active objects. The extended genericity features integrate cleanly with the features for object-orientation and abstract communication, and interact with them to provide powerful modelling capabilities. The trivial cases in which augmentation of function can be readily achieved are those in which new ports are added, and the new declarations and concurrent statements are interconnected only with them and the inherited ports. An example is the inheritance from the DREG design entity to form the DREGN design entity in Section 3 of the Objective VHDL Language Definition. (Note that in this exam- Note that Objective VHDL does allow a simple form of genericity in class definitions, namely, parameterisation by generic constants. This language feature is more akin to discriminated types in Ada than to the existing genericity features in VHDL. 7 5. Conclusion In this critique, we have identified a number of aspects of the Objective VHDL language design that unnecessarily complicate the language definition and make the language difficult to use. These problems largely stem from a lack of careful integration of new features with the semantic mechanisms of the existing language. The most significant issue is the choice of a class type encapsulating the storage of an ADT. From this choice, several negative consequences flow. The designers of Objective VHDL have based this choice on requirements from potential users, who expressed a preference for the class-type approach over the Ada-95-based approach. We believe that this illustrates the importance of collecting usage requirements from users, as opposed to requirements for specific language features. The task of detailed language design is complex and requires consideration of deep semantic issues. Users are not always in a position to appreciate the ramifications of language design decisions and the interactions between semantic mechanisms. Language designers who are “inculturated” with the language definition are in the best position to maintain the conceptual integrity of the language when designing extensions. [2] P. J. Ashenden, P. A. Wilsey, and D. E. Martin, “SUAVE: Extending VHDL to Improve Data Modeling Support,” IEEE Design and Test of Computers, vol. 15, no. 2, pp. 34–44, 1998. [3] P. J. Ashenden, P. A. Wilsey, and D. E. Martin, SUAVE Language Description, Dept Computer Science, University of Adelaide, Adelaide, Australia, Technical Report 99/04 (http://www.cs.adelaide.edu.au/users/petera/suave.html), 1999. [4] G. Booch, The Best of Booch. New York, NY: SIGS Books and Multimedia, 1996. [5] F. P. Brooks, Jr., The Mythical Man-Month, Anniversary ed. Reading, MA: Addison-Wesley, 1995. [6] C. A. R. Hoare, “Hints on Programming Language Design,” in Essays in Computing Science, C. A. R. Hoare and C. B. Jones, Eds. Herts, UK: Prentice Hall, 1989, pp. 193–216. [7] ISO/IEC, Ada 95 Reference Manual. International Standard ISO/IEC 8652:1995 (E), Berlin, Germany: Springer-Verlag, 1995. [8] M. Radetzki, W. Putzke-Röming, and W. Nebel, Objective VHDL Language Definition, OFFIS Research Institute, Oldenburg, Germany, REQUEST Deliverable 2.1A (http://eis.informatik.uni-oldenburg.de/research/objective_vhdl.shtml), 1998. [9] R. D. Tennent, “Language Design Methods Based on Semantic Principles,” Acta Informatica, vol. 8, , pp. 97–112, 1977. [10] P. Wegner, “Dimensions of Object-Based Language Design,” ACM SIGPLAN Notices, vol. 22, no. 12, Proceedings of OOPSLA ’87, pp. 168–182, 1987. [11] N. Wirth, “From Programming Language Design to Computer Construction,” Communications of the ACM, vol. 28, no. 2, pp. 160–164, 1985. References [1] P. J. Ashenden and P. A. Wilsey, “Extensions to VHDL for Abstraction of Concurrency and Communication,” Proceedings of Sixth International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS ’98), Montreal, Canada, pp. 301–308, 1998. 8