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


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