Re: [sv-bc] Virtual interfaces in always_comb

I certainly think that virt interfaces (and classes) should
have their role in the "single writer" rules clarified.  Virt
interfaces should have their role in the sensitivity list
clarified as well.  Of course that is all out 4 years from
now.

Gord.

Daniel Mlynek wrote:
> The question is should virt interfaces be added to LRM text as you suggest -
> or it shuld be left users/implementors common sense ;)
> 
> 
> DANiel 
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: 8 września 2009 15:50
> To: Bresticker, Shalom
> Cc: Rich, Dave; Daniel Mlynek; sv-bc@server.eda.org
> Subject: Re: [sv-bc] Virtual interfaces in always_comb
> 
> I agree with Shalom that I don't think that the longest static prefix rules
> were meant to cover this kind of case.  Classes have the same kind of issue
> -- surely we don't want to have such an application for class references.
> 
> I think that the intent is more clearly suggested by:
>      References to class objects and method calls of class objects
>      do not add anything to the sensitivity list of an always_comb.
> I would be inclined to read that in a slightly wider manner and include
> virtual interfaces.  And, as I suspect everyone is doing, if the
> "sensitivity list" isn't impacted, the "single writer" rule shouldn't be
> applied either.
> 
> Certainly this aligns with the expectation that always_comb rules are meant
> to apply to (synthesizable) combinational blocks and enforce some additional
> checking on such blocks.  If there are dynamic constructs such as classes
> and virt interfaces in play, I don't think it makes sense to apply the
> additional rule checking to those writes.
> 
> Unfortunately (yet again), a construct intended for one aspect wasn't made
> narrow enough to be *illegal* with other uses and as a result, all sorts of
> bizarre issues show up.
> 
> Gord
> 
> Bresticker, Shalom wrote:
>> I think such an interpretation of the longest static prefix subclause 
>> of the LRM (11.5.3) is arguable at best.
>>  
>> Shalom
>>
>>
> ------------------------------------------------------------------------
>>     *From:* owner-sv-bc@server.eda.org
>>     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Rich, Dave
>>     *Sent:* Tuesday, September 08, 2009 1:07 AM
>>     *To:* Daniel Mlynek; sv-bc@server.eda.org
>>     *Subject:* RE: [sv-bc] Virtual interfaces in always_comb
>>
>>     I believe if you apply the principals of the longest static prefix
>>     rules, this is already illegal.
>>
>>      
>>
>>     Dave
>>
>>      
>>
>>      
>>
>>     
>> ----------------------------------------------------------------------
>> --
>>
>>     *From:* owner-sv-bc@server.eda.org
>>     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Daniel Mlynek
>>     *Sent:* Monday, September 07, 2009 2:45 AM
>>     *To:* sv-bc@server.eda.org
>>     *Subject:* [sv-bc] Virtual interfaces in always_comb
>>
>>      
>>
>>     Should virtual interfaces be allowed to be assigned in always_comb
>>     blocks? This leads to situation like below- vi1.i  nad vi2.i point
>>     the same output variable while this is forbidden for variable driven
>>     from always comb to be driven in other processes (lrm:  "The
>>     variables written on the left-hand side of assignments shall not be
>>     written to by any other process.". Such situation can be
>>     detected only on runtime.
>>
>>     As always_comb was added to be used in synthethisabe combitional
>>     processses maybe there should be a rule saying that this is
>>     forbidden to drive virtual interface drives (similar for class 
>> handles)
>>
>>      
>>
>>     interface iface1;
>>      bit [7:0] i;
>>     endinterface
>>
>>     module top;
>>       iface1 ifci1();
>>       virtual iface1 vi1 = ifci1, vi2 = ifci1; bit [7:0] ii1 = 1; bit
>>     [7:0]  ii2 = 2;
>>
>>      always_comb
>>         vi1.i = ii1;
>>
>>
>>      always_comb
>>        vi2.i = ii2;
>>
>>      initial #2 $finish;
>>
>>     endmodule
>>
>>      
>>
>>     DANiel
>>
>>
>>     -- 
>>     This message has been scanned for viruses and
>>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>>     and is
>>     believed to be clean.
>>     -- 
>>     This message has been scanned for viruses and
>>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>>     and is
>>     believed to be clean. 
>>
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
>>
>>
>> --
>> This message has been scanned for viruses and dangerous content by 
>> *MailScanner* <http://www.mailscanner.info/>, 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.