Verilog Book for VHDL Users

[rickman]

I am finally going to learn Verilog for real after using VHDL for 15
years. I've done a little work with Verilog and found it relatively
easy to use. Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do. My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect. This is
what I need detailed info on.

Otherwise I am looking for something that covers synthesis well and
include info on writing test benches.

I have "HDL Chip Design" by Douglas Smith, third printing 1997. This
book covers both VHDL and Verilog, side by side, but has an odd style
and often does not cover all the details of a topic clearly. There
are times I can only find the info I want if I analyze the example
code very, very carefully.

Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey. The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case? Why do you like the
books you like?

Rick

 

[Jonathan Bromley]

On Fri, 14 Jan 2011 08:44:28 -0800 (PST), rickman wrote:

What do the Verilog users recommend in my case?
Why do you like the books you like?

Rick,

I've always found that Verilog is nowhere near so well
served by textbooks as VHDL. I can speculate why that
is, but I don't know for sure. I haven't met ANY book
on Verilog for design that I really like.

Since you've been doing this for a loooong time and
you know exactly what to expect from HDL synthesis,
you may find it better to pick up the basics by osmosis
(you probably did that already) and then go for a more
advanced tips-and-tricks book like Stu Sutherland and
Don Mills's Verilog and SystemVerilog Gotchas.

For testbenches, it's hard to beat the second edition
of Janick Bergeron's Writing Testbenches. That one
covers both VHDL and Verilog, but it's a goldmine of
good sense and useful ideas. There's also an "edition
2.5" called Writing Testbenches in SystemVerilog, or
something like that; it's OK but you probably want to
get a good feel for more traditional testbench writing
styles before you attack SystemVerilog's bottomless pit.
There are interesting things you can do with Verilog
testbenches that you simply can't begin to do in VHDL,
so you'll probably want to mess around with some of
Janick's examples and see what parts of it can be made
to work for you.

There are good resources on Cliff Cummings' website
www.sunburst-design.com although, as reported here on
many occasions, I profoundly disagree with some of
Cliff's conclusions about good style. Again, you're
plenty experienced enough to make up your own mind
about such things.

Finally, you'll also encounter things that you have
been able to do easily in VHDL but are devil-hard
or just plain impossible in Verilog, especially
when it comes to designing parameterizable blocks.
And you'll have to decide just how to soothe your
conscience after you start using the Verilog
macro preprocessor.

And another thing... In VHDL you got frustrated with
the clunky syntax and restrictive rules for doing
arithmetic on vectors, right? And it'll all be so
much easier in Verilog, with hardly any red tape.
But you forget at your peril the arcane and complex
rules about arithmetic bit-width in Verilog. Trawling
back through the comp.lang.verilog archives in search
of wisdom from Steven Sharp will save you much pain.

Good luck
--
Jonathan Bromley

 

[Gabor]

On Jan 14, 11:44 am, rickman <gnu...@gmail.com> wrote:

I am finally going to learn Verilog for real after using VHDL for 15
years.  I've done a little work with Verilog and found it relatively
easy to use.  Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do.  My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect.  This is
what I need detailed info on.

Otherwise I am looking for something that covers synthesis well and
include info on writing test benches.

I have "HDL Chip Design" by Douglas Smith, third printing 1997.  This
book covers both VHDL and Verilog, side by side, but has an odd style
and often does not cover all the details of a topic clearly.  There
are times I can only find the info I want if I analyze the example
code very, very carefully.

Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey.  The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case?  Why do you like the
books you like?

Rick

As Jonathan (a true HDL guru) pointed out it's not easy to find good
texts
on Verilog. I started in by modifying and adding to existing projects
(our
company has adopted Verilog almost exclusively) and then went back
and read through Thomas & Moorby's book, an old text that predates
Verilog 2001. While I don't think the book would have been a good
text
without the initial dabbling in Verilog, it definitely cleared up some
concepts
in my mind like blocking and non-blocking assignments and the syntax
of # delays. Having already written in VHDL for some years you should
be able to pick this up quickly, since there are similar concepts in
VHDL (signals v. variables). I also find it handy to have a good
language reference.
The official LRM is a bit dry and unfriendly, but makes the expected
workings clear (as mud). However I generally refer to the Doulos
"Verilog Golden Reference Guide" when I need to look up some obscure
syntax that I don't use often, and sometimes just to browse through
and find constructs I've never come across before. It is well
organized
and includes examples and "gotcha's" for most of the entries.

