SV INTERFACE

                                                  INTERFACE

In Verilog, the communication between blocks is specified using module ports. SystemVerilog adds the interface construct which encapsulates the communication between blocks.
An interface is a bundle of signals or nets through which a testbench communicates with a design. Fig shows TB & DUT with and without interface.
An interface is a named bundle of wires, the interfaces aim is to encapsulate communication.
 

Interface specifies the,
        directional information, i.e modports
    timing information, i.e clocking blocks
An interface can have parameters, constants, variables, functions, and tasks.

Advantages of the interface over the traditional connection,
-allows the number of signals to be grouped together and represented as a single port, the single port handle is passed instead of multiple signal/ports.
-interface declaration is made once and the handle is passed across the modules/components.
-addition and deletion of signals are easy.
-Increases the reusability.
- Reduces errors which can cause during module connections.


Modports

 To specify the direction of the signal w.r.t module which uses interface instead of port list, modports are used.
Modport restrict interface access within a module based on the direction declared.
Ex:
interface intf (input clk);
logic read, enable,
logic [7:0] addr,data;
modport dut (input read,enable,addr,output data);
modport tb (output read,enable,addr,input data);
endinterface :intf



Clocking Block:
clocking block that identifies clock signals, and captures the timing and synchronization requirements of the blocks being modeled.
clocking cb @(posedge clk);
default input #1ns output #0ns;
output read,enable,addr;
input negedge data;
Endclocking
In the above example, the first line declares a clocking block called cb that is to be clocked on the positive edge of the signal clk.
 The second line specifies that by default all signals in the clocking block shall use a 1ns input skew and a 0ns output skew by default. and data should be stable for this time with respect to clock edge.
The next line adds three output signals to the clocking block: read, enable and addr.
The fourth line adds the signal data to the clocking block as input. Fourth line also contains negedge which overrides the skew ,so that data is sampled on the negedge of the clk.

Virtual Interface 
Interface is static in nature, whereas classes are dynamic in nature. because of this reason, it is not allowed to declare the interface within classes, but it is allowed to refer to or point to the interface.
A virtual interface is a variable of an interface type that is used in classes to provide access to the interface signals.
Virtual interfaces provide a mechanism for separating abstract models and test programs from the actual signals that make up the design.
Virtual interface can be used to make the TestBench independent of the physical interface.
A virtual interface must be initialized before it can be used, by default, it points to null. Attempting to use an uninitialized virtual interface will result in a run-time error.
 Syntax
virtual interface_name instance_name;

Interface Passing to ENV 

Using a virtual interface as a reference or handle to the interface instance, the testbench can access the tasks, functions, ports, and internal variables of the SystemVerilog interface.
As the interface instance is connected to the DUT pins, the testbench can monitor and control the DUT pins indirectly through the interface elements.
The recommended approach for passing this information to the testbench is to use either the configuration database using the config_db API.




                                                                                        
Step #1: Placing a Virtual Interface into the Configuration Database using the config_db
module top_mac;// Top level module for a wishbone system with bus connection
...
wishbone_bus_syscon_if wb_bus_if(); // WISHBONE interface instance
 ...
  initial begin
 uvm_config_db #(virtual wishbone_bus_syscon_if)::set(null, "uvm_test_top", "WB_BUS_IF", wb_bus_if);  //set interfaces in config space
 run_test("test_mac_simple_duplex");  // create and start running test
  end
endmodule    

Step #2: Making the Virtual Interface Available in the Testbench         
Test class gets the virtual interface and places it into configuration object. This object can then be accessed by all TB components.
class test_mac_simple_duplex extends uvm_test;
.......
wb_config wb_config_0;  // config object for Virtual Interface

 function void build_phase(uvm_phase phase); //build_phase

    if (!uvm_config_db #(virtual wishbone_bus_syscon_if)::get(this, "", "WB_BUS_IF", wb_config_0.v_wb_bus_if))  // virtual interface getting

    `uvm_fatal("TEST_MAC_SIMPLE_DUPLEX", "Can't read WB_BUS_IF");

 uvm_config_db#(wb_config)::set(this, "*", "wb_config", wb_config_0); // Place the Virtual interface into Configuration object

  endfunction
 endclass

Step #3: Assigning Virtual Interface Property to component that actually accesses the DUT(Driver,moniter..) 

class wb_m_bus_driver extends uvm_driver  #(wb_txn, wb_txn);
...
   virtual wishbone_bus_syscon_if m_v_wb_bus_if;  // Virtual Interface
  wb_config m_config;

//Get the config DB for virtual interface
  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    if (!uvm_config_db #(wb_config)::get(this, "", "wb_config", m_config)) // get config object

      `uvm_fatal("Config Fatal", "Can't get the wb_config")
    ...
  endfunction : build_phase
 // Drive it to DUT using local Virtual Interface
  function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    m_v_wb_bus_if = m_config.v_wb_bus_if; // set local virtual if property
  endfunction : connect_phase
  ...
endclass