( ESNUG 467 Item 15 ) ------------------------------------------- [07/26/07]
Subject: ( ESNUG 465 #7 ) Cliff goes all postal on "default_nettype none"
> 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: Cliff Cummings <cliffc=user domain=sunburst-design bot calm>
Hi, John,
Concerning the benefits of `default_nettype none usage ... forgive me while
I hurl!
In this discussion, I recognize a number of colleagues who have already
responded and many of them have strong VHDL backgrounds, so I am not
surprised to see their support for the `default_nettype none abomination.
Verilog-2001 added the terribly flawed ability to require all wire
declarations by issuing the `default_nettype none directive to a design.
The purported advantages of using the `default_nettype none directive are
overrated, and positive reviews of this directive miss important shortfalls,
the potential introduction of new mistakes, required verbosity, and problems
related to instilling a false sense of comfort, confidence and security.
The `default_nettype compiler directive is the greatest abomination added to
Verilog-2001 and it offers a false sense of security to its users. This
switch does not achieve the desired goal of identifying all typos and
unconnected nets in a module. In fact, this switch can actually contribute
to the insertion of new mistakes into a design.
Guideline: Do not use the `default_nettype none compiler directive!
The question is, can we achieve the sure-connections goal using other
techniques and could vendors offer a superior capability to solve the actual
misspelled-identifier and unconnected-net problems? (See my proposal for a
solution below.)
Why do languages like VHDL require all signals to be declared?
The intent of making declarations is to catch mistakes related to typos in
identifiers used in design and verification code. The assumption is that
when signals are properly declared, a mis-typed identifier in the actual
design or verification code will be flagged as an undeclared identifier,
causing the engineer to recognize the mistake in the code. To the extent
that all declarations are spelled correctly and all mis-spelled identifiers
exist in the body of the code, the intended goal is largely (but not fully)
achieved.
Does the `default_nettype none compiler directive enforce the same VHDL-like
restrictions when added to Verilog designs? No!
VHDL requires declared identifiers to match in both name and usage size.
This is part of the strong-typing VHDL philosophy intended to catch errors
before they happen. In Verilog, one could add the `default_nettype none
compiler directive to a design, add correctly named declarations but
incorrectly size the declared identifiers and no error will be reported
(this can be very difficult to debug!)
Even in VHDL, the required declarations still cause problems. I worked on
one large VHDL ASIC design years ago where not only were the declarations
required, but company guidelines required that each declaration be on a
separate line and a comment describing the signal or bus be attached to the
end of the line. The declarations spanned multiple pages and I found that
I made as many typos in the declarations as I did in the body of the code.
I received multiple error messages related to the correctly coded body-code
and spent too much time trying to figure out why my CORRECT body code was
getting errors, only to discover later that I misspelled the identifier name
in the declaration.
I also spent large amounts of time debugging another VHDL design where the
body code identifier was spelled correctly in one place, the body code
identifier was misspelled in another place, but an engineer had obviously
added another declaration to the pages of existing declarations to get past
the compilation error. This gave two very similar declarations on different
pages and was a nightmare to debug (because the model compiled and I could
find declarations for the code that did not seem to work).
Declarations Can Add Bugs
Below is one of many examples that I have seen showing a small contrived
design where adding the `default_nettype none compiler directive actually
forces more declarations and in this case, a flawed declaration causes code
that would otherwise work, to fail. (I have more examples that I intend to
include in a paper on this topic)
`default_nettype none
module adder2 (output wire sum, co,
input wire a, b, ci);
wire nl, n2, n3; // Error in added declaration
xor g1 (n1, a, b); // code is good but error reported
xor g2 (sum, n1, ci); // code is good but error reported
and g3 (n2, a, b, ci);
and g4 (n3, n1, ci);
or g5 (co, n2, n3);
endmodule
Is there a better solution??
I believe there is. The real intent of making declarations is to find the
dangling connections. Why not just add compiler directives and a compiler
switch to find "dangles" in the design? Something like this to embed:
`report_dangles on
`report_dangles off
To check from a -dangles command line switch
The dangle-checker should reports errors when:
- scalar net or variable has driver(s) but no receiver
- vector net or variable has driver(s) but no receiver on
one or more bits in the vector
- scalar net or variable has receiver(s) but no driver
- vector net or variable has receiver(s) but no driver on
one or more bits in the vector
- scalar or vector nets or variables have no driver(s) OR
receiver(s) (declared net or variable is not in use;
to remove the clutter from the design)
There is more to this pending proposal but it gives the main idea: identify
dangling nets and unused nets so the user will be forced to fix them. If
every net in the design has a source and a destination, the connections are
likely to be good. If any nets only have drivers or receivers, it is
probably a mistake. If a net has neither drivers nor receivers, it is
probably a left over declaration from earlier obsolete code and should be
removed because it is only adds to the clutter and confusion.
I am open to input on this pending proposal.
Please, Pa-leeze, don't force designers to use the `default_nettype none
compiler directive!
I know, I know ... `default_nettype none would have caught my misspelled
Pa-leeze in this sentence. :-)
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
Index
Next->Item
|
|
