How to bind an interface with system verilog module?

UVM
1

Hi All,
I have an system verilog interface

interface add_sub_if(
input bit clk,
input [7:0] a,
input [7:0] b,
input       doAdd,
input [8:0] result
);

  clocking dut_cb @(posedge clk);
    output    a;
    output    b;
    output    doAdd;
    input     result;
  endclocking // cb

  modport dut(clocking dut_cb);

endinterface: add_sub_if

And i have a SV module which uses this interface


module dummy(add_sub_if.dut _if);
  ....
endmodule: dummy

What is the ideal way to hook up this in my TB?

If i instantiate the interface, i need to create wires.

If i use bind then also i need to do a port mapping of the individual signals, that beats the convenience of having an interface.

Another add on question is, how to assign one such interface to another interface?

Thanks in advance,

Rajdeep

2

In reply to justrajdeep:

I guess your interface does not contain internal signals of the DUT. Right?
If you want to connect your SV interface you to your DUT and maybe your TB you have to modle it correctly, i.e.
interface add_sub_if(input bit clk):
logic [7:0] a,
logic [7:0] b,
logic doAdd,
logic [8:0] result
);

clocking dut_cb @(posedge clk);
output a;
output b;
output doAdd;
input result;
endclocking // cb

modport dut(clocking dut_cb);

endinterface: add_sub_if

This interface assumes that clk is input to all modules/units connected to.
Check the direction of the variables in the clocking block. All inputs to the DUT are outputs in the clocking block and outputs of the DUT are inputs to the clocking block.

3

In reply to justrajdeep:

As the other poster (Chris?) suggested - your interface code looks incorrect to me. Ideally it should have global signals such as clk, reset as inputs and rest all as internal signals within the interface. But what you have written doesn’t surprise me at all - many noivce users, first comers do this. This is why we developed some cool apps to automate this SV Interface creation given a RTL block. See http://verifworks.com/products/dvcreate-svi/

We also have TCL based apps to run with Xilinx and others, drop me an email srini @ cvcblr if interested.

Srini
www.go2uvm.org

4

Hi Srini/Chris?

I have seen both kinds of interface definition, the one you have mentioned and the one I have showcased.

The one you have showcased is the typical interface that UVM cookbook and most UVMers recommend.

But the one i have shown comes with an added advantage, it can be used to bind with modules and sub-modules easily.

@Chris,
The code snippet that you have shown does not look syntactically correct(though i have not compiled it).

5

In reply to justrajdeep:

Hi Rajdeep,

the SV standard knows one SV interface construct only. See chapter 3.5 in the standard.
The most simple, but often used, definition looks like this (copied from the standard:
interface simple_bus(input logic logic clk);
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus
It starts with the keyword interface and may hav arguments. In this case it is clk.
Inside the definition there is a list of all variables belonging to this interface.
There is know data direction, because the interface might be connected to at least two blocks. In one of the block the variable might be an input and in the other one an output.

If you want to connect a module to variables internal to the DUT you can use the SV-bind construct. But this is not an SV interface.

6

In reply to justrajdeep:

The standard/recommended way of interface definition works well for internal modules too - can you elaborate where it suffers?

Srini
www.go2uvm.org

7

Hi Srini,

What i meant was that, if the interface has all the signals in the portlist, i can just bind it with the .* notation, even if the interface needs to be bound to a submodule. The same cannot be achieved with the std/recommended interface(i might be wrong). You would either need to create a module to help with the bind or use hierarchical references for alias connections.

Isnt that the case, or am I missing something?

8

In reply to chr_sue:

In reply to justrajdeep:
Hi Rajdeep,
the SV standard knows one SV interface construct only. See chapter 3.5 in the standard.
The most simple, but often used, definition looks like this (copied from the standard:
interface simple_bus(input logic logic clk);
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus
It starts with the keyword interface and may hav arguments. In this case it is clk.
Inside the definition there is a list of all variables belonging to this interface.
There is know data direction, because the interface might be connected to at least two blocks. In one of the block the variable might be an input and in the other one an output.
If you want to connect a module to variables internal to the DUT you can use the SV-bind construct. But this is not an SV interface.

Thanks Chris, yes thats what the SV LRM states.

9

In reply to justrajdeep:

I see your point, but fundamentally interfaces are supposed to be abstracting individual signals at the bare minimum - in your case it is not doing that. The instantiation is little verbose for a legacy RTL, but then can easily be automated. See what our recently released open-source Go2UVM (www.go2uvm.org) apps generated:

  // Connect TB clk to Interface instance clk

  // DUT instance
  sprot sprot_0 (
    .a(sprot_if_0.a),
    .b(sprot_if_0.b),
    .clk(sprot_if_0.clk),
    .rst_n(sprot_if_0.rst_n),
    .start(sprot_if_0.start),
    .prot_err(sprot_if_0.prot_err),
    .xfer_end(sprot_if_0.xfer_end)
  );

Corresponding Interface (auto-generated)

// Generating SystemVerilog interface for module: sprot
// ---------------------------------------------------------
// Using VW_CLK as a text macro for clock 
// If your clock signal is named other than clk, change the macro below
`define VW_CLK clk
interface sprot_if (input logic `VW_CLK);
  logic   a;
  logic   b;
  logic   rst_n;
  logic   start;
  logic   prot_err;
  logic   xfer_end;
  // End of interface signals 

  // Not showing modport/clocking blocks/assertions

The input to this DVC_Go2UVM app is your RTL top level, in this example it looks like this:


module sprot (input clk, rst_n,
  input start, a, b,
  output logic prot_err, xfer_end);

You can download Verdi plug-in/VC-apps from here: ttp://www.go2uvm.org/download/DVC_GO2UVM_Verdi_2016.05.tar.gz

We also have an integration done to Mentor Questa via PLI. TCL port is on the way.

Regards
Srini
www.go2uvm.org

10

In reply to Srini @ CVCblr.com:

In reply to justrajdeep:
The standard/recommended way of interface definition works well for internal modules too - can you elaborate where it suffers?
Srini
www.go2uvm.org

How can you bind an interface to RTL and hook up all the signals, unless they are all defined as ports? example please