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

ok I undestand
I've reported a mantis on that:
http://www.verilog.org/mantis/view.php?id=3604

DANiel

On 6/7/2011 3:57 PM, Gordon Vreugdenhil wrote:
> 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
>>>
>>>
>

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