Re: [sv-ac] Fwd: sv-ac: virtual interface application example

<VHDL has sensitivity lists; Verilog does not. Verilog has event controls.>
But isn't a sensitivity list a set of signals that when an event occurs on
any of those signals they wait up a process? The always_comb or the wait have
a sensitivity list.
The VHDL LRM 10.2 IEEE Std 1076-2008 states
"The sensitivity clause defines the sensitivity set of the wait statement,
which is the set of signals to which the
wait statement is sensitive. Each signal name in the sensitivity list
identifies a given signal as a member of
the sensitivity set. Each signal name in the sensitivity list shall be a
static signal name, and each name shall
denote a signal for which reading is permitted. "

Thus, I believe that Section 20.8 is incorrect in stating says that an
interface component referenced through a virtual interface cannot be used in
a "sensitivity list". This is because it includes an example WITH an event
control @(posedge bus.grant).
Ben

On Mon, Jul 5, 2010 at 1:20 AM, Bresticker, Shalom <
shalom.bresticker@intel.com> wrote:

> See Mantis 1441 (http://www.eda-stds.org/mantis/view.php?id=1441).
>
>
>
> Shalom
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Kulshrestha,
> Manisha
> *Sent:* Monday, July 05, 2010 10:19 AM
> *To:* ben@systemverilog.us
>
> *Cc:* Eduard Cerny; sv-ac@eda.org; Korchemny, Dmitry
> *Subject:* RE: [sv-ac] Fwd: sv-ac: virtual interface application example
>
>
>
> Hi,
>
>
>
> Yes it is. I do not know what exactly they mean by sensitivity lists. I
> think LRM is not clear on this. I'll see if I can get opinion on this from
> somebody in sv-ec.
>
>
>
> Manisha
> ------------------------------
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *ben
> cohen
> *Sent:* Monday, July 05, 2010 11:32 AM
> *To:* Kulshrestha, Manisha
> *Cc:* Eduard Cerny; sv-ac@eda.org; Korchemny, Dmitry
> *Subject:* Re: [sv-ac] Fwd: sv-ac: virtual interface application example
>
> Manisha,
>
> 2. Using class variables in clock expression. Currently usage of class
> variables in clock expressions is not well defined. In your example, the
> expect needs to be explicitly clocked (it does not infer clock). We have
> seen usage of class variables in clock expressions earlier and I filed a
> mantis item (001513: LRM does not clarify if class variables can be used
> in clock expressions under SV-EC). Here is something from LRM which
> prohibits use of virtual interface in sensitivity lists. If we use virtual
> interface in the clock expression for expect, we are effectively using it
> in sensitivity list:
>
>
>
> 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
>
>
>
> [Ben] I sort of disagree that If we use virtual interface in the clock
> expression for expect, we are effectively using it in sensitivity list:, The
> LRM that you quote just says that the following is illegal:
>
> assign some_virutal_if.w = some_virutal_if.q;
>
> always (@ some_virutal_if.w) ???? Illegal But
> per LRM example ???
>
> *task wait_for_bus(); // wait for the bus to be granted*
>
> *@(posedge bus.grant); **[Ben] Isn't that a
> sensitivity list? *
>
> *endtask*
>
>
>
> Can I get some clarification as to why the LRM example *@(posedge
> bus.grant); * is legal ?
>
> Ben
>
> On Wed, Jun 23, 2010 at 1:08 AM, Kulshrestha, Manisha <
> Manisha_Kulshrestha@mentor.com> wrote:
>
> Hi Ben,
>
>
>
> There are few issues here that we need to address.
>
>
>
> 1. The virtual interface is attached to an instance of a class (or class
> object). So, different class objects (of the same class) can have different
> interface objects attached to them. Even same class object can refer to
> different virtual interfaces at different times. It is possible that in the
> middle of execution of expect (while it is waiting), the virtual interface
> object changes.
>
> Here is some text from LRM:
>
>
>
> Virtual interface variables may be passed as arguments to tasks, functions,
> or methods. A single virtual interface variable can thus represent different
> interface instances at different times throughout the simulation. A virtual
> interface shall be initialized before referencing a component of the virtual
> interface; it has the value *null *before it is initialized. Attempting to
> use a *null *virtual interface shall result in a fatal run-time error.
>
>
>
>
>
> 2. Using class variables in clock expression. Currently usage of class
> variables in clock expressions is not well defined. In your example, the
> expect needs to be explicitly clocked (it does not infer clock). We have
> seen usage of class variables in clock expressions earlier and I filed a
> mantis item (001513: LRM does not clarify if class variables can be used
> in clock expressions under SV-EC). Here is something from LRM which
> prohibits use of virtual interface in sensitivity lists. If we use virtual
> interface in the clock expression for expect, we are effectively using it in
> sensitivity list:
>
>
>
> 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.
>
>
>
> 2. Usage of automatic variables in expect. Although LRM currently allows
> usage of automatic variables in expect, the assumption is that the automatic
> variable will not change in the middle of execution of expect. Even
> procedural concurrent assertions are allowed to use automatic variables but
> they are considered constants. The value of these variables is captured at
> the time of attempt and the same value is used through out the evaluation of
> that attempt. Is that how you see the usage of automatic signals in your
> example, or you would like the expect to use the latest values.
>
>
>
>
>
> Thanks.
>
> Manisha
>
>
> ------------------------------
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *ben
> cohen
>
> *Sent:* Wednesday, June 23, 2010 3:29 AM
> *To:* Eduard Cerny; sv-ac@eda.org; Korchemny, Dmitry
> *Subject:* Re: [sv-ac] Fwd: sv-ac: virtual interface application example
>
> Ed,
>
> That particular example is from my VMM book, and does not use the expect.
> Here are 2 examples; One with a modification that could use the expect, and
> another example.
>
> class Fifo_cmd_xactor extends vmm_xactor;
>
> *virtual fifo_if.fdrvr_if_mp f_if;*
>
> * virtual fifo_if.fslave_if_mp s_if; *
>
> ...
>
> function new(...
>
> virtual fifo_if.fdrvr_if_mp new_vir_if,
>
> virtual fifo_if.fslave_if_mp new_svir_if;
>
> ... );
>
> *this.f_if = new_vir_if;*
>
> * this.s_if = new_svir_if; *
>
> ...
>
> endfunction : new
>
> endclass: Fifo_cmd_xactor
>
>
>
> task Fifo_cmd_xactor::push_task (word_t data);
>
> * @ ( f_if.driver_cb);*
>
> * expect (s_if.xxx ##[1:5} s_if.yyy); // <----*
>
> * f_if.driver_cb.data_in <= data;*
>
> * f_if.driver_cb.push <= 1'b1;*
>
> * f_if.driver_cb.pop <= 1'b0;*
>
> * @ ( f_if.driver_cb);*
>
> * f_if.driver_cb.push <= 1'b0;*
>
> * *
>
> endtask : push_task
>
>
>
> // NEW EXAMPLE with Action Blocks
>
> However, here is another example
>
> class mst_bfm; // driver class
>
> * virtual master_if.fdrvr_if_mp v_if;*
>
> function new( …
>
> *virtual master_if.fdrvr_if_mp new_vir_if, ..);*
>
> this.v_if = new_vir_if;
>
> ..
>
> endfunction : new
>
> …
>
> task continue2() .. endtask : continue2 // What to do if response to abort
> is the ABORTED
>
> task abort_error(); … endtask : abort_error // What to do if response to
> abort is not ABORTED
>
> *task driver(pkt_c in_pkt);*
>
> // code..
>
> vif.abort <= 1'b1;
>
> *expect ( @(posedge vif.clk) vif.mst_abort ##[5:8] vif.slv_resp ==
> ABORTED)*
>
> * continue2(); // pass action block*
>
> *else abort_error() ); // fail action block*
>
> *endtask : driver*
>
> endclass : mst_bfm
>
>
>
> In fact, this is how envisioned the application of the "expect" in a
> class.
>
> Ben
>
>
>
> On Tue, Jun 22, 2010 at 12:28 PM, Eduard Cerny <Eduard.Cerny@synopsys.com>
> wrote:
>
> Hi Ben,
>
>
>
> did you say that the example uses an expect? I do not see one.
>
>
>
> Thanks,
>
> ed
>
>
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *ben
> cohen
> *Sent:* Tuesday, June 22, 2010 1:30 PM
> *To:* Korchemny, Dmitry; sv-ac@eda.org
> *Subject:* [sv-ac] Fwd: sv-ac: virtual interface application example
>
>
>
>
>
> ---------- Forwarded message ----------
> From: *ben cohen* <hdlcohen@gmail.com>
> Date: Tue, Jun 22, 2010 at 9:58 AM
> Subject: sv-ac: virtual interface application example
> To: sv-ac@eda.org
>
> * `define TOP fifo_tb*
>
> module fifo_tb;
>
> ...
>
> * fifo_if f_if(.*); // instantiation of fifo interface*
>
> endmodule : fifo_tb
>
>
>
> class Fifo_env extends vmm_env; // ENVIRONMENT
>
> ....
>
> Fifo_cmd_xactor fifo_cmd_xactor_0; // command-layer declaration
>
> ...
>
> endclass : Fifo_env
>
>
>
> function void Fifo_env::build();
>
> ...
>
> this.fifo_cmd_xactor_0 = new("cmd_xactor",
>
> 0,
>
> * `TOP.f_if,* // <----- actual interface passed
>
> fifo_channel_0,
>
> fifo_response_chan0
>
> );
>
> ...
>
>
>
> endfunction : build
>
>
>
> class Fifo_cmd_xactor extends vmm_xactor;
>
> *virtual fifo_if.fdrvr_if_mp f_if;*
>
> ...
>
> function new(...
>
> virtual fifo_if.fdrvr_if_mp new_vir_if,
>
> ... );
>
> *this.f_if = new_vir_if;*
>
> ...
>
> endfunction : new
>
> endclass: Fifo_cmd_xactor
>
>
>
> task Fifo_cmd_xactor::push_task (word_t data);
>
> * f_if.driver_cb.data_in <= data;*
>
> * f_if.driver_cb.push <= 1'b1;*
>
> * f_if.driver_cb.pop <= 1'b0;*
>
> * @ ( f_if.driver_cb);*
>
> * f_if.driver_cb.push <= 1'b0;*
>
> endtask : push_task
>
>
>
> --
> 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* <http://www.mailscanner.info/>, 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* <http://www.mailscanner.info/>, 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 *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.