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

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. The uwire
feature in only useful when mixing top-level legacy Verilog modules with
lower level SV modules; a very unlikely scenario.

I think allowing a single procedural assignment to a wire would be very
diffucult to enforce with current port colapsing behavior and the fact
that port direction is meaningless for wires. Single procedural
assignments for variables is localized to a maodule for variables.

Dave


-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Clifford E. Cummings
Sent: Monday, July 02, 2007 3:49 PM
To: sv-bc@server.eda.org
Subject: [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.


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