Cliff, I like your idea of having default nettype set to "logic". As for your thoughts on allowing a net to be driven inside a procedural block, I think that would add more confusion then help. I have recommended, when I did training, and now within the ears of my current employer to use the logic type everywhere except when a signal has multiple drivers and only then to use the "tri" net type. dm Clifford E. Cummings wrote: > >> 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 > > -- ========================================================== Don Mills mills@lcdm-eng.com www.lcdm-eng.com ========================================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jul 3 11:16:59 2007
This archive was generated by hypermail 2.1.8 : Tue Jul 03 2007 - 11:17:29 PDT