FW: IR 2064

Folks,

I just looked at IR2064 again.  May I propose an alternate analysis that
provides an explanation of the relevant part of the LRM:

VASG-ISAC Analysis & Rationale
------------------------------

The part of the LRM that addresses the code in question is the following
text from 3.2.1.1:

    - For a local generic or a local port of a component that is of an
      unconstrained array type and that is associated in whole, the index
      ranges are obtained from the corresponding association element in the
      generic map aspect (in the case of a local generic) or port map aspect
      (in the case of a local port) of the applicable component
instantiation
      statement.

    ...

    If the index ranges for an interface object or member of an interface
    object are obtained from the corresponding association element (when
    associating in whole) or elements (when associating individually), then
    they are determined either by the actual part(s) or by the formal
part(s)
    of the association element(s), depending upon the mode of the interface
    object, as follows:

    ...

    - For an interface object or member of an interface object whose mode is
      out, buffer, inout, or linkage, if the formal part includes a
conversion
      function or a type conversion, then the parameter subtype of that
function
      or the type mark of the type conversion must be a constrained array
      subtype, and the index ranges are obtained from this constrained
subtype;
      otherwise, the index ranges are obtained from the object denoted by
the
      actual designator(s).

In the component instantiation statement labeled u_add, sample_out is an
out-mode local port of an unconstrained array type that is associated in
whole.  Hence its index range is obtained as specified in the last of the
above paragraphs.  Since the formal part includes a type conversion, then
"the type mark of the type conversion must be a constrained array subtype".

The key to the difference in interpretation between the two tools mentioned
by the submitter is the interpretation of the word "must".  Clause 0.2
states

    To the developer of tools that process VHDL, must denotes a requirement
    that the standard imposes. The resulting implementation is required to
    enforce the requirement and to issue an error if the requirement is not
    met by some VHDL source text.

Thus, the code in question is in error, since the type mark of the type
conversion is not a constrained array subtype.  The rule following the word
"otherwise" in the quoted paragraph only applies if the formal part does not
include conversion function or a type conversion.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

No change.

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106


-----Original Message-----
From: owner-isac@eda.org [mailto:owner-isac@eda.org] On Behalf Of Peter
Ashenden
Sent: Monday, 14 March 2005 09:54
To: isac@eda.org
Subject: RE: IR 2064


Folks,

I agree with Ajay, that no rewording is needed.  If you search the LRM for
"otherwise", you will find that the usage "if <condition-1>, then
<specification-1>; otherwise <specification-2>" is pervasive.  It means

  <condition-1> => <specification-1>

  not <condition-2> => <specification-2>

I think that in this case, we need only issue an explanation, not an
interpretation.  (The terms "explanation" and "interpretation" are defined
in clause 5.9 of the IEEE Standards Board Ops Manual, see
http://standards.ieee.org/guides/opman/sect5.html#5.9.)

BTW, our resolutions should refer to the current revision of the standard,
1076-2002.  Where relevant for explanatory purposes, we can refer to
prevision revisions.  So, in the case of this issue, we should explain the
specification in 1076-2002 and indicate that it was the same in 1076-1993.

</nit-picking>

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106


> -----Original Message-----
> From: owner-isac@eda.org [mailto:owner-isac@eda.org] On
> Behalf Of Ajayharsh Varikat
> Sent: Friday, 11 March 2005 00:18
> To: isac@eda.org
> Subject: IR 2064
> 
> 
> 
> The intent in the LRM looks obvious to me, and I agree with
> the analysis. Personally, I am not even convinced there is a need to 
> change the wording. 
> 
> -ajay
> 
> 
> ----- Begin Included Message -----
> 
> >From owner-isac@eda.org Wed Mar  9 02:17 IST 2005
> Date: Tue, 08 Mar 2005 12:47:18 -0800
> To: isac@eda.org
> Subject: Some ISAC issues.
> Sender: owner-isac@eda.org
> 
> Larry has analyzed IR2064. You can read his analysis on the website.
> 
> I sent out an email asking for a vote on IRs 2042, 2048 and
> 2051 So far, only Larry and Peter have responded. Please try 
> to vote on these.
> 
> Chuck Swart
> 
> 
> 
> ----- End Included Message -----
>