RE: [sv-ec] multi drive of variable via virtual interface

The longest static prefix rule falls apart when you try to apply it to a virtual interface reference.

The virtual interface is a variable, and different values for that variable can cause it to refer to different objects. Therefore, it is not static. This is similar to the way in "array[i].member" where i is a variable, the "[i]" part is not static because different values for i cause it to refer to different objects. So the longest static prefix is just "array". In vi.sig_read, different values of vi can cause this to refer to different objects, so the "vi" part is not static. That leaves you with a longest static prefix of "". An empty longest static prefix would overlap all other references in the design, so this would lead to a conflict with any other drive of anything elsewhere in the design.

It may be obvious to you that this cannot conflict with anything but a reference to a variable sig_read in an instance of interface iface, but there is nothing in the longest static prefix rule that takes such things into account. The sig_read is not part of the longest static prefix, so the rule doesn't consider it. This is the same as the way array[i].member is considered to conflict with array[j].member2. Their longest static prefixes are array, and overlap. The fact that their suffixes are distinct members is not considered.

Since the longest static prefix doesn't really address virtual interfaces, we could try to apply an unwritten rule based on the fact that while vi could refer to any instance of interface iface in the design, it can't refer to anything but such an instance. So we could treat the empty prefix as only overlapping references to variables in such interfaces. I doubt that this helps much, since it would still conflict with any driver of any variable in one of those interfaces.

Even if there were some static prefix to the virtual interface in the reference, it would have to be discarded. Such a prefix does nothing to constrain what interfaces the expression references. If we have an array of ints, and refer to array[i], we still know that this refers to an int in array, so treating array as the static prefix works. But if we have an array of virtual interfaces, and use an expression like struct_name.arr_name[3].vi.sig_read, the "struct_name.arr_name[3]" does nothing to restrict which variables could be referenced. The virtual interface struct_name.arr_name[3].vi could refer to any interface that a simple virtual interface variable vi could. So not only is the virtual interface part not static, it prevents treating any prefix of the virtual interface reference as being static.

The same problems would arise with class handles, except that a class handle can only refer to class objects, whose members can't be driven by continuous assignments.

So as I said, the longest static prefix rule falls apart for virtual interfaces. I see little choice but to ignore them in the multiple driver rule.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gran, Alex
Sent: Friday, May 27, 2011 2:27 PM
To: neil.korpusik@oracle.com; SV_EC List
Cc: danielm
Subject: RE: [sv-ec] multi drive of variable via virtual interface

Daniel,
   I believe this should be an error. Are you expecting something different? If so, how are you expecting sig_read to behave.

This rule for Sec 6.5 should be in effect for this case.

        The precise rule is that it shall be an error to have multiple continuous assignments or a mixture of procedural
        and continuous assignments writing to any term in the expansion of a written longest static prefix of a
        variable (see 11.5.3 for the definition of a longest static prefix).

~Alex

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Neil Korpusik
Sent: Friday, May 27, 2011 11:08 AM
To: SV_EC List
Cc: danielm
Subject: [sv-ec] multi drive of variable via virtual interface

<forwarding email from Daniel Mlynek>

-------- Original Message --------
Date: Fri, 27 May 2011 09:08:22 +0200
From: Daniel Mlynek <danielm@aldec.com>
To: "sv-ec@eda.org" <sv-ec@eda.org>
Subject: multi drive of variable via continous assignment and procedural assignment
  via virtual interface

In below code varaible sig_read is driven by dut module output and it is
also driven by NBA to virtual interface select.
How should tool behave for such code.
Detect multidrive and fail?

CODE:

     interface iface;
          logic clk;
          logic sig_read;
     endinterface

     module dut(input clk,output reg xbus_read);
          initial xbus_read<=1'bz;
          always @(posedge clk)begin
              xbus_read<=1'bz;
              $display("2: xbus_read<=1'bz");
          end
     endmodule

     class C;
          virtual iface vi;
          function new(virtual iface i);
              vi=i;
          endfunction
          function drive;
              vi.sig_read<=1;* //procedural drive of sig_read*
              $display("1: vi.sig_read<=1");
          endfunction
     endclass

     module top;
          iface iface_i();
          dut uut(iface_i.clk,iface_i.sig_read);* //dut instantation - continous drive of sig_read*
          C c =new(iface_i);
          initial iface_i.clk=0;
          always #5 iface_i.clk = ~ iface_i.clk;
          initial begin
              $display("START");
               $monitor($time,">>>>", iface_i.sig_read);
              @(posedge iface_i.clk)
              c.drive();
              @(posedge iface_i.clk);
              #1;
              $display("END");
              assert(iface_i.sig_read)else $fatal("fatal error");
              $finish;
              end

     endmodule

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.