Re: [sv-ac] automatic variiables in clock expr // virtual interface

Dave,
I filed Mantis 0003120 "expect" construct to refer to virtual interfaces
It would be nice if we could incorporate this into our discussions and
changes. Even though it is major, the level of difficulty is light, as most
of us would agree that, in view of UVM stadardization by Accellera, it is
important that the *expect *can refer to automatic variables as well as
static variables and virtual interfaces. Should this be "dynamic variables"
instead?
Note that one vendor is already (incorrectly(?)) implementing this; See
http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=18184#18184

On Fri, Jun 18, 2010 at 10:45 AM, Rich, Dave <Dave_Rich@mentor.com> wrote:

> Ben,
>
>
>
> This is exactly the kind of issue that needs to be addressed in this go
> around of the standard. We need to spend the time and make sure the existing
> constructs are clarified and made useful before adding more enhancements.
>
>
>
> There are two key reasons references to dynamic variables were prohibited
> outside of procedural contexts.
>
>
>
> The first reason was time 0 initialization. It’s too easy to create an
> expression that would reference a null handle, and too difficult to define
> an initialization ordering that would prevent handles from being null when
> referenced. The expect statement is a special case of a non-procedural
> construct not effected by time 0, but I would not make an exception because
> of that. We now have short-circuit operators defined to guard against null
> references, as well as a lot more user experience to make this reason go
> away and make it user-beware.
>
>
>
> The second reason, and the one needing more clarification, is the behavior
> of changing the dynamic reference, especially in the context of sampled
> values. I know that the OVM use model is to set a virtual interface variable
> once and never change it, but the LRM usage is more general. Some
> implementations may have gotten that use model working, but ignored the
> other cases. The problem arises when we try to standardize the behavior of
> those ignored cases and everyone has gone off in different implementation
> directions.
>
>
>
> Dave
>
>
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Wednesday, June 16, 2010 6:18 PM
> *To:* Eduard Cerny
> *Cc:* Rich, Dave; neil.korpusik@oracle.com; danielm; sv-ac@server.eda.org
>
> *Subject:* Re: [sv-ac] automatic variiables in clock expr // virtual
> interface
>
>
>
> Ed,
>
> Thanks for the explanation. It might be too late to make any changes on
> this go around, however, I just want to state that it is important that
> the "expect" construct can refer to dynamic variables. This is because the
> virtual interface is embedded in the OVM, VMM, UVM methodology. Consider an
> OVM/VMM/UVM driver or monitor that uses a virtual interface. Before making
> a decision to drive or to check for monitoring a condition, it is necessary
> to wait until properties of the virtual interface signals.
>
> Otherwise, the "expect" is really useless in the design of testbenches
> with OVM/VMM/UVM.
>
> Ben Cohen
>
>
>
>
>
> On Wed, Jun 16, 2010 at 5:50 PM, Eduard Cerny <Eduard.Cerny@synopsys.com>
> wrote:
>
> Hi Ben, I think that we should go by the LRM and not by what a simulator
> supports. The LRM is quite clear.
>
> The *expect *statement can be incorporated in any procedural code,
> including tasks or class methods.
>
> Because it is a blocking statement, the property can refer to automatic
> variables as well as static variables.
>
> There is no mention of dynamic variables, such as virtual interfaces that
> can be reassigned. Or do I misinterpret it?
>
>
>
> best regards,
>
> ed
>
>
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *ben
> cohen
> *Sent:* Wednesday, June 16, 2010 7:22 PM
> *To:* Rich, Dave
> *Cc:* neil.korpusik@oracle.com; sv-ac@server.eda.org; danielm
> *Subject:* Re: [sv-ac] automatic variiables in clock expr // virtual
> interface
>
>
>
> Attached is a file of a test model that failed in one simulator.
>
> ** Fatal: .. expect.sv(20):Incorrect use of virtual interface object
> "/test/test_class::run_c/this*.f_if.a" in assertion expression.
>
> The code in question is
>
> task run_c();
>
> ex <=0;
>
> expect ( @(posedge clk) f_if.a |-> ##2 !f_if.a);
>
> if(f_if.a) $display("f_if.a= %b", f_if.a);
>
> ex <= 1'b1;
>
> endtask
>
> Commenting out the expect line causes the model to run OK.
>
> Questions:
>
> 1) why is " expect ( @(posedge clk) f_if.a |-> ##2 !f_if.a);" illegal?
>
> 2) If I cannot reference an object of a virtual interface in a class with
> the "expect" construct, then the use of the "expect" in a class is pretty
> much useless for applications like VMM, OVM, or UVM.
>
> 3) I understand that one simulator accepted this form.
>
> 4) Can someone try the model in other simulators and report the results.
> We do not need to know the name of the simulator.
>
> Thanks,
>
> Ben
>
>
>
>
>
> On Wed, Jun 16, 2010 at 11:22 AM, ben cohen <hdlcohen@gmail.com> wrote:
>
> Sorry to push this issue, but it seems that 2 vendors implement this
> differently + if the virtual interface signals cannot be referenced in an
> expect, the expect is almost useless. Specifically:
>
> class test_class;
> virtual test_if tf;
> task run_c();
> expect ( @(posedge clk) tf.a |-> ##2 !tf.a); // <-- ******
> endtask
>
>
> I understand that this is illegal. I don't understand why.
>
> Also, from
> http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=18171#18171
>
> class ---
> ---
> task run_c();
> expect ( @(posedge tf.clk) tf.a |-> ##2 !tf.a);
> endtask
> ----
> endclass
>
> That run OK on one simulator.
>
> So what's the story and the rational for either answer, legal or illegal?
>
> Ben
>
> On Mon, Jun 14, 2010 at 11:34 PM, Rich, Dave <Dave_Rich@mentor.com> wrote:
>
> Daniel,
>
> I believe the intent of the rule was: These components *shall* only be
> used in procedural statements. period.
>
> A continuous assignment is not a procedural statement; the statements
> within an always block are procedural.
>
> The rule was mainly to avoid null virtual interface references at
> start-up time, as well as performance penalties for having dynamic
> sensitivity lists.
>
> Dave
>
>
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
>
> Neil
> > Korpusik
> > Sent: Monday, June 14, 2010 5:30 PM
> > To: sv-ac@server.eda.org
> > Cc: danielm
> > Subject: RE: [sv-ac] automatic variiables in clock expr // virtual
> > interface
> >
> > <forwarding email from Daniel Mlynek>
> >
> > -------- Original Message --------
> > From: "Daniel Mlynek" <danielm@aldec.com>
> > To: "'Bresticker, Shalom'" <shalom.bresticker@intel.com>,
> > <ben@systemverilog.us>, <sv-ac@eda.org>
> > Subject: RE: [sv-ac] automatic variiables in clock expr // virtual
> > interface
> > Date: Mon, 14 Jun 2010 15:42:05 +0200
> >
> >
> > Sensitivity list is also illegal. Could someone give an example for
> > illegal
> > usage of virtual interface on sensitivity list, I see nothing wrong in
> > example:
> >
> > interface ifc;
> > logic [7:0] data;
> > bit clk;
> > initial $monitor (data);
> > initial forever #5 clk =~ clk;
> > endinterface
> >
> > module test;
> > ifc Rx();
> > virtual ifc vi=Rx ;
> > byte data1;
> > initial forever #5 data1++;
> > //assign vi.data=data1; //illegal - ok
> > always @vi.clk $display("event" ,$time); //legal???
> > initial #101 $finish;
> > endmodule
> >
> >
> > DANiel
> >
> > _____
> >
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Bresticker, Shalom
> > Sent: Monday, June 14, 2010 3:25 PM
> > To: ben@systemverilog.us; sv-ac@eda.org
> > Subject: RE: [sv-ac] automatic variiables in clock expr // virtual
> > interface
> >
> >
> > Maybe the following (25.9):
> >
> > Once a virtual interface has been initialized, all the components of
> the
> > underlying interface instance are directly available to the virtual
> > interface via the dot notation. These components can only be used in
> > procedural statements; they cannot be used in continuous assignments
> or
> > sensitivity lists.
> >
> > Shalom
> >
> >
> >
> > _____
> >
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> ben
> > cohen
> > Sent: Monday, June 14, 2010 4:17 PM
> > To: sv-ac@eda.org
> > Subject: [sv-ac] automatic variiables in clock expr // virtual
> interface
> >
> >
> > See http://verificationguild.com/modules.php?name=Forums
> >
> <http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=1
> 8
> > 142
> > #18142> &file=viewtopic&p=18142#18142
> > Lrm reference ?
> > Question is somewhat related to our upcoming discussion in interfaces
> and
> > checkers.
> > Ben
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by <http://www.mailscanner.info/> MailScanner, and
> is
> > believed to be clean.
> >
> > ---------------------------------------------------------------------
> >
> > Intel Israel (74) Limited
> >
> >
> >
> > This e-mail and any attachments may contain confidential material for
> >
> > the sole use of the intended recipient(s). Any review or distribution
> >
> > by others is strictly prohibited. If you are not the intended
> >
> > recipient, please contact the sender and delete all copies.
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by <http://www.mailscanner.info/> 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.
> >
> >
> > --
> > 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
>

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