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.