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.

- 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.

- 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?

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:20:00 2004