Jump to content

Connect interface to dut


fbochud

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

 

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment
Share on other sites

  • 4 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...