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

(I hit send to quickly)

Stu, Steve,

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 there.

In fact, Steve's change to 1800-2005 made the port definition 'input
logic a;' actually default to the wire kind. See 22.2.2.3 Aggregate
ports. BTW, I think this section is improperly titled. It should be
something like "Additional port features"

Dave


> -----Original Message-----
> From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
> Sent: Tuesday, July 10, 2007 12:19 PM
> To: sv-bc@server.eda.org; Rich, Dave
> Subject: RE: [sv-bc] uwire & wire -vs- reg
> 
> Steven,
> 
> This is very valuable information, and I appreciate your sharing it.
I
> adopted the modeling style long ago of declaring all ports as a logic
> type,
> except for bidirectional busses.  I also teach my students that style.
It
> makes writing Verilog coding much easier and faster, and tremendously
> shortens the learning curve for new Verilog users.  Verilog user's
love
> this
> simplification of the language!  In addition, a major Verilog user
company
> presented a great paper at DAC about three years that discussed how
the
> single-source semantics of the logic type helped expose functional
errors
> in
> a large design with lots of continuous assignments that would have
taken
> much longer to find and debug if nets had been used.  That paper was
> before
> uwire was added to the language, which would also have exposed those
> coding
> errors.
> 
> Prior to this new information about the possible impact on
performance, I
> saw little need for Cliff's recent idea of allowing procedural
assignments
> to nets.  Being able to use the logic type almost everywhere
simplifies
> the
> language enough (at least in regard to data declarations).  Based on
your
> comment, I now fully endorse Cliff's suggestion.  I want to be able to
use
> net types everywhere, including for procedural assignments.  That will
> give
> me the language simplification that is needed, without the risk of
losing
> the performance optimizations of port collapsing.
> 
> Cliff, I would like to encourage you to write up a full proposal on
the
> exact changes to the LRM (including BNF) for this enhancement, and
create
> a
> Mantis item for the enhancement request.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Steven Sharp
> > Sent: Tuesday, July 10, 2007 11:24 AM
> > To: cliffc@sunburst-design.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>
> >
> > >Cliff,
> > >
> > >The 'net' kind is essentially a builtin resoltion function
> > that has no
> > >stored value (trireg being an exception). I believe that
> > going forward
> > >in SV, you should always recommend using variables for all signals
> > >except in cases where multiple drivers are anticipated.
> >
> > This has the potential to seriously impact simulation performance,
> > depending on the details of the implementation.  Port-collapsing
> > of nets has major performance advantages.
> >
> > 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.