It would be nice if someone wrote a good book on synthesizable Verilog
with coding examples, but unfortunately that seems to be a moving
target
as many synthesis tools add more language coverage over time. If
you're
designing with Xilinx, you can also glean some useful information from
the XST user's guide, which gives some templates for synthesizing into
FPGA features like memory and shift registers.

Good luck on your transformation,

Gabor

 

[evilkidder@googlemail.com]

On Jan 14, 4:44 pm, rickman <gnu...@gmail.com> wrote:

I am finally going to learn Verilog for real after using VHDL for 15
years.  I've done a little work with Verilog and found it relatively
easy to use.  Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do.  My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect.  This is
what I need detailed info on.

I also did a VHDL to Verilog transition a few years back. The two key
points have been mentioned in this thread already - default arithmetic
rules and blocking/non-blocking.

The former is a bit of a pig. The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years). I generally ignore
them and use explicit wire declarations when they are needed. This is
a nice thing in Verilog - you don't need to declare a signal first and
then assign to it later on - you can make new 'wires' at any point in
your code. Generally this means when I would need a conversion
function in VHDL to make my types or bit widths match I will introduce
a new 'wire'. The rules become much simpler to comprehend because of
this.

The blocking/non-blocking thing simply requires restraint - there are
lots of coding styles that will work in Verilog. That said it's
perfectly reasonable to use '<=' and '=' in a manner that matches
VHDL's '<=' and ':=' assignments. The only difference is that in VHDL
signals and variables are distinct entities and therefore the compiler
can tell you when you have made a mistake. Verilog can't, but its not
really that difficult to be a good citizen in this case.

I would also dispute the assertion that Verilog lack parameterization
capabilities. At the module level Verilog is just as capable as
VHDL. Functions and procedures are much more flexible in VHDL,
however. On the other hand testbenches are dramatically easier in
Verilog. For all it's many faults I prefer Verilog to VHDL because of
this.

Personally I think both languages are hugely flawed so I wrote my own.

-Andy

 

[Jonathan Bromley]

On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:

The former is a bit of a pig. The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years).

I agree it's a pig - frighteningly easy to get wrong - but
I'm not entirely sure its design is as bad as you imply.

There are many possible choices for how to deal with
arbitrary-precision arithmetic, and I'm fairly certain
that there is *no* choice that will give the intuitively
correct behaviour for everyone in every case. Some of
the options are:

- Permit unlimited bit growth of expressions so that the
mathematical intent is preserved in all situations,
narrowing only on final copy into a target object.
This sounds nice, but doesn't sit nicely with the
bounded sizes of physical hardware, so it may force
you into generating a lot of explicit intermediate
variables to model real hardware's behaviour
(although I sense that you may feel this to be
a good thing rather than a disadvantage).

- Have every operation return a result whose bit width
is determined solely by the operand widths and the
operation (VHDL). This has the huge advantage of being
relatively easy to define and understand, but leads to
nonsenses in practice; either you get the carry-out from
an add, in which case it's too wide to put back into
one of the operand variables, or you throw away the
carry as numeric_std does. Either way, some users will
be forced into doing non-obvious things to get the
results they want.

- Have context-determined size rules. Verilog does this,
and provides a fine example of how hard (impossible?)
it is to get all the rules right so that people don't
get nasty surprises.

It really isn't easy to make clear, reproducible rules
that do The Right Thing for everyone's needs. I'm not
saying that either VHDL or Verilog have it exactly right,
but each has an internal consistency that's fairly
satisfying and comprehensible once you're used to it.

and use explicit wire declarations when they are needed. This is
a nice thing in Verilog - you don't need to declare a signal first and
then assign to it later on - you can make new 'wires' at any point in
your code. Generally this means when I would need a conversion
function in VHDL to make my types or bit widths match I will introduce
a new 'wire'. The rules become much simpler to comprehend because of
this.

That's a useful idea, but it does push you into a style of
coding that's perhaps unnecessarily explicit and verbose.

[snip good sense about blocking/nonblocking]

I would also dispute the assertion that Verilog lack parameterization
capabilities. At the module level Verilog is just as capable as
VHDL.

I really don't think this is true, although V-2001 "generate"
plugs some of the most gaping holes.

