UVM video lactures link

http://videos.accellera.org/uvmreadysetdeploy/uvm38mtR57B/index.html

Virtual Interface

1. We cannot pass a port (interface) directly in a class, so we use the concept of the virtual interface that points to the actual interface and can be passed in a class as a class is a dynamic entity.

2. The interface is used for connection of two modules.

3. The virtual interface is used to connect a class (dynamic entity) to a module (static entity)

4. Virtual interfaces provide a mechanism for separating abstract models and test programs from the actual signals that make up the design.

5. A virtual interface allows the same subprogram to operate on different portions of a design and to dynamically control the set of signals associated with the subprogram.

6. Instead of referring to the actual set of signals directly, users are able to manipulate a set of virtual signals. Changes to the underlying design do not require the code using virtual interfaces to be rewritten.

7. By abstracting the connectivity and functionality of a set of blocks, virtual interfaces promote code reuse.

8. Virtual interfaces can be declared as class properties, which can be initialized procedurally or by an argument to new(). This allows the same virtual interface to be used in different classes.

8. In UVM based environment we can set the virtual interface using config_db in the tb_top and then it will be available down the hierarchy.


9. The following example shows how the same transactor class can be used to interact with various different devices:

01.interface SBus; // A Simple bus interface

02.logic req, grant;

03.logic [7:0] addr, data;

04.endinterface



05.class SBusTransctor; // SBus transactor class

06.virtual SBus bus; // virtual interface of type Sbus


07 function new( virtual SBus s );

08.bus = s; // initialize the virtual interface

09.endfunction


10.task request(); // request the bus

11.bus.req <= 1'b1;

12.endtask


13.task wait_for_bus(); // wait for the bus to be granted

14.@(posedge bus.grant);

15.endtask


16.endclass



17.module devA( Sbus s ) ... endmodule // devices that use SBus

18.module devB( Sbus s ) ... endmodule


19.module top;

20.SBus s[1:4] (); // instantiate 4 interfaces

21.devA a1( s[1] ); // instantiate 4 devices

22.devB b1( s[2] );

23.devA a2( s[3] );

24.devB b2( s[4] );


25.initial begin

26.SbusTransactor t[1:4]; // create 4 bus-transactors and bind

27.t[1] = new( s[1] );

28.t[2] = new( s[2] );

29.t[3] = new( s[3] );

30.t[4] = new( s[4] );

31. end



32.endmodule


In the preceding example, the transaction class SbusTransctor is a simple reusable component. It is written without any global or hierarchical references and is unaware of the particular device with which it will interact. Nevertheless, the class can interact with any number of devices (four in the example) that adhere to the interface’s protocol.

Notes :
1. virtual i/f is just a handle (like pointers) when a virtual i/f is declared, it only creates handles, doesn't create a local interface.

2. Virtual interface variables can 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. 

3. A virtual interface must be initialized before it can be used; it has the value null before it is initialized.


Benefits of using interface :
1. can contain protocol checking using assertions and functional coverage blocks. 
2. maintainability and reusability. 
3. can contain tasks and functions.