I'd Rather Switch than Fight!

R

rickman

Guest
I thought a few of you might be interested in how my trial switch to
Verilog for my last project went. I have to say although there were
some surprises all in all it was a success and showed me that Verilog
is a lot easier to use and live with than Verilog.

One of the surprises was just the predicted issue of signed arithmetic
when defaults are used. I made a mistake of treating a counter as an
integer and used an expression like (0 > (count - 1)). In simulation
this never became true because the counter just wrapped around as an
unsigned number. That was a victory for strong typing! But I found
that relatively quickly and only scratched my head for a couple of
minutes. However, this was a small project and I'm sure on a larger
project this could be a more time consuming issue. So in the future I
need to learn the exact rules for signed and unsigned arithmetic so I
can develop a style that lets me work without causing this type of
error.

I found a few things I could do in Verilog easily that I thought I
couldn't do in VHDL. But when I dug into them more the real issue was
that I was working with an older compiler that included Verilog 2001,
but did not include VHDL 2008. It's amazing what can happen in a mere
seven years!

But the big thing was just how easy it is to write in Verilog compared
to all the verbosity of VHDL. Not just the extra typing, but extra
thinking that had little to do with addressing the design problem but
rather how to work with the language to express my solution to the
design problem. Even my test bench was a lot easier writing than my
typical test benches in VHDL. The readmemh system task was great! I
could even add comments to the data file!

The hardware for my design has not been built yet, so the design has
not been tested in the chip. But my record is usually that the design
works pretty well right out of the box. But then most of my designs
aren't all that complex. I haven't done a large design in years.
Although, a small design today was a large design 10 years ago....

Rick
 
On 02/05/2011 04:22 AM, rickman wrote:
I have to say although there were
some surprises all in all it was a success and showed me that Verilog
is a lot easier to use and live with than Verilog.
I have similar feelings about VHDL :)

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
 
On Feb 4, 10:22 pm, rickman <gnu...@gmail.com> wrote:
I thought a few of you might be interested in how my trial switch to
Verilog for my last project went.  I have to say although there were
some surprises all in all it was a success and showed me that Verilog
is a lot easier to use and live with than Verilog.

One of the surprises was just the predicted issue of signed arithmetic
when defaults are used.  I made a mistake of treating a counter as an
integer and used an expression like (0 > (count - 1)).  In simulation
this never became true because the counter just wrapped around as an
unsigned number.  That was a victory for strong typing!  But I found
that relatively quickly and only scratched my head for a couple of
minutes.  However, this was a small project and I'm sure on a larger
project this could be a more time consuming issue.  So in the future I
need to learn the exact rules for signed and unsigned arithmetic so I
can develop a style that lets me work without causing this type of
error.

I found a few things I could do in Verilog easily that I thought I
couldn't do in VHDL.  But when I dug into them more the real issue was
that I was working with an older compiler that included Verilog 2001,
but did not include VHDL 2008.  It's amazing what can happen in a mere
seven years!

But the big thing was just how easy it is to write in Verilog compared
to all the verbosity of VHDL.  Not just the extra typing, but extra
thinking that had little to do with addressing the design problem but
rather how to work with the language to express my solution to the
design problem.  Even my test bench was a lot easier writing than my
typical test benches in VHDL.  The readmemh system task was great!  I
could even add comments to the data file!

The hardware for my design has not been built yet, so the design has
not been tested in the chip.  But my record is usually that the design
works pretty well right out of the box.  But then most of my designs
aren't all that complex.  I haven't done a large design in years.
Although, a small design today was a large design 10 years ago....

Rick
Be careful with $readmemh for synthesis. In XST there are a lot of
restrictions, although some may have been fixed since 10.1i:

1) One value per line
2) No addressing in the data file
3) No comments in the data file
4) The file must have exactly the number of elements as the array to
be initialized, or the entire initialization process is thrown out
and the array ends up at defaults (all zero).

That being said, I was still pleasantly surprised that XST
actually allowed me to use $readmemh at all. It's definitely
easier than dealing with their 256-bit INIT vectors for
instantiated block RAM.

I've heard the buzz about Verilog and signed arithmetic, but
have to confess I never really ran into this because I don't
do much with signed numbers in practice, and when I do I
still write the code as if the numbers were unsigned and
deal with the real meaning of the 2's complement numbers
in my head. The only place I usually run into trouble is
when I generate a core using CoreGen and don't realize that
the customization process slipped in signed operands
when I wasn't looking.

I do some maintenance of VHDL code written by others, but
generally write my own in Verilog just because I'm much
more productive with it. There are very few things about
VHDL that I might wish I had in Verilog, but one nice one
is enumerated types. I see these usually for FSM states
and like the way you don't need to muck with the
encoding even when you know the encoding gets munged
in synthesis anyway. It's also nice to see the state
names pop up in the simulation waveform without having
to define a type for it in ModelSim.

One thing I don't miss is strong typing. It seems
draconian that you need to write a constant for
a 5-bit quantity in binary, or use a type conversion.
I almost never size constants in Verilog. I understand
that some people do it to remind themselves of the
actual number of bits being used in the context,
but I just find the code more readable without
all the 3'd7 notation, instead of just plain 7.

Good luck on your new ventures,
Gabor
 
On Feb 5, 2:59 pm, gabor <ga...@alacron.com> wrote:
One thing I don't miss is strong typing.  It seems
draconian that you need to write a constant for
a 5-bit quantity in binary, or use a type conversion.
I almost never size constants in Verilog.  I understand
that some people do it to remind themselves of the
actual number of bits being used in the context,
but I just find the code more readable without
all the 3'd7 notation, instead of just plain 7.

Good luck on your new ventures,
Gabor- Hide quoted text -

- Show quoted text -
I'm sure whoever gets to maintain your code will appreciate all the
unlabeled, unexplained, unbounded literals for which you saved so much
time and effort by not bothering to define constants.

Defining a constant with a useful name gives the value a purpose and a
reason why it is what it is. Giving the constant a type gives the
value a context in which it may be interpreted. Giving the constant a
constrained type gives the value a range within which it might be
changed should the need arise.

Yes, you could accomplish all that with equally verbose comments that
are ignored by anything but human readers, if only they could trust
that the comments had been kept up to date.

If developers thought more about maintaining their code than typing
it, they'd spend far less time chasing their tails when it does not
work than they'd spent on a few extra keystrokes.

Andy
 

Welcome to EDABoard.com

Sponsor

Back
Top