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

The previous email was type from a portable device. I edited the text.
 This is a repeat, but cleaned up a bit.
The disconnect/reconnect of virtual interfaces within a class is a generic
issue applicable the the virtual interfaces, and not just to 'expect'
construct. For example, within a class that has multiple virtual interfaces
it is possible to set withhin tasks the various virtual interfaces to null
or to other virtual interfaces to another one, thus emulatisomething like a
crossbar switch. That switching can occur while the tasks are still working
on the interfaces.
Eor example,
task t1;
 ...
 vif1.xx=...;
   some_delay; // e.g. repeat 10 (@ (posedge vif1.clk));
 vif11.xx=...;
endtask

task crossbarSwiitch; // This can mess up the working of task t1
 ...
  vif1=null; // <--- Set to null, possibly in the middle of t1
... delay
  vif1=vif2; // <-- Set to another interface, possibly in the middle of t1
endtask

task tx;
 ..
 fork
   t1;
   crossbarSwitch;
  join_none
endtask

the above 2 tasks arebe called concurrently. Thus, thus issue of reassigning
the virtual interfaces in the middle of transactions, and what should the
simulator do is something that we have not addressed. The issues with the
'expect' are same as the issues with virtual interfaces being nulled or
modified in the middle of transactions within a class.

This issue of the expect and the virtual interfaces being linked to null or
to other interfaces is very similar to a railroad switch where it is
possible for an operator to activate the switch while the train is still
traversing the railroad tracks. What happens next?

Def: (A *railroad <http://en.wikipedia.org/wiki/Railroad> switch*, *turnout*
 or *[set of]* *points* is a mechanical installation enabling
railway<http://en.wikipedia.org/wiki/Railway> trains
to be guided from one track <http://en.wikipedia.org/wiki/Rail_tracks> to
another at a railway junction <http://en.wikipedia.org/wiki/Junction_(rail)>
.)
Ben

On Thu, Jun 24, 2010 at 7:39 AM, ben cohen <hdlcohen@gmail.com> wrote:

> After more thioughts, the disconnect/reconnect of virtual interfaces within
> a class is a generic issue applicable the the virtual interfaces, and not
> just to 'expect' For example, I could within a clss that has multiple
> virtual interfaces set withhin tasks the variousually VIs to null or to
> other VIs, thus emulatisomething like a crossbar switch. That switching can
> occur while sim tasks are still working on one interface.
> Example,
> task t1;
> ...
> vif1.xx=...;
> ... . delay
> vif11.xx=...;
> endtask
>
> task crossbarSwiitch;
> ...
> vif1=null;
> ... delay
> vif1=vif2;
> endtask
>
> the above 2 task can be called concurrently.
> Thus, thus issue of reassigning the VIs in the middle of transactions, and
> what should the simulator do is something that we have not addressed. The
> issues with the 'expect' are same as the issues with VIs being nulled or
> modified in the middle of transactions within a class.
> Ben
>
>
> On 6/23/10, ben cohen <hdlcohen@gmail.com> wrote:
>>
>> [Ben] See my comments:
>>
>> On Wed, Jun 23, 2010 at 10:01 PM, Kulshrestha, Manisha <
>> Manisha_Kulshrestha@mentor.com> wrote:
>>
>>> Hi,
>>>
>>> Please see my comments:
>>>
>>> ------------------------------
>>> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *ben
>>> cohen
>>> *Sent:* Thursday, June 24, 2010 3:41 AM
>>> *To:* Kulshrestha, Manisha
>>> *Cc:* Eduard Cerny; sv-ac@eda.org; Korchemny, Dmitry
>>> *Subject:* [POSSIBLE VIRUS:###] Re: [sv-ac] Fwd: sv-ac: virtual
>>> interface application example
>>>
>>> Manisha,
>>> Thanks for your detailed explanations. Please bear with me on some
>>> comments, see below:
>>>
>>> 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.
>>>>
>>> Consider this example: (complete VMM model is attached, but without the
>>> expect. In previous email (further down in this email is a snippet with the
>>> expect). In the environment (the Fifo_env class), I can see the
>>> possibility of assigning to null the object where the expect were to be used
>>> in a class, and the expect was in the wait state. Specifically, one can do
>>> after a certain run time the following:
>>> this.fifo_cmd_xactor_0 = null;
>>> ... some time later
>>> this.fifo_cmd_xactor_0 = new("cmd_xactor",
>>>
>>> 0,
>>>
>>> * `TOP.f_if,* // Same or different interface <----- actual interface passed
>>>
>>> fifo_channel_0,
>>>
>>> fifo_response_chan0
>>>
>>> );
>>>
>>> *`define TOP 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
>>>
>>>>
>>>>
>>>>
>>> So far, so good! But what are the complications of doing such a thing?
>>> If the class instance is nulled in the middle of an expect, then everything
>>> in that class goes away. I don't understand the implications here.
>>>
>>> MK: What I wanted to say was that we need to define what happens in such
>>> cases. If interface object changes or becomes null (not the class
>>> object), how does expect behave. Is it allowed or tools gives error in this
>>> case ?
>>>
>> [Ben] How can the interface object change without a new of the class
>> object? Isn't this where the new of the class links the virtual interface
>> to the actual? Again, please bear with me with those questions, They
>> might be obvious to you, but not to me.
>>
>>>
>>> 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.
>>>>
>>> That kills the application of something like:
>>> *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*
>>> Is there a way to fix this? Do we want that? If one vendor implemented
>>> such application, what assumptions did he do?
>>>
>>> MK: I do not know what assumptions any specific vendor made. What I am
>>> saying is that this restriction in the virtual interfaces has to go away and
>>> the behaviour needs to be defined if we want to support virtual interfaces
>>> in the clock expression.
>>>
>> [Ben] I really would like us to support the virtual interfaces for the
>> expect.
>>
>>>
>>>> 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.
>>>>
>>>> Can you sho an example of the expect with automatic variables?
>>>>
>>>> MK: There is an example in the LRM in expect section. Here value is an
>>>> automatic variable.
>>>>
>>>> *
>>>>
>>>> integer
>>>> *data;
>>>>
>>>> ...
>>>> *
>>>>
>>>> task automatic
>>>> *wait_for( *integer *value, *output bit *success );*
>>>>
>>>> expect
>>>> *( @(*posedge *clk) ##[1:10] data == value ) success = 1;*
>>>>
>>>> else
>>>> *success = 0;*
>>>>
>>>> endtask
>>>>
>>>> initial begin
>>>>
>>>> bit
>>>> *ok;
>>>>
>>>> wait_for( 23, ok ); // wait for the value 23
>>>>
>>>> ...
>>>> *
>>>>
>>>> end
>>>> *
>>>>
>>> [Ben] Now, I want:
>> *
>>
>> integer data;
>> *
>> *
>>
>> task automatic wait_for( integer value, output bit success );
>> **
>>
>> expect
>> *( @(*posedge *clk) ##[1:10] data == my_virtual_interface_object.data)
>> success = 1;*
>>
>> else
>> *success = 0;
>> *
>>
>> endtask
>> *
>>
>>>
>>> Ben
>>>
>>>> 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, and is
believed to be clean.