( ESNUG 469 Item 7 ) -------------------------------------------- [09/27/07]
Subject: ( ESNUG 468 #5 ) Even the French think Cliff is wrong about this!
> Cliff's gone a bit far with this on the "default_nettype none" directive.
> He cannot justify his "guideline" to not use this directive.
>
> - Mark Curry
> Intuitive Surgical, Inc. Sunnyvale, CA
From: Bertrand Cuzeau <cuzeau=user domain=alse-fr hot mom>
Hello John,
This mail's about "`default_nettype none" and I also don't agree with Cliff.
How about a new Verilog directive:
`giveup_Verilog_laxity_for_VHDL_rigorism ?
We are a design house in Paris and we design between 40 and 80 projects per
year, both with Verilog and VHDL (though more in VHDL than in Verilog).
We also teach HDL languages (VHDL, Verilog, System Verilog, SystemC).
When I discovered "`default_nettype none", I thought as many designers: "it
won't change the world, but it's a little help in detecting a few typos".
However, I noticed that it forces you into adding some stupid net type
declarations in the ports, which is clumsy since Verilog rules are (mostly)
unambiguous as of the net types in ports.
(A) I think auto-declaring *nets* is what should be outlawed, not
net *types* !
(B) I also think that allowing the use of objects that have not been
declared is a bad feature in a language. :-( In VHDL, only the
loop index is like this, but I don't lose sleep over it: VHDL
signals and variables *must* be declared to before being used !
So my recommendation in terms of Verilog coding style would be :
"If the module instanciates some submodules, use `default_nettype none
and suffer the very minor penalty of completing the port declarations.
If the module is a leaf (bottom of hierarchy), do not bother."
In practice it means to enforce the use of "`default_nettype none" in *any*
case (because you often don't know for sure that a module instanciation
won't be added later.) To sum it up:
I more *agree* with using "`default_nettype none" than I disagree.
But I also think there is more to it, see below.
Note that my personal coding rules also say "don't use Verilog primitives!"
(continuous assignments are more powerful anyway). I don't see *any*
advantage in using primitives for RTL code, so I do not really get Cliff's
point or agree with him at all. Mistyping a "rl" for "r1" is always caught
when using assign statements and is caught with the nettype clause when
instanciating user modules.
Now, if we think about all this, the *real* issue is that Verilog is so lax
(as opposed to VHDL) that you MUST use a linter, if only to get rid of all
the stupid typos, cut & paste type errors, vectors of wrong size, malformed
constants, etc. I see two practical solutions available today:
1- If you can afford it, use a "super" linter (one with a formal engine,
also able to detect a lot of design errors like CDC issues, etc.)
2- If you're on a tight budget (like when you design only FPGAs and your
project can't afford ASIC-class tools), then use your *synthesis* tool
as a linter! This won't work for test benches (fixtures), but that's
slightly off-topic in this discussion.
The second solution won't cost you anything (FPGA synthesis tools are free)
and it will detect a lot more inconsistencies than a plain linter would.
Some tools (like Quartus' Design Assistant e.g.) will even spot relatively
subtle design issues (CDC, reset policy, asynchronous loops through the
hierarchy, etc.)
With 1 or 2, you won't have to care about default_nettype any more.
In our FPGA projects, I enforce the following methodology :
- Each and every module/entity must have a test bench (fixture)
and must be unitary-tested with appropriate coverage etc...
- Each and every module/entity must go through unitary synthesis & DRC,
and should not generate warnings. This delivers another advantage:
getting very early an estimation for area and timing.
This policy is simple to enforce and gracefully addresses (I think) most of
the linting concerns. In Verilog, it's just appropriate to start with
synthesis rather than with simulation. (We do the opposite in VHDL.)
- Bert Cuzeau
ALSE Paris, France
Index
Next->Item
|
|
