RE: [sv-bc] uwire & wire -vs- reg

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Wed Jul 11 2007 - 01:14:40 PDT
This was discussed in the past in
http://www.eda-stds.org/sv-bc/hm/3551.html .

(My browser is having some problem displaying it. I can send a copy to
the list if needed.)

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Steven Sharp
> Sent: Wednesday, July 11, 2007 12:18 AM
> To: stuart@sutherland-hdl.com; sv-bc@server.eda.org;
> Dave_Rich@mentor.com
> Subject: RE: [sv-bc] uwire & wire -vs- reg
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> 
> >I don't see how this logic optimization is any different than what
> one
> >would use to perform port net collapsing. Any global optimization
> that
> >normally looks for the absence of forces, hierarchical references, or
> >PLI write access could perform the same port collapsing on logic
> types
> >in those cases because there is no difference between a wire and a
> var
> >kind.
> 
> I agree that you may be able to recover some of the performance loss
> by collapsing var ports in some cases also.  As you mention, this
> would
> require analysis to determine the cases where this optimization was
> valid, i.e. that it produces behavior that would be valid for the
> design without port collapsing (I don't say equivalent, since it might
> change the original behavior to some other valid behavior, perhaps
> with
> different event ordering).
> 
> For nets, port collapsing is explicitly allowed, whether it changes
> the visible behavior or not.  So net ports can legally be collapsed in
> cases where var ports cannot.  This means that nets still have a
> performance advantage, though I don't know how much.
> 
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> 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.
Received on Wed Jul 11 01:15:08 2007

This archive was generated by hypermail 2.1.8 : Wed Jul 11 2007 - 01:15:24 PDT