RE: [sv-ec] implicit sensitivity list and class dynamic members

From: Daniel Mlynek <daniel.mlynek_at_.....>
Date: Sun Jul 26 2009 - 23:47:45 PDT
Thank you for yours responses.
My question was only "if this is allowed or not".
Case with always_comb is explictly defined in LRM but for "always @*" it is
not so obvious - maybe this could/should expressed explicitly in the text?

DANiel

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: 24 lipca 2009 20:21
To: Mark Hartoog
Cc: Daniel Mlynek; sv-ec@eda.org
Subject: Re: [sv-ec] implicit sensitivity list and class dynamic members


Mark,

always_comb addresses the class method side directly in the text I quoted so
I don't think virtual comes into play -- you don't impact the sensitivity
list with a virtual method call either.

I view the "write rule" for always_comb as being tied to the sensitivity
lists -- if we ignore methods and class objects for sensitivity, I think
they should also be ignored for the "write rule".

Gord.



Mark Hartoog wrote:
> I agree with Gord's interpretation that class objects, class methods and
class properties do not add to the sensitivity list of always_comb or @(*).
> 
> If Daniel's question is should the LRM be changed to allow this, there are
a number of issues to consider.
> 
> Always_comb sensitivity lists include sensitivities from functions called
from the always_comb. Since class methods can be virtual, there is no way to
do this for virtual class methods.
> 
> Always_comb also says it is an error for multiple always_comb to write to
the same variable. The aliasing problem with class handles makes it very
difficult to do this check for class fields.
> 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Gordon Vreugdenhil
> Sent: Friday, July 24, 2009 6:49 AM
> To: Daniel Mlynek
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] implicit sensitivity list and class dynamic 
> members
> 
> Daniel,
> 
> 9.2.2.2.1 explicitly deals with always_comb:
>     References to class objects and method calls of class objects do
>     not add anything to the sensitivity list of an always_comb.
> 
> 9.2.2.2.2 (on @(*)) is less clear although it claims that
>     The SystemVerilog always_comb procedure differs from
>     always @* (see 9.4.2.2) in the following ways:
>        ...
> 
> Whether @(*) is sensitive to class refs was never explicitly addressed 
> in the LRM, but it would be reasonable to interpret the lack of 
> comment about classes in 9.2.2.2.2 to imply that
> @(*) should be sensitized to class references either.
> 
> Gord.
> 
> Daniel Mlynek wrote:
>> I've a question related to implicit sensitivity list (@*, always_comb).
>> This feature was assumed to help users in design code - for 
>> combinatorial blocks. But in blocks under @* or always_comb also 
>> references to dynamic class members can be used - as in below code.
>> Should such references be added to implicit sensitivity list>
>>
>>     class class0;
>>      int x;
>>     endclass
>>
>>     module top_006;
>>      class0 c0 = new;
>>      class0 c1 = new;
>>
>>      initial begin
>>         #10 c0.x = 1;
>>         #10 c0.x = 0;
>>         #10 c0.x = 1;
>>         #10 c0 = c1;
>>      end
>>      always@* $display($time, c0.x);        //should this be sensitive
>>     to c0.x?
>>     endmodule
>>
>> DANiel
>>
>> --
>> This message has been scanned for viruses and dangerous content by 
>> *MailScanner* <http://www.mailscanner.info/>, and is believed to be 
>> clean.
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Jul 26 23:51:24 2009

This archive was generated by hypermail 2.1.8 : Sun Jul 26 2009 - 23:52:25 PDT