Re: [sv-ec] class dynamic member as $monitor argument

I think hat there are few possibilities here but I cannot see LRM
statements which explains which one should be in power for $monitor
The only clearly forbidden thing is that automatic variables cannot be
monitored.

For dynamic class members we have three options:
- the one you are saying is ok so to allow to monitor "static hierarchy"
- <handle>.<member> in this case when handle goes to null then monitor
should tigger fatal error - null pointer reference
- allow to monitor all dynamic variables in this case $monitor(hnd.a);
will monitor the value of a in object pointed by hnd even if hnd
changes it will monitor the same <object>.a ( so there will be no null
pointer erference error never but also object cannot be removed buy
garbage collector)
- explicitly forbid dynamic variables monitoring

IMHO forbidding it is the best solution.

LRM is also not clear but I assume that this is legal to monitor all
kind of types (singular, aggregate)

DANiel

On 7/10/2012 4:42 PM, Gordon Vreugdenhil wrote:
>
> $monitor semantics are pretty well defined and the state of the
> dynamic variable at the time the $monitor is evaluated is what is
> going to be used.
>
> What I would argue is that in "foo", your reference to "a" really
> doesn't count as a static reference. That isn't stated clearly in the
> LRM, but the key assumption for "static" access is that there is a
> "hierarchical" anchor for the static -- things after that might be
> selects, etc. but there must be an anchor in the static hierarchy. In
> this case, the reference to "a" is not a static. That makes the
> $monitor illegal in this context. If however, you had:
> initial $monitor($time, c.a);
> in "top", that would be fine.
>
> So it really isn't the "dynamic" aspect of the class instance, it is
> the fact that you don't have a "static" anchor for the reference that
> causes the problem.
>
> Gord.
>
> On 7/10/2012 1:25 AM, Daniel Mlynek wrote:
>> LRM does not say explicitly what can be used as argument to $monitor
>> task There are some controversial cases - ie dynamic arrays, dynamic
>> arrays items, class dynamic member
>> Consider the case:
>>
>> class C;
>> int a;
>> function void foo;
>> $monitor ($time, a);
>> endfunction
>>
>> endclass
>> module top;
>> C c=new;
>>
>> initial begin;
>> c.foo();
>> #1
>> c.a++;
>> #1
>> c.a++;
>> #1;
>> end
>>
>> endmodule
>>
>>
>> is it legal. IMHO LRM should be explicit. Now LRM disallows for
>> monitor only local automatic variables - so one cas assume that all
>> but aoutomatic variables are ok
>>
>> DANiel
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics)gordonv@model.com
>
>
Received on Wed Jul 11 06:25:00 2012