Verilog Book for VHDL Users

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

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

On Jan 14, 11:44=A0am, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15
> years. =A0I've done a little work with Verilog and found it relatively
> easy to use. =A0Now 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. =A0My 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. =A0This 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. =A0This
> 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. =A0There
> 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=AE Hardware
> Description Language", Donald E. Thomas and "HDL Programming
> Fundamentals: VHDL and Verilog", Nazeih Botros. =A0The 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. =A0The
> 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? =A0Why 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

I dont think you should have much problem learning Verilog as I found it
easier than VHDL. I would read some of the articles at Sunburst design as
they explain some of the problems you might encounter like blocking vs non
blocking. I wouldnt bother buying any books as you can get most info off
the internet. 

Regards

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote
in message news:TqednQam6MfNN63QnZ2dnUVZ_g-dnZ2d@giganews.com...
> I dont think you should have much problem learning Verilog as
> I found it easier than VHDL. I would read some of the articles
> at Sunburst design as they explain some of the problems you might
> encounter like blocking vs non-blocking. I wouldnt bother buying
> any books as you can get most info off the internet.  Regards
> Jon
> --------------------------------------- 
> Posted through http://www.FPGARelated.com

I agree with Jon, in that you have prior knowledge in the art,
but, if you are like me, learning from scratch for a particular
device, I bought this:

"FPGA PROTOTYPING BY VERILOG EXAMPLES"
     'XILINX SPARTAN&#4294967295;-3 VERSION'
             PONG P. CHU

It is very informative, and helps you build things properly.

I got mine through my sister, who works at Baker and Taylor.

Bill

On Jan 14, 4:44=A0pm, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15
> years. =A0I've done a little work with Verilog and found it relatively
> easy to use. =A0Now 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. =A0My 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. =A0This 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 '<=3D' and '=3D' in a manner that matches
VHDL's '<=3D' and ':=3D' 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

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.

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

[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

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

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&#4294967295; 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

On Jan 15, 10:38=A0am, 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. =A0The 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.



> > =A0I generally ignore [the bit width rules]
> >and use explicit wire declarations when they are needed. =A0This 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. =A0Generally 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'. =A0The 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. =A0At 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. =A0And, 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