Since 2005 Verilog has had a clear definition of "constant
function". Along with SystemVerilog's ability to give
arbitrary data types to parameters, this makes things much
better because you can now compute parameter values in a
reasonably complicated way if you wish - just as you've been
able to do in VHDL since forever. It's too little too late,
though, and it's still at the mercy of tool support in
synthesis. And, as you also point out, the power of VHDL's
unconstrained subprogram arguments has no match in Verilog;
that has an impact on design parameterization too.

testbenches are dramatically easier in Verilog.

It's hard to disagree with this.

Personally I think both languages are hugely flawed so I wrote my own.

What specific flaws have you overcome, and what new ones have
you introduced?
--
Jonathan Bromley

 

[Jan Decaluwe]

Jonathan Bromley wrote:

On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:

The former is a bit of a pig. The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years).

I agree it's a pig - frighteningly easy to get wrong - but
I'm not entirely sure its design is as bad as you imply.

There are many possible choices for how to deal with
arbitrary-precision arithmetic, and I'm fairly certain
that there is *no* choice that will give the intuitively
correct behaviour for everyone in every case. Some of
the options are:

- Permit unlimited bit growth of expressions so that the
mathematical intent is preserved in all situations,

That's what MyHDL does, and I believe it is the intuitively
correct behavior for arithmetic.

narrowing only on final copy into a target object.

MyHDL doesn't do this: it checks whether the value is
within the stated target bounds and gives you a run-time
error when it's not. It never throws anything away
silently.

This sounds nice, but doesn't sit nicely with the
bounded sizes of physical hardware, so it may force
you into generating a lot of explicit intermediate
variables to model real hardware's behaviour

I don't get this. After debugging, the target objects
do have adequate bit widths. A synthesis tool can
optimize away any logic not required to fill those bits.

(although I sense that you may feel this to be
a good thing rather than a disadvantage).

- Have every operation return a result whose bit width
is determined solely by the operand widths and the
operation (VHDL). This has the huge advantage of being
relatively easy to define and understand, but leads to
nonsenses in practice; either you get the carry-out from
an add, in which case it's too wide to put back into
one of the operand variables, or you throw away the
carry as numeric_std does. Either way, some users will
be forced into doing non-obvious things to get the
results they want.

- Have context-determined size rules. Verilog does this,
and provides a fine example of how hard (impossible?)
it is to get all the rules right so that people don't
get nasty surprises.

It really isn't easy to make clear, reproducible rules
that do The Right Thing for everyone's needs. I'm not
saying that either VHDL or Verilog have it exactly right,
but each has an internal consistency that's fairly
satisfying and comprehensible once you're used to it.

--
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

 

[Jan Decaluwe]

Gabor wrote:

On Jan 14, 11:44 am, rickman <gnu...@gmail.com> wrote:
I am finally going to learn Verilog for real after using VHDL for 15
years. I've done a little work with Verilog and found it relatively
easy to use. Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do. My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect. This is
what I need detailed info on.

Otherwise I am looking for something that covers synthesis well and
include info on writing test benches.

I have "HDL Chip Design" by Douglas Smith, third printing 1997. This
book covers both VHDL and Verilog, side by side, but has an odd style
and often does not cover all the details of a topic clearly. There
are times I can only find the info I want if I analyze the example
code very, very carefully.

Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey. The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case? Why do you like the
books you like?

Rick

As Jonathan (a true HDL guru) pointed out it's not easy to find good
texts
on Verilog. I started in by modifying and adding to existing projects
(our
company has adopted Verilog almost exclusively) and then went back
and read through Thomas & Moorby's book, an old text that predates
Verilog 2001. While I don't think the book would have been a good
text
without the initial dabbling in Verilog, it definitely cleared up some
concepts
in my mind like blocking and non-blocking assignments

That I find really surprizing: my assessment about that book
is totally different.

Thomas & Moorby, The Verilog Hardware Description Language,
5th edition, 2002 (updated to Verilog 2001)
===========================================================

1. Blocking assignments
-----------------------
2. The role of synthesis
------------------------

p.51 """All procedural assignments in an always block must
either be blocking or non-blocking assignments. They cannot
be mixed ... Although descriptions using the regular "="
will synthesize properly, they may not simulate properly.
Since both simulation and synthesis are generally of
importance, use "<=" for edge sensitive circuits."""

This is a combination of two common fallacies. First, about
the use of blocking assignments: not making the difference
between synchronous communication (problematic) and
local computation (a good idea). Second, about the role
of synthesis: it is meaningless to make statements about
synthesis when a model doesn't simulate properly.

