Wire vs. Logic in SV Interface

SystemVerilog
, ,
1

Hi,

Which is better to use in SystemVerilog interface. Wire or Logic? Or this does not make much difference. When using logic for interface signal, a problem I’ve encountered is simulator throws warning message when there’s mix of Driver Clocking Block and continuous assignment.

E.g.

interface intf(bit clock);
  logic a; //wire a;

  clocking drvCb @(posedge clock);
    output a;
  endclocking
...

Warning Message:
If a variable is driven by a continuous assignment or primitive output,
then no procedural assignment to that variable is allowed

2

In reply to MayurKubavat:

The top level signals that connect to your DUT should be wires. The interface should have internal logic that will drive the wires from logic or tri-state them so that the interface can be used as either a master or slave.

3

See my response, with examples, at
Http://verificationacademy.com/forums/systemverilog/assigning-interface-net-type-signals-class

Ben Ben@systemverilog.us

4

In reply to ben@SystemVerilog.us:

@cgales, This looks like some extra logic in interface.

The interface should have internal logic that will drive the wires from logic or tri-state them

This kind of logic we generally have in Driver component. Where if the Driver is not connected to testbench, same interface can be also used as slave.

@ben, your solution in given link looks good. But there also, declaring clocking variable as inout might be unnecessary.

Just replacing “logic” with “wire” in above code seem to have done the job!

interface intf(bit clock);
  wire a; //logic a;
 
  clocking drvCb @(posedge clock);
    output a; //Can be driven through procedural block
  endclocking
...
5

In reply to MayurKubavat:

Here is a small example which demonstrates an interface that can be used as a master/slave:


interface intf(input clock);
  wire a;
  wire b;

  bit mode = 1;   // 1 - Master ; 0 - Slave - You can use an enum
 
  logic a_i;
  logic b_1;

  assign a = (mode==1) ? a_i : 1'bz;
  assign b = (mode==1) ? b_i : 1'bz;

  function void set_mode(bit new_mode)
    mode = new_mode;
  endfunction
...

You can read all of the inputs using the wires. You can use the logic variables in your procedural code, which you can’t do with wires. This solution also eliminates the multiple driver warnings/errors.

6

In reply to MayurKubavat:

In reply to ben@SystemVerilog.us:
@ben, your solution in given link looks good. But there also, declaring clocking variable as inout might be unnecessary.
Just replacing “logic” with “wire” in above code seem to have done the job!

interface intf(bit clock);
wire a; //logic a;
clocking drvCb @(posedge clock);
output a; //Can be driven through procedural block
endclocking
...

I disagree that “declaring clocking variable as inout might be unnecessary”
Decalaring it as inout maintains the integrety/signifance/role of that variable in its context.
Declaring it as output has the implication that the variable is constantly driven to a hard value (i.e., not tri-stated); it now called “fake news” :).
Quote:
1800-2012 14.3 Clocking block declaration

  • A clockvar whose clocking_direction is inout shall behave as if it were two clockvars, one input and one output, having the same name and the same clocking_signal.
  • Reading the value of such an inout clockvar shall be equivalent to reading the corresponding input clockvar.
  • Writing to such an inout clockvar shall be equivalent to writing to the corresponding output clockvar.
    Ben Cohen
    http://www.systemverilog.us/ ben@systemverilog.us
    For training, consulting, services: contact Home - My cvcblr
  • SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
  • A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
  • Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
  • Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 978-1539769712
  • Component Design by Example ", 2001 ISBN 0-9705394-0-1
  • VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
  • VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
7

In reply to cgales:

@cgales, This looks like some extra logic in interface.
Quote:The interface should have internal logic that will drive the wires from logic or tri-state them

Actually, it is more than just extra logic in the interface. It is more as to how the interface is viewed: Is it viewed as

  1. An active component/driver/modifier participating in the values of signals connected to e DUT?
  2. As a bundle of wires connecting the DUT to its environment?

My view of an interface is the bundle of wires, and should not play an active role in the connection to the DUT. It can play a passive role in the verification/monitoring processes.
The other problem with this approach is that the driving process is now distributed:

  • One part is in the class driver
  • The other part is within the interface

interface intf(input clock);
  wire a;
  wire b;
  bit mode = 1;   // Fake interface signal 
  logic a_i;  // Fake interface signal 
  logic b_1;   // Fake interface signal 
   assign a = (mode==1) ? a_i : 1'bz;  // Fake driver 
  assign b = (mode==1) ? b_i : 1'bz;  // Fake driver
...
  endfunction

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

8

In reply to ben@SystemVerilog.us:

This is true, but if you desire to use emulation, which is a requirement for a growing number of UVM users, then this approach is a necessity. For emulation, all the BFM functionality needs to be in the interface, so starting with this approach is beneficial for long-term portable agents.