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

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<http://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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto:danielm@aldec.com>>
> To: "'Bresticker, Shalom'" <shalom.bresticker@intel.com<mailto:shalom.bresticker@intel.com>>,
>          <ben@systemverilog.us<mailto:ben@systemverilog.us>>, <sv-ac@eda.org<mailto: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> [mailto: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<mailto:ben@systemverilog.us>; sv-ac@eda.org<mailto: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> [mailto: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<mailto: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.