3. Blocking assignments (contradiction)
--------------------------------------

p.197 """The use of blocking and non-blocking assignments was
mixed in this specification. Non-blocking assignments were used
for registers which are used outside of the always block. For
registers used only in one always block this is not necessary ...
you can use blocking assignments to calculate intermediate
values and values only used inside the always block."""

Perfect! If only more designers would make it to this chapter

The problem here is that it contradicts 1) above. Such a
contradiction within the same publication is an error in
its own right.

4. Non-blocking assignments
---------------------------

p.205 """When using cycle-accurate specification, only one
non-blocking assignment is made to any member of the output
set in a state. If two such assignments were made to a
register, its final value would be indeterminate."""

Note: "state" in this context means the code between
clock events.

This is wrong: The last non-blocking assignment wins.
Note that this is an essential feature in RTL modeling,
for the efficient modeling of default values.

5. The nature of a reg
----------------------

p.329 """Registers are abstractions of storage devices
found in digital systems. They are defined with the
reg keyword ..."""

Linking Verilog regs to "an abstraction of storage
devices" is flawed. This is not how Verilog works and
makes it harder to understand the language.

----------------------------------------------------------


Jan

--
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

 

[evilkidder@googlemail.com]

On Jan 15, 10:38 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
The former is a bit of a pig.  The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years).

I agree it's a pig - frighteningly easy to get wrong - but
I'm not entirely sure its design is as bad as you imply.

Maybe the best has been made of what I consider a bad idea in the
first place. Unfortunately, the inherent complexity in the Verilog
design doesn't just burn designers, but also tool vendors where
occasional synthesis/simulation mismatches have led to many, many
hours of head scratching and refactoring. At least thats my
experience.

and use explicit wire declarations when they are needed.  This is
a nice thing in Verilog - you don't need to declare a signal first and
then assign to it later on - you can make new 'wires' at any point in
your code.  Generally this means when I would need a conversion
function in VHDL to make my types or bit widths match I will introduce
a new 'wire'.  The rules become much simpler to comprehend because of
this.

That's a useful idea, but it does push you into a style of
coding that's perhaps unnecessarily explicit and verbose.

Yes, it is a little bit more verbose, but if it leads to code I can
read and understand more easily (and that makes things a bit more
explicit for the toolchain), I find that worthwhile. You may disagree
and think that less verbose code more desirable and I think that's a
valid point too. Probably the sweet spot is somewhere in the middle.

I would also dispute the assertion that Verilog lack parameterization
capabilities.  At the module level Verilog is just as capable as
VHDL.

I really don't think this is true, although V-2001 "generate"
plugs some of the most gaping holes.

Probably the one place where VHDL has a clear practical advantage in
my mind is the ability to parameterize the port map of a circuit using
functions and/or constants from packages. But I tend to find that
just makes Verilog a bit more verbose, not less useful as such.

synthesis.  And, as you also point out, the power of VHDL's
unconstrained subprogram arguments has no match in Verilog;
that has an impact on design parameterization too.

Yes, that's a big win for VHDL, however, Verilog does have the ability
to parameterize functions if you package them into an (otherwise
empty) module. It's not quite the same thing, but still useful on
occasion.

Personally I think both languages are hugely flawed so I wrote my own.

What specific flaws have you overcome, and what new ones have
you introduced?

Obviously I am hugely biased, but ...

- Parameterization is terribly verbose in both languages and quite
limited.
- Static typing in VHDL is, again, very verbose compared to what can
be achieved using 40 year old technology (Hindley-Milner based type
systems).
- Most importantly I have a deep dislike of having to maintain a
golden model in a wholly different language in order to test my
designs.

My solution (actually, I can't take any credit for the general
approach) is to embed an HDL in a general purpose functional language
(ocaml) and build a toolset around that. Now my parameterization
language is a full industrial strength programming language. So is my
testbench language. I can write everything including my golden model,
RTL and testbench in one language and I have found this leads to much
more automatic self checking testbenches which can pinpoint errors
quickly and easily without staring at waveforms all the time.

It also tickles a particular interest of mine in that it's possible to
build mini-compilers which target particular types of hardware. That
is I can write abstract specifications of systems and then compile
then into different hardware architectures. Good luck trying that in
Verilog!

