Verilog Book for VHDL Users

On Jan 15, 12:33=A0pm, "evilkid...@googlemail.com"
<evilkid...@gmail.com> wrote:
> 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. =A0Unfortunately, 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. =A0At 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 o=
f
> > >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. =A0You may disagree
> and think that less verbose code more desirable and I think that's a
> valid point too. =A0Probably 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

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

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

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

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

>Integer [has] (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

On Jan 18, 4:57=A0pm, 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. =A0

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


> >Integer [has] (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. =A0The inability to represent 32-bit
> unsigned values in a purely-numeric type is painful almost
> beyond belief. =A0One 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

rickman <gnuarm@gmail.com> writes:

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

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.

On Jan 19, 5:49=A0am, Anssi Saari <a...@sci.fi> wrote:
> rickman <gnu...@gmail.com> writes:
> > 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 t=
o
> > 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?
>
> 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

On Jan 19, 11:19=A0am, rickman <gnu...@gmail.com> wrote:
> On Jan 19, 5:49=A0am, Anssi Saari <a...@sci.fi> wrote:
>
>
>
> > rickman <gnu...@gmail.com> writes:
> > > 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. =A0T=
he
> > > 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 th=
e
> > > 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? =A0Is this a job
> requirement or do you prefer VHDL? =A0Was 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. =A0When I go
> through the warning list with Verilog I see a number of things that
> could easily trip me up. =A0I guess I'm nervous that I am going to be
> bitten by one of these at some point. =A0I 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 <=3D 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

On Jan 19, 2:12=A0pm, Gabor <ga...@alacron.com> wrote:
> On Jan 19, 11:19=A0am, 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. =A0When I go
> > through the warning list with Verilog I see a number of things that
> > could easily trip me up. =A0I guess I'm nervous that I am going to be
> > bitten by one of these at some point. =A0I 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. =A0There 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). =A0Verilog 2001 has
> added the 'default_nettype directive which allows you to override this
> behavior. =A0I 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. =A0Note 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. =A0I 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. =A0For example:
>
> reg [3:0] foo;
>
> always @ (posedge clk)
> =A0 foo <=3D 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

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.