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, and is
believed to be clean.