Flaws? The intersection between people interested in functional
programming and hardware design is, well, miniscule and is probably
mainly made up of people with 'professor' in their title.

Also, as an embedded language (or at least given it's current
implementation) it can be quite hard to relate information from later
parts in the toolchain back to the original source code ie finding the
code related to a critical path from the synthesizer.

-Andy

 

[rickman]

On Jan 15, 12:33 pm, "evilkid...@googlemail.com"
<evilkid...@gmail.com> wrote:

On Jan 15, 10:38 am, Jonathan Bromley <s...@oxfordbromley.plus.com
wrote:

On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
The former is a bit of a pig.  The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years).

I agree it's a pig - frighteningly easy to get wrong - but
I'm not entirely sure its design is as bad as you imply.

Maybe the best has been made of what I consider a bad idea in the
first place.  Unfortunately, the inherent complexity in the Verilog
design doesn't just burn designers, but also tool vendors where
occasional synthesis/simulation mismatches have led to many, many
hours of head scratching and refactoring.  At least thats my
experience.

 I generally ignore [the bit width rules]
and use explicit wire declarations when they are needed.  This is
a nice thing in Verilog - you don't need to declare a signal first and
then assign to it later on - you can make new 'wires' at any point in
your code.  Generally this means when I would need a conversion
function in VHDL to make my types or bit widths match I will introduce
a new 'wire'.  The rules become much simpler to comprehend because of
this.

That's a useful idea, but it does push you into a style of
coding that's perhaps unnecessarily explicit and verbose.

Yes, it is a little bit more verbose, but if it leads to code I can
read and understand more easily (and that makes things a bit more
explicit for the toolchain), I find that worthwhile.  You may disagree
and think that less verbose code more desirable and I think that's a
valid point too.  Probably the sweet spot is somewhere in the middle.

This is starting to sound like VHDL...! I don't mind being explicit.
It is just that in VHDL it can get rather confusing as to what you
need to be explicit about or how exactly to be explicit.

I find it hard to believe that there are no good texts on this. In
1995 or thereabout when I was first learning VHDL, I found the texts
to be a bit lacking not to mention few. I originally thought that
once I had gotten to a point where I could write the stuff, I would
write a book explaining how to code VHDL without learning all the
bloody details. By the time I got ready to consider it, a bazillion
books had come out, so instead I bought a couple. If the good Verilog
text field is really sparse, maybe I should tackle that one instead...

Rick

 

[Mike Treseler]

On 1/15/2011 12:09 PM, rickman wrote:

This is starting to sound like VHDL...! I don't mind being explicit.
It is just that in VHDL it can get rather confusing as to what you
need to be explicit about or how exactly to be explicit.

I find it hard to believe that there are no good texts on this.

It is true.
I found this one slightly useful:
http://www.google.com/search?q=botros+isbn+1584508558

It's the only book of side by side vhdl|verilog examples in print.
But that is all it is -- simple synthesis examples and a short
explanation. No language reference or simulation examples.
But it's a quick way for a vhdl guy to get started
on verilog synthesis, and the price is right.

In
1995 or thereabout when I was first learning VHDL, I found the texts
to be a bit lacking not to mention few. I originally thought that
once I had gotten to a point where I could write the stuff, I would
write a book explaining how to code VHDL without learning all the
bloody details. By the time I got ready to consider it, a bazillion
books had come out, so instead I bought a couple. If the good Verilog
text field is really sparse, maybe I should tackle that one instead...

Maybe, but do it for fun, not for money.

-- Mike Treseler

 

[Andy]

On Jan 15, 4:38 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

- Have every operation return a result whose bit width
  is determined solely by the operand widths and the
  operation (VHDL).  This has the huge advantage of being
  relatively easy to define and understand, but leads to
  nonsenses in practice; either you get the carry-out from
  an add, in which case it's too wide to put back into
  one of the operand variables, or you throw away the
  carry as numeric_std does.  Either way, some users will
  be forced into doing non-obvious things to get the
  results they want.

Jonathan,

You seem to attribute one "style" of arithmetic to VHDL, when it has
several, distinct, standard "styles".

Numeric_std is what you described as "VHDL". There was integer based
arithmetic long before that. And more recently, the standard fixed
point packages have their own style.

Integer is close to MyHDL, but with (very) limited datapath widths
(31-32 bits in all existing implementations).

The fixed point packages are kind of a hybrid between them. You get
the expanded data paths to handle arithmetic precision (unless you do
unsigned subtraction!), but unlike integer, you have to manually re-
size prior to storage in smaller objects.

