>2. The NUMBER 1 RULE of writing VHDL or Verilog IMHO is: eliminate ALL
>warnings. Almost every time I've encountered a problem with someone's
>code it's been traced back to a warning they should NOT have ignored.
>While warnings are "normal" to most people in most programming
>languages, IMHO 0 warnings is the only way to stay out of a huge amount
>of trouble when coding in HDLs. 
>
Warnings are to be avoided in any programming language, if not for the 
simple fact that if you have a bunch of warnings every time you compile, 
when you have a real problem YOU WON'T SEE IT because it is camouflaged 
in all of the warnings. In C++ if you have a warning that you understand 
completely (and you're REALLY POSITIVE you understand it) and absolutely 
don't want to "fix" the code to please the compiler, some compilers 
allow you to squelch the warning for that single line of code using a 
#pragma directive. Otherwise comment the heck out of it so you'll 
remember why you left it when you revisit your code in 6 months and 
can't remember any of it.

I once worked for a company that had a program that dealt with sensitive 
data. When building the product, the compiler would belch out hundreds 
and hundreds of warnings. As the poor sap who had to maintain that 
blinking mess, I'll tell you it was more than a bit disconcerting. After 
making a change and recompiling the $64,000 question was always: "Did I 
cause one of those?" The best we could do was count the warnings in our 
module before the change and after and look for a delta. Not good. But 
we were in a Catch-22 situation: fixing the warnings would likely break 
the program, not fixing them was nearly as dangerous.

Don't paint yourself into a corner, fix all warnings and set your 
warning level as high as practical when programming in C/C++ or 
programming language X.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist