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

The LRM says this about explicit events

Changing the value of object data members, aggregate elements, or the
size of a dynamically sized array referenced by a method or function
shall cause the event expression to be reevaluated. An implementation
can cause the event expression to be reevaluated when changing the value
or size even if the members are not referenced by the method or
function.


Repeating Gordon's comment, it says nothing about implicit events.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Stuart Sutherland
> Sent: Friday, July 24, 2009 1:03 PM
> To: 'Mark Hartoog'; Vreugdenhil, Gordon
> Cc: 'Daniel Mlynek'; sv-ec@server.eda.org
> Subject: RE: [sv-ec] implicit sensitivity list and class dynamic
members
> 
> What about continuous assignments?  Will the assignment update on a
call to
> a method function.  For example (not in full context):
> 
> mailbox foo = new;
> assign empty == (foo.num() == 0);
>
> Stu
> ~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> (503) 692-0898
> 
> 
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Mark
> > Hartoog
> > Sent: Friday, July 24, 2009 11:25 AM
> > To: Gordon Vreugdenhil; Mark Hartoog
> > Cc: Daniel Mlynek; sv-ec@eda.org
> > Subject: RE: [sv-ec] implicit sensitivity list and class dynamic
members
> >
> > I agree with you.
> >
> > Daniel's question was "Should such references be added to implicit
> > sensitivity list?"
> >
> > I was just pointing out that if Daniel was asking if the LRM should
be
> > changed to allow this, there are some problems with doing it.
> >
> > -----Original Message-----
> > From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> > Sent: Friday, July 24, 2009 11:21 AM
> > 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.
> 
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.


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