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 Mon Aug 20 06:25:49 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 20 2007 - 06:26:00 PDT