Connect interface to dut

[fbochud]

Hi,

 

I have issues connecting my interface to my dut when using the cadence compilator (vcs does not give any warning here): See the source code below. I get the following warning:

 

ncelab: *W,ICDPAVW (<my_file>): Illegal combination of driver and procedural assignment to variable my_data detected (output clockvar found in clocking block at line <n> in file <my_file>).
           .out_data  (my_if.my_data)

 

Any idea what is wrong her?

Thank you

 

Here's the source code:

interface my_if (input bit clk);

  logic reset;
  logic data;

   clocking master_cb @ (posedge clk);
      output                data;
   endclocking // cb

   clocking slave_cb @ (posedge clk);
      input                data;
   endclocking // cb

   clocking passive_cb @ (posedge clk);
      input                data;
   endclocking // cb

endinterface : my_if

module tb_top;

   logic clk;
   logic reset;

   /* Dut interfaces */
   my_if my_if(clk);
  
   /* Clocks and reset gen*/
   <...>


   assign my_if.reset = reset;

   dut
     my_dut(
                 .clk      (my_if.clk),
                 .arst     (my_if.reset),
                 .out_data (my_if.data)
     );

   initial begin : ib_main
      <...>

   end

endmodule

 

[dave_59]

Questa will also generate an error because the code is illegal as the error message reports. The DUT connection makes a continuous assignment to data, and the clocking block output is consider a procedural assignment to data. Declare data as a wire instead. See http://go.mentor.com/wire-vs-reg for an explanation of why you can;t mix procedural and continuous assignments to the same signal.

[fbochud]

Thank you.

I don't quite understand though. The signal of my_if interface will always be single-driven, as long as I am not using the master_cb clocking block in my monitor.

 

Is that because the interface is connected at run-time and the compiler won't know about which clocking block will drive/monitor the interface at compile time? It checks for the worst case

 

Could I use modport to avoid this as well? How?

[fbochud]

I have a book here that recommends to use logic in interfaces (System Verilog for Verification, Chris Spear / Greg Tumbush, chapter 4.2.8). This is then not valid when using clocking blocks?

[dave_59]

Thank you.

I don't quite understand though. The signal of my_if interface will always be single-driven, as long as I am not using the master_cb clocking block in my monitor.

 

Is that because the interface is connected at run-time and the compiler won't know about which clocking block will drive/monitor the interface at compile time? It checks for the worst case

 

Could I use modport to avoid this as well? How?

 

The LRM considers the clocking block output declaration as the assignment to the signal data. The statement cb.data <= value is not a direct assignment to data. Checking this at run-time rather than statically would be a severe performance penalty for all assignments. A modport would not help. You either need to change data to a wire, or conditionally compile/generate the clocking block.

I have a book here that recommends to use logic in interfaces (System Verilog for Verification, Chris Spear / Greg Tumbush, chapter 4.2.8). This is then not valid when using clocking blocks?

Chris Spear is a Synopsys employee and mainly has access to VCS. From my experience with other joint customers, VCS is not performing any assignment checks regardless of whether the clocking block is driven or not.

[fbochud]

Ok, it make sense. Thank you, Dave

[janaksw.patel]

So how to handle active and passive agent. In interface we would require clocking block for monitor and driver.  Same agent will be require to instance multiple times let say one with active and other with passive. Is this tool issue or LRM 

[dave_59]

Change the interface signal to a wire.