( ESNUG 465 Item 7 ) -------------------------------------------- [06/28/07]
Subject: ( ESNUG 464 #1 ) A boatload of engineers on "default_nettype none"
> Has anyone had any experience using Verilog-2001's
>
> `default_nettype none
>
> compiler directive? This directive turns off Verilog's implicit net
> declarations, thereby making it necessary to explicitly declare all wires
> used in a module.
>
> Did using the directive solve problems in your Verilog code, or did it
> create new problems? Or did you use it just because you like having to
> declare every single wire?
>
> - Stu Sutherland
> Sutherland HDL, Inc. Tualatin, OR
From: David Spaniol <dspaniol=user domain=sarnoff bot calm>
Hi, John,
With regards to "`default_nettype none", we had an engineer insert it in
a commonly shared file and we have spent more time debating whether it
should be in there than fixing the lack of wire declarations or
commenting out the directive. To answer Stu's question, I think the
engineer who put it in there declared a wire, which had a fanout of more
than 1, and misspelled the wire's name somewhere in his code. Verilog
simply set the default net type to wire on this misspelled name and,
voila, he had a floating connection. (To me, this is just another
example of where VHDL is superior to Verilog.)
Having said that, it is odd that Verilog allows a default net type and
the synthesis and simulation tools accept it, but Verilog puts in a
directive to turn that feature off. My opinion is if the HDL allows it,
the tools don't choke on it, and the code is readily understood by
someone skilled in the art, then there is no reason to avoid using a
default net type. You can shoot yourself in the foot many ways and your
energy would be better spent getting your product out the door rather
than policing every little thing like this.
- David Spaniol
Sarnoff Corporation Princeton, NJ
---- ---- ---- ---- ---- ---- ----
From: Bertrand Cuzeau <cuzeau=user domain=alse-fr bot calm>
Hello John,
I did not see the respective point of views of Stuart & Cliff, but here is
my personal view about the issue in Verilog2k:
- The implicit declaration of nets is one of the curses in Verilog. The
issue is that a misspelling in a port map ends up with a broken
connection, no warning, and a tough to spot problem. Grrr.
- `default_nettype none does address this, but creates a stupid,
"by-product" in that the "non-reg" ports in the module declaration
will also be outlawed and require a "wire" qualifier, which is very
clumsy. Having to add "wire" to inputs looks real weird to me.
So my recommendation to Verilog users is to :
- use `default_nettype none for structural modules (with
instanciations)
- don't use it on pure RTL modules (I think it's really useless
in this case)
- it's probably a good idea to add "wire" in the port list, in
case. I'm not sure of how this would/should translate in System
Verilog, but I guess the situation will be similar due to the
upward compatibility.
What I would like to have is an attribute which outlaws implicit declaration
of nets, and not the type of properly declared nets!
Implicit object = no, implicit type =yes
Still in other words : the pragma is `default_net type, while, I would have
preferred `default_net none.
- Bertrand Cuzeau
Alse Paris, France
---- ---- ---- ---- ---- ---- ----
From: Jonathan Bromley <jonathan.bromley=user domain=doulos bot calm>
Hi, John,
It's always nice to see a playground fight. :-)
For me, the issue depends on whether you're using Verilog-2001/5 or System
Verilog.
In Verilog-2001/5, I *love* `default_nettype because it helps me catch
connection goofs much earlier; and I *hate* it because it forces me to
declare all my input ports, and some of my output ports, as wires. The
"makes you declare every wire" thing is fine: implicit declaration of nets
when they are wired to instance ports is OK for machine-generated netlists,
but a farcical source of potential errors in hand-written RTL. (Please,
please tell me you're not writing gate-level netlists by hand? Please? In
the 21st century?)
But it's a real PITA to have to write "input wire [7:0] yada" instead of
simply "input [7:0] yada". I think someone has suggested a modified version
of `default_nettype that doesn't suppress the default on ports, but only on
internal nets. I'd be very happy with that.
In System Verilog, at least two issues make things a tad more complicated.
First off, the cute new port connection syntax (like .A instead of .A(A),
and .* to wire up *every* port to a signal of the same name) stops default
nets from being created on any instance that uses the new style. Many
people will use these constructs in their RTL, so `default_nettype might
seem less valuable than it was. However, I can imagine a situation where
I *thought* I was getting protection against accidental creation of nets,
and then I change my port hookup syntax bak to the old Verilog style for
some reason, and suddenly I get default nets being created all over the
place. So I think I would like to have `default_nettype none here, too.
Secondly, the fact that you can have variables (that's reg-like things, for
any Verilog-95 dinosaurs out there) be driven by a single continuous
assignment, or across an input or output port connection, means that it's
almost always necessary to declare your ports in full every time. Cliff,
and (I think) Stu too, recommends using variables *everywhere* in your
System Verilog RTL, reserving nets only for those very few places where you
really need resolution of multiple drivers. If I follow this guidance, I
need to declare the variable type of every input and output port, just as
I would if using `default_nettype none in Verilog-2001. So I would lose
absolutely nothing by using `default_nettype none, and I gain just a little
compile-time checking -- which, let us all admit, is a commodity in
embarrassingly short supply in Verilog.
- Jonathan Bromley
Doulos Ltd. Ringwood, UK
---- ---- ---- ---- ---- ---- ----
From: Greg Tumbush <greg_tumbush=user domain=amis bot calm>
Hi, John,
I think verilog's implicit net declaration is one of it's worst "features".
I've been bitten by this on so many occasions that the `default_nettype none
compiler directive goes into EVERY piece of code I write and I encourage
others to put it in their code as well.
- Greg Tumbush
AMI Semiconductor Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: [ Hello, Kitty ]
Hi, John,
Make Me Anon
On Item #1, We did not use this directive continuously, but as testbench
lead I did activate it several times on our last project to help identify
failed digital connectivity within Verilog-AMS integration layers and design
blocks. So, I would say it solved functional problems at the expense of
needing to add declarations... a fair tradeoff.
On the purely digital hierarchy (embedded core, memories, peripherals) we
heavily leveraged Verilog-mode in emacs for AUTOARG, AUTOPARAM, AUTOINPUT,
AUTOOUTPUT, AUTOINST, and AUTOWIRE, and followed a strict project-defined
naming convention so that everything connected up correctly. This was
highly automated and worked very well for us.
- [ Hello, Kitty ]
---- ---- ---- ---- ---- ---- ----
From: Tom Mannos <tjmanno=user domain=sandia.gov>
Hi, John,
Are Stu and Cliff kidding me??
Now that I know it exists, on all my future projects I'm going to REQUIRE
that directive to be at the top of everyone's code. You don't know how many
unconnected nets we've had to diagnose because they were spelled differently
or had different capitalization. We do pretty thorough code reviews, but
sometimes even a room full of people doesn't catch on that "read" and "raed"
are not the same signal...
- Tom Mannos
Sandia National Labs. Albuquerque, NM
---- ---- ---- ---- ---- ---- ----
From: Duth Vidyanandan <premduth.vidyanandan=user domain=xilinx bot calm>
Hi John,
Regarding "`default_nettype none", I have an incident that I figured would
help out as well.
In Xilinx, we had multiple customers who were using this setting and it was
causing linter issues with our libraries as our libraries do not have all
the net types defined. I am not sure why they did this, although we took an
action to change all our models to accommodate this.
- Duth Vidyanandan
Xilinx, Inc.
---- ---- ---- ---- ---- ---- ----
From: Shalom Bresticker <shalom.bresticker=user domain=intel bot calm>
Hi, John,
We don't like implicit net declarations on continuous assignments or on
module instance port connections, but the problem with the `default_nettype
none directive is that it also prevent implicit declarations on port
declarations, e.g.
module m;
input [4:0] p;
creates an implicit
wire [4:0] p;
declaration, and this we do want. The "`default_nettype none" does not
allow that today. We have opened Mantis 1747 to allow such an option.
- Shalom Bresticker
Intel Corp. Jerusalem, Israel
---- ---- ---- ---- ---- ---- ----
From: Lars Sundell <lars.sundell=user domain=nordicsemi.no>
Hello, John,
When I first discovered the `default_nettype none directive I liked the idea
of using it to avoid implicit declaration of nets. I believe that this can
save some debugging time, especially for hierarchical levels and for
assertion code.
I have only tested this with Mentor's QuestaSim (6.2f).
Unfortunately, I had to resign from using it due to a bug in Questa that
caused the compiler to give syntax error messages for tasks with inputs
of type int or logic vector (and propably other packed array types). Due to
this error I have not discovered any pros or cons for the directive.
- Lars Sundell
Nordic Semiconductor Trondheim, Norway
---- ---- ---- ---- ---- ---- ----
From: Rob Larkin <Rob.Larkin=user domain=analog bot calm>
Hi, John,
In my opinion undeclared wires are a sign of last minute hacks to the code
(but then I was a VHDL guy in a former life, so I'm used to much stricter
declarations). Usually I catch these in Design Compiler, but I have added
'strict compile' options to our simulation environment to run with a default
net type of none. This is great as far a lint mechanism for your own code
goes, but unfortunately you're then exposed to all the warnings produced by
undeclared nets in the third party modules (RAM models, etc). So yes, the
command is useful, but does create it's own problems, too, sometimes.
- Rob Larkin
Analog Devices, Inc. Cambridge, England
Index
Next->Item
|
|