Then there's also parameterizable floating point too...

My point is, this is all possible because of the abilities of the
native VHDL language, which itself only defines the integer style (of
these we are discussing). Sure, the numeric_std and fixed/floating
point packages are part of the IEEE VHDL standard, but they are really
nothing more than sactioned user-definable packages of types and
functions/operators.

I could easily develop and use a package that works like fixed point,
but gets unsigned subtraction right (promotion to signed) too, without
having to change the language. Or someone much smarter than me could
come up with better ways yet. All within the existing VHDL language.

Andy

 

[Jonathan Bromley]

On Tue, 18 Jan 2011 11:00:13 -0800 (PST), Andy wrote:

On Jan 15, 4:38 am, Jonathan Bromley <s...@oxfordbromley.plus.com
wrote:
- Have every operation return a result whose bit width
  is determined solely by the operand widths and the
  operation (VHDL).  This has the huge advantage of being
  relatively easy to define and understand, but leads to
  nonsenses in practice; either you get the carry-out from
  an add, in which case it's too wide to put back into
  one of the operand variables, or you throw away the
  carry as numeric_std does.  Either way, some users will
  be forced into doing non-obvious things to get the
  results they want.

You seem to attribute one "style" of arithmetic to VHDL, when it has
several, distinct, standard "styles".

Yes, of course you're right. "VHDL" was shorthand for
"numeric_std" here, and I should have been clearer.

I completely agree about VHDL's wonderful malleability in
this respect and I wasn't trying to diss VHDL here at all.
Rather, I was trying to use the (perfectly reasonable)
behaviour of numeric_std's addition as an example of
something that meets some requirements well, but falls
badly short for others. We could stay with VHDL and
contrast numeric_std's addition with that of the fixed-
point package; here the bit-growth on addition preserves
mathematical intent but requires you to do some wardances
if for any reason you need modulo arithmetic. In other
words, it's very hard to come up with a set of behaviour
that meets all needs straight out of the box.

(very) limited datapath widths
(31-32 bits in all existing implementations).

Yes, and that's horrible - as has been noted here and
elsewhere many times. The inability to represent 32-bit
unsigned values in a purely-numeric type is painful almost
beyond belief. One place where VHDL really is hobbled.

Jonathan Bromley

 

[KJ]

On Jan 18, 4:57 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Rather, I was trying to use the (perfectly reasonable)
behaviour of numeric_std's addition as an example of
something that meets some requirements well, but falls
badly short for others.  

So what is your point? Many things are good at one task but not good
at another.

We could stay with VHDL and
contrast numeric_std's addition with that of the fixed-
point package; here the bit-growth on addition preserves
mathematical intent but requires you to do some wardances
if for any reason you need modulo arithmetic.  In other
words, it's very hard to come up with a set of behaviour
that meets all needs straight out of the box.

You most likely don't expect a screwdriver to be a good hammer so why
do you think it reasonable to state how using the wrong package (i.e.
'tool') makes it difficult or awkward to meet certain requirements?
Use the best tool you can for the particular problem...grumble only if
it is still awkward and clumsy for that task...but only if the
limitations of some other tool (in this case the VHDL LRM) inhibit you
from creating a better tool more suited to the task.

- Use the right tool for the right job
- Be satisified when you are able to create a new and useful tool that
is applicable for a certain class of problems.

(very) limited datapath widths
(31-32 bits in all existing implementations).

Yes, and that's horrible - as has been noted here and
elsewhere many times.  The inability to represent 32-bit
unsigned values in a purely-numeric type is painful almost
beyond belief.  One place where VHDL really is hobbled.

The VHDL group is currently begining on a new revision...perhaps
you'll contribute your solutions to that group where it could have
some effect. That would be the proper forum to possibly effect
change.

Kevin Jennings

 

[Anssi Saari]

rickman <gnuarm@gmail.com> writes:

Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey. The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case? Why do you like the
books you like?

I don't know what to recommend, since I haven't used Verilog much
since 2002. I did buy Botros' book recently since it's so cheap and
includes a CD too with code examples and figures from the book. But I
mostly need a VHDL book and this one seems a little shallow so I find
myself relying on Ashenden's VHDL book mostly. I do beliece Botros'
book is the only book in print that covers both VHDL and Verilog.

