On Jan 16, 4:36 pm, Mike Treseler <mtrese...@gmail.com> wrote:
> 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.
>
>         -- Mike Treseler

Why do you say this is the "only" text?  I know of at least two others
that cover both VHDL and Verilog.  One is Ben Cohen's book, "Real Chip
Design and Verification Using Verilog and VHDL".  The other I have,
Douglas J. Smith, "HDL Chip Design".  The Smith book has side by side
examples of both like you describe for the Botros book, but I can't
say about the Cohen book since I haven't seen it.

I will say this is the only affordable one of the three.  The other
two are $167 and $135!  Thats just too rich for my blood.

Rick

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

On Jan 21, 10:04=A0am, Anssi Saari <a...@sci.fi> wrote:
> rickman <gnu...@gmail.com> writes:
> > I'm curious, why are you using VHDL more now? =A0Is this a job
> > requirement or do you prefer VHDL? =A0
>
> 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

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.

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

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

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

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