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

i've reported
http://www.verilog.org/mantis/view.php?id=4254

DANiel

On 7/11/2012 3:24 PM, Daniel Mlynek wrote:
> 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 Fri Jul 13 01:55:08 2012