RE: [sv-ac] AC 196:

Hi Hillel,

by value vs ref - this means that for variables in bool expr in sequences
the two would be equivalent, right? Sampled in preponed region?
For the covergroup,

covergroup cg (int x, ref int y) @(clk);
   coverpoint x;
   coverpoint y;
endgroup

as far as I know (na dhave tried), coverpoint x would sample the value when
the group is created using new(), while coverpoint y would be getting a new
value each time the sampling clock triggers.

ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> Behalf Of Miller Hillel-R53776
> Sent: Tuesday, November 16, 2004 1:30 PM
> To: 'Eduard.Cerny@synopsys.com'; sv-ac@eda.org
> Cc: Miller Hillel-R53776
> Subject: 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:41:46 2004