RE: [sv-ac] use of $ as actual argument to sequence and property instances

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Wed Aug 22 2007 - 04:33:33 PDT
While it could be done, that change might endanger or at least delay
approval of 1730, so I think 1730 should be left alone.

Regards,
Shalom  

> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
> Sent: Monday, August 20, 2007 4:25 PM
> To: john.havlicek@freescale.com; Bresticker, Shalom
> Cc: Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] use of $ as actual argument to sequence 
> and property instances
> 
> Perhaps it could also be done as part of 1730 (which I just 
> corrected). 
> 
> ed 
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of 
> > John Havlicek
> > Sent: Monday, August 20, 2007 9:21 AM
> > To: shalom.bresticker@intel.com
> > Cc: Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org
> > Subject: [sv-ac] use of $ as actual argument to sequence 
> and property 
> > instances
> > 
> > Hi Shalom, Brad:
> > 
> > I had forgotten about 1982, which seems to be the place to address 
> > problems with $ in assertions.
> > 
> > I know it is ancient history, but if you look back at the 
> > SystemVerilog 3.1a LRM, we had
> > 
> > 
> > sequence_instance ::=
> >   ps_sequence_identifier [ ( [ actual_arg_list ] ) ]
> > 
> > property_instance::=
> >   ps_property_identifier [ ( [ actual_arg_list ] ) ]
> > 
> > actual_arg_list ::=
> >     actual_arg_expr { , actual_arg_expr }
> >   | . formal_identifier ( actual_arg_expr ) { , . 
> > formal_identifier ( actual_arg_expr ) }
> > 
> > actual_arg_expr ::=
> >     event_expression
> >   | $
> > 
> > 
> > So in 3.1a it was very clear that $ can be an actual argument to a 
> > sequence or property instance.
> > 
> > In 1800-2005 this became bungled.  The production for 
> actual_arg_expr 
> > remained as in 3.1a, but this was disconnected from the instances, 
> > which became
> > 
> > sequence_instance ::=
> >   ps_sequence_identifier [ ( [ list_of_arguments ] ) ]
> > 
> > property_instance ::=
> >   ps_sequence_identifier [ ( [ list_of_arguments ] ) ]
> > 
> > 
> > and actual_arg_expr was left as an unreferenced non-terminal.
> > From the point of view of the BNF, the use of $ as an 
> actual argument 
> > to a sequence or property instance was then forbidden by note 22 
> > (which is now note 21 in 1800-2008 Draft3a).
> > 
> > I don't think Clause 17 (now Clause 16) reflects this 
> change because I 
> > don't think anyone in SV-AC realized it.  It was not to my 
> knowledge 
> > intentional to remove the capability.  In fact, there have been 
> > several discussions in which we thought we lost the capability and 
> > then reassured ourselves that we had not because we could 
> get $ as a 
> > primary.
> > 
> > But note 21 foils this.
> > 
> > I am thinking now that as a part of resolving 1982 (rather 
> than 1350, 
> > although the two can be coordinated), we should put $ back into the 
> > production for sequence_actual_arg.
> > 
> > What do you think?
> > 
> > J.H.
> > 
> > 
> > 
> > > X-Authentication-Warning: server.eda-stds.org: majordom set
> > sender to owner-sv-ac@eda.org using -f
> > > X-ExtLoop1: 1
> > > X-IronPort-AV: E=Sophos;i="4.19,283,1183359600"; 
> > >    d="scan'208";a="285088951"
> > > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > > Content-class: urn:content-classes:message
> > > Date: Mon, 20 Aug 2007 10:37:31 +0300
> > > X-MS-Has-Attach: 
> > > X-MS-TNEF-Correlator: 
> > > Thread-Topic: [sv-ac] call to vote on 1549
> > > Thread-Index: 
> > Acfird8wc7Cf4S3ZTE2oSYC00Waz/wAQ9zMAAADX2XAAAAm9IAABrMTQ
> > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > X-OriginalArrivalTime: 20 Aug 2007 07:37:32.0417 (UTC)
> > FILETIME=[F806A710:01C7E2FC]
> > > X-eda.org-MailScanner: Found to be clean, Found to be clean
> > > X-Spam-Status: No, No
> > > X-MIME-Autoconverted: from quoted-printable to 8bit by
> > server.eda-stds.org id l7K7c7aV004015
> > > Sender: owner-sv-ac@eda.org
> > > X-eda.org-MailScanner-Information: Please contact the ISP
> > for more information
> > > X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> > > 
> > > Brad,
> > > 
> > > I agree, but the subject of Mantis 1982 is not whether the
> > wording of
> > > 6.20.2.1 is optimal, but whether the description of 16.7
> > regarding $ is
> > > consistent with the rest of the LRM. It isn't. 
> > > 
> > > (The BNF supplements the text in any case, so that even
> > though 6.20.2.1
> > > is missing the word 'only', the BNF implicitly adds it.)
> > > 
> > > I'll add your comment to Mantis 1350, though.
> > > 
> > > Thanks,
> > > Shalom
> > > 
> > > > -----Original Message-----
> > > > From: owner-sv-ac@server.eda.org
> > > > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Brad Pierce
> > > > Sent: Monday, August 20, 2007 10:08 AM
> > > > To: sv-ac@server.eda-stds.org
> > > > Subject: RE: [sv-ac] call to vote on 1549
> > > > 
> > > > Shalom,
> > > > 
> > > > It's clear from the BNF, of course, (and I personally 
> believe it 
> > > > was the intent of IEEE Std 1800-2005) that a parameter 
> is the only 
> > > > kind of data object that can be assigned '$' (via 
> > > > constant_param_expression in A.8.3), but that doesn't 
> change what 
> > > > the statement in 6.20.2.1 says and doesn't say.
> > > > 
> > > > What it *should* say is
> > > > 
> > > >       1)  An integer parameter is the only sort of data object 
> > > > that can be assigned '$'.
> > > > 
> > > >       2)  An integer parameter that has been assigned 
> '$' can only 
> > > > be legally referred to in contexts where '$' would anyway be 
> > > > legal, as described in Footnote A.10.21.
> > > > 
> > > > -- Brad
> > > > 
> > > > -----Original Message-----
> > > > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > > > Sent: Sunday, August 19, 2007 11:42 PM
> > > > To: Brad Pierce; sv-ac@eda-stds.org
> > > > Subject: RE: [sv-ac] call to vote on 1549
> > > > 
> > > > Brad,
> > > > 
> > > > Look at the BNF.
> > > > 
> > > > Shalom
> > > > 
> > > > > -----Original Message-----
> > > > > From: owner-sv-ac@server.eda.org 
> > > > > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Brad Pierce
> > > > > Sent: Monday, August 20, 2007 9:38 AM
> > > > > To: sv-ac@server.eda-stds.org
> > > > > Subject: RE: [sv-ac] call to vote on 1549
> > > > > 
> > > > > >Does the statement in 6.20.2.1 actually imply that $ can
> > > > be assigned
> > > > > only
> > > > > >to parameters and then only to ones of integer types?
> > > > > 
> > > > > No, it doesn't.  It says that
> > > > > 
> > > > >     1)  An integer parameter can be assigned '$'.  (Perhaps
> > > > there are
> > > > > other sorts of data objects that can be assigned '$',
> > > > perhaps not, but
> > > > 
> > > > > this statement is silent on that issue.)
> > > > > 
> > > > >     2)  An integer parameter that has been assigned '$' 
> > can only be
> > > > > legally referred to in contexts where '$' would 
> anyway be legal.
> > > > > 
> > > > > -- Brad
> > > > > 
> > > > > -----Original Message-----
> > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
> > On Behalf Of
> > > > > John Havlicek
> > > > > Sent: Sunday, August 19, 2007 3:10 PM
> > > > > To: shalom.bresticker@intel.com
> > > > > Cc: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > > > Subject: Re: [sv-ac] call to vote on 1549
> > > > > 
> > > > > Hi Shalom:
> > > > > 
> > > > > This is interesting.  We have thought for a long time
> > that $ can be
> > > > > passed as actual argument to sequence and property
> > > > instances.  I think
> > > > 
> > > > > tools support this too.
> > > > > 
> > > > > Does the statement in 6.20.2.1 actually imply that $ can be
> > > > assigned
> > > > > only to parameters and then only to ones of integer
> > types?  That is
> > > > > not the way I read it.
> > > > > 
> > > > > I also do not like the turn of phrase
> > > > > 
> > > > >   "An actual argument can replace any of the following:"
> > > > > 
> > > > > 
> > > > > Best regards,
> > > > > 
> > > > > J.H.
> > > > > 
> > > > > > X-ExtLoop1: 1
> > > > > > X-IronPort-AV: E=Sophos;i="4.19,281,1183359600"; 
> > > > > >    d="scan'208";a="284779936"
> > > > > > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > > > > > Content-class: urn:content-classes:message
> > > > > > Date: Sun, 19 Aug 2007 11:57:00 +0300
> > > > > > X-MS-Has-Attach: 
> > > > > > X-MS-TNEF-Correlator: 
> > > > > > Thread-Topic: [sv-ac] call to vote on 1549
> > > > > > Thread-Index: AcfgwmImOfiRY4IgSZCSHsE6gjltOABeqaNg
> > > > > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > > > > Cc: <sv-ac@eda-stds.org>
> > > > > > X-OriginalArrivalTime: 19 Aug 2007 08:57:02.0177 (UTC) 
> > > > > > FILETIME=[E89C8510:01C7E23E]
> > > > > > 
> > > > > > John,
> > > > > > 
> > > > > > I looked at this a little.
> > > > > > 
> > > > > > Mantis 1350 discusses ambiguities with respect to the use
> > > > of $, but
> > > > > > the basic restrictions are stated at the beginning of
> > 6.20.2.1:
> > > > > > 
> > > > > > "The value $ can be assigned to parameters of integer
> > types. A
> > > > > > parameter to which $ is assigned shall only be used
> > > > > wherever $ can be
> > > > > > specified as a literal constant."
> > > > > > 
> > > > > > Assigning $ to a variable does not fit those criteria.
> > > > > > Nor does passing $ as an argument.
> > > > > > You mentioned passing $ "as actual argument
> > expression to a typed
> > > > > > formal argument."
> > > > > > I do not see that it could be passed even to an 
> untyped formal
> > > > > argument.
> > > > > > 
> > > > > > I doubt even that what is written in 16.7 meets those
> > criteria:
> > > > > > 
> > > > > > "An actual argument can replace any of the following:
> > > > > >  ...
> > > > > >  - Upper delay range or repetition range if the actual
> > > > > argument is $"
> > > > > > 
> > > > > > Regards,
> > > > > > Shalom
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: John Havlicek 
> [mailto:john.havlicek@freescale.com]=20
> > > > > > > Sent: Friday, August 17, 2007 2:32 PM
> > > > > > > To: Bresticker, Shalom
> > > > > > > Cc: Bustan, Doron; Yaniv.Fais@freescale.com;
> > sv-ac@eda-stds.org
> > > > > > > Subject: Re: [sv-ac] call to vote on 1549 =20  Hi Shalom:
> > > > > > >=20
> > > > > > > Lisa and I had a discussion yesterday about the example
> > > > in=20  the
> > > > > > >1549 proposal.
> > > > > > >=20
> > > > > > > I do not think the LRM as it stands now allows $ to be=20
> > > > >  assigned
> > > > > > >to a variable or passed as actual argument=20  expression
> > > > > to a typed
> > > > > > >formal argument.  Do you know otherwise?
> > > > > > >=20
> > > > > > > The main conceptual issue that I see with allowing
> > $ to be=20
> > > > > > >assigned to a variable or passed as actual argument=20
> > > > > expression to
> > > > > 
> > > > > > >a typed formal argument is defining what value=20
> > it has in the
> > > > > > >space of possible values for the associated data type.
> > > > > > >=20
> > > > > > > It doesn't seem quite right to me to say that if $ is=20
> > > > > assigned
> > > > > > >to a shortint, for example, then the value is the=20
> > > > largest one
> > > > > > >that can be represented in an shortint.  On the=20  other
> > > > > hand, maybe
> > > > > 
> > > > > > >this is a useful and sensible definition. =20  With
> > > > definitions of
> > > > > > >this kind, the meaning of $ is dependent=20  on the data
> > > > type into
> > > > > > >which it is assigned or to which it is=20  bound,
> > but there is
> > > > > > >already precedent for that in the various=20  
> coercion rules.
> > > > > > >=20
> > > > > > > I recommended that we avoid this problem altogether for
> > > > > now=20  and
> > > > > > >not allow $ to be assigned to a variable or passed
> > as=20  actual
> > > > > > >argument expression to a typed formal argument.  I=20
> > > > recommended
> > > > > > >that Lisa change the example to pass $ to a=20
> > context formal
> > > > > > >argument.
> > > > > > >=20
> > > > > > > J.H.
> > > > > > >=20
> > > > > > > > X-Authentication-Warning: server.eda-stds.org: 
> > majordom set=20
> > > > > > > sender to=20
> > > > > > > > owner-sv-ac@eda.org using -f
> > > > > > > > X-ExtLoop1: 1
> > > > > > > > X-IronPort-AV: E=3DSophos;i=3D"4.19,269,1183359600";=20
> > > > > > > >    d=3D"scan'208";a=3D"118117813"
> > > > > > > > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > > > > > > > Content-class: urn:content-classes:message
> > > > > > > > Date: Thu, 16 Aug 2007 09:15:58 +0300 
> X-MS-Has-Attach:=20 
> > > > > > > > X-MS-TNEF-Correlator:=20
> > > > > > > > Thread-Topic: [sv-ac] call to vote on 1549
> > > > > > > > Thread-Index: =
> > > > > > AcfeiQ52OKcMoqhRQC+dKxDIPbJwOwADZVDwABotlYAAMwPDUA=3D=3D
> > > > > > > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > > > > > > Cc: <sv-ac@eda-stds.org>
> > > > > > > > X-OriginalArrivalTime: 16 Aug 2007 
> 06:15:59.0713 (UTC)=20 
> > > > > > > >FILETIME=3D[EA184510:01C7DFCC]
> > > > > > > > X-eda.org-MailScanner: Found to be clean, Found
> > to be clean
> > > > > > > > X-Spam-Status: No, No
> > > > > > > > X-MIME-Autoconverted: from quoted-printable to 
> 8bit by=20 
> > > > > > > >server.eda-stds.org id l7G6GDdJ019035
> > > > > > > > Sender: owner-sv-ac@eda.org
> > > > > > > > X-eda.org-MailScanner-Information: Please contact
> > the ISP for
> > > > > > > >more=20  information
> > > > > > > > X-eda.org-MailScanner-From: 
> > > > owner-sv-ac@server.eda.org =20  The
> > > > > > > >LRM states in other places restrictions on the use of
> > > > $.=20  The
> > > > > > > >question is whether the example fulfills those 
> conditions.
> > > > > > > >=20
> > > > > > > > The following quoted wording is a little unclear:=20 =20
> > > > > > > > > An actual argument can replace any of the following:
> > > > > > > > > - Identifier
> > > > > > > > > - Expression
> > > > > > > > > - Event control expression
> > > > > > > > > - Upper delay range or repetition range if 
> the actual=20
> > > > > > > argument is $
> > > > > > > >=20
> > > > > > > > "can replace" seems a little problematic here.
> > > > > > > > An actual argument cannot really replace an
> > expression. E.g.,
> > > > > > > >it=20  cannot replace a+b. It can replace a formal
> > argument
> > > > > > > >which=20
> > > > > > > is used as=20
> > > > > > > > an expression, which is a little different.
> > > > > > > >=20
> > > > > > > > And does this list cover all the possibilities,
> > or is it=20
> > > > > > > just intended=20
> > > > > > > > to be examples?
> > > > > > > >=20
> > > > > > > > And does the last item mean:
> > > > > > > > 1. If the actual argument is $, it can be used
> > only in this=20
> > > > > > > way? If it=20
> > > > > > > > is not $, can it be used in this way?
> > > > > > > > 2. It can be used in this way only if it is $? If
> > it is $,=20
> > > > > > > can it be=20
> > > > > > > > used in another way?
> > > > > 
> > > > > --
> > > > > This message has been scanned for viruses and dangerous
> > content by
> > > > > MailScanner, and is believed to be clean.
> > > > > 
> > > > > 
> > > > > --
> > > > > This message has been scanned for viruses and dangerous
> > content by
> > > > > MailScanner, and is believed to be clean.
> > > > > 
> > > > 
> > > > --
> > > > This message has been scanned for viruses and dangerous 
> content by 
> > > > MailScanner, and is believed to be clean.
> > > > 
> > > 
> > > --
> > > This message has been scanned for viruses and dangerous 
> content by 
> > > MailScanner, and is believed to be clean.
> > > 
> > > 
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, and is believed to be clean.
> > 
> > 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Aug 22 04:34:18 2007

This archive was generated by hypermail 2.1.8 : Wed Aug 22 2007 - 04:34:40 PDT