Subject: Call for votes
From: Peter Ashenden (petera@cs.adelaide.edu.au)
Date: Mon Mar 13 2000 - 11:50:14 PST
Dear colleagues,
It's now time to vote on whether to accept the recommendation of the
OOVHDL review panel. For your information, the message containing the
review findings are attached. See also the OOVHDL web page
for pointers to the review documents and a hypermail archive of
discussion on the oovhdl list.
The question to vote on is:
Which proposal should be adopted as the basis for object-oriented
extensions to VHDL?
____ SUAVE
____ Objective VHDL
____ SUAVE with entity/architecture inheritance
adopted from Objective VHDL
Note that you need to be a DASC or Standards Association member as of
now for your vote to count.
Please reply either to Peter Ashenden (mailto:petera@cs.adelaide.edu.au)
or to Wolfgang Nebel (mailto:nebel@informatik.uni-oldenburg.de) by
Sunday 26 March, 12noon US-PST. We will jointly collate votes and
announce the outcome at the OOVHDL meeting at DATE in Paris on Monday 27
March.
Cheers,
PA
-- Dr. Peter J. Ashenden Email: petera@cs.adelaide.edu.au Dept. Computer Science peter.ashenden@acm.org University of Adelaide peter.ashenden@computer.org Adelaide, SA 5005 Phone: +61 8 8303 4477 Australia Fax: +61 8 8303 4366WWW: http://www.cs.adelaide.edu.au/~petera (includes PGP public key)
attached mail follows:
Ladies and Gentlemen of the OOVHDL Study Group,
At long last is the analysis of the two OOVHDL proposals, Objective VHDL and SUAVE.
Presented herein are analyzes of the two proposals, responses from the proposal authors to my specific comments, and a recommendation as to which proposal to select.
Please note that the author responses are not intended to be rebuttals. Prior to prenting the analyses to the full group, I presented each draft analysis to the respective proposal authors to ensure that they felt the analysis was fair and complete.
I take full responsibility for what follows, except for the reponses from the proposal authors, which is their work. I'd also like to acknowlege the contributions of Wolfgang Ecker and Jacques Rouillard to the analyses, although the conclusions are mine.
See you at the OOVHDL meeting!
Paul Menchini
*****************************************************************************
Review of the Objective VHDL Proposal for the OOVHDL Study Group
I have been asked by the IEEE OOVHDL Study Group to review two competing proposals for the strawman for further OOVHDL work. In this document, I answer the five questions posed by the SG for the Objective VHDL proposal. There is a similar document covering the SUAVE proposal.
Q0: To what extent does the proposal address the user requirements identified in Document 0? ------------------------------------------------------------------
I believe that Objective VHDL generally covers the referenced requirements well. However, I do have a number of concerns about specific requirements, namely:
1. Compatibility with VHDL and legacy models. (In particular, VHDL compatibility).
11. Abstraction (of data, concurrency, communications, timing). (In particular, timing.)
12. Relaxed timing and typing in controlled manner. (In particular, timing.)
22. Exceptions (There is no exception mechanism specified.)
23. Dynamic process creation and distruction. (No mechanism specified.)
26. Simplicity.
27. Efficiency.
29. Well defined.
32. Translatable. (I don't think Objective VHDL is particularly translatable to any other HDL or HLL. But, this is extremely low on my list of concerns, so I consider this lack to be of little import.)
35. Ease of compilation/synthesis/optimization. (In particular, I have some concerns about the runtime support required.)
36. Implementability. (See #1 and #35.)
Q1: Is the proposal a strict superset of VHDL? ---------------------------------------------- The documentation is not quite sufficient to unambiguously answer this question (see the response to Q2 for details), but insofar as I can tell, yes, it is.
Q2: Is the proposal semantically consistent with VHDL? ------------------------------------------------------ I have a number of concerns here. First and foremost, it appears that Objective VHDL may assume visibility rules that are different from those of VHDL.
In particular, subprograms in an entity declarative part are apparently defined to be methods of the design entity [Final Objective bVHDL language definition, 9 July 1998, section 3.2.2]. This feature appears to require that the scope and visibility of these subprograms be extended to outside of the design entity and corresponding configurations. The same concern exists for certain objects, defined in the same section to be attributes of the object.
Moreover, the visibility rules for ancestor entity interfaces from within derived entity interfaces [section 3.2] are not described.
In sections 3.2.2 and 3.4.1, the inheritance of implicit declarations is discussed. Implicit declarations are also defined. Unfortunately, VHDL already has the notion of implicit declarations, leading to confusion.
Perhaps it's just a consequence of the informal defintion, but the language in sections 3.2.2 and 3.4.1 describing under what conditions implicit declarations are hidden does not refer to the concept of homographs, but instead to overloading. Such defintions are, at minimum, therefore incomplete, and may also be inconsistent with current VHDL.
Section 4.8.2 defines the result type of T'CLASS as a type defintion, which is not a type. (This issue may be merely one of specification.)
Q3: Is the proposal consistent with VHDL syntax? ------------------------------------------------ I believe it is.
Q4: Is the proposal completely defined? --------------------------------------- I believe that the proposal is incompletely defined.
For example, there is no definition or illustration of how the methods and attributes of an entity interface are accessed.
Additionally, the inheritance of specifications in sections 3.2.2 and 3.4.1 (and perhaps other sections) is not discussed. The same can be said of the current notion of implicit declarations--those subprograms that are implicitly defined as a result of type declarations.
Section 3.5.2 discusses the implicit declaration of THIS. The details are quite incomplete, however. What is the nature of THIS? For example, what kind of declaration is it? Exactly where is it declared? Presumably within the declarative part of the enclosing construct, but where within the declarative part? (Consideration must be given to it's relationship to the declaration of labels.) Moreover, the text refers to "a subprogram call prefix with THIS is inherited," but nowhere is it discussed how a subprogram call is inherited. Earlier text seemed to refer only to the inheritance of declarations and statements.
In the same section, the phrase "must not" is used when referring to restrictions on use clauses. The meaning of this phrase is at issue. Does it mean "it is an error if" the condition occurs?
The semantics and uses of class body entity configurations [section 4.3.8] is not understood by me.
Section 4.4.2 is quite incomplete. Scope extensions will be needed in order to provide extended visibility [section 4.4.3].
Section 4.5.1 discusses the lack of equality and inequality operators for composite types having elements of a class type or class-wide type. The implication is that class types or class-wide types themselves do not have the equality and inequality operators defined on them, but nowhere is this stated. Moreover, the remaining relational operators (<, <=, > and >=) are not discussed.
Section 4.5.2 states that allocators can be used to construct the values of a class type or class-wide type. In particular, in the case of an allocator whose type mark is a class-wide type, it is stated that a qualified expression must be used to determine the value, but I am unable to determine the form and contents of this qualified expression.
Section 4.6.2 discusses the semantics of assignment. In particular, in the second paragraph in the subsection on signal assignment, the meaning is unclear. Does this paragraph discuss driver updating, network evaluation, both, or something else entirely?
Section 4.8.1 defines universal_TAG as being of an enumeration type, but does not define the values of this type. Indeed, I suspect that it is not possible to enumerate the values, which may be a problem.
Other Comments -------------- At first blush, I like the idea of deriving entity interfaces and architectures from other entity interfaces and architectures. However, it appears that the mechanisms specified are quite complex. Careful thought will have to be given as to whether this added capability is worth the added complexity.
*****************************************************************************
Review of the SUAVE Proposal for the OOVHDL Study Group
I have been asked by the IEEE OOVHDL Study Group to review two competing proposals for the strawman for further OOVHDL work. In this document, I answer the five questions posed by the SG for the SUAVE proposal. There is a similar document covering the Objective VHDL proposal.
I also added a section, "Other Comments," that addresses other issues I noted while reviewing SUAVE.
Q0: To what extent does the proposal address the user requirements identified in Document 0? ------------------------------------------------------------------ I believe that SUAVE generally covers the referenced requirements well. However, I do have a number of concerns about specific requirements, namely:
1. Compatibility with VHDL and legacy models. (In particular, VHDL compatibility).
22. Exceptions. (There is no exception mechanism specified.)
29. Well defined.
30. Extensions are unique and consistent. (In particular, uniqueness.)
32. Translatable. (I don't think SUAVE is particularly translatable to any other HDL or HLL. But, this is extremely low on my list of concerns, so I consider this lack to be of little import.)
35. Ease of compilation/synthesis/optimization. (In particular, I have some concerns about the runtime support required.)
36. Implementability. (See #1 and #35.)
Most of the specifics are covered in the answers to other questions.
Q1: Is the proposal a strict superset of VHDL? ---------------------------------------------- The documentation is not quite sufficient to unambiguously answer this question (see the response to Q2 for details), but insofar as I can tell, yes, it is.
Q2: Is the proposal semantically consistent with VHDL? ------------------------------------------------------ I have a number of concerns here. First and foremost, it appears that SUAVE may assume visibility rules that are different from those of VHDL.
When a new type is derived from an existing type, the SUAVE documentation states that "[t]he derived type inherits the set of values and the primitive operations of the parent type." [SUAVE Language Description, 7 July 1999, Section 3.2]
If this statement is taken literally, then the values and primitive operations need not be visible, either directly or by selection, for this inheritance to take place. Such a rule would be quite at odds with the current rules of VHDL.
Of course, this statement might just be an approximate specification of the intended behavior, which is that the values and primitive operations must be visible in some fashion for the described inheritance to occur. In that case, I think it would be most consistent with VHDL that said values and primitive operations be directly visible. (Under most, if not all circumstances, if the parent type is visible at all, either direcly or by selection, then the values and primitive operations are also visible, at least by selection.)
A limited type is defined as having no predefined equality operator. The definition, is silent, however, on the remaining relational operators, such as inequality, less than, etc. A strict reading would thus imply that, at minimum, the inequality operator is defined on limited types (since equality and inequality are now defined on all types except for file types). Again, I think it makes more sense if inequality is similarly undefined on private types.
Several places were private types are discussed, there is a prohibition against the use of access types, but no similar prohibition regarding file types. I believe it would be more consistent with VHDL to similarly prohibit file types in these circumstances.
There are also a number of problematic areas dealing with process declarations [Section 7.1ff]. For example, it seems that a sequential process satement could be executed from within a function call. Such a situation would have very interesting semantics, but unfortunately, proably more harmful than beneficial. Accordingly, I recommend that the sequential process statement not be allowed within a function call (either directly or indirectly).
Additionally, Section 7.2 defines an equivalent block model for a process instantiation statement. This equivalent block model is not formally defined, but is illustrated by example. (This definition via illustration is properly viewed as an incomplete definition and thus merits inclusion under the answer to Q4, but the illustration appears to define some novel semantics, hence the inclusion under this section.)
The equivalent block model illustration turns a simple name ("x" in the source process declaration) into a selected name ("... .x" in the process statement within the equivalent block model). This transformation is nowhere else specified in the current VHDL LRM, making me question its adherence to current VHDL semantics. Moreover, the nature of the transformation is unspecified, as are the conditions under which it is performed.
In Section 7.3.1, the proposal describes the semantics of associating the signal ports of an instantiated process during the elaboration of the port map of a sequential process instantiation statement. In particular, the proposal states (as the last sentence of the first paragraph of this section) "For a signal port of mode IN associated with a signal, the port becomes part of the same net as the signal, and the effective value of the port is determined by the signal update algorithm."
This statement is both (slightly) underspecified and has problematic semantics. The underspecification comes from the fact that the phrase "part of the same net" is ambiguous. I believe that the authors meant instead "a sink of the specified actual signal."
However, the phrase "the effective value of the port is determined by the signal update algorithm" is more of an issue. This phrase seems to imply that the signal update algorithm be used at the time of the dynamic association to determine the value of the port. Unfortunately, the association comes too late in a given simulation cycle for this implication to be valid. Sequential statements (except for those in resolution functions) are executed only in either of the last two steps of the simulation cycle, after all the networks active in the current simulation cycle have been updated. To re-invoke the network update algorithm at this point could result in problems.
A similar problem may exist for ports of mode OUT and BUFFER, in that a driver appears on a net during a time when the network evaluation algorithm cannot be run. As long as the implication is not that the network is immediately evaluated upon such an event, then I forsee no problem.
The solution might be as simple as stating that, initially, dynamically associated ports of mode IN take their effective value from the associated actual signal, possibly after applying the appropriate conversion or conversion function. In subsequent simulation cycles, the normal network evaluation algorithm applies. Similiarly, for ports of mode OUT and BUFFER, the dynamic association implies nothing in the current simulation cycle. Thereafter, the normal network evaluation algorithm applies.
(Also see the comment under Q4 about guarded signals and these dynamically associated signals.)
Q3: Is the proposal consistent with VHDL syntax? ------------------------------------------------ I believe it is, with perhaps one exception. I suggest that the terminate statement [Section 7.4] instead be an extension of the exit statement. Such a change has several advantages. We remove the introduction of one additional keyword, we allow conditional termination of processes, and we unify the notions of loop exiting and process termination. Such a unification may even be extended to allow process resetting, something that has been long desired.
Q4: Is the proposal completely defined? --------------------------------------- No, it is not. For example, the inclusion of formal processes in generic clauses [Sections 5, 5.3 and 5.3.12] (and maps) is explicitly unspecified.
Section 6.3.2 states, "A channel [is] dynamically allocated using an allocator with a subtype indication denoting a channel type." Unfortunately, there are two forms of allocators:
NEW subtype_indication NEW qualified_expression
Presumably, the first form of allocator is meant. Moreover, I assume that it should be an error to attempt to use the second form in this context.
A more significant set of omissions relates to process declarations. In particular, can they be postponed, and can they be instantiated from an ancestor that is a postponed process?
Moreover, see the comments under Q2 regarding the equivalent block model for the process instantiation statement.
Additionally, it is stated that, when a process terminates [Section 7.4], its drivers are disconnected from the signals that they drive, and that said signals must be guarded signals. However, no requirement is made that, upon instantiation, the newly created drivers begin driving only guarded signals. Presumably, this second requirement, in fact, exists, and is merely omitted.
Technically, the semantics of a dynamically associated signal port of mode LINKAGE is undefined, but I see little problem with this lack.
Other Comments --------------
The extensions to packages for encapsulation seem to have little in common with the current notion of packages. I suggest that the extensions instead create a new declaration, the "class." I realize that this suggestion creates yet another reserved word, but I think it appropriate that the distinction between current packages and this new notion be maintained (and I've already suggested giving back the new keyword TERMINATE).
The use of the predefined attribute 'Length on channels is defined to supply the size of the buffer for a constrained bounded channel type (or object thereof) [Section 6.1.1]. There appears to be no way to determine how many of these buffer elements are occupied at a given point in time. It might be better to define a new attribute, 'Capacity, to provide the buffer size, and extend 'Length to describe the number of buffer elements in use.
*****************************************************************************
Objective VHDL Author Response
>Q0: To what extent does the proposal address the user requirements >identified in Document 0? >------------------------------------------------------------------ > >I believe that Objective VHDL generally covers the referenced >requirements well. However, I do have a number of concerns about >specific requirements, namely: > > 1. Compatibility with VHDL and legacy models. (In particular, > VHDL compatibility).
What is your definition of compatibility? Acceptance of VHDL93 legacy code in Objective VHDL tools and/or compatibility with VHDL semantic paradigms?
> > 11. Abstraction (of data, concurrency, communications, timing). > (In particular, timing.) > > 12. Relaxed timing and typing in controlled manner. (In > particular, timing.)
The class-wide type / polymorphism feature is a means to relaxed typing.
> > 22. Exceptions (There is no exception mechanism specified.) > > 23. Dynamic process creation and distruction. (No mechanism > specified.) > > 26. Simplicity. > > 27. Efficiency. > > 29. Well defined. > > 32. Translatable. (I don't think Objective VHDL is particularly > translatable to any other HDL or HLL. But, this is extremely > low on my list of concerns, so I consider this lack to be of > little import.)
>From our point of view Objective VHDL is translatable in general to VHDL. >From the legal point of view, we intend to put the language in the public domain, so that there are no legal reasons for not being able to translate Objective VHDL to any other language.
> > 35. Ease of compilation/synthesis/optimization. (In particular, I > have some concerns about the runtime support required.)
What are the reasons for your concern? From our work on prototype tools (analyser, VHDL translator) and synthesis concepts we believe it's feasible. We have been able to map Objective VHDL runtime aspects to the VHDL runtime system (e.g., detection of runtime errors in assignments to class-wide objects).
> > 36. Implementability. (See #1 and #35.) > > >Q1: Is the proposal a strict superset of VHDL? >---------------------------------------------- >The documentation is not quite sufficient to unambiguously answer this >question (see the response to Q2 for details), but insofar as I can >tell, yes, it is. > >Q2: Is the proposal semantically consistent with VHDL? >------------------------------------------------------ >I have a number of concerns here. First and foremost, it appears that >Objective VHDL may assume visibility rules that are different from >those of VHDL. > >In particular, subprograms in an entity declarative part are >apparently defined to be methods of the design entity [Final Objective >bVHDL language definition, 9 July 1998, section 3.2.2]. This feature >appears to require that the scope and visibility of these subprograms >be extended to outside of the design entity and corresponding >configurations. The same concern exists for certain objects, defined >in the same section to be attributes of the object.
In the current version of Objective VHDL, which we are discussing, the ... for entity ... construct is used to achieve visibility of methods of entities from within in the body of class types. However, we are in discussion that this should be replaced by a more consistent concept of visibility creation.
> >Moreover, the visibility rules for ancestor entity interfaces from >within derived entity interfaces [section 3.2] are not described.
It is intended to permit the use of generics of a parent entity in port declarations of a derived entity. We expected to cover this, in combination with VHDL rules about the visibility of generics, by defining the "effective generic list" and "effective port list".
> >In sections 3.2.2 and 3.4.1, the inheritance of implicit declarations >is discussed. Implicit declarations are also defined. Unfortunately, >VHDL already has the notion of implicit declarations, leading to >confusion.
You are right, a better integration into the VHDL terminology is advisible.
> >Perhaps it's just a consequence of the informal defintion, but the >language in sections 3.2.2 and 3.4.1 describing under what conditions >implicit declarations are hidden does not refer to the concept of >homographs, but instead to overloading. Such defintions are, at >minimum, therefore incomplete, and may also be inconsistent with >current VHDL. > >Section 4.8.2 defines the result type of T'CLASS as a type defintion, >which is not a type. (This issue may be merely one of specification.) > >Q3: Is the proposal consistent with VHDL syntax? >------------------------------------------------ >I believe it is. > >Q4: Is the proposal completely defined? >--------------------------------------- >I believe that the proposal is incompletely defined. > >For example, there is no definition or illustration of how the methods >and attributes of an entity interface are accessed. > >Additionally, the inheritance of specifications in sections 3.2.2 and >3.4.1 (and perhaps other sections) is not discussed. The same can be >said of the current notion of implicit declarations--those subprograms >that are implicitly defined as a result of type declarations.
Maybe there is some confusion with the implicit declaration. We think that inheritance is discussed; however, again using the term implicit declaration.
> >Section 3.5.2 discusses the implicit declaration of THIS. The details >are quite incomplete, however. What is the nature of THIS? For >example, what kind of declaration is it? Exactly where is it >declared? Presumably within the declarative part of the enclosing >construct, but where within the declarative part? (Consideration must >be given to it's relationship to the declaration of labels.) >Moreover, the text refers to "a subprogram call prefix with THIS is >inherited," but nowhere is it discussed how a subprogram call is >inherited. Earlier text seemed to refer only to the inheritance of >declarations and statements.
This should be better described in the LRM.
> >In the same section, the phrase "must not" is used when referring to >restrictions on use clauses. The meaning of this phrase is at issue. >Does it mean "it is an error if" the condition occurs? > >The semantics and uses of class body entity configurations [section >4.3.8] is not understood by me.
This related to the ..for entity ... construct (s.above).
> >Section 4.4.2 is quite incomplete. Scope extensions will be needed in >order to provide extended visibility [section 4.4.3].
Could you please give an example of what is missing.
> >Section 4.5.1 discusses the lack of equality and inequality operators >for composite types having elements of a class type or class-wide >type. The implication is that class types or class-wide types >themselves do not have the equality and inequality operators defined >on them, but nowhere is this stated. Moreover, the remaining >relational operators (<, <=, > and >=) are not discussed. > >Section 4.5.2 states that allocators can be used to construct the >values of a class type or class-wide type. In particular, in the case >of an allocator whose type mark is a class-wide type, it is stated >that a qualified expression must be used to determine the value, but I >am unable to determine the form and contents of this qualified >expression.
This qualified expression would *not* be of a class-wide type. It would be of a class type which is assignment-compatible with the class-wide type. The syntax is the same as a VHDL qualified expression, hence we did not replicate it.
> >Section 4.6.2 discusses the semantics of assignment. In particular, >in the second paragraph in the subsection on signal assignment, the >meaning is unclear. Does this paragraph discuss driver updating, >network evaluation, both, or something else entirely?
We assume the same semantics as in VHDL unless specified explicitly. In this section we discuss type compatibility issues.
> >Section 4.8.1 defines universal_TAG as being of an enumeration type, >but does not define the values of this type. Indeed, I suspect that >it is not possible to enumerate the values, which may be a problem.
The values of the universal_TAG type are created during elaboration.
> >Other Comments >-------------- >At first blush, I like the idea of deriving entity interfaces and >architectures from other entity interfaces and architectures. >However, it appears that the mechanisms specified are quite complex. >Careful thought will have to be given as to whether this added >capability is worth the added complexity.
*****************************************************************************
SUAVE Author Response
> Q0: To what extent does the proposal address the user requirements > identified in Document 0? > ------------------------------------------------------------------ > I believe that SUAVE generally covers the referenced requirements > well. However, I do have a number of concerns about specific > requirements, namely: > > 1. Compatibility with VHDL and legacy models. (In particular, > VHDL compatibility).
There are some new reserved words that could cause problems with existing VHDL models. This is always a consideration when extending the language. However, it is inlikely that existing models use the new reserved words as identifiers, since they would not make "grammatic sense". Other extensions in SUAVE either preserve existing semantics, or remove restrictions.
> 22. Exceptions. (There is no exception mechanism specified.)
Agreed.
> 29. Well defined.
The OO and genericity extensions are based on Ada-95, which is well defined. The definitions are adapted to integrate with VHDL semantics. Detailed LRM crafting remains to be done.
> 30. Extensions are unique and consistent. (In particular, > uniqueness.)
Would you care to be specific about which extensions involve replication?
> 32. Translatable. (I don't think SUAVE is particularly > translatable to any other HDL or HLL. But, this is extremely > low on my list of concerns, so I consider this lack to be of > little import.)
Agreed.
> 35. Ease of compilation/synthesis/optimization. (In particular, I > have some concerns about the runtime support required.)
Most of the extended semantics are static. The OO extensions adopt aspects of language design from Ada-95. One primary concern in the design of Ada-95 was to make as much as possible statically determinable, allowing static binding and minimizing dynamic binding to those cases where it is really needed. In those latter cases, runtime support can be readily generated and does not have a high performance penalty.
The genericity extensions allow elaboration-time instantiation. Again, much of the semantics are borrowed from Ada, which is designed to allow instantiation of generics during program build.
Agreed there is significant runtime overhead for channel-based communication and dynamic process instantiation. However, this is similar in scope and magnitude to the support required for signal-based communication and process scheduling.
> 36. Implementability. (See #1 and #35.) > > Most of the specifics are covered in the answers to other questions. > > Q1: Is the proposal a strict superset of VHDL? > ---------------------------------------------- > The documentation is not quite sufficient to unambiguously answer this > question (see the response to Q2 for details), but insofar as I can > tell, yes, it is. > > Q2: Is the proposal semantically consistent with VHDL? > ------------------------------------------------------ > I have a number of concerns here. First and foremost, it appears that > SUAVE may assume visibility rules that are different from those of > VHDL. > > When a new type is derived from an existing type, the SUAVE > documentation states that "[t]he derived type inherits the set of > values and the primitive operations of the parent type." [SUAVE > Language Description, 7 July 1999, Section 3.2] > > If this statement is taken literally, then the values and primitive > operations need not be visible, either directly or by selection, for > this inheritance to take place. Such a rule would be quite at odds > with the current rules of VHDL. > > Of course, this statement might just be an approximate specification > of the intended behavior, which is that the values and primitive > operations must be visible in some fashion for the described > inheritance to occur. In that case, I think it would be most > consistent with VHDL that said values and primitive operations be > directly visible. (Under most, if not all circumstances, if the > parent type is visible at all, either direcly or by selection, then > the values and primitive operations are also visible, at least by > selection.)
The SUAVE rules follow of the Ada-95 rules, and distinguish between inheritance and visibility. For a derived type, inherited primitive operations are defined as being the primitive operations of the parent type, with systematic replacement of the parent type name by the derived type name. If a primitive operation of the parent is visible at the place of the derived type definition, the corresponding inherited operation is implicitly declared immediately after the derived type definition, and the usual visibility rules apply to the implicit declaration. If a primitive operation of the parent is not visible at the place of declaration of the derived type, the inherited operation is not declared, and so cannot be named or overridden. However, for a tagged type, it can be dispatched to. (In implementation terms, this simply amounts to invoking the parent operation.)
> A limited type is defined as having no predefined equality operator. > The definition, is silent, however, on the remaining relational > operators, such as inequality, less than, etc. A strict reading would > thus imply that, at minimum, the inequality operator is defined on > limited types (since equality and inequality are now defined on all > types except for file types). Again, I think it makes more sense if > inequality is similarly undefined on private types.
Agreed. This is an error of incomplete adaption from Ada, in which "/=" is defined to be not "=" if "=" is defined, and underfined otherwise. The language description is silent on the remaining relational operators, since only record and private types can be limited, and the relational operators are not predefined for them.
> Several places were private types are discussed, there is a > prohibition against the use of access types, but no similar > prohibition regarding file types. I believe it would be more > consistent with VHDL to similarly prohibit file types in these > circumstances.
A private type may or may not include access values in its full view. The presence or absence of the word access in the private type declaration governs this. Separately, the language description specifies that a private type may not in its full view be a file type, and that the element type of a file type may not be or include a private type.
Are the places that you are referring to the descriptions of interface private types? If so, I agree that the language description should specify that the actual type must not be or include a file type. Please let me know fi there are other places.
> There are also a number of problematic areas dealing with process > declarations [Section 7.1ff]. For example, it seems that a sequential > process satement could be executed from within a function call. Such > a situation would have very interesting semantics, but unfortunately, > proably more harmful than beneficial. Accordingly, I recommend that > the sequential process statement not be allowed within a function call > (either directly or indirectly).
Agreed. This is analogous to disallowing execution of a wait statement directly ro indirectly in a function call.
> Additionally, Section 7.2 defines an equivalent block model for a > process instantiation statement. This equivalent block model is not > formally defined, but is illustrated by example. (This definition via > illustration is properly viewed as an incomplete definition and thus > merits inclusion under the answer to Q4, but the illustration appears > to define some novel semantics, hence the inclusion under this > section.) > > The equivalent block model illustration turns a simple name ("x" in > the source process declaration) into a selected name ("... .x" in the > process statement within the equivalent block model). This > transformation is nowhere else specified in the current VHDL LRM, > making me question its adherence to current VHDL semantics. Moreover, > the nature of the transformation is unspecified, as are the conditions > under which it is performed.
The intention here is the same as that expressed in the equivalent block model for component instantiation in VHDL. The VHDL LRM clause 9.6.1 specifies that "The meaning of any identifier appearing anywhere in this block statement is that associated with the corresponding occurrence of the identifier in the entity declaration or architecture body, respectively." The illustrative example in 7.2 of the SUAVE Language Description uses name prefixing to accomplish this, whereas in the VHDL LRM, no semantic mechanism is given explicitly.
If the transformation shown is incorrect or is a red herring, please let me know.
> In Section 7.3.1, the proposal describes the semantics of associating > the signal ports of an instantiated process during the elaboration of > the port map of a sequential process instantiation statement. In > particular, the proposal states (as the last sentence of the first > paragraph of this section) "For a signal port of mode IN associated > with a signal, the port becomes part of the same net as the signal, > and the effective value of the port is determined by the signal update > algorithm." > > This statement is both (slightly) underspecified and has problematic > semantics. The underspecification comes from the fact that the phrase > "part of the same net" is ambiguous. I believe that the authors meant > instead "a sink of the specified actual signal."
Agreed.
> However, the phrase "the effective value of the port is determined by > the signal update algorithm" is more of an issue. This phrase seems > to imply that the signal update algorithm be used at the time of the > dynamic association to determine the value of the port. > Unfortunately, the association comes too late in a given simulation > cycle for this implication to be valid. Sequential statements (except > for those in resolution functions) are executed only in either of the > last two steps of the simulation cycle, after all the networks active > in the current simulation cycle have been updated. To re-invoke the > network update algorithm at this point could result in problems.
That was not the intention. The description is incorrect. The intention is that the current effective value of the actual part of the association element be used as the initial effective value of the port. The network update algorithm is not invoked as part of the dynamic process instantiation. In subsequent simulation cycles, the network update algorithm will apply to determine the effective value of the port.
> A similar problem may exist for ports of mode OUT and BUFFER, in that > a driver appears on a net during a time when the network evaluation > algorithm cannot be run. As long as the implication is not that the > network is immediately evaluated upon such an event, then I forsee no > problem.
That is the intention.
> The solution might be as simple as stating that, initially, > dynamically associated ports of mode IN take their effective value > from the associated actual signal, possibly after applying the > appropriate conversion or conversion function. In subsequent > simulation cycles, the normal network evaluation algorithm applies. > Similiarly, for ports of mode OUT and BUFFER, the dynamic association > implies nothing in the current simulation cycle. Thereafter, the > normal network evaluation algorithm applies.
Agreed.
> (Also see the comment under Q4 about guarded signals and these > dynamically associated signals.) > > Q3: Is the proposal consistent with VHDL syntax? > ------------------------------------------------ > I believe it is, with perhaps one exception. I suggest that the > terminate statement [Section 7.4] instead be an extension of the exit > statement. Such a change has several advantages. We remove the > introduction of one additional keyword, we allow conditional > termination of processes, and we unify the notions of loop exiting and > process termination. Such a unification may even be extended to allow > process resetting, something that has been long desired.
Sounds good. Resetting could be achieved by a similar extension to the "next" statement - abort the remainder of the current iternation of the process body and start again.
> Q4: Is the proposal completely defined? > --------------------------------------- > No, it is not. For example, the inclusion of formal processes in > generic clauses [Sections 5, 5.3 and 5.3.12] (and maps) is explicitly > unspecified.
Agreed. Still tbd.
> Section 6.3.2 states, "A channel [is] dynamically allocated using an > allocator with a subtype indication denoting a channel type." > Unfortunately, there are two forms of allocators: > > NEW subtype_indication > NEW qualified_expression > > Presumably, the first form of allocator is meant. Moreover, I assume > that it should be an error to attempt to use the second form in this > context.
Agreed.
> A more significant set of omissions relates to process declarations. > In particular, can they be postponed, and can they be instantiated > from an ancestor that is a postponed process?
Agreed that these are omissions. A solution would be to allow specification of postponedness in a process declaration. (To my mind, postponedness should be a property of the declaration, not the instance.) If a postponed process is dynamically instantiated, it should be activated and execute first during the simulation cycle in which it is instantiated (analogous to initialization of postponed process statements), and subsequently resume in the last delta cycle of time instants when it is re-activated due to a wait statement. If it suspends on a send/receive/select statement, at can resume in the same simulation cycle or in the last delta cycle of a subsequent time instant.
> Moreover, see the comments under Q2 regarding the equivalent block > model for the process instantiation statement. > > Additionally, it is stated that, when a process terminates [Section > 7.4], its drivers are disconnected from the signals that they drive, > and that said signals must be guarded signals. However, no > requirement is made that, upon instantiation, the newly created > drivers begin driving only guarded signals. Presumably, this second > requirement, in fact, exists, and is merely omitted.
No, the intention is as expressed in the SUAVE Language Description. Any process can terminate itself, not just dynamically created processes. So termination is like a suicidal form of disconnection. The same rules for disconnecting apply, namely, that the driven signal be guarded.
A process connected to a signal during dynamic instantion is allowed never to terminate, in which case there is no need for the actual signal to be guarded. Guardedness is only needed if there is the possibility that, through disconnections or terminations, there remain no drivers for a signal.
> Technically, the semantics of a dynamically associated signal port of > mode LINKAGE is undefined, but I see little problem with this lack.
We had planned to remove linkage ports, so did not specify semantics for them.
> Other Comments > -------------- > > The extensions to packages for encapsulation seem to have little in > common with the current notion of packages. I suggest that the > extensions instead create a new declaration, the "class." I realize > that this suggestion creates yet another reserved word, but I think it > appropriate that the distinction between current packages and this new > notion be maintained (and I've already suggested giving back the new > keyword TERMINATE).
Depends what you want to put into a "class" declaration. If you use it to encapsulate storage, you buy into the problems that we have identified in Objective VHDL. Alternatively, if you encapsulate just the abstract type definition and leave declaration of the storage (be it variable or signal) to the class instatiator, you avoid those difficulties. The penalty is a language construct that largely replicates the semantic mechanisms of packages, namely, encapsulating a set of declarations. You can try to have the best of both worlds, which is what we investigated in following Nebel's Proposal (see Section IV of "A Comparison of SUAVE and Objective VHDL"). While that proposal may have merits, it is largely unexplored. In particular, noone has considered integration of the language constructs outlined there with constructions for genericity, abstract communication, etc.
> The use of the predefined attribute 'Length on channels is defined to > supply the size of the buffer for a constrained bounded channel type > (or object thereof) [Section 6.1.1]. There appears to be no way to > determine how many of these buffer elements are occupied at a given > point in time. It might be better to define a new attribute, > 'Capacity, to provide the buffer size, and extend 'Length to describe > the number of buffer elements in use.
Looking at the number of buffer elements occupied is a way of peeking into your future and modifying your behaviour accordingly. I seem to recall from the concurrency literature that this is bad karma. I could investigate if deemed necessary. If all you want to do is choose alternate paths based on whether a communication is possible, you can use a select statement, for example
select receive ...; do_something_with_the_message; or after 0 hr => do_alternative_action_with_no_communication; end select;
If there are no messages available for reception, the select statement will time out on the next simulation cycle. I admit this does not allow you to proceed in the same simulation cycle, but I'm not sure how strong a requirement that is.
*****************************************************************************
Recommendation to the OOVHDL Study Group on How to Proceed
Both proposals have their merits. In my opinion, SUAVE seems to do a better job at adding OO features in the sequential domain, while Objective VHDL does a better job in the concurrent domain. In this, they complement each other nicely.
My ideal recommendation would be to synthesize the sequential domain OO features of SUAVE, and the concurrent domain OO extensions of Objective VHDL, although I recognize that the reason these analyses took place is that the OOVHDL group felt that no synthesis of the two proposals was possible.
I urge the group to reconsider this stance and try again. I feel that many benefits will come from providing both sets of OO features.
I recognize that this effort may, once again, fail; or, the group may decide against reattempting a synthesis. Therefore, I will make a recommendation as to which single proposal to adopt as a strawman for future work.
Before making this recommendation, I wish to stress the high quailty of both proposals, and acknowledge the tremendous effort that clearly went in to each. Both are very strong candidates, while neither is ready "out of the box." As a consequence, the choice is not crystal clear.
Nevertheless, should I choose, I am compelled to recommend SUAVE. This recommendation is based primarily on the fact that SUAVE contains more "high-level" abstraction features than does OOVHDL. It is my opinion that, if it is not possible to add OO features both in the concurrent and sequential domains, that is is more important to have the sequential features. I believe that the primary use of OO features in VHDL will be at the higher levels of design abstraction, and that SoC and SLDL considerations require these "high-level" features.
This archive was generated by hypermail 2b28 : Mon Mar 13 2000 - 11:52:32 PST