NOTE: A few LCSs, in fact, recommended that nothing be done at this time.
In effect, the LCS had no proposal to modify the language. Those LCSs were
included in the approval voting to allow further comment.
All comments will be reviewed and replied to prior to submission of the
draft LRM to the IEEE. No replies to comments are provided herein. This is
the "raw" results.
LCS Approve Disapprove Abstain
------------------------------------------------------
1 9
2 9
3 6 2 1
4 9
5 8 1
6 9
7 9
8 9
9 9
10 (No proposal)
11 9
12 8 1
13 9
14 9
15 9
16 9
17 (No proposal)
18 (No proposal)
19 9
20 7 2
21 6 3
22 7 2
23 7 2
24 8 1
25 9
26 6 2 1
Comments:
LCS 3
I agree that the LRM should add a declarative region that encompasses
BOTH the entity and the architecture. In order to allow then an
architecture with the same name as the entity the LRM should make them
non-homographs.
LCS 3
An important point is that the root declarative region encompasses the
*declarative region* of the current design unit (stated in
recommendation 1). This means that, in the case of the current design
unit being an architecture body, the root declarative region
encompasses both the entity declaration and the architecture body.
The remarks in the last paragraph are thus incorrect. The analogy
described does appear, but not as described. In the case of a
subprogram declaration in a package declaration and the subprogram
body in the package body, both are in the same declarative region,
composed of the package declaration and body. Similarly, a subprogram
declaration in an entity declaration and the corresponding subprogram
body in an architecture body are both in the one declarative region
comprising the entity declaration and architecture body.
This leaves the question of whether "architecture E of E" is legal.
If the entity name and architecture name are homographs, then the
construction is illegal, since both the entity name and architecture
name appear in the root declarative region enclosing the entity and
architecture. Making the names not homographs would require
extensions to the rules for homographs and overload resolution.
A further comment is that recommendation 2 is incomplete: "through the
end" of what?
----------------
LCS 5
In the current state of affairs, the analyzer may check at compile
time the compatibility between a componnet declaration and the
associated entity, issue errors about type and width mismatch at the
earliest possible stage. Moreover the analyzer can then generate code
that saves a lot of work and information reading during elaboration.
Secondly I don't agree with the wording:
"Secondly, requiring the entity to be directly visible at analysis
implies that the entity interface must exist during the analysis of
the component instantiation statement that will eventually be bound to
the entity interface. This requirement has the effect of precluding
top-down design, where the entity interface need not exist when its
corresponding component is instantiated."
The interface has to exist in the component declaration, and even if
the entity does not exist one can still compile the instantiating unit
and even simulate it. The only overhead is that instantiating unit has
to be compiled after the entity is compiled.
It does not seem consistant to allow in some cases compile time
checking of the instantiation and in other cases only elaboration.
My proposal for the solution is to specify that the entity with the
component declaration's name within the component declaration's
library is made visible for the binding indication. In my opinion this
can be achieved by adding another visibilty rule (c) to the rules in
5.2.2.
-----------------------------------------------
LCS 8:
I am in general agreement with Steve's analysis and recommendation, but
note that there is a further problem.
1.3.2 states:
If the component configuration contains a binding indication (see
5.2.1), then the component configuration implies a configuration
specification for the component instances to which it applies.
This implicit configuration specification has the same component
specification and binding indication as that of the component
configuration.
In the case of incremental binding, this means there are two
configuration specification for a component instance: the explicit
primary binding indication, and the implicit incremental binding
indication.
5.2 states:
The elaboration of a configuration specification results in the
association of binding information with the labels identified by the
instantiation list. A label that has binding information associated
with it is said to be bound. It is an error if the elaboration of a
configuration specification results in the association of binding
information with a component label that is already bound.
Taken with 1.3.2, this means that an error occurs when incremental
binding is used: elaboration of one of the configuration specifications
binds the complonent instance label, and so elaboration of the other
results in an error!
The intention is that there cannot be more than one configuration
specification for a given component instance unless it arises from an
incremental binding indication. It should also be an error if there is
more than one incremental binding indication for a given component
instance.
I suggest this be fixed by revising 5.2 as follows:
... It is an error if the elaboration of a configuration specification
results in the association of binding information with a component
label that is already bound, unless the binding indication in the
configuration specification is an incremental binding indication (see
5.2.1). It is an error if the elaboration of a configuration
specification containing an incremental binding indication results in
the association of binding information with a component label that is
already incrementally rebound (see 5.2.1).
For expediance, we might like to roll this in with Steve's issue, rather
than generating a whole new issue.
-----------------------------------------------
LCS 11:
However the LRM can allow unconstrained result conversion functions
for constrained formals.
LCS 11
I'd like to revisit this in 200x. The goal being to make std_logic_vector
a subtype of std_ulogic_vector. The fact that std_logic is a subtype of
std_ulogic but std_logic_vector and std_ulogic_vector are distinct
types is troublesome to most users.
LCS 11
One of the things I would still like to see in the language is the ability
to utilize unconstrained arrays. So we should allow for unconstrained
arrays whenever feasible.
------------------------------------------------
LCS 12:
First, let us correct an apparent typographical error and consider the
relational expression:
1.001 ps = 1001 fs.
This expression is always true in the absence of 3.1.3.1, page 39, line 231
which describes modifying the execution time resolution limit of type time.
It is always true (and thus exact) because a physical type is constructed of
an
integer range constraint, and integral multiples of the primary and
secondary
unit declarations. Therefore, while writing a "time literal with a real
part," one
is expressing an integer time. Furthermore, 3.1.3.1 states that it is an
error
if a unit is used in the model that is smaller than the resolution limit
requested.
So, if we selected ps as our resolution limit, our expression would cause an
error.
With that said, if VHDL-AMS has a different concept of time, this issue
should be forwarded to VHDL-AMS.
LCS 12
The issue statement seems to be confused. Presumably "123456.789 fs"
should read "123456.789 ms", so that one might argue that (123456.789
ms = 123456789 us) could be false. Similarly, in the following
sentence, presumably the issue author meant that one could argue that
1001 ps is not always the same as 1.001 ns, or that 10001 ps is not
always the same as 1.0001 ns.
In any case, the analysis and rationale is erroneous and incomplete.
Note that the issue is relevant not just to literals of type time, but
to physical literals in general.
There are two cases where a physical literal that contains a floating
point literal can occur: in a secondary unit declaration, and in an
expression. I will consider them in reverse order.
The value of a physical literal in an expression can be determined
using its position number, as defined in 3.1.3 lines 173-177:
There is a position number corresponding to each value of a
physical type. The position number of the value corresponding to a
unit name is the number of primary units represented by that unit
name. The position number of the value corresponding to a physical
literal with an abstract literal part is the largest integer that
is not greater than the product of the value of the abstract
literal and the position number of the accompanying unit name.
This implies that the value of a physical literal is exact, but
depends on the value of the abstract literal. In the case of floating
point literals, which are of type universal_real, the precision is
implementation defined, provided it includes at least 6 decimal digits
of precision. Thus a physical literal with a floating point literal
is exact, but its value may vary between implementations of the
language. (The LCS to adopt IEEE format floating point will address
this lack of portability, however.)
In a secondary unit declaration, 3.1.3 lines 165-166 state
Unit names declared in secondary unit declarations must be
directly or indirectly defined in terms of integral multiples of
the primary unit of the type declaration in which they appear.
This does not appear to imply that the physical literal in the
secondary unit declaration have an integer literal as the abstract
literal. For example, in the following type defintion
type example is range 0 to 1E9
units
pu;
su1 = 1000 pu;
su2 = 0.5 su1;
su3 = 0.10001 su1;
end units example;
the secondary unit su2 is defined indirectly to be an integral
multiple of pu, namely, 500 pu. (Note that the floating point number
0.5 can be represented exactly in floating point representation.)
In the case where a secondary unit is defined using a physical literal
that is not an integer multiple of the primary unit, or where the
abstract literal is not exactly representable, you would have to
appeal to the definition of the value of a physical literal to
determine the value of the secondary unit. For example, the unit su3
in the above definition is the largest integer multiple of pu that is
not greater than 0.10001 * 1000 * pu, namely 100 pu.
Whether this was the intention of the language designers, I don't
know. Certainly it would be simpler to require that a secondary unit
declaration have a physical literal in which the abstract literal is
either absent or is an integer literal.
In summary, no LRM changes are required to address the issue for
physical literals in expressions. However, LRM changes may be
required if physical literals in decondary unit declarations are to be
limited to those containing integer abstract literals.
------------------------------------------------
LCS 16:
The LRM only allows graphic characters and format effectors in a VHDL
description (13.1, line 8). To support the proposal, this restriction
would have to be qualified by saying that other non-graphic characters
could be included, but only in comment text.
------------------------------------------------
LRM 19:
As suggested in the proposed resolution, include a note after 12.6.1,
referring to 4.3.1.2, indicating that there are requirements for
inclusion of drivers in processes.
------------------------------------------------
LCS 20:
I agree that the problem is that attribute names denoting implicit
signals are not defined to be static names. Note that the prefix of
each attributes of a signal name is required to be static. Thus the
change to 6.1 only needs to be
-- the name is an implicit signal defined by a predefined
attribute
I disagree that association of implicit signals with ports should be
disallowed. If an implicit signal can be used in a concurrent
statement, then it should be allowed in an abstraction of a concurrent
statement, namely, a component instance. The means of doing so is
through a port association.
LCS 20
A concurrence with preceding comment.
------------------------------------------------
LCS-21:
LCS-21 proposes to amending the LRM(section 12.6.4). However, it
seems that ISAC opposes this proposal, because there is the
sentence with boldface saying no change of the LRM. We think it is
necessary to amend the LRM, and agree to the LCS-21 proposal.
LCS 21:
The statement in the last line, "This LCS does not call for a change
in the LRM," is wrong. The LCS calls for a change in the way
postponed processes are initialized. I suggest the following changes:
Delete the following step in the initialization phase
-- Each postponed process in the model is executed until it
suspends.
Add the following step as the last step in the initialization phase
-- If the next simulation cycle will be a delta cycle, the
remainder of this step is skipped. Otherwise, each postponed
process is executed until it suspends. Then Tn is recalculated
according to the rules of step f of the simulation cycle,
below. It is an error if the execution of any postponed
process causes a delta cycle to occur immediately after the
initialization phase.
LCS 21:
A concurrence with preceding comment.
-----------------------------------------------
LCS 22:
The change should also apply to type universal_real and to
user-defined floating-point types, not just the predefined type real
and its subtypes.
LCS 22
A concurrence with preceding comment.
-----------------------------------------------
LCS 23:
Recommendation 3: don't include the BNF rules for signature,
left_square_bracket and right_square_bracket. The rule for signature
is already included in the standard BNF.
LCS 23
A concurrence with preceding comment.
-----------------------------------------------
LCS-24:
The mode of the port is a basic part. So, the specification of the
mode should not be changed, and kept the compatibility between
VHDL93 and VHDL98.
LCS 24
VHDL users are using buffer ports as a mean to get compilation errors
for multiple drivers even for resolved signals. Hence the restriction
of a single driver to a buffer port should not be relaxed.
LCS 24
Note that the issue author's proposed resolution 2 will not work,
since the 'driving_value attribute of a signal can only be used within
a process that has a driver for the signal, and returns the driving
value for that driver. Hence resolution 1 is the only valid
alternative of the two.
Furthermore, if the second restriction of 1.1.1.2 is to be relaxed,
why not relax both restrictions, allowing a buffer-mode port to have
multiple sources. This would make them just like out-mode ports,
except that the unit can read the driving value internally. Note
that, if a buffer-mode port has multiple sources, it must be resolved,
but that should still be ok.
-----------------------------------------------
LCS 25:
I do not think all of the features should be removed.
-----------------------------------------------
LCS-26:
LCS-26 proposes to create special cases for function declarations.
We are afraid that this makes designers confused. (Designers may
wonder whether a function applies to the special cases or not.)
LCS 26
The analysis is insufficient, and there is no detailed proposal for
resolution. This issue needs further work, and should not hold up the
VHDL-99 process. Meanwhile, the language is still useable without
infix invocation of operators for protected-type parameters.
The following people voted:
Ron Werner
Gabe Moretti
Peter Ashenden
Paul Menchini
Jake Karrfalt
Lance Thompson
Yosi Veller
Takeshi Kitahara (representing the collective EIAJ)
John Willis
Steve Bailey
HDL & Simulation Product Manager
Free Evaluation of VB VHDL: http://www.veribest.com/vhdl.html
VeriBest Inc.
The EDA Systems Company
6101 Lookout Rd.
Boulder, CO 80301
303-581-2467 (voice) 303-581-9143 (fax)
303-588-2001 (mobile)
mailto:sbailey@veribest.com http://www.veribest.com