Attached is IR2013. It is the same as the IR in the eda.org repository.
Please vote on thi ASAP.
This is a difficult issue, but we seem to have reached consensus
If you have any issues let me know and we will reconsider at the next
meeting.
Otherwise, I would like to get this off the table.
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: 3
Date Last Revised: 05 February 2005
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.
The ISAC agrees that 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. Allow different directions.
No significant 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 Broadening/narrowing of subtypes.
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 arbitrary subtypes.
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.
Solution 2 gives the greatest benefit for a reasonable effort. Also,
in those cases where solution 2 is not powerful enough, type
conversions can be used in the port association.
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. Note, however, that checking the broadening of subtypes for
subprogram parameters can require simulation time checks, since
non-static subtypes can be involved.
Consequently, the ISAC recommends that solution 2 be adopted.
In addition, it should be required that in a scalar signal assignment,
all waveform values must belong to the subtype of the target. This
seems both intuitive and reasonable.
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
---------------------------------------------
Specific LRM changes:
Clause 2.1.1.2 Signal parameter
The paragraph reading "If an actual signal is associated with a signal
parameter of any mode, and if the type of the formal is a scalar
type..."
Should be replaced by:
"If an actual signal is associated with a signal parameter of mode IN
or INOUT, and if the type of the formal is a scalar type, then it is
an error if the subtype of the actual is not compatible with the
subtype of the formal."
"Similarly, if an actual signal is associated with a signal parameter
of mode OUT or INOUT, and if the type of the actual is a scalar type,
then it is an error if the subtype of the formal is not compatible
with the subtype of the actual."
Clause 3.1 Scalar types.
After the paragraph defining compatibility between a range constraint
and a subtype, add the following:
"A subtype S1 is "compatible" with a subtype S2 if the range
constraint associated with S1 is compatible with S2."
Clause 8.4.1 Updating a projected output waveform
Add to the end of the paragraph starting "For the execution of a
signal assignment statement whose target is of a scalar type..."
"It is also an error if the value of any value expression in the
waveform does not belong to the subtype of the target."
Clause 12.2.4. The port map aspect
Replace the paragraph beginning "If an actual signal is associated
with a port of any mode..." with the following:
"If an actual signal is associated with a port of mode IN or INOUT (or
BUFFER), and if the type of the formal is a scalar type, then it is an
error if (after applying any conversion function or type conversion
expression present in the actual part) the subtype of the actual is
not compatible with the subtype of the formal.If an actual expression
is associated with a formal port (of mode IN)..."
"Similarly, if an actual signal is associated with a port of mode OUT,
INOUT or BUFFER, and if the type of the actual is a scalar type, then
it is an error if (after applying any conversion function or type
conversion expression present in the formal part) the subtype of the
formal is not compatible with the subtype of the actual."
The paragraph reading: "If an actual signal or expression ... then it
is an error if the rules of the preceding three paragraphs do not
apply..." should be replaced by:
"If an actual signal or expression...then it is an error if the rules
of the preceding four paragraphs do not apply..."
-------------END OF IR----------------
Received on Sat Feb 5 16:50:19 2005
This archive was generated by hypermail 2.1.8 : Sat Feb 05 2005 - 16:50:19 PST