Subject: OOVHDL Analyses and Recommendation
From: Paul J. Menchini (mench@mench.com)
Date: Sat Feb 26 2000 - 13:00:02 PST
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 : Sat Feb 26 2000 - 13:03:31 PST