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 09:42:37 2004