RE: [sv-ac] AC 196:

Ed,

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]On Behalf Of Eduard Cerny
Sent: Tuesday, November 16, 2004 8:21 PM
To: Miller Hillel-R53776; 'Eduard.Cerny@synopsys.com'; sv-ac@eda.org
Subject: RE: [sv-ac] AC 196:

Hi Hillel,

a few more questions as I am not clear that I undesrtand:
- in my comments I rferred to the text as it exists on the web, this is why
some comments may seem not pertinent, e.g., optional type spec.

HM: Ok.

- by value: You say "The value is the value of the evaluated "actual
> expression" at the clock tick that sequence/property are activated."
But the property can be viewed as activated on the first clock tick (due to
implicit always) or on every clock tick that it is activated.

HM: Correct. If it is activated at every clock tick it will recieve an updated value every clock tick.
This is the same behavior as in SV tasks when passing by value. Everytime the task is called
by values's get updated.

- by ref: are the values also sampled if used in a boolean expr in the
sequence? How different is it then from the passing by value? Should these
be aligned with what covergroups are doing?

HM: The values are updated every time the formal parameter is observed within the sequence/property.
This is the same behavior you get in SV tasks with ref variables. Could you send me an example with
const ref's in covergroups?

Best regards,

ed

> -----Original Message-----
> From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
> Sent: Tuesday, November 16, 2004 12:43 PM
> To: 'Eduard.Cerny@synopsys.com'; 'sv-ac@eda.org'
> Cc: Miller Hillel-R53776
> Subject: RE: [sv-ac] AC 196:
>
> Ed,
>
> Comments inside.
>
> Thanks
> Hillel
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]On
> Behalf Of Eduard Cerny
> Sent: Friday, November 12, 2004 11:38 PM
> To: Sv_Ac
> Cc: Eduard Cerny
> Subject: [sv-ac] AC 196:
>
>
> Hello Hillel,
>
> - the proposal should make the type spec optional.
>
> HM: This is required to stay backward compatible. I do not
> think it is preffered.
>
> - if specified, it should be from only the existing types
> that are allowed for expressions in concurrent assertions.
>
> HM: Correct.
>
> - if passed by value, e.g., int x, what is the value? Is the
> one at the first clock tick of every eval. attempt, the value
> at time 0, other?
>
> HM: The value is the value of the evaluated "actual
> expression" at the clock tick that sequence/property are activated.
>
> - if passed by reference, e.g., ref int x, I would suppose
> that if used in expressions it will be the value sampled at
> each clock tick or the immediate value if used in disable
> iff? It can be read and written.
>
> HM: The formal parameter recieves that value of the
> respective evaluated "actual expression" at the clock tick
> that the formal parameter is observed. With disable iff, it
> is the same, the "actual expression" continues to be
> evaluated throughout the property evaluation.
> That is the immeadiate value is not the one used.
> The initial proposal will not include writing to parameters
> that have data types on them.
> - if specified as const ref, it should only allow reading.
>
> HM: The initial proposal will not include writing to
> parameters that have data types on them. Therefore 'ref' and
> 'const ref' will have the same behavior.
>
> - if passed by ref, is it possible to assign the variable in
> the sequence even if it is not a local variable of a sequence
> / property? E.g., an external variable to the assertions (I
> would like that...)
>
> HM: The initial proposal will not include writing to
> parameters that have data types on them.
>
> - if the type is optional, then it seems that the changed BNF
> would have tf_port_list instead of list_of_formals. I suppose
> the type is optional because in the "implicit" form the
> "packed_dimension" is optional {}.
> Correct?
>
> HM: The proposal requires "tf_port_list_for_assertions",
> however in this case the optional type is what exist today.
> The new proposal will need a BNF definition which steals from
> the tf_port_list definition what is needed and leaves
> non-type parameters with the same behavior as before.
>
>
> Best regards,
> ed
>
>
Received on Tue Nov 16 10:29:51 2004