When I was learning Verilog in the mid-1990s, I think I used Cadence's
excellent manuals for the old Verilog-XL and experienced colleagues.

 

[rickman]

On Jan 19, 5:49 am, Anssi Saari <a...@sci.fi> wrote:

rickman <gnu...@gmail.com> writes:
Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey.  The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case?  Why do you like the
books you like?

I don't know what to recommend, since I haven't used Verilog much
since 2002. I did buy Botros' book recently since it's so cheap and
includes a CD too with code examples and figures from the book. But I
mostly need a VHDL book and this one seems a little shallow so I find
myself relying on Ashenden's VHDL book mostly. I do beliece Botros'
book is the only book in print that covers both VHDL and Verilog.

When I was learning Verilog in the mid-1990s, I think I used Cadence's
excellent manuals for the old Verilog-XL and experienced colleagues.

I'm curious, why are you using VHDL more now? Is this a job
requirement or do you prefer VHDL? Was there something about Verilog
you didn't like?

As I am learning Verilog, I am finding that I had become pretty used
to VHDL and I had a certain level of comfort knowing that if I made a
dumb mistake, the tool would most likely let me know. When I go
through the warning list with Verilog I see a number of things that
could easily trip me up. I guess I'm nervous that I am going to be
bitten by one of these at some point. I guess I'll keep checking the
warnings.

Rick

 

[Gabor]

On Jan 19, 11:19 am, rickman <gnu...@gmail.com> wrote:

On Jan 19, 5:49 am, Anssi Saari <a...@sci.fi> wrote:



rickman <gnu...@gmail.com> writes:
Searching here I found recommendations for "The VerilogŽ Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey.  The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case?  Why do you like the
books you like?

I don't know what to recommend, since I haven't used Verilog much
since 2002. I did buy Botros' book recently since it's so cheap and
includes a CD too with code examples and figures from the book. But I
mostly need a VHDL book and this one seems a little shallow so I find
myself relying on Ashenden's VHDL book mostly. I do beliece Botros'
book is the only book in print that covers both VHDL and Verilog.

When I was learning Verilog in the mid-1990s, I think I used Cadence's
excellent manuals for the old Verilog-XL and experienced colleagues.

I'm curious, why are you using VHDL more now?  Is this a job
requirement or do you prefer VHDL?  Was there something about Verilog
you didn't like?

As I am learning Verilog, I am finding that I had become pretty used
to VHDL and I had a certain level of comfort knowing that if I made a
dumb mistake, the tool would most likely let me know.  When I go
through the warning list with Verilog I see a number of things that
could easily trip me up.  I guess I'm nervous that I am going to be
bitten by one of these at some point.  I guess I'll keep checking the
warnings.

Rick

One of the big "biters" in Verilog is the ability to declare a net
implicitly.
This often covers up a mistake in spelling. There is even no warning
for implicitly declared nets unless they happen to cause a size
mismatch
at a module port (this would be an error in VHDL). Verilog 2001 has
added the 'default_nettype directive which allows you to override this
behavior. I generally do this at the top of each module:

`default_nettype none

module foo
.. . .
And then this at the bottom:

endmodule

`default_nettype wire

Bringing the default back. Note that as long as you only write your
own
code this bit at the end would make no difference, but as soon as you
add some IP from another source (Xilinx comes to mind) you can end
up with piles of errors when they use implicitly declared nets.

There are some things about Verilog that I think make it much more
human friendly like not requiring constants to be sized. I go batty
reading VHDL case statements with all the cases listed in binary.
However, this can again show some lack of error coverage because
there is no check to see if the constant will even fit into the size
required by the operand. For example:

reg [3:0] foo;

always @ (posedge clk)
foo <= 25;

Obviously you can't fit 25 into a 4-bit register, but this won't even
cause
a warning, it just blithely takes the low 4 bits of the value and
stuffs it
into foo.

-- Gabor

 

[rickman]

On Jan 19, 2:12 pm, Gabor <ga...@alacron.com> wrote:

On Jan 19, 11:19 am, rickman <gnu...@gmail.com> wrote:

As I am learning Verilog, I am finding that I had become pretty used
to VHDL and I had a certain level of comfort knowing that if I made a
dumb mistake, the tool would most likely let me know.  When I go
through the warning list with Verilog I see a number of things that
could easily trip me up.  I guess I'm nervous that I am going to be
bitten by one of these at some point.  I guess I'll keep checking the
warnings.

