Re: [sv-bc] 2097 comments/thoughts

>Date: Tue, 15 Jan 2008 08:15:18 -0800
>From: Gordon Vreugdenhil <gordonv@model.com>

>> However, the OO conceptual model is that it is part of the class
>> aggregate object.  It seems to me that this more relevant to the
>> issue than the implementation detains.
>
>I don't really agree with this view.  The LRM is avoiding
>issues with forcing of *dynamic* values.  A class static
>doesn't have that problem

I agree that a static property of a class is not dynamic, so
the prohibition on forcing dynamic variables would not apply.
However, it IS part of a larger aggregate variable, so the
prohibition on forcing part of a variable would apply.

>and given that in all other
>scenarios at least a reference of the form class_name::static_var
>is treated in the same manner as a normal variable, it seems
>strange to me that the procedural continuous assignments
>would be an exception.

Are there any of these scenarios in which a reference to a static
property acts like a normal variable, in which a reference to an
static unpacked struct member does not also act like a normal
variable?


>By the way, on a related issue, is it valid to force a variable in an
>interface instance when referenced by way of a virtual interface?
>The LRM explicitly says that procedural assignments are valid and that
>continuous assignments are not.  What are procedural continuous
>assignments?  My expectation here is that the "continuous" aspect
>is the dominant consideration and thus such forces should likely
>be illegal.

I would also expect it to be illegal.  Note that a net force may be done
to an lvalue that is a constant bit-selects or array select.  However,
it shall not be done to variable bit-selects or array selects.  The
part of a net affected by a force is fixed at elaboration time, and cannot
change with the value of a runtime variable.  A reference through a
virtual interface would similarly use the value of a runtime variable to
select what is being affected, and should therefore be illegal.


Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.