--------------ms09BF6819B2A5E1377D897758
Content-Type: multipart/mixed;
boundary="------------A7DC5FA8DD0BB0B4E2259278"
This is a multi-part message in MIME format.
--------------A7DC5FA8DD0BB0B4E2259278
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Steve,
Review and comments attached.
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) --------------A7DC5FA8DD0BB0B4E2259278 Content-Type: text/plain; charset=us-ascii; name="review-4-Jan-99.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="review-4-Jan-99.txt"
Review and comments on the VHDL-98 LCSs, Version D, December 1998
Peter Ashenden, 4 January 1999.
LCS Approve Disapprove Comment ----------------------------------------------- 1 Approve 2 Approve 3 Disapprove see below 4 Approve 5 Approve 6 Approve 7 Approve 8 Approve see below 9 Approve 10 - 11 Approve 12 Disapprove see below 13 - subsumed by LCS 5 14 Approve 15 Approve 16 Approve see below 17 - 18 - 19 Approve see below 20 Disapprove see below 21 Disapprove see below 22 Disapprove see below 23 Disapprove see below 24 Approve see below 25 Approve 26 Disapprove see below
Other issues: see comments below. (These were brought to the attention of the ISAC, but no action was taken!)
----------------
LCS 3/IR 1028
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 8/IR 1096
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 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.
----------------
LCS 19/IR1117
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/IR 1116
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 21/IR 1107
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 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 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 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 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.
----------------
LCS ??/IR ????
This is an issue I identified when writing The Designer's Guide to VHDL, but no IR was ever generated.
The procedure READLINE in TEXTIO has a parameter L : out LINE. 14.3 line 985 states
If parameter L contains a nonnull access value at the start of the call, the object designated by that value is deallocated before the new object is created.
For this to occur, the parameter should be INOUT.
Proposed resolution: change the mode of L in READLINE to INOUT.
----------------
IR 1000
This issue report includes a number of corrections to typos, etc. Most of the corrections are fine, but some aren't. Following are some comments.
1.3: The correction is wrong. The generic map should be
generic map ((1 to 2 => (others => '0')))
The actual is an aggregate containing an aggregate.
1.4: Would be better style to change "have an affect on" to "affect"; this corresponds to the usage in the first part of the sentence.
1.6: Wrong - see 1.3
3.3: Note - there are two occurrences that should be changed.
4.3: The issue author points out a problem, but does not suggest a resolution. I suggest:
A given subprogram designator can be used to denote everal subprograms. The subprogram designator is then said to be overloaded; ...
The several is generally interpreted to mean "more than one." I don't see a problem with the use of the term.
4.4: I suggest the following wording:
If the entity tag is overloaded and the entity designator does not contain a signature, all named entities that are already declared in the current declarative part and that match the specification are decorated.
4.6, section 4.7: I suggest the following change:
A name that is a group constituent must not be an attribute name (see 6.6). Furthermore, if such a name contains a prefix, that prefix must not be a function call.
4.6, section 11.2: I suggest that "may or may not" be left unchanged. Also, "libraries" should be "library".
4.6, section 14.1: Leave the first "may" unchanged, and change the second "may" to "might".
----------------
IR 1106
This IR contains some clarification of wording that I think should be fairly non-contentious.
----------------
In the 1076a ballot, a reviewer pointed out an error in an example in the LRM.
On page 116, line 217, the final waveform element should be "not Input_pin after 20 ns", rather than "... after 10 ns".
----------------
--------------A7DC5FA8DD0BB0B4E2259278--
--------------ms09BF6819B2A5E1377D897758 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
MIIEUQYJKoZIhvcNAQcCoIIEQjCCBD4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC ArUwggKxMIIBmaADAgECAgQL68SbMA0GCSqGSIb3DQEBBAUAMDcxCzAJBgNVBAYTAmF1MSgw JgYDVQQKEx9LZXlQT1NUIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MCYXETk4MTIxMDE0MDAw MCsxMDAwFxE5OTEyMTExMzU5NTkrMTAwMDB6MQswCQYDVQQGEwJhdTEoMCYGA1UEChMfS2V5 UE9TVCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEXMBUGA1UEAxMOUGV0ZXIgQXNoZW5kZW4x KDAmBgkqhkiG9w0BCQETGXBldGVyYUBjcy5hZGVsYWlkZS5lZHUuYXUwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALDa2Ju7/Pa1Q9PS+6Og16RJJtta7xklsiT4QkDGGO5yVT5sWnPU rOD0Xmol5vfhAXvALs1h6AZ2j7/edX1M7ZQ9vu4PsKPbzgRR/lDpBlk3AcsdyU+JecfuTQpZ Y+Mjn1XkQE/TWkrTUTxfBwrMzAg7LSyL4GIUt4Ht/vFYEebJAgMBAAEwDQYJKoZIhvcNAQEE BQADggEBAI/XJnxHspzryy59JIio7iHnGMKKBeUI9iiIxuwYXNVxYpVVbYMrCWqQefCPNAFx nD9+tt0vkGB8LWHtNo78BOvLCuj09X4wr88tq0fO1YQUdGuJF752NwYOMlUHFTqhHG1MKisy kqsg/nlXBG5xvKOPxg0xkiw34HzZHPyX7nt3p8dXy3n8i6R7FQqO3u4rwk/hV+9wldWHEyea pdkFxeK5rlX7nzxjqGgXAKXjLiIhHy/XQU3H1GhCQFtWcA4P/scomLM5kg3XBj7LMF2941OL ENf6Gf3eqhM7bEAkLCU0nbxPV10FwRhXfUi5hENlaHO9B/fvKkBEUX6OCSIgUgcxggFkMIIB YAIBATA/MDcxCzAJBgNVBAYTAmF1MSgwJgYDVQQKEx9LZXlQT1NUIENlcnRpZmljYXRpb24g QXV0aG9yaXR5AgQL68SbMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTAxMDQwNDA1MTRaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFBHSw1021znmXqZGm3VaXX8MKYzHMA0GCSqGSIb3 DQEBAQUABIGAWpFCX0KkBaz9uPN3Dun6xEFJAuaKwnqWC2bbxJ7KwiPFONejjtTpzBqRQbAb 30HCmb/HNj+aDR37KVxwj50dSkqhxJj0oDRrYMOGq51nLFLg8zmcHBcA7RmdDqzn5m16/0iC nmNGefw5ZvBx7XkOHut4mnh83Ndd+yMiXr0YHA0= --------------ms09BF6819B2A5E1377D897758--