RE: FW: Analysis of IR2062

Ajay,

It appears that ISAC and FT folks have each assumed the other is making the
change!

I think the issue referred to in FT22 is IR2022, but that issue only deals
with indexed and slice names for which the prefix is locally static.  It
doesn't address staticness of the subtype of a declared constant.  No other
ISAC IR addresses the issue.

I'd suggest that John revise FT22 to propose the change to item b) without
reference to ISAC.  (John, does that make sense to you?)

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: Ajayharsh Varikat [mailto:ajay@cadence.com] 
> Sent: Thursday, 7 April 2005 18:02
> To: peter@ashenden.com.au
> Subject: Re: FW: Analysis of IR2062
> 
> 
> 
> Peter,
> 
> I am working on incorporating these into the analysis. 
> 
> I have a question about the locally static case. You mentioned that 
> there is an FT proposal which makes it mandatory for a locally static 
> constant to have a locally static subtype. The only reference to this 
> that I could find was as part of FT22, which in turn says 
> that there is 
> an ISAC proposal to this effect. Is this going to come 
> through an ISAC IR or is FT22 being modified to take care of 
> this also?
> 
> Thanks,
> 
> -ajay
> 
>  
> >> To: <isac@eda.org>
> >> Subject: FW: Analysis of IR2062
> >> Date: Thu, 7 Apr 2005 13:46:40 +0930
> >> X-Virus-Scanned: clamd / ClamAV version 0.74, 
> clamav-milter version 
> >> 0.74a on
> server.eda.org
> >> X-Virus-Scanned: clamd / ClamAV version 0.74, 
> clamav-milter version 
> >> 0.74a on
> server.eda.org
> >> X-Virus-Status: Clean
> >> X-Virus-Status: Clean
> >> 
> >> Ajay,
> >> 
> >> I agree with the general sense of your proposed change, 
> but I think 
> >> you've inadvertently omitted a case that needs to be there.  You 
> >> write:
> >> 
> >> In section 7.4.2, change the sentence
> >> 
> >>     "A globally static range is either a range of the second form 
> >>      (see  3.1  ) whose bounds are globally static 
> expressions, or a 
> >>      range of the first form whose prefix denotes either a 
> globally 
> >>      static subtype or an object that is of a globally static 
> >> subtype."
> >> 
> >> to the following.
> >> 
> >>     "A globally static range is either a range of the second form 
> >>      (see  3.1 ) whose bounds are globally static 
> expressions, or a 
> >>      range of the first form whose prefix either denotes a 
> globally 
> >>      static subtype or is a globally static primary that 
> denotes an 
> >> object."
> >> 
> >> However, the words "an object that is of a globally static 
> subtype" 
> >> cover, for example, a signal that is declared to be of a 
> constrained 
> >> subtype, such as
> >> 
> >>   generic ( width : natural )
> >>   ...
> >>   signal s : bit_vector(0 to width - 1);
> >> 
> >> The words make the attribute name s'range globally static, 
> since s is 
> >> of a globally static subtype.  However, s is not a globally static 
> >> primary.
> >> 
> >> I'd suggest the changed wording be
> >> 
> >>      ... or a range of the first form whose prefix denotes 
> either a 
> >> globally
> >> 
> >>      static subtype or an object that is of a globally 
> static subtype 
> >> or whose
> >>      prefix is a globally static primary.
> >> 
> >> Note that the same issue arises in items j) and k) of the list of 
> >> globally static primaries.  For example, currently, in
> >> 
> >>   generic ( a : bit_vector )
> >>   ...
> >>   ... a'length ... a'
> >> 
> >> a'length is not currently globally static.  This would be fixed by 
> >> allowing the prefix of the attribute name in j) and k) to be a 
> >> globally static primary.
> >> 
> >> Note also that analogous problems arises in description of locally 
> >> static ranges and attribute names.  However, there is an 
> FT proposal 
> >> to require a constant (or an alias) to have a locally 
> static subtype 
> >> in order to be locally static.  With that change, we don't need to 
> >> revise the definition of locally static ranges or attribute names.
> >> 
> >> 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: Wednesday, 6 April 2005 23:43
> >> > To: cswart@model.com
> >> > Cc: isac@eda.org
> >> > Subject: Analysis of IR2062
> >> > 
> >> > 
> >> > 
> >> > Please find attached my analysis of IR2062.
> >> > 
> >> > -ajay
> >> > 
> >> 
> >> 
> 
>