Most of the IRs we have looked at have been relatively straightforward.
Many deal with
deciding correct wording for concepts which we understand pretty well.
This IR touches on one of those issues which John Ries calls "heavy
lifting."
It raises a significant issue which VHDL hasn't handled very well.
Please review my analysis, and we'll go over this at the next meeting.
I am also enclosing IR 0034, which describes the general issue.
I can also send VHDL 93 LCS 0041 if you want it, but I'll have to either
scan it or fax it to you, since all I have is printed copy.
Chuck Swart
VHDL Issue Number: 2013
Language_Version: VHDL-2002
Classification: Language Definition Problem
Summary: Exact subtype "matching" for port associations
Relevant_LRM_Sections: 12.2.4 12.5
Related_Issues:
Key_Words_and_Phrases: port association subtype range direction bounds
Authors_Name: Stephen Bailey
Authors_Phone_Number: 303-588-2001
Authors_Fax_Number: 303-652-1578
Authors_Email_Address: stephen@srbailey.com
Authors_Affiliation: Synopsys Inc.
Authors_Address1: 6664 Cherokee Ct
Authors_Address2: Niwot, CO 80503
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 14 May 2001
Date Analyzed: 02 December 2004
Author of Analysis: Chuck Swart
Revision Number: 1
Date Last Revised: 02 December 2004
Description of Problem
----------------------
The '93 LRM added the following text in the 3rd paragraph of 12.2.4
(relative to '87):
"If an actual signal is associated with a port of any mode, and
if the type of the formal is a scalar type, the it is an error if
(after applying any conversion function or type conversion expression
present in the actual part) the bounds and direction of the subtype
denoted by the subtype indication of the formal are not identical to
the bounds and direction of the subtype denoted by the subtype
indication of the actual."
(The 2nd sentence of the paragraph is NOT part of this IR.)
This new restriction requires exact "subtype matching" of bounds
and direction for scalars in port associations. However, this
restriction does not exist for subprogram parameter associations. Why
are the 2 treated differently?
Also, I find the restriction to be overbearing (overly
restrictive) and believe the LRM should revert back to '87 and strike
this "new" restriction from the next language version.
The restriction makes it difficult to write code for a reusable
component that takes an integer-typed port and performs operations on
it as users of that component who wish to constrain the range of their
integer values (to ensure minimum bit-size for synthesis or other
reasons) must use type conversions in the port maps. While this can
be viewed as a trivial thing, one of the frequent complaints about
VHDL is the all of the "excessive" typing the language requires.
(Excessive is definitely in the eye of the beholder, but it is a
relevant point.) It is unclear to me that the advantage the user
gains is worth the trouble of extra typing (and worse, dealing with
what they may consider an obscure error message -- obscure not because
the vendor has a terrible message, but because of language
"idiosyncrasies" -- again in the eye of the beholder).
Proposed Resolution
-------------------
I believe all associations should be treated equally. If there are
valid reasons for enforcing strict subtype conformance of port
associations, then those reasons almost assuredly apply to parameter
associations.
As noted previously, I think the new restriction is overly
restrictive. Therefore, I believe the consistency principle should be
applied but in favor of eliminating the restriction for port
associations.
VASG-ISAC Analysis & Rationale
------------------------------
The submitter claims that the scalar restriction "does not exist for
subprogram parameter associations." He is not completely correct.
Scalar restrictions are not present for constants or variables,
because copy-in copy-out semantics make range checks easy to
implement. However, for subprogram signal parameters, Section
2.1.1.2, paragraph seven, states:
"If an actual signal is associated with a signal parameter of any
mode, and if the type of the formal is a scalar type, then it is an
error if the bounds and direction of the subtype denoted by the
subtype indication of the formal are not identical to the bounds and
direction of the subtype denoted by the subtype indication of the
actual."
Other relevant LRM sections are:
Section 12.6.2 paragraph 12?
"For a scalar signal S, both the driving and effective values must
belong to the subtype of the signal."
Section 12.6.2 paragraph 13?
"In order to update a signal during a given simulation cycle, the
kernel process first determines the driving and effective values of
that signal. The kernel process then updates the variable containing
the current value of the signal with the newly determined effective
value, as follows:
a) If S is a signal of some type that is not an array type, the
effective value of S is used to update the current value of S. A check
is made that the effective value of S belongs to the subtype of S. An
error occurs if this subtype check fails."
Note that the LRM states when the subtype check on the effective value
is done. It does not state when the subtype check on the driving value
is done.
Also note that in a signal assignment statement there is no
requirement that all waveform values belong to the subtype of the
target signal, although perhaps such a requirement should exist.
The basic problem with signal parameters in subprograms is that
changes both in read and written values can occur at times outside of
the control of the subprogram, because of driving values that can
occur during wait statements in the subprogram, and because of signal
assignments that are made within the subprogram, but that mature
after leaving the subprogram. Consequently, copy-in copy-out semantics
are inadequate for signal parameters in subprograms.
For a discussion of the problems of scalar signal parameters in which
the subtypes of the formal and the actual differ, see IR0034 "The
meaning of the constraint on a scalar signal parameter is unclear" and
also VHDL93 LCS-0041(2) "Run-time constraint/subtype checks". In these
documents at least five different solutions for dealing with this
problem are proposed.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
The current rules are consistent, if restrictive. No changes to the
existing LRM are needed.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
The existing requirements for scalar ports (and perhaps scalar signal
parameters) are overly restrictive.
Possible Solutions for Port Associations in Port Maps.
We define subtype S1 to be "compatible" with subtype S2 if they have
the same base type and if the range constraint of S1 is
compatible with subtype S2. (See Section 3.1.) Basically, S1 is
compatible with S2 if its range is contained within the
range of S2.
Solution 1. It seems that no problems will arise if we require that
the bounds match (taking into consideration null ranges) but no longer
require that directions match.
Solution 2. Allow scalar subtypes that do not have the same bounds if
a) the mode of the formal is IN and the subtype of the actual is
compatible with the subtype of the formal, or b) the mode of the
formal is OUT and the subtype of the formal is compatible with the
subtype of the actual.
The checks for this would, in general, be done at elaboration time,
but no new simulation checks would be required.
Solution 3. Allow the formal and actual to have non-compatible
subtypes. This would, in general, require additional range checks
during simulation as values were propagated through nets. Essentially, there
would be one check each time a driving value changed and a check when an
effective value is determined. Also, elaboration time optimizations could be
performed to remove redundant checks.
It seems that solution 2 gives the greatest benefit for a reasonable effort.
Possible Solutions for Signal Associations in Subprogram Calls.
Solution 1 and solution 2 from above are viable.
Solution 3 would require very expensive checks during simulation. For
example, consider an IN mode signal parameter to a procedure which
contains WAIT statements. Various possibilities are
A. Perform a range check every time the parameter is read.
B. Perform a range check every time the procedure returns from a WAIT.
C. Modify range information on the actual signal when entering and leaving the
subprogram.
All of these solutions difficult to implement and will result in slower simulation.
It seems that solution 2 gives the greatest benefit for a reasonable effort.
In addition, it should be required that in a scalar signal assignment,
all waveform values must belong to the subtype of the target.
-------------END OF IR----------------
VHDL Issue Number: 0134
Classification: Language Definition Problem
Language Version: VHDL-87
Summary: The restriction that subprogram association
elements may not have input or output conversion
functions for signal parameters means that conversion
functions for signals can't be used in
concurrent_procedure_call statements.
Related Issues: ?
Relevant LRM Sections: 4.3.3.2
Key Words and Phrases: Conversion Functions, Concurrent Procedure Calls
Current Status: Submitted
1076-1993 Disposition: Bugs Fixed, Enhancements Outstanding (No ISAC Issues)
Disposition Rationale: Non-ISAC issues outstanding.
Superseded By: N/A
-----------------------
Date Submitted: 1989/06/21
Author of Submission: Rod Farrow
Author's Affiliation: Vantage Analysis Systems, Inc.
Author's Post Address: 42840 Christy St., Suite 201
Fremont, CA 94538
Author's Phone Number: (415) 659-0901
Author's Fax Number:
Author's Net Address: N/A
-----------------------
Date Analyzed: TBD
Author of Analysis: TBD
Revision Number: $Revision: 1.9 $
Date Last Revised: $Date: 1995/08/04 01:37:53 $
Description of Problem
----------------------
The restriction that subprogram association elements may not have input
or output conversion functions for signal parameters means that conversion
functions for signals can't be used in concurrent\_procedure\_call statements.
Further the utility of
conversion functions for variable parameters is marginal at best: these
could always be simulated by an assignment before the procedure call, followed
by an assignment after the procedure call.
Proposed Resolution
-------------------
We propose that all conversion functions on subprogram parameters be
disallowed, as a simplification to the language.
VASG-ISAC Analysis & Rationale
------------------------------
VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Received on Fri Dec 3 13:40:28 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 13:40:29 PST