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

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=18
171#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.