need a cheap student edition FPGA

Thu Feb 17, 2011 8:04 pm   

Yes, it is easy to write bad (unmaintainable) code in both vhdl and
verilog.

The point I was trying to make is that just using 7 or 3'd7 is just as
bad as "111" in far too many cases.

Why is it 7 instead of 5? What is significant about 7? Or is it just
"all bits are set"? Is it a maximum value, a minimum value, an initial
value, "everything is on", "everything is off", or what? Does/should
the value track something else? A constant's declaration can tell the
reader all of that with code that gets verified by the tool every time
it is run.

I actually agree with your comment about being reminded of the exact
number of bits every time it appears. The code should be written such
that if the exact number of bits needs to change, it should require as
few manual changes to as few places in the code as practical. In that
regard, 7 may be preferable to 3'd7, but not to a well-defined
constant.

Andy

Thu Feb 17, 2011 10:19 pm   

Almost any embedded numerical constants are a sign of bad code. As you wrote, it doesn't tell you what it means. They should almost always - except in extremely trivial cases - be predefined (e.g. header file) constants using macros, parameters, enums, etc.

Tue Feb 22, 2011 2:10 pm   

On Donnerstag, 17. Februar 2011 04:08, unfrostedpoptart wrote:


You are putting a straw man up. I've done >$1M ASICs, and of course one of
the actions you should take is to implement a prototype in an FPGA, which
allows to exercise your design much better than simulation. Certainly, you
*also* should do simulations to test your design under artificial, but
controlled border conditions. And finally, using other tools to gather
informations for you can't be wrong.

The impression you are generating however is that compile+lint do 90% of the
work to achieve a good design. Never. Closer to 1%, I'd say. "If it
compiles, it's good" is a typical VHDL attitude, and can't be further from
the truth. It's probably a psychological problem: "because it was hard to
compile, it now must be good", but that's false reasoning. Writing VHDL
properly is just so much harder than writing proper Verilog.

--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Wed Feb 23, 2011 1:25 am   

On Tuesday, February 22, 2011 5:10:59 AM UTC-8, Bernd Paysan wrote:

Not at all. I'm just saying one important part of having a good design database is that it's syntactically clean. I didn't give any percentages of how important this is versus other testing, but even if it's only 1%, that's still a big deal in the face of NRE/re-spin costs and time-to-market.

David

Fri Mar 18, 2011 3:06 pm   

On Friday, March 18, 2011 1:19:12 AM UTC-4, aldorus wrote:

I find that having a simplified view of Verilog as a
simulation language helps me understand the rules a
bit better. If you think like a simulator, then a
reg or integer implies that the simulator needs storage
to compute the current value. A wire does not need
storage because it is continuously assigned or
connected to some other value for which the simulator
already has storage. This has nothing to do with the
type of procedural block within which the reg or integer
is assigned. For example a "reg" does not necessarily
imply storage in the actual hardware. If you were to
translate the Verilog procedure to a C program, however
the "reg" would require a variable.

Hope that isn't more confusing than helpful.

-- Gabor