What is a "bug", and what is "good code"? (or: more default_

[Evan Lavelle]

Some of you may have seen Cliff Cumming's item in the current Deepchip
(http://www.deepchip.com/items/0467-15.html), where he takes exception
to the usage of "default_nettype none". I spent a couple of minutes
looking at his example code, and couldn't see the error it it:

`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 // adder2

Finally, it dawned on me that the wire declaration is for "n-ell", and
the wire connecting the primitives is labelled "n-one". Compiling the
code gives the obvious error messages:

ERROR:HDLCompilers:28 - "foo.v" line 6 'n1' has not been declared
ERROR:HDLCompilers:28 - "foo.v" line 7 'n1' has not been declared
ERROR:HDLCompilers:28 - "foo.v" line 9 'n1' has not been declared

Cliff's point is that he doesn't like 'default_nettype none' because,
to summarise, "Declarations Can Add Bugs", "a flawed declaration
causes code that would otherwise work, to fail", and "code is good but
error reported".

Is there a bug in this code? In my book, a "bug" is something which is
*not* caught by the compiler, and which causes an error at *runtime*.
If the compiler catches a problem, then that's simply a syntax error
of some sort. In this case, the problem is trivial and is easily fixed
once the compiler has caught the problem; it's not a "bug".

Second, the comments in the code state "code is good but error
reported". Surely the point is that the code is *not* good, and the
compiler has correctly identified this? Yes, in principle, the code
would have been good if default_nettype had *not* been set to none,
but so what?

Third, the problems caused by implicit nets, when default_nettype is
not set to none, are actually (or can be) real bugs, in that they get
through compilation and cause a runtime failure, which can be
difficult to detect and fix.

Or have I missed the point?

Evan

 

[Jonathan Bromley]

On Thu, 26 Jul 2007 12:24:57 +0100,
Evan Lavelle <nospam@nospam.com> wrote:

Some of you may have seen Cliff Cumming's item in the current Deepchip
[...]
Or have I missed the point?

Don't start. Just don't start.

There are some limitations to "`default_nettype none", for sure.
Cliff has suggested some new syntax to address what he perceives
to be the most urgent of those limitations. But Cliff's ideas
about the best way to write clean, bug-free code are, shall
we say, somewhat divergent from mine. I have made only very
limited contributions to the discussion of this on the
SystemVerilog committees, out of respect for my blood pressure.

No, I don't think you have missed the point. But others certainly
would think so.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[gabor]

On Jul 26, 7:24 am, Evan Lavelle <nos...@nospam.com> wrote:

Some of you may have seen Cliff Cumming's item in the current Deepchip
(http://www.deepchip.com/items/0467-15.html), where he takes exception
to the usage of "default_nettype none". I spent a couple of minutes
looking at his example code, and couldn't see the error it it:

`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 // adder2

Finally, it dawned on me that the wire declaration is for "n-ell", and
the wire connecting the primitives is labelled "n-one". Compiling the
code gives the obvious error messages:

ERROR:HDLCompilers:28 - "foo.v" line 6 'n1' has not been declared
ERROR:HDLCompilers:28 - "foo.v" line 7 'n1' has not been declared
ERROR:HDLCompilers:28 - "foo.v" line 9 'n1' has not been declared

Cliff's point is that he doesn't like 'default_nettype none' because,
to summarise, "Declarations Can Add Bugs", "a flawed declaration
causes code that would otherwise work, to fail", and "code is good but
error reported".

Is there a bug in this code? In my book, a "bug" is something which is
*not* caught by the compiler, and which causes an error at *runtime*.
If the compiler catches a problem, then that's simply a syntax error
of some sort. In this case, the problem is trivial and is easily fixed
once the compiler has caught the problem; it's not a "bug".

Second, the comments in the code state "code is good but error
reported". Surely the point is that the code is *not* good, and the
compiler has correctly identified this? Yes, in principle, the code
would have been good if default_nettype had *not* been set to none,
but so what?

This is a case where the code using a default nettype would in
fact work at runtime. I would agree that it is not "good" in
the sense of good design practice. The code would not be "good"
in either sense if the nets were not scaler or otherwise default
as in:
wire [3:0] nl, a, b; // "n-ell"

Third, the problems caused by implicit nets, when default_nettype is
not set to none, are actually (or can be) real bugs, in that they get
through compilation and cause a runtime failure, which can be
difficult to detect and fix.

Or have I missed the point?

Evan

I doubt you missed the point. One of the biggest problems
in verilog is the promiscuity of the compilers. This means
that little items like mis-matched widths on module ports
are buried in the sea of inevitable warnings in your
synthesis report. Any tool at your disposal for reducing
these problems, like default_nettype, should not be discarded
for the simple reason it breaks code that happened to work
for a degenerate case.

Just my 2 cents,
Gabor