( ESNUG 468 Item 5 ) -------------------------------------------- [09/13/07]

Subject: ( ESNUG 467 #15 ) Cliff is out-to-lunch on "default_nettype none"

> 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??
>
>     - Cliff Cummings
>       Sunburst Design, Inc.                      Beaverton, OR


From: Mark Curry <mark.curry=user domain=intusurg not calm>

Hi John,

Cliff's gone a bit far with this on the "default_nettype none" directive.
He cannot justify the "Guideline" to not use this directive.

His example indicates that using the directive "Can Add Bugs".  The example
shows no such thing.  At best, his mis-declaration of "nl" instead of "n1"
is a false negative error where the compiler yelled at him, but the code
would have worked fine.

I take the opposite view.  The error was real, and I'd liked to know it.
Even if the sim had coincidentally worked, had the error been ignored.

Cliff mentions that he's working on a paper with more examples.  Maybe I'm
missing something and his paper will show something unique, but I can't
think of ANY situation where adding that directive will INTRODUCE a bug.

It's funny the timing of these things.  In the past, I've rarely bothered
to declare single bit wires.  And sure, I liked to taunt my VHDL frieds
about space savings.  But with the System Verilog .name port connection
method requiring explicit declarations of everything, I've started
declaring everything.

And recently I've just started using that directive -- and I've found it
quite helpful.  But I understand others may not like it.  And since this
is one of those directives that are sticky (so the next module that
the compiler/simulator sees will follow it) I'm kind to the next designer
and return the default to wire. =20

So, my module header/footer:

   `default_nettype none
   module xxx
   (
     input  wire clk,
     input  wire reset,
     input  wire [ 7 : 0 ] d,
     output wire [ 7 : 0 ] q
   );
   ...
   endmodule
   `default_nettype wire

OK, so adding all those "wire" declarations to the inputs is more text;
but the ANSI-C style headers still make it compact.  And most of the
coding guidelines we now use are one port per line -- and I've got a nice
wide monitor -- even with the longest port names, complex parameters, and
comments it doesn't take much horizontal width in my window for those
four extra letters and a space.

I see no use for Cliff's junk with new `report_dangle switches, etc.  We've
got all the tools already.  No need to add more clutter, use the tools that
we have now, or don't -- designer's choice.  But, unlike Cliff's other
excellent guidelines, this one isn't justified.

    - Mark Curry
      Intuitive Surgical, Inc.                   Sunnyvale, CA

         ----    ----    ----    ----    ----    ----   ----

From: Stu Sutherland <stuart=user domain=sutherland-hdl not calm>

Hi, John,

Regarding ESNUG 467 Item 15, "Cliff goes all postal on 'default_nettype
none'", I do not share Cliff's feelings that this Verilog feature is evil.

In my opinion, the only bad characteristic of this language feature is that
it is a compiler directive.  This means that it has the same side effect as
most other compiler directive, in that it can affect not just the intended
module, but other modules in other files, as well.  As with other Verilog
compiler directives, the savvy engineers needs to remember to turn compiler
directives on when wanted, and turn them off at the end of a module or file.
I emphasize this important coding style in my training classes.

I think that System Verilog has a better way to force all nets to be
declared, without side effects.  The better way is to use the System Verilog
".name" and ".*" module instantiation shortcuts.  I am surprised that Cliff
did not mention these, as I know he is a big proponent of using ".*".  Some
advantages of these System Verilog shortcuts are:

  - The shortcuts are local to a module (no side effects like compiler
    directives have).

  - The shortcuts require that internal nets be explicitly declared, the
    same as "`default_nettype none" requires.

  - The shortcuts will infer nets from the containing module's port list
    ("`default_nettype none" requires that the containing module's ports
    also be explicitly declared as nets or variables).

  - The shortcuts check for and prevent port connection mismatches, such as
    incorrect vector sizes and incompatible types ("`default_nettype none"
    only checks that names match -- it will still let a 1-bit wire be
    connected to an 8-bit port, for example).

  - By using these shortcuts, net names only have to be declared, the names
    are not duplicated in the netlist (using just "`default_nettype none" in
    a Verilog-style netlist requires names be typed in both the net
    declarations and then typed again each place they are used in the
    netlist).

The last advantage, above, means a typographical error cannot occur in the
netlist, which is the type of error "`default_nettype none" is designed to
prevent.  The shortcuts do still have the disadvantage of "`default_nettype
none" that Cliff does not like, which is that a typographical error in the
declarations will be reported as a problem at some line number in the
netlist, rather than at the line number where the error exists. 

I agree with Cliff that a new enhancement to Verilog or System Verilog that
detects dangling nets would be useful.  I will support such an enhancement
on the standards committee when Cliff makes the formal proposal (but will
argue that it should not be a compiler directive, as that would have the
same bad side affects as "`default_nettype none").  With or without an
enhancement to detect dangling nets, though, the System Verilog ".name" and
".*" shortcuts can eliminate most netlist errors.  The "`default_nettype
none" Verilog feature can also eliminate most netlist errors, but users need
to be aware of its side effects and use the construct correctly.

Cliff and I will probably always disagree as to whether "`default_nettype
none" has any value.  I think it does solve problems, but that SV has an
even better way to solve those problems.  One of the great things about
engineering is that there is often (always?) more than one right way to do
things, and we each get to have our own opinions on which right is the
best right.  :)

    - Stu Sutherland
      Sutherland HDL, Inc.                       Tualatin, OR
Index    Next->Item








   
 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)