Welcome ! This website will help YOU (recent graduates/professionals) learn verification languages like SystemVerilog and UVM. Register for free and access more content !

What is an Interface ?

An Interface is a way to encapsulate signals into a block. All related signals are grouped together to form an interface block so that the same interface can be re-used for other projects. Also it becomes easier to connect with the DUT and other verification components.

Example

APB bus protocol signals are put together in the given interface. Note that signals are declared within interface and endinterface.

 
interface apb_if (input pclk);
  logic [31:0]    paddr;
  logic [31:0]    pwdata;
  logic [31:0]    prdata;
  logic           penable;
  logic           pwrite;
  logic           psel;
endinterface
 

Why are signals declared logic ?

logic is a new data type that lets you drive signals of this type via assign statements and in a procedural block. Remember that in verilog, you could drive a reg only in procedural block and a wire only in assign statement. But this is only one reason.

Signals connected to the DUT should support 4-states so that X/Z values can be caught. If these signals were bit then the X/Z would have shown up as 0, and you would have missed that DUT had a X/Z value.

How to define port directions ?

Interface signals can be used within various verification components as well as the DUT, and hence modport is used to define signal directions. Different modport definitions can be passed to different components that allows us to define different input-output directions for each component.

 
// Filename : myBus.sv
interface myBus (input clk);
  logic [7:0]  data;
  logic      enable;
 
  // From TestBench perspective, 'data' is input and 'write' is output
  modport TB  (input data, output enable);  
 
  // From DUT perspective, 'data' is output and 'enable' is input
  modport DUT (output data, input enable); 
endinterface
 

How to connect an interface with DUT ?

An interface object should be created in the top testbench module where DUT is instantiated, and passed to DUT. It is essential to ensure that the correct modport is assigned to DUT.

 
// Filename : dut.sv
module dut (myBus.DUT busIf);
  always @ (posedge clk) 
    if (busIf.enable)
      busIf.data <= busIf.data+1;
    else 
      busIf.data <= 0;
endmodule 
 
 
// Filename : tb_top.sv
module tb_top;
  bit clk;
  bit enable;
 
  // Create a clock
  always #10 clk = ~clk;
 
  // Create an interface object
  myBus busIf (clk);
 
  // Instantiate the DUT; pass modport DUT of busIf
  dut dut0 (busIf.DUT);
 
  // Testbench code : let's wiggle enable
  initial begin
    enable  <= 0;
    #10 enable <= 1;
    #40 enable <= 0;
    #20 enable <= 1;
  end
endmodule
 

What are the advantages ?

Interfaces can contain tasks, functions, parameters, variables, functional coverage, and assertions. This enables us to monitor and record the transactions via the interface within this block. It also becomes easier to connect to design regardless of the number of ports it has since that information is encapsulated in an interface.

 
//Before interface
dut dut0  (.data (data),
           .enable (enable),
           //  all other signals
           );
 
// With interface - higher level of abstraction possible
dut dut0  (busIf.DUT);
 

How to parameterize an interface ?

The same way you would do for a module.

 
interface myBus #(parameter D_WIDTH=31) (input clk);
  logic [D_WIDTH-1:0] data;
  logic               enable;
endinterface
 

What are clocking blocks ?

Signals that are specified inside a clocking block will be sampled/driven with respect to that clock. There can be mulitple clocking blocks in an interface. Note that this is for testbench related signals. You want to control when the TB drives and samples signals from DUT. Solves some part of the race condition, but not entirely. You can also parameterize the skew values.

 
clocking cb_clk @(posedge clk);
  default input #3ns output #2ns;
  input enable;
  output data;
endclocking
 

In the above example, we have specified that by default, input should be sampled 3ns before posedge of clk, and output should be driven 2ns after posedge of clk.

How to use a clocking block ?

 
// To wait for posedge of clock
@busIf.cb_clk;
 
// To use clocking block signals
busIf.cb_clk.enable = 1;
 

As you can see, you don't have to wait for the posedge of clk, before you assign 1 to enable. This way, you are assured that enable will be driven 2ns after the next posedge clk.

Was this article helpful ?

We use cookies to personalize content and ads, to provide social media features and to analyze our traffic. You consent to our cookies if you continue to use our website. To find out more about the cookies we use and how to delete them, see our privacy policy.

  I accept cookies from this site.
Agree
EU Cookie Directive plugin by www.channeldigital.co.uk