RE: [sv-bc] Virtual interfaces in always_comb

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


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