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

Daniel,

The end behavior is why I really do not want this to be legal. Trying
to define the behavior is likely going to cause serious disagreement;
not defining it leads to substantial vendor divergence. I'd prefer the
LRM to take a conservative option and say that a write through a
virtual interface prefixed name means that the static prefix of the
rest of the name is considered to be written in any feasible interface
instance (ie. any instance that could be referenced). That is
conservative, but at least keeps the error in place.

I really don't like the argument that Arturo is making. If we're going
to start ignoring parts of the check, let's start defining what constitutes
a TB construct and ignore all such constructs. Just ignoring a check
because it is inconvenient leads to inconsistencies in user expectations
and no clear picture of what the language guarantees.

Gord.

On 6/7/2011 6:25 AM, Daniel Mlynek wrote:
> 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
>>
>>

-- 
--------------------------------------------------------------------
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.