Ben,
When there is ambiguity in the LRM, we have to get past what it
currently says and figure out what it should have said. It will also
help to get some agreement on what is not ambiguous.
An event control is a procedural statement.
initial begin
@(posedge clk);
...
end
An event control statement suspends a process in an initial, always
block, or fork block, and resumes by executing the next sequential
statement.
A clocking block and sequence are example of non-procedural contexts
where an implicit state machine is created to execute some declarative
statement.
clocking cb @(posedge clk);
...
endclocking
In this context @(posedge clk) is not an event control, but instead
declares the sensitivity of the clocking block. A clocking block is
implemented by implicitly creating additional temporary variables and
processes with event controls to execute sampling inputs and driving
outputs. I believe a "sensitivity list" is any context where the
compiler has to implicitly build a set of event control to manage an
implicitly created process.
The virtual interface restriction in 20.8 was put in place because the
committee did not have the time to deal with all the issues and will
always make the rules more restrictive so they can be relaxed later
rather than having to deal with backward incompatibilities.
If the LRM were to allow
clocking cb @(posedge virt_interface.clk);
endclocking
Two issues that immediately come to mind is how to deal with time 0
initialization where virt_interface is still null, and how does changing
virt_interface from one instance to another affect all the implicit
processes. In a procedural context, the user can always write code to
guard against a null handle reference. It very difficult to do that with
implicitly generated event controls, especially where the LRM does not
specify the implementation.
Dave Rich
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben
cohen
Sent: Monday, July 05, 2010 11:13 AM
To: Bresticker, Shalom
Cc: sv-ac@server.eda.org
Subject: 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 <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.Received on Mon Jul 5 23:01:36 2010
This archive was generated by hypermail 2.1.8 : Mon Jul 05 2010 - 23:01:45 PDT