Clocking block in interface

SystemVerilog
1

Hi,

Are there any disadvantages of using a clocking block inside an interface.

Thanks.

2

Putting the clocking block inside an interface is the recommended way. Below are snippets of code:

interface counter_if (input logic clk);
     import counter_pkg::*; 
     logic[3:0] data_in;
     logic ld;
     logic[3:0] counter;
     logic rst_n;
     ct_scen_e kind_cp; // for debug only
            
            
     clocking driver_cb @ (posedge clk);
         output rst_n, data_in, ld, kind_cp; 
         input counter;
     endclocking : driver_cb
  
     clocking mon_cb @ (posedge clk);
         input rst_n, data_in, ld, kind_cp; 
         input counter;
     endclocking : mon_cb
     
     modport drvr_if_mp (clocking driver_cb);
     modport mon_if_mp (clocking mon_cb);   
 endinterface : counter_if

class counter_driver extends uvm_driver #(counter_xactn, counter_xactn);
	virtual interface counter_if.drvr_if_mp vif;
 /// ....
	task load_task(int data);
		this.vif.driver_cb.data_in <= data;
		this.vif.driver_cb.rst_n <= 1'b1;
		this.vif.driver_cb.ld <= 1'b1; 
		@(this.vif.driver_cb)this.vif.driver_cb.ld <= 1'b0; 
        
	endtask : load_task
    endclass : counter_driver

class counter_env extends uvm_env;
//....
	virtual function void connect_phase(uvm_phase phase); // connect();
		agent0.assign_vif(top.if0);
	endfunction : connect_phase
endclass : counter_env

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us

  • A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
  • SystemVerilog Assertions Handbook, 2005 ISBN 0-9705394-7-9
  • 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 0-9705394-2-8
  • 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
3

As opposed to not using them at all, I assume?

The answer really depends on your knowledge of the Verilog scheduling mechanism - do you know how to code to prevent race conditions, and do you know how to deal with bidirectional buses from the testbench. If you don’t understand this, then clocking blocks simplify the problem. However, they do come with several additional guidelines that you need to follow

  1. All samples and drives to clocking block inputs and outputs respectively must be synchronized to the clocking block event (cb). Do not use any other events or waits other than @cb or @(cb iff signal==1)
  2. The clock event used to trigger the clocking block must not come from a program. (we do not recommend using program blocks anyways)
  3. Once you start using clocking blocks in an interface, do not reference those signals from anything other than the clocking block in your testbench.

However, if you already understand how to code to prevent race conditions and deal with bidirectional buses, then clocking blocks are an additional level of complexity that can be avoided.

4

In reply to dave_59:

Thanks Dave for the answers.

5

In reply to ben@SystemVerilog.us:

Thanks Ben for the snippet.

6

In reply to KumarSunilB:

See Why non blocking while driving signals on interface - UVM - Verification Academy
and Assigning interface net-type signals from class - SystemVerilog - Verification Academy
Particularly this section
The best way to drive interface wires is to use clocking blocks.

  • 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.