One of the big "biters" in Verilog is the ability to declare a net
implicitly.
This often covers up a mistake in spelling.  There is even no warning
for implicitly declared nets unless they happen to cause a size
mismatch
at a module port (this would be an error in VHDL).  Verilog 2001 has
added the 'default_nettype directive which allows you to override this
behavior.  I generally do this at the top of each module:

`default_nettype none

module foo
. . .
And then this at the bottom:

endmodule

`default_nettype wire

Bringing the default back.  Note that as long as you only write your
own
code this bit at the end would make no difference, but as soon as you
add some IP from another source (Xilinx comes to mind) you can end
up with piles of errors when they use implicitly declared nets.

There are some things about Verilog that I think make it much more
human friendly like not requiring constants to be sized.  I go batty
reading VHDL case statements with all the cases listed in binary.
However, this can again show some lack of error coverage because
there is no check to see if the constant will even fit into the size
required by the operand.  For example:

reg [3:0] foo;

always @ (posedge clk)
  foo <= 25;

Obviously you can't fit 25 into a 4-bit register, but this won't even
cause
a warning, it just blithely takes the low 4 bits of the value and
stuffs it
into foo.

And that's the sticky wicket, isn't it? Getting the tool to
understand what you want without having to tell it every excruciating
detail. VHDL requires you to tell it enough that it doesn't need to
assume and Verilog lets you get by with what a person might need to be
told, but if you aren't on the same page with the tool, you won't get
what you expected.

I've been wanting to learn Verilog well enough that I can make a fully
educated opinion about which is better but just hadn't found the time
for it. I probably still wouldn't be learning it, but I have some
work that requires it. So I'm trying to take the time to learn it
properly rather than just getting by with code that seems to work.

Thanks for the info.

Rick

 

[Anssi Saari]

rickman <gnuarm@gmail.com> writes:

I'm curious, why are you using VHDL more now? Is this a job
requirement or do you prefer VHDL?

Job requirement. Euroland is VHDLland too, with some exceptions.
Usually means customer is somewhere else, like in North America or
Asia. Even then, Verilog may be the result of autoconversion from
VHDL...

Was there something about Verilog you didn't like?

I liked it just fine for design. Didn't much care for writing
testbenches in it. Most of my Verilog work was for telecom. For
example, generating ATM cells and sending them to the design was just
awful. Should've done it in Perl and put the data in a file. In fact,
I did that for the received data.

I'm not too keen on VHDL, but it gets the job done. I used to hate the
strong typing and required conversions, but I guess I don't mind that
much any more. Maybe it's influence from my recent interest in Python
too.

 

[Petter Gustad]

Anssi Saari <as@sci.fi> writes:

Was there something about Verilog you didn't like?

I liked it just fine for design. Didn't much care for writing
testbenches in it. Most of my Verilog work was for telecom. For

I'm the opposite VHDL is ok for design, but not for testbenches.
SystemVerilog provides a much higher level of abstraction and features
like assertions, covergroups, and randomize classes for making
constraint random based testbenches.

//Petter

 

[rickman]

On Jan 21, 10:04 am, Anssi Saari <a...@sci.fi> wrote:

rickman <gnu...@gmail.com> writes:
I'm curious, why are you using VHDL more now?  Is this a job
requirement or do you prefer VHDL?  

Job requirement. Euroland is VHDLland too, with some exceptions.
Usually means customer is somewhere else, like in North America or
Asia. Even then, Verilog may be the result of autoconversion from
VHDL...

Was there something about Verilog you didn't like?

I liked it just fine for design. Didn't much care for writing
testbenches in it. Most of my Verilog work was for telecom. For
example, generating ATM cells and sending them to the design was just
awful. Should've done it in Perl and put the data in a file. In fact,
I did that for the received data.

I'm not too keen on VHDL, but it gets the job done. I used to hate the
strong typing and required conversions, but I guess I don't mind that
much any more. Maybe it's influence from my recent interest in Python
too.

That was the one place where I used Verilog in the past, at a telecom
test equipment company. I'm near Washington, DC and a lot of the jobs
around here are government. I was in a government contractor job when
I learned HDL, so it was VHDL. Now I want to learn Verilog as well as
I know VHDL and it is ticking me off a bit that I'm being told there
are NO good text books in it.

I've heard that Europe is very VHDL oriented. I have no idea what
predominates in the far East. I'm curious about that.

Rick