Jump to content
Sign in to follow this  
fbochud

Connect interface to dut

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×