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

So the best would be to have runtime error when we try to do procedural
assignment via virtual interface to variable already driven by continous
assignment but this is impossible b'cos this will kill the performance?
Summarizing there is no way to resolve this issue.
Maybe it should be at least mentioned how it should behave - which
assignment will won?
Semantically this situation is same as below one (illegal according to
LRM) and LRM do not give us rule so we now what should be the value of a;

module top;
     int a,b;
     assign a=b;
     initial #1 a<=1;
     initial #1 b<=2;
endmodule

DANiel

On 6/1/2011 6:03 PM, Arturo Salz wrote:
> Gord,
>
> I don't think we should make exclusions based on the construct's intent (i.e., TB vs. DUT), but strictly on what the tool's an reason about. If the class contains a statically determinable driver (e.g., a hierarchical reference or a port) then the multi-driver rule should be applied. But for a virtual interface, where the reference to the interface itself is not known at compile/elaboration time, I think it's best to live it alone. Also, I don't understand what it is that you are actually proposing - Dave did say to apply option 1 and mark as an error any actual or potential mix of procedural and continuous assignments (is that your opinion?)
>
> I do agree with Dave that this type of use should be discouraged - it probably points to a methodology deficiency. But I don't know that we want to use a hammer approach to deal with this problem.
>
> Arturo
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Wednesday, June 01, 2011 7:32 AM
> To: Arturo Salz
> Cc: Gran, Alex; Steven Sharp; neil.korpusik@oracle.com; SV_EC List; danielm
> Subject: Re: [sv-ec] multi drive of variable via virtual interface
>
> Arturo,
>
> By the same reasoning as in (3), should we not also ignore any procedural writes from classes in terms of error/warning generation? If we want to strongly separate the TB side from the DUT side, I think it would follow that classes should be lumped together with a virtual interface in terms of resulting behavior.
>
> Part of my concern here (as is Dave's) is that once you mix procedural and continuous assignments on a variable, you end up with very odd semantics and (very likely) considerable divergence in what the end result would be in various simulators. Even though this is "only" the TB, I am concerned about allowing this to become legal.
>
> Gord.
>
> On 5/27/2011 6:03 PM, Arturo Salz wrote:
>> Alex,
>>
>> No, I don't believe so.
>> A "driver" means something specific: . the output of some hardware component (i.e., a statically determinable writer). It does not mean every conceivable software component that could write or deposit a value on some signal. As I wrote earlier, the signal could be written via VPI (or via the debugger) and that does not constitute a driver.
>> But, I hope this doesn't get stuck in a semantic discussion of what constitutes a driver. Rather, we should make reasonable decisions based on the intent of the problems that these checks are intended to address. And, while option 2 is plausible, I don't think it is worth the cost (in complexity and performance) nor will users be happy to get a run-time for something that is not a hardware model but a part of the testbench.
>>
>> Arturo
>>
>> -----Original Message-----
>> From: Gran, Alex [mailto:alex_gran@mentor.com]
>> Sent: Friday, May 27, 2011 5:25 PM
>> To: Arturo Salz; Steven Sharp; neil.korpusik@oracle.com; SV_EC List
>> Cc: danielm
>> Subject: RE: [sv-ec] multi drive of variable via virtual interface
>>
>> Arturo,
>> Of your 3 options, wouldn't this text from Sec 10.3.2 suggest option 2?
>>
>> It shall be an error for a variable driven by a continuous assignment or output to
>> have an initializer in the declaration or any procedural assignment
>>
>> ~Alex
>>
>>
>> -----Original Message-----
>> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
>> Sent: Friday, May 27, 2011 4:30 PM
>> To: Steven Sharp; Gran, Alex; neil.korpusik@oracle.com; SV_EC List
>> Cc: danielm
>> Subject: RE: [sv-ec] multi drive of variable via virtual interface
>>
>> I mostly agree with Steven's analysis.
>>
>> When applied to a virtual interface, the "longest static prefix" yields and empty prefix. Since the compiler cannot statically determine which interface is associated to a particular virtual interface, a virtual interface is essentially a dynamic construct. Accordingly, the virtual interface itself is excluded from the static prefix, which makes it impossible for the compiler to *accurately* check whether the multiple driver rule is violated by a virtual interface. This, I believe, is no different than users writing to a variable via VPI - the compiler cannot check for such a violation (and it is in fact not an error).
>>
>> To deal with this issue we have essentially three options:
>> 1) Issue a conservative compiler warning/error - if a signal is potentially multiply driven. Because this error is conservative, it is inaccurate and may report as potentially erroneous a non-violating design.
>> 2) Issue a run-time error when a procedural driver in the virtual interface writes to a continuously driven net. This option will require a substantial amount of run-time bookkeeping, particularly if the written bits are non-overlapping due to indexing and part-selects.
>> 3) Ignore the multiple driver - the virtual interface does not represent a static driver and is strictly part of the testbench.
>>
>> Option 3 most closely matches the LRM intent, which was to avoid synthesis/simulation mismatches due to multiple drivers (avoid last-write-wins semantics on non-memory elements). Since virtual interfaces are not synthesizable, this should not be a problem. I cannot see scenarios under which users would care to see this reported as an error. Option 1 is likely too restrictive, while option 2 is likely to become an annoyance since the model may not be incorrect (assuming the user wants last-write-wins semantics).
>>
>> Arturo
>>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>> Steven Sharp
>> Sent: Friday, May 27, 2011 3:53 PM
>> To: Gran, Alex; neil.korpusik@oracle.com; SV_EC List
>> Cc: danielm
>> Subject: 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.
>>
>>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>

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