Thanks -----Original Message----- From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Thursday, October 05, 2006 2:36 PM To: Korchemny, Dmitry; Kulshrestha, Manisha Cc: sv-ac@eda-stds.org Subject: RE: [sv-ac] RE: minor comments on 1549 BTW the 3rd rule has been dropped as it causes problems. ed > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of Korchemny, Dmitry > Sent: Thursday, October 05, 2006 7:56 AM > To: Kulshrestha, Manisha > Cc: sv-ac@eda-stds.org > Subject: RE: [sv-ac] RE: minor comments on 1549 > > Hi Manisha, > > I meant the following: > > RESTRICTION 4: For every recursive instance of property q in the > declaration of property p, each > actual argument expression e of the instance satisfies at least one of > the following conditions: > - e is itself a formal argument of p. > - No formal argument of p appears in e. > - e is passed to a formal argument of q that is typed and the set of > values for the type is bounded. > > that is in some cases you must specify the argument type of the > property. I remember that there was a discussion about the last case, > and it may have become not legal anymore. If so, my comment is not > relevant. > > Thanks, > Dmitry > > -----Original Message----- > From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] > Sent: Wednesday, October 04, 2006 8:36 PM > To: Korchemny, Dmitry > Cc: sv-ac@server.eda-stds.org > Subject: RE: [sv-ac] RE: minor comments on 1549 > > Hi Dimitry, > > I do not understand your statement below (from your previous email): > > Another thing, for recursive properties the explicit typing is > compulsory. > > I do not think there is any such restriction ?? > > Thanks. > Manisha > > -----Original Message----- > From: John Havlicek [mailto:john.havlicek@freescale.com] > Sent: Monday, September 11, 2006 3:37 PM > To: Korchemny, Dmitry > Cc: Arturo.Salz@synopsys.com; john.havlicek@freescale.com; > piper@cadence.com; sv-ac@eda-stds.org > Subject: Re: [sv-ac] RE: minor comments on 1549 > > Hi Dmitry: > > I don't understand your point clearly. > > Are you saying that the users would rather have wrappers > whose arguments > have no types than to instantiate properties with separate parameter > lists? > > It seems that if this is true, then the library developers for these > customers should simply not use argument types. > > J.H. > > > X-ExtLoop1: 1 > > X-IronPort-AV: i="4.08,224,1154934000"; > > d="scan'208"; a="122464533:sNHT7001764896" > > X-MimeOLE: Produced By Microsoft Exchange V6.5 > > Content-class: urn:content-classes:message > > Date: Thu, 7 Sep 2006 13:57:21 +0300 > > X-MS-Has-Attach: > > X-MS-TNEF-Correlator: > > Thread-Topic: [sv-ac] RE: minor comments on 1549 > > Thread-Index: AcbQ6x7G/ThvDacgR4qLtTc8ukYs2AAHtQKwAFfk6pA= > > From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com> > > Cc: <piper@cadence.com>, <sv-ac@eda-stds.org> > > X-OriginalArrivalTime: 07 Sep 2006 10:57:57.0932 (UTC) > FILETIME=[7A735EC0:01C6D26C] > > > > Hi Arturo, > > > > Using parameters is indeed consistent with other SV areas, but the > > property usage becomes more difficult: the end-users will have to > > distinguish between parameters and ports. E.g. instead of writing > > > > assert property (triggers(.cond(a), .impl(b), .delay(c)); > > > > The user will have to write: > > > > assert property (triggers#(.delay(c))(.cond(a), .impl(b)); > > > > For the end-user the first form is more intuitive. > Therefore when in > > this approach the library properties will always have > wrappers. E.g., > > > > property triggers(cond, impl, delay); > > lib_triggers#(delay)(cond, impl); > > endproperty > > > > property lib_triggers#(shortint delay =3D 1) (cond, impl); > > a |-> ##delay b; > > endproperty > > > > Using const would save one wrapper. > > > > Regards, > > Dmitry > > > > -----Original Message----- > > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] > On > > Behalf Of Arturo Salz > > Sent: Tuesday, September 05, 2006 8:03 PM > > To: john.havlicek@freescale.com; Arturo.Salz@synopsys.com > > Cc: piper@cadence.com; sv-ac@server.eda-stds.org > > Subject: RE: [sv-ac] RE: minor comments on 1549 > > > > Hi John, > > > > I believe the use of parameters is most consistent. Using > parameters > > would provide properties with the same abstraction mechanism as > classes > > - SV parameterized classes are equivalent to C++ template classes. > > Because properties are instantiated, I believe parameters > will be less > > > confusing. I would envision something like: > > > > sequence SEQ #( shortint delay1 =3D 1, int delay2 =3D 2, int min > =3D = > > 0, int > > max =3D 1 ); > > x ##delay1 y[*min:max] ##delay2 z; > > endsequence > > =20 > > cover property SEQ#( 2, 2, 3 $ ); > > OR > > cover property SEQ#( `my_delay, `my_delay - 1, ... ); > > > > This makes it very clear that the parameters are all elaboration > > constants that affect the "shape" and "size" of the > property, and not > a > > procedural variable. > > > > BTW, this mechanism would allow users to create generic properties > whose > > types are parameters, as for example: > > > > property foo #(type T =3D logic, int delay =3D 5 ); > > T localv; > > (x, localv =3D in_v) |-> ## delay (out_v =3D=3D localv); > > endproperty > > > > typedef struct packed { ... } xyz; > > > > assert foo#( xyz ); > > > > I believe this is closer to the intent. > > > > Arturo > > > > -----Original Message----- > > From: John Havlicek [mailto:john.havlicek@freescale.com]=20 > > Sent: Tuesday, September 05, 2006 5:59 AM > > To: Arturo.Salz@synopsys.COM > > Cc: piper@cadence.com; john.havlicek@freescale.com; > sv-ac@eda-stds.org > > Subject: Re: [sv-ac] RE: minor comments on 1549 > > > > Hi Arturo: > > > > I agree that the suggested use of const to indicate a compile-time > > constant is not consistent with its use elsewhere. > > > > However, I would like to see the argument types in sequence and > > property declarations do a better job of telling the > instantiator of > > the sequence or property what actual argument expressions are legal. > > > > I see several alternatives: > > > > 1. Use const as suggested and accept the inconsistency in exchange > > for avoiding a new keyword. > > > > 2. Find a different keyword than const. > > > > 3. Introduce parameters to the sequence and property constructs. > > > > Which of these looks best to you? > > > > J.H. > > > > > X-MimeOLE: Produced By Microsoft Exchange V6.5 > > > Content-class: urn:content-classes:message > > > Date: Thu, 31 Aug 2006 13:05:09 -0400 X-MS-Has-Attach:=20 > > > X-MS-TNEF-Correlator:=20 > > > Thread-Topic: [sv-ac] RE: minor comments on 1549 > > > Thread-Index: > AcbLdwtjqYEYUGn2SqKZT7bT6rwKsQA9K3kAACrmukAAARefUA=3D=3D > > > From: "Lisa Piper" <piper@cadence.com> > > > X-Received: By mx-sanjose2.Cadence.COM as k7VH5DZ5008925 > at Thu Aug > 31 > > 10:05:14 2006 > > > X-OriginalArrivalTime: 31 Aug 2006 17:05:20.0905 (UTC) > > FILETIME=3D[A431DF90:01C6CD1F] > > >=20 > > > This is a multi-part message in MIME format. > > >=20 > > > ------_=3D_NextPart_001_01C6CD1F.A54FD2AF > > > Content-Type: text/plain; > > > charset=3D"us-ascii" > > > Content-Transfer-Encoding: quoted-printable =20 =3D20 =20 =3D20 > > >=20 ________________________________ =20 > > > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]=3D20 > > > Sent: Thursday, August 31, 2006 12:32 PM > > > To: Lisa Piper; john.havlicek@freescale.com; sv-ac@eda-stds.org > > > Subject: RE: [sv-ac] RE: minor comments on 1549 =20 > =3D20 =20 This > > > >proposal seems inconsistent with the general meaning of const > in > > > the rest of the language: A const declaration is computed after > > > elaboration and what I believe you want here is to have the > semantics > > of > > > a parameter.=3D20 > > >=20 > > > Wouldn't it be simpler to trigger an error when the delay or > > repetition > > > argument was not an elaboration time constant - the desired > semantics > > - > > > rather than require users to specify this additional check using a > > const > > > modifier?=3D20 > > >=20 > > > [Lisa Piper >>>] the intent is that you can provide the > interface to > a > > > user and they will know that this needs to be a constant. This > would > > > help, for example, the user of a property library that does not > know > > > SVA real well. > > >=20 > > > I don't understand what it means when you say "this is strongly > > >recommended for all parameters". Since a property is > instantiated at > > > >elaboration time, how could the parameters be anything other than > > >constants? Surely they cannot be depend on procedural code. > > >=20 > > > [Lisa Piper >>>] The tool would give an error regardless so it is > not > > > required, just recommended to help the user =20 =3D20 =20 Also, > > >there is a slight mistake in the example: It should be (the = > > =3D3D > > =3D > > > and > > > ; are incorrect): `define my_delay 2 =20 [Lisa Piper >>>] oops! > > >Thanks! > > >=20 > > > =3D20 > > >=20 > > > Arturo > > >=20 > > > =3D20 > > >=20 > > > ________________________________ > > >=20 > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of > > Lisa > > > Piper > > > Sent: Thursday, August 31, 2006 8:50 AM > > > To: john.havlicek@freescale.com; sv-ac@eda-stds.org > > > Subject: [sv-ac] RE: minor comments on 1549 =20 =3D20 > =20 I have > > >changed the new types proposal as suggested by John with the > > >exception of the comment about passing delay and repetition values > as > > > compile time constants. Would people object to my adding the > > following > > > to this proposal (versus making it a separate standalone > proposal). > > > There may be other qualifiers that are desired too but they will > > likely > > > need more discussion. I think this an obvious one though that is > very > > > important. > > >=20 > > > =3D20 > > >=20 > > > In essence, I would state: > > >=20 > > > =3D20 > > >=20 > > > A const qualifier may appear in front of any type as a way of > > specifying > > > that the argument must be statically computable at compile time. > This > > > is strongly recommended for all parameters that will be used for > delay > > > or repetition values. If const is used without a specific type, > then > > > the type is implicit.=3D20 > > >=20 > > > =3D20 > > >=20 > > > Any integer type can be used to pass delay and repetition values. > For > > > example, two equivalent ways of passing delay and repetition > arguments > > > are shown below: > > >=20 > > > =3D20 > > >=20 > > > sequence delay_arg_example ( const shortint delay1, > > delay2, > > > min, max); > > >=20 > > > x ##delay1 y[*min:max] ##delay2 z; > > >=20 > > > endsequence > > >=20 > > > =3D20 > > >=20 > > > `define my_delay=3D3D2; > > >=20 > > > cover property ( delay_arg_example ( `my_delay, > > `my_delay-1, > > > 3, $) ); > > >=20 > > > =3D20 > > >=20 > > > which is equivalent to: > > >=20 > > > =3D20 > > >=20 > > > cover property ( x ##2 y[*3:$] ##1 z); > > >=20 > > > =3D20 > > >=20 > > > =3D20 > > >=20 > > > Of course I'd have to update the BNF too. > > >=20 > > > =3D20 > > >=20 > > > Lisa > > >=20 > > > =3D20 > > >=20 > > > =3D20 > > >=20 > > > -----Original Message----- > > > From: John Havlicek [mailto:john.havlicek@freescale.com]=3D20 > > > Sent: Tuesday, August 29, 2006 10:26 AM > > > To: Lisa Piper > > > Cc: sv-ac@eda-stds.org > > > Subject: minor comments on 1549 > > >=20 > > > =3D20 > > >=20 > > > Hi Lisa: > > >=20 > > > =3D20 > > >=20 > > > Below are a few minor comments (mostly editorial) on 1549. > > >=20 > > > =3D20 > > >=20 > > > J.H. > > >=20 > > > =3D20 > > >=20 > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3 > D3D=3D3D=3 > D= > > 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > =3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3 > D3D=3D3D=3 > D= > > 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > =3D3D=3D > > > = > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3 > D3D=3D3D=3 > D= > > 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > =3D3D=3D3D > > >=20 > > > =3D20 > > >=20 > > > - p. 3, 17.6.1 change. I am confused by the use of "data type" in > the > > > context=3D20 > > >=20 > > > of=3D20 > > >=20 > > > =3D20 > > >=20 > > > "The supported data types for sequence formal > arguments are the > > > >types that =20 > > > are allowed for operands in assertion expressions (see > 17.4.1)." > > >=20 > > > =3D20 > > >=20 > > > This suggests that the additional types "sequence" and > "implicit" > > are > > > not=3D20 > > >=20 > > > data types. However, later on p. 6 there is the statement =20 > > >=3D20 =20 > > > "The supported data types for property formal > arguments include > > all > > > the=3D20 > > >=20 > > > types allowed for sequences plus the addition of > the property > > > >type." > > >=20 > > > =3D20 > > >=20 > > > This suggests that all the sequence types are considered data > types. > > >=20 > > > [Lisa Piper >>>] good catch. I will change the latter to > :=3D20 =20 > > > >=3D20 =20 > > > "The supported data types for property formal arguments > include > > > all the=3D20 > > >=20 > > > types allowed for sequences plus the addition of > the property > > > >type." > > >=20 > > > =3D20 > > >=20 > > > - Top of p. 4: =3D20 > > >=20 > > > =3D20 > > >=20 > > > "For example, three equivalent ways of passing > arguments ..." = > > =3D20 > > >=20 > > > =3D20 > > >=20 > > > I am a bit concerned with saying that these three are > equivalent. > > >=20 > > > They are not equivalent when the assignment rules for binding > actual > > >=20 > > > arguments to typed formal arguments are taken into > account. I =20 > > > prefer to say > > >=20 > > > =3D20 > > >=20 > > > "For example, three similar ways of passing arguments ..." > > >=20 > > > [Lisa Piper >>>] good point - done > > >=20 > > > =3D20 > > >=20 > > > Ways 2 and 3 really are equivalent. > > >=20 > > > =3D20 > > >=20 > > > - p. 4. Doron has written a separate comment about passing delay > and > > > repetition=3D20 > > >=20 > > > values to integer types with constant qualifier. I > think at this > > time > > > we should=3D20 > > >=20 > > > at least review the vision for this sort of argument passing. > > >=20 > > > . As Doron points out, it will be nice to specify that > the formal > > > >argument is=3D20 =20 > > > for a compile-time constant expression since it is used in a > delay > > >=20 > > > or range value. > > >=20 > > > . Using integer types means that we impose the assignment rules > > of=3D20 > > >=20 > > > binding actual arguments to typed formal arguments. > > >=20 > > > . I think we have understood that there is an exception to the > > >assignment =20 > > > rule for binding when the actual argument is $. > > >=20 > > > =3D20 > > >=20 > > > - p. 5. I would change > > >=20 > > > =3D20 > > >=20 > > > "If the intent is to pass only the name of the signal of an > > >event_expression ..." > > >=20 > > > =3D20 > > >=20 > > > to=3D20 > > >=20 > > > =3D20 > > >=20 > > > "If the intent is to pass a signal that is not an entire > > >event_expression ..." > > >=20 > > > [Lisa Piper >>>] done > > >=20 > > > =3D20 > > >=20 > > > - p. 5. In the example with sequence foo, operator associativity > > makes > > > the=3D20 > > >=20 > > > implicit parenthesization like this: > > >=20 > > > =3D20 > > >=20 > > > ( (1'b1, loc_a =3D3D a) ##0 (t =3D3D=3D3D > loc_a)[*0:$] ) ##1 b > > >=20 =3D20 =20 > > > and so the [*0:$] cannot match 0 times due to the ##0 > fusion. I > > >recommend=3D20 =20 changing [*0:$] to [*1:$]. > > >=20 > > > [Lisa Piper >>>] done > > >=20 > > > =3D20 > > >=20 > > >=20 > >Received on Thu Oct 5 05:47:28 2006
This archive was generated by hypermail 2.1.8 : Thu Oct 05 2006 - 05:47:43 PDT