Hi, All - Don raises a good point. Today in SystemVeirlog training, I believe a number of us recommend using the logic type and then tell users to only make wire declarations when multi-driver-resolution is needed. `default_nettype logic would be a useful extension, because then we would not have to declare all of the ports to be of type logic. The reason I still believe allowing procedural assignments to wires are useful is for the Verilog folks. I now realize that I would need to convince EDA vendors to allow this capability even without turning on the various SystemVerilog switches. That is the one downside to combining the standards, legacy Verilog compilers might not allow this new capability. Allowing procedural assignments to wires would still be fully Verilog backward compatible in the same way that continuous assignments to reg's are backward compatible. Why? Because it was never allowed before so there is no code that collided with the capability. Allowing procedural assignments to variables is primarily for the Verilog users, and yes, I still do a fair amount of plain-old Verilog training and we devote way too much time to reg -vs- wire explanation and debugging. Every time I show reg -vs- wire requirements to a VHDL team looking to adopt Verilog, I am asked "what value is there in changing a wire to a reg just so I could change the continuous assignment to a procedural assignment?" And it is just fodder for the passionate VHDL coders who are looking for more reasons to block the use of Verilog at their companies. Allowing a procedural assignment to a wire would permit simple transition consistency to VHDL users: - logic-type is roughly equivalent to std_ulogic. - wire-type would be roughly equivalent to std_logic. Allow procedural assignments to nets without requiring the application of a SystemVerilog command line switch and almost half of the complaints about Verilog will disappear. Regards - Cliff At 11:12 AM 7/3/2007, Don Mills wrote: >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 >> >>---------------------------------------------------- >>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.Received on Tue Jul 3 14:22:54 2007
This archive was generated by hypermail 2.1.8 : Tue Jul 03 2007 - 14:23:16 PDT