John, >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. Another option would be to modify Footnote A.10.21 so that it no longer foils your ability to get $ as a primary. -- Brad -----Original Message----- From: John Havlicek [mailto:john.havlicek@freescale.com] Sent: Monday, August 20, 2007 6:21 AM To: shalom.bresticker@intel.com Cc: Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org Subject: 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.Received on Mon, 20 Aug 2007 08:23:15 -0700
This archive was generated by hypermail 2.1.8 : Mon Aug 20 2007 - 08:24:37 PDT