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

>Hi, Brad -
>
>Thanks for digging up this historical summary. Prior to reading this, I
>thought that uwire was worthless. Now I believe it is only almost
>worthless.
>
>Is anybody using uwire?? Has anybody found a good use for uwire??
>
>I now see that uwire net collapsing can find resolved drivers upstream
>in instantiated modules. This is not necessarily a good thing as the
>module might just be a behavioral representation of instantiated IP with
>a single driver, plus the multiple drivers would have been caught if the
>IP developer had used logic-type outputs.
>
>I see that default_nettype uwire can force all implicit wires to be of
>an unresolved type, which means we now have two data types that can be
>driven with continuous assignments (wire and uwire) but the declarations
>must be changed when the assignment is converted into a procedural block
>assignment (I *hate* this - and so do the majority of Verilog users!).
>
>----- default_nettype rules relaxation -----
>
>I would rather see the default_nettype rules relaxed to allow variable
>types for the default type:
>default_nettype logic (which would have caught the same multi-driver
>module in the historical example and still allow procedural assignments
>to implicit variables).
>
>----- wire assignments from a procedural block -----
>
>We have relaxed the restriction that variable types could not be driven
>from modules or continuous assignments. I would *again* like to propose
>that we do the same for wires and procedural assignments.
>
>In SystemVerilog, if one declares logic variables, one can EITHER make
>one or more procedural assignments to the variable -OR- a single
>driver-assignment (most commonly: module output or continuous
>assignment), BUT NOT BOTH. First usage determines if the variable will
>be treated like a variable or a single-driver net.
>
>I would like to propose that we allow nets to be EITHER driven by one or
>more continuous assignments -OR- assigned from a single procedural block
>(similar to the always_type one-block restrictions), BUT NOT BOTH. First
>usage again would determine if the net behaves like a resolved net type
>or as a procedural variable.
>
>wire -vs- reg declarations continues to be one of the biggest headaches
>for new Verilog users (and experienced Verilog users!) I teach engineers
>that this is just a very silly rule of the Verilog language!
>
>If I want resolved types, I would prefer to declare everything as wire
>types. engineers think in terms of wire connections and making a
>procedural assignment to a wire is not foreign to hardware designers.
>
>I know Stu had once objected to this proposal because declared wires
>would be reported as reg-variables in VPI applications. I would like to
>suggest that experienced VPI users will not be very confused, VPI usage
>is diminishing to more of a vendor application (in favor of DPI
>coding) and that new Verilog users would hail this capability as it
>would remove one of the most confusing issues to new Verilog users (reg
>-vs- wire and blocking -vs- nonblocking are the two most confusing
>issues to new Verilog users).
>
>Is anybody interested in procedural assignments to wires??
>
>Regards - Cliff
>
>At 10:51 AM 7/2/2007, you wrote:
> >Here's some history on 'uwire'.
> >
> >        http://boydtechinc.com/btf/archive/btf_2004/2372.html
> >
> >________________________________
> >
> >From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> >Sent: Monday, July 02, 2007 10:45 AM
> >To: Brad Pierce; sv-bc@eda.org
> >Subject: RE: [sv-bc] minor wire issues
> >
> >
> >Then why did we need uwire?

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


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