Why VHDL?

[rickman]

I'm not looking to start a VHDL vs. Verilog argument, but I was puzzled
by Glen's comment in the VHDL group that he learned Verilog first before
using VHDL. Am I correct in assuming you used VHDL because a customer
required it?

I learned VHDL, although not well, then went to work for a comms company
who used Verilog. I never went to school for Verilog and never really
bought a book. So I don't feel comfortable using it even though I have
coded in it. On the other hand, after many years of VHDL, I won't say
I've ever gotten "comfortable" with it. I've just learned to live with
it. Part of the reason I haven't switched to Verilog is that I've never
found a good book for it. In fact when I have asked in the Verilog
group I'm told there *isn't* one. Buy "good" I mean one that covers all
the pitfalls well. At least with VHDL it tells you you've screwed up.

I'm curious who here has learned both and why? Which do you prefer and
why?

--

Rick

 

[glen herrmannsfeldt]

In comp.lang.vhdl rickman <gnuarm@gmail.com> wrote:

I'm not looking to start a VHDL vs. Verilog argument, but I was puzzled
by Glen's comment in the VHDL group that he learned Verilog first before
using VHDL. Am I correct in assuming you used VHDL because a customer
required it?

That is about right.

I learned VHDL, although not well, then went to work for a comms company
who used Verilog. I never went to school for Verilog and never really
bought a book. So I don't feel comfortable using it even though I have
coded in it.

I started about 1993. I was told that C programmers usually like
verilog, others I worked with were using it, so I did to.

I bought both Thomas and Moorby's book, and the Sternhiem, Singh,
Madhavan, and Trivedi book. There might not have been many books
back then. Those two, and some Xilinx software to run designs
through, and I started writing down logic designs pretty soon.

I also did some simulations with Veriwell.

Not so many years ago, I was working with an existing design that was
done using a mix of schematic capture, VHDL, and AHDL (that is, Altera),
and wrote mine in verilog. I had to be able to read the VHDL, but didn't
need to write it.

On the other hand, after many years of VHDL, I won't say
I've ever gotten "comfortable" with it. I've just learned to live with
it. Part of the reason I haven't switched to Verilog is that I've never
found a good book for it. In fact when I have asked in the Verilog
group I'm told there *isn't* one. Buy "good" I mean one that covers all
the pitfalls well. At least with VHDL it tells you you've screwed up.

Many useful verilog features are new to VHDL, some too new for the
version of tools that I use. Even more, they are different for different
FPGA chips with the same version of tools. (Specifically, Spartan 3 vs.
Spartan 6.) Strange.

I'm curious who here has learned both and why? Which do you prefer and
why?

Most verilog operators are similar to C operators, so that helps some.
A few times, not so many, I have used & in VHDL when I meant AND.

I still prefer verilog, but I figured out how to write most of the
things I need from verilog into VHDL.

Verilog style concatenations are still too new to VHDL. The result is
a fair number of signals that are only needed to combine or separate
signals to/from a vector.

VHDL is a little wordier than I like, but it isn't so hard to live with.
I will like it better when VHDL 2008 is supported, where I rarely
complained about the features in verilog 95.

-- glen

 

[michael6866]

On Friday, October 16, 2015 at 9:24:23 PM UTC-4, rickman wrote:

I'm not looking to start a VHDL vs. Verilog argument, but I was puzzled
by Glen's comment in the VHDL group that he learned Verilog first before
using VHDL. Am I correct in assuming you used VHDL because a customer
required it?

I learned VHDL, although not well, then went to work for a comms company
who used Verilog. I never went to school for Verilog and never really
bought a book. So I don't feel comfortable using it even though I have
coded in it. On the other hand, after many years of VHDL, I won't say
I've ever gotten "comfortable" with it. I've just learned to live with
it. Part of the reason I haven't switched to Verilog is that I've never
found a good book for it. In fact when I have asked in the Verilog
group I'm told there *isn't* one. Buy "good" I mean one that covers all
the pitfalls well. At least with VHDL it tells you you've screwed up.

I'm curious who here has learned both and why? Which do you prefer and
why?

--

Rick

My two cents: it's just personal preference.

I learned VHDL in my sophomore year (at that time it's the only HDL course offered in my college) and did a bunch of course projects with it. Though I studied EE for 6 years in college, I came from a software background. Prior to VHDL I had been using C++ for ~5 years in high school. As a result my first impression on VHDL was that the syntax seems very odd and redundant to me. For example something like "std_logic_vector(N downto 0)" is not user friendly. Also the data conversions / std libraries always confused me (I know those are just basics but even today I still feel it's not easy for newbies).

During the VHDL course my professor also mentioned Verilog several times. So I searched it online and read that many people saying the trend was Verilog would replace VHDL soon. That started my interest. As a result I self-studied Verilog in my junior year and I realized I truly liked it. Believe or not its similarity to C/C++ made my learning progress much faster than VHDL. My gut feeling on Verilog (and later SystemVerilog) is that I can focus on the functionality rather than struggling with the syntax (yes it could just be that I didn't learn VHDL well but anyway).

Though I don't want to debate on the future trend, the fact is more and more companies are using Verilog / SV (now I work for EDA vendors to develop simulation and synthesis tools so trust me I know in the market where the major investment / competition is). But I don't deny the fact that you can use any HDL languages to do the work as long as you're used to it.

I agree that there is no single book covering all pitfalls well. But there is a basic one named "Verilog and SystemVerilog Gotchas" which could be a good start. There are also several papers from Mr.Sutherland and Mr.Cummings that focusing on this area. I don't really think there are a lot of pitfalls. In fact as a C++ guru I believe C++ has much more pitfalls even you take those hardware / circuit traps into account

 

[Brian Drummond]

On Sat, 17 Oct 2015 07:21:33 +0000, glen herrmannsfeldt wrote:

VHDL is a little wordier than I like, but it isn't so hard to live with.
I will like it better when VHDL 2008 is supported, where I rarely
complained about the features in verilog 95.

-- glen

You may be pleased to know that ghdl at version 0.33 supports a lot more
of VHDL-2008 than previously. Enough to run Jim's OSVVM suite.

Its source release was last week. There aren't builds for all OS/
distributions yet, so some people will still have to build from source,
or wait...

https://sourceforge.net/projects/ghdl-updates/

-- Brian

 

[rickman]

On 10/17/2015 3:21 AM, glen herrmannsfeldt wrote:

In comp.lang.vhdl rickman <gnuarm@gmail.com> wrote:
I'm not looking to start a VHDL vs. Verilog argument, but I was puzzled
by Glen's comment in the VHDL group that he learned Verilog first before
using VHDL. Am I correct in assuming you used VHDL because a customer
required it?

That is about right.

I learned VHDL, although not well, then went to work for a comms company
who used Verilog. I never went to school for Verilog and never really
bought a book. So I don't feel comfortable using it even though I have
coded in it.

I started about 1993. I was told that C programmers usually like
verilog, others I worked with were using it, so I did to.

I bought both Thomas and Moorby's book, and the Sternhiem, Singh,
Madhavan, and Trivedi book. There might not have been many books
back then. Those two, and some Xilinx software to run designs
through, and I started writing down logic designs pretty soon.

I will look into those references. My thing is I don't remember what I
read as well as I used to. I'd like a book with the important stuff
explicitly stated in a well organized manner so I can refer to it
easily. Most importantly I want spelled out the various assumptions of
Verilog code. I know there are things that are done with arithmetic
that the user needs to understand.

I found I could download the Thomas and Moorby book. The Doulos pages
are often good, if not a great reference to return to. In this case I
find the text runs off the screen without a scrollbar. To get it all on
the page I have to shrink the text quite a bit. My old eyes don't like
that. I wonder where that scrollbar has gotten to?



> I also did some simulations with Veriwell.

Is that more useful than the simulation tools from the FPGA vendors?

On the other hand, after many years of VHDL, I won't say
I've ever gotten "comfortable" with it. I've just learned to live with
it. Part of the reason I haven't switched to Verilog is that I've never
found a good book for it. In fact when I have asked in the Verilog
group I'm told there *isn't* one. Buy "good" I mean one that covers all
the pitfalls well. At least with VHDL it tells you you've screwed up.

Many useful verilog features are new to VHDL, some too new for the
version of tools that I use. Even more, they are different for different
FPGA chips with the same version of tools. (Specifically, Spartan 3 vs.
Spartan 6.) Strange.

By too new and "different" you mean some tools support some features
which differ between the tools? So far I haven't found a VHDL 2008
feature I wanted to use that wasn't supported. It would be useful to
have a chart of the features and the tools. With the restrictions on
the tool licenses, I wonder if that would violate any by making and
posting such a feature list?

I'm curious who here has learned both and why? Which do you prefer and
why?

Most verilog operators are similar to C operators, so that helps some.
A few times, not so many, I have used & in VHDL when I meant AND.

I still prefer verilog, but I figured out how to write most of the
things I need from verilog into VHDL.

Verilog style concatenations are still too new to VHDL. The result is
a fair number of signals that are only needed to combine or separate
signals to/from a vector.

I haven't found that. Have a ready example?

VHDL is a little wordier than I like, but it isn't so hard to live with.
I will like it better when VHDL 2008 is supported, where I rarely
complained about the features in verilog 95.

I think calling VHDL "wordy" is like calling the Pope Catholic. I use
it, but the typing is a PITA to the point I have regular expressions
written in my boiler plate for converting between port declarations,
instantiations and signal lists. Nicer would be an editor that could do
much of that automatically... use a signal and the editor adds it to the
signals list. Add a component instantiation and you just type the name
and the full port map is added with "name => name" for each signal in
the port list.

I've touted the advantages of the strong typing used in VHDL, but I've
never completely accepted that it is a big advantage. So I'm ready to
give Verilog a try if I can find it less painful than all the typing I'd
have to do to keep using VHDL.

--

Rick

 

[glen herrmannsfeldt]

In comp.lang.vhdl rickman <gnuarm@gmail.com> wrote:

(snip)

I also did some simulations with Veriwell.

Is that more useful than the simulation tools from the FPGA vendors?

That was in the days before A and X had free versions.

I was part of a discussion at FCCM 95 suggesting that companies
should have free versions of the tools, and affordable (small)
FPGAs.

In my high school and college days, TTL chips were affordable enough
to buy, design simple logic circuits and build them. A big reason
for that was that enough were used in the computer industry to keep
the economy of scale large, and prices low.

I suspected in 1995 that as computers went more to VLSI, that TTL
would go away. It seems that 20 years later, it is still fairly
easy to get, and afford, TTL, but maybe not in 20 more years.

(Though as I understand it, the usual undergrad digital logic course
is now taught with simulation and no actual circuits.)

If you just want a simple simulation, though, Veriwell is a fine choice.

-- glen

 

[rickman]

On 10/17/2015 3:56 AM, michael6866 wrote:

My two cents: it's just personal preference.

I learned VHDL in my sophomore year (at that time it's the only HDL
course offered in my college) and did a bunch of course projects with
it. Though I studied EE for 6 years in college, I came from a
software background. Prior to VHDL I had been using C++ for ~5 years
in high school. As a result my first impression on VHDL was that the
syntax seems very odd and redundant to me. For example something like
"std_logic_vector(N downto 0)" is not user friendly. Also the data
conversions / std libraries always confused me (I know those are just
basics but even today I still feel it's not easy for newbies).

I think VHDL is not so easy to learn, but not really because of the
verbosity. I think it is the strong typing that makes it hard to learn.
It is better now, but when I started there were many errors reported
from very simple issues, as if the language was never intended to be
used for real projects. One that gets everyone at some time (and is
hard to figure out) is the issue of "globally or locally static". I
hate having to read a damn language specification just to figure out an
error message.

During the VHDL course my professor also mentioned Verilog several
times. So I searched it online and read that many people saying the
trend was Verilog would replace VHDL soon. That started my interest.
As a result I self-studied Verilog in my junior year and I realized I
truly liked it. Believe or not its similarity to C/C++ made my
learning progress much faster than VHDL. My gut feeling on Verilog
(and later SystemVerilog) is that I can focus on the functionality
rather than struggling with the syntax (yes it could just be that I
didn't learn VHDL well but anyway).

Yeah, that's possible. At this point I am very well versed in VHDL and
I think, why bother to switch? But it would be useful to be bi-lingual.

Though I don't want to debate on the future trend, the fact is more
and more companies are using Verilog / SV (now I work for EDA vendors
to develop simulation and synthesis tools so trust me I know in the
market where the major investment / competition is). But I don't deny
the fact that you can use any HDL languages to do the work as long as
you're used to it.

I agree that there is no single book covering all pitfalls well. But
there is a basic one named "Verilog and SystemVerilog Gotchas" which
could be a good start. There are also several papers from
Mr.Sutherland and Mr.Cummings that focusing on this area. I don't
really think there are a lot of pitfalls. In fact as a C++ guru I
believe C++ has much more pitfalls even you take those hardware /
circuit traps into account

I'll take your word on the companies converting. I have heard this from
other sources as well. I'm not worried about the number of pitfalls. I
just don't want to have to learn about them by making all the mistakes.
I'd like the owner's manual for a car which will cover *all* the don't
so that my warranty is not voided. lol I also don't want to look
stupid by I delivering a design with fundamental errors.

--

Rick

 

[rickman]

On 10/17/2015 3:10 PM, glen herrmannsfeldt wrote:

In comp.lang.vhdl rickman <gnuarm@gmail.com> wrote:

(snip)

I also did some simulations with Veriwell.

Is that more useful than the simulation tools from the FPGA vendors?

That was in the days before A and X had free versions.

I was part of a discussion at FCCM 95 suggesting that companies
should have free versions of the tools, and affordable (small)
FPGAs.

Thank you on both those accounts. I have always felt FPGAs could be
sold more like MCUs in many packages and with lots of variations of
included I/O features. But the FPGA vendors still like their primary
markets of comms where most of the need is for larger and faster
devices. Unlike car companies where the money is made on the products
for the average buyer, FPGAs are marketed to higher end buyers with
extreme needs. I guess in general they do better selling to a few large
customers rather than lots of small ones. Maybe the MCU market is just
plain different in that regard with most of the profit coming from the
many, many small quantity users across the board of device complexity.

In my high school and college days, TTL chips were affordable enough
to buy, design simple logic circuits and build them. A big reason
for that was that enough were used in the computer industry to keep
the economy of scale large, and prices low.

I suspected in 1995 that as computers went more to VLSI, that TTL
would go away. It seems that 20 years later, it is still fairly
easy to get, and afford, TTL, but maybe not in 20 more years.

Much TTL is getting harder to buy. There are still many basic functions
available, but there used to be a wide assortment of specialized
functions, many of which are no longer sold in any of the TTL/CMOS
families.

(Though as I understand it, the usual undergrad digital logic course
is now taught with simulation and no actual circuits.)

If you just want a simple simulation, though, Veriwell is a fine choice.

I don't mind the vendor tools. Many years ago I had learned a bit of
Modelsim and ordered the low end Lattice tools with Modelsim. At that
point you still had to pay Lattice for a package with a simulator. A
month later when they shipped, it came with the Aldec simulator which I
knew nothing about. I had a COW and talked to half a dozen reps on the
phone which got me nowhere. When I fired up the tool I found there was
little difference and could use the tool pretty well so I cooled off and
got to work. Heck, at that time Modelsim had a memory leak that would
crash it every so often and this tool worked without crashing so I was
actually better off. lol

So I'm happy with the simulators from the vendors although I haven't
used Xilinx tools in a while. I read a lot lately about their schizoid
nature.

--

Rick

 

[Anssi Saari]

rickman <gnuarm@gmail.com> writes:

I'm curious who here has learned both and why? Which do you prefer
and why?

I learned some VHDL in school then went to work at telecoms
company. There the old school POTS and related stuff was done in Verilog
and the new fangled cellular radio stuff was in VHDL. I don't really
know why. I worked with the POTS stuff first and used mostly Verilog and
then later moved to the radio stuff but as the project manager didn't
want to learn VHDL everyone in my team used Verilog. By that time
simulation and synthesis tools didn't care so it was no problem to do
mixed language.

After that job, which ended in 2002, it's been pretty exlusively VHDL
for me. European thing I suppose. One IP company I consulted at even
went so far as to have us write code in VHDL which they would then put
through a Verilog converter before shipping to customers in Asia or
somewhere who wanted Verilog.

I don't really have a preference between either but... As a fresh
graduate I liked the simplicity and freedom of Verilog (and C) and
really didn't like the bewildering mess of types in VHDL and the
required type conversions. Or the seeming need to write things in
triplicate (entity, component, instance). Thankfully there's direct
instantiation which eliminates the need for components and then the
Emacs VHDL mode makes instantiating and declaring signals a snap.

As I've gotten older I've come to like Python quite a lot and these days
I really like strong typing and explicit type conversions. I also
maintain some old code and now scoff at the use of std_arith to do
arithmetic on std_logic_vectors. Now the way of thinking that goes like
"anything, even binary literals to avoid having to call type
conversions" just seems stupid. Then again, readability is in the eye of
the beholder. I was just reminded of this the other week...

Well, the state of support for VHDL 2008 is a constant annoyance. I work
on Altera parts without access to a third party synthesis tool and
Quartus hasn't progressed at all with VHDL 2008 support in the last five
years or so while Modelsim and Questa (which I do have access to)
have. I think Xilinx Vivado is about the same? So the smaller guys
(Lattice and Microsemi) are maybe offering better tools now since they
bundle Synplify. If they still do, haven't checked.

 

[Kevin Neilson]

There are really no good Verilog books. The classic ones are not only bad, but they focus a lot on low-level modeling, which is of little use to the modern designer. I've only found one decent book, but it's not for beginners, and by the time I found it I didn't need it. Now I just consult the LRM.

When I'm required to use VHDL, it's extremely frustrating. I would look unfavorably at a job offer that was for VHDL only. But it seems crazy that there are still two languages to do the same thing. I can't believe everything hasn't coalesced to one or the other. It's not like one is better for certain applications. It's just a huge waste of productivity, especially when code has to be translated. Even if it were VHDL, it would be better to standardize on one language.

I'm disappointed in the slow adoption of SystemVerilog constructs into synthesizers. Even when I'm using a decent synthesizer, I am usually not allowed to use any modern syntax because my code has to be portable to lame/old synthesizers.

 

[rickman]

On 10/21/2015 6:34 PM, Kevin Neilson wrote:

There are really no good Verilog books. The classic ones are not only bad, but they focus a lot on low-level modeling, which is of little use to the modern designer. I've only found one decent book, but it's not for beginners, and by the time I found it I didn't need it. Now I just consult the LRM.

When I'm required to use VHDL, it's extremely frustrating. I would look unfavorably at a job offer that was for VHDL only. But it seems crazy that there are still two languages to do the same thing. I can't believe everything hasn't coalesced to one or the other. It's not like one is better for certain applications. It's just a huge waste of productivity, especially when code has to be translated. Even if it were VHDL, it would be better to standardize on one language.

I think the reason the two exist is still the same reason they were
created. Verilog was created to get work done when there was nothing
else. VHDL was created by the US government to help designs chips with
the same level of "protection" from making mistakes as Ada. There are
many who just want to code in Verilog without the hassles of a nanny and
there are those who use VHDL because they like the protection or they
are just plain required to use it.

I use VHDL because I have yet to find a good book for Verilog.


> I'm disappointed in the slow adoption of SystemVerilog constructs into synthesizers. Even when I'm using a decent synthesizer, I am usually not allowed to use any modern syntax because my code has to be portable to lame/old synthesizers.

I dunno...

--

Rick

 

[Kevin Neilson]

I looked for my one good book but can't find it. If I do, I'll post the name. I moved into a new cube once and the previous owner had quit and left it behind. I don't like Moorby, Bhasker, Palnitkar, Douglas Smith, or the others I've read. You'll find good examples (Verilog & VHDL) in the Xilinx Synthesis Guide and the Altera Synthesis Cookbook. I've always wanted to write a book, but who's got time for that?

I wish somebody would write a comprehensive guide to conversions in VHDL. I had one once but lost it. Every time I write something in that infernal language I can't remember how to convert unsigned into integer or whatever. Sometimes it takes a double conversion. And no, you won't find this in Ashenden or any of the VHDL books either. This is why everybody leaves everything as std_logic_vector and everything is in binary, whether it makes the code readable or not.

 

[rickman]

On 10/23/2015 6:02 PM, Kevin Neilson wrote:

I looked for my one good book but can't find it. If I do, I'll post the name. I moved into a new cube once and the previous owner had quit and left it behind. I don't like Moorby, Bhasker, Palnitkar, Douglas Smith, or the others I've read. You'll find good examples (Verilog & VHDL) in the Xilinx Synthesis Guide and the Altera Synthesis Cookbook. I've always wanted to write a book, but who's got time for that?

I wish somebody would write a comprehensive guide to conversions in VHDL. I had one once but lost it. Every time I write something in that infernal language I can't remember how to convert unsigned into integer or whatever. Sometimes it takes a double conversion. And no, you won't find this in Ashenden or any of the VHDL books either. This is why everybody leaves everything as std_logic_vector and everything is in binary, whether it makes the code readable or not.

That "infernal" language isn't that hard to deal with. Type conversions
can be a bit hard to learn initially, but more likely you were confused
by the several different types of type "manipulation". I just had a
discussion on this in the VHDL group. Someone was having trouble with
this sort of thing and I posted a summary of conversions. The author of
the page I used to crib from posted corrections to mind. lol

It was at the end of September. If you can't find it, I'll reply to it
and crosspost here.

For me, the most important thing to help with type conversions is to
*not* use SLV. Signed and unsigned do everything sLV does plus
arithmetic.

--

Rick

 

[Kevin Neilson]

For me, the most important thing to help with type conversions is to
*not* use SLV. Signed and unsigned do everything sLV does plus
arithmetic.

I would avoid SLV, but a lot of people still want you to use that for all your module ports, and last time I made a module with unsigned ports, my colleague told me the synthesis tool didn't like it. I didn't look into it myself; I just sighed and converted everything.

 

[rickman]

On 10/26/2015 12:11 PM, Kevin Neilson wrote:

For me, the most important thing to help with type conversions is
to *not* use SLV. Signed and unsigned do everything sLV does plus
arithmetic.

I would avoid SLV, but a lot of people still want you to use that for
all your module ports, and last time I made a module with unsigned
ports, my colleague told me the synthesis tool didn't like it. I
didn't look into it myself; I just sighed and converted everything.

There is no reason why a tool would not be happy with signed/unsigned in
ports unless your colleague didn't include the appropriate library. I
would rather fight that switch. lol

--

Rick

 

[Mark Curry]

In article <vg3fv0wpi8j.fsf@coffee.modeemi.fi>, Anssi Saari <as@sci.fi> wrote:

Kevin Neilson <kevin.neilson@xilinx.com> writes:

I wish somebody would write a comprehensive guide to conversions in
VHDL. I had one once but lost it.

There's the 2003 PDF by Jim Lewis of Synthworks titled "VHDL Math Tricks
of the Trade"
(http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf) which
is pretty good. It covers both the old std_arith stuff and current
numeric_std stuff.

For a quick reference, there're lots of images floating around that
cover the common conversions. Like this one:
http://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png

Every time I write something in that infernal language I can't
remember how to convert unsigned into integer or whatever. Sometimes
it takes a double conversion.

I dunno, it seems to me to_integer and to_unsigned are pretty easy to
remember.

Anssi - Thanks very much for the links.

I think todays designers must be able to work with either VHDL or Verilog.
These language wars are over.

It's ok to have a preference - I prefer Verilog. But I deal with
VHDL all the time. It's the nature of the business. So much IP,
you're bound to work with your non "native" language.

I can READ VHDL fine, as well as tweak existing code. But to
straight-up code up a new entity? Errgh, I trip up everytime
on the basics. What Library to "use". What types to declare, etc.
For a Verilog user that runs loosey goosey around around typing and
bit vectors vs arithmetic context, etc, getting the right "Recipe"
for VHDL takes some relearning for me everytime.

Sure it's pretty easy for you to remember - you probably
use it almost every day!

I wasn't aware of these guides, and I'm glad to now have them.

Jim's guide list the three main libs, "numeric_std", "std_logic_arith", and
"std_logic_unsigned". I belive however, that most modern styles suggest
JUST using "numeric_std" correct? (Jim's guide is from 2003).
(I remember more than one VHDL expert strongly suggesting not to use one
or the other, but I can't remember which was which...)

Thanks,

Mark

 

[Anssi Saari]

Kevin Neilson <kevin.neilson@xilinx.com> writes:

I wish somebody would write a comprehensive guide to conversions in
VHDL. I had one once but lost it.

There's the 2003 PDF by Jim Lewis of Synthworks titled "VHDL Math Tricks
of the Trade"
(http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf) which
is pretty good. It covers both the old std_arith stuff and current
numeric_std stuff.

For a quick reference, there're lots of images floating around that
cover the common conversions. Like this one:
http://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png

Every time I write something in that infernal language I can't
remember how to convert unsigned into integer or whatever. Sometimes
it takes a double conversion.

I dunno, it seems to me to_integer and to_unsigned are pretty easy to
remember.

 

[Mark Curry]

In article <n0ob11$b5j$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:

On 10/27/2015 12:26 PM, Mark Curry wrote:
In article <vg3fv0wpi8j.fsf@coffee.modeemi.fi>, Anssi Saari <as@sci.fi> wrote:
Kevin Neilson <kevin.neilson@xilinx.com> writes:

I wish somebody would write a comprehensive guide to conversions in
VHDL. I had one once but lost it.

There's the 2003 PDF by Jim Lewis of Synthworks titled "VHDL Math Tricks
of the Trade"
(http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf) which
is pretty good. It covers both the old std_arith stuff and current
numeric_std stuff.

For a quick reference, there're lots of images floating around that
cover the common conversions. Like this one:
http://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png

Every time I write something in that infernal language I can't
remember how to convert unsigned into integer or whatever. Sometimes
it takes a double conversion.

I dunno, it seems to me to_integer and to_unsigned are pretty easy to
remember.

Anssi - Thanks very much for the links.

I think todays designers must be able to work with either VHDL or Verilog.
These language wars are over.

snip

In my "book" anyone who discusses std_logic_arith is so far out of date
they don't deserve serious respect. There literally is *no* reason to
learn anything about std_logic_arith and its kin unless you are trying
to maintain code so old the processes used to implement it are no longer
around.

The reasons to avoid std_logic_arith are many and well known. This is

Noted - but as a verilog user, I don't know what those reasons are.
I do trust you, and other VHDL experts and will certainly follow
the suggestions. Like I said, I remembered there was a
strong suggestion to NOT use one of them. I'll try and
cement that in my head "don't use std_logic_arith"...

the sort of info I'd like to have on Verilog. I understand there are
default rules of how many thing operate in Verilog, but they are hard to
find out about. That is what I would like in a Verilog book.

As a verilog user, it's all obvious to me
Actually, if I had a suggestion, it just be Cliff's oldy but goody:
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

It's still relevant today, IMHO. Not sure if this is what you're
looking for, but it's golden.

Cliff's got many other great papers up on his website.

Regards,

Mark

 

[rickman]

On 10/27/2015 12:26 PM, Mark Curry wrote:

In article <vg3fv0wpi8j.fsf@coffee.modeemi.fi>, Anssi Saari <as@sci.fi> wrote:
Kevin Neilson <kevin.neilson@xilinx.com> writes:

I wish somebody would write a comprehensive guide to conversions in
VHDL. I had one once but lost it.

There's the 2003 PDF by Jim Lewis of Synthworks titled "VHDL Math Tricks
of the Trade"
(http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf) which
is pretty good. It covers both the old std_arith stuff and current
numeric_std stuff.

For a quick reference, there're lots of images floating around that
cover the common conversions. Like this one:
http://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png

Every time I write something in that infernal language I can't
remember how to convert unsigned into integer or whatever. Sometimes
it takes a double conversion.

I dunno, it seems to me to_integer and to_unsigned are pretty easy to
remember.

Anssi - Thanks very much for the links.

I think todays designers must be able to work with either VHDL or Verilog.
These language wars are over.

It's ok to have a preference - I prefer Verilog. But I deal with
VHDL all the time. It's the nature of the business. So much IP,
you're bound to work with your non "native" language.

I can READ VHDL fine, as well as tweak existing code. But to
straight-up code up a new entity? Errgh, I trip up everytime
on the basics. What Library to "use". What types to declare, etc.
For a Verilog user that runs loosey goosey around around typing and
bit vectors vs arithmetic context, etc, getting the right "Recipe"
for VHDL takes some relearning for me everytime.

Sure it's pretty easy for you to remember - you probably
use it almost every day!

I wasn't aware of these guides, and I'm glad to now have them.

Jim's guide list the three main libs, "numeric_std", "std_logic_arith", and
"std_logic_unsigned". I belive however, that most modern styles suggest
JUST using "numeric_std" correct? (Jim's guide is from 2003).
(I remember more than one VHDL expert strongly suggesting not to use one
or the other, but I can't remember which was which...)

In my "book" anyone who discusses std_logic_arith is so far out of date
they don't deserve serious respect. There literally is *no* reason to
learn anything about std_logic_arith and its kin unless you are trying
to maintain code so old the processes used to implement it are no longer
around.

The reasons to avoid std_logic_arith are many and well known. This is
the sort of info I'd like to have on Verilog. I understand there are
default rules of how many thing operate in Verilog, but they are hard to
find out about. That is what I would like in a Verilog book.

BTW, your problems starting a VHDL design from scratch shouldn't be so
hard. Just use a boilerplate. That's what I do. I don't remember all
the piddling little details because I only code in it once a year maybe.
When I get a project I usually am doing the entire design from stem to
stern and the HDL is about a month or two coding, debugging and
integrating. Then I wait like a spider for the next project. lol

I've got a new toy, a Microsemi SoC board with a combined FPGA/ARM CM3.
I need to get the tools installed so I can see what it can do and how
to do it.

--

Rick

 

[rickman]

On 10/27/2015 3:21 PM, Mark Curry wrote:

In article <n0ob11$b5j$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 10/27/2015 12:26 PM, Mark Curry wrote:
In article <vg3fv0wpi8j.fsf@coffee.modeemi.fi>, Anssi Saari <as@sci.fi> wrote:
Kevin Neilson <kevin.neilson@xilinx.com> writes:

I wish somebody would write a comprehensive guide to conversions in
VHDL. I had one once but lost it.

There's the 2003 PDF by Jim Lewis of Synthworks titled "VHDL Math Tricks
of the Trade"
(http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf) which
is pretty good. It covers both the old std_arith stuff and current
numeric_std stuff.

For a quick reference, there're lots of images floating around that
cover the common conversions. Like this one:
http://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png

Every time I write something in that infernal language I can't
remember how to convert unsigned into integer or whatever. Sometimes
it takes a double conversion.

I dunno, it seems to me to_integer and to_unsigned are pretty easy to
remember.

Anssi - Thanks very much for the links.

I think todays designers must be able to work with either VHDL or Verilog.
These language wars are over.

snip

In my "book" anyone who discusses std_logic_arith is so far out of date
they don't deserve serious respect. There literally is *no* reason to
learn anything about std_logic_arith and its kin unless you are trying
to maintain code so old the processes used to implement it are no longer
around.

The reasons to avoid std_logic_arith are many and well known. This is

Noted - but as a verilog user, I don't know what those reasons are.
I do trust you, and other VHDL experts and will certainly follow
the suggestions. Like I said, I remembered there was a
strong suggestion to NOT use one of them. I'll try and
cement that in my head "don't use std_logic_arith"...

To be honest, it has been so long that I don't remember all of the
reasons. One that I recall is that with these packages you can't use
signed and unsigned at the same time. These packages don't define new
types, they define operators for SLV to implement signed or unsigned
arithmetic. Adding both signed and unsigned packages gives you multiple
operators for the same data types... which do you get?

I know there are other issues with them as well, so they are best
forgotten.

In addition to numeric_std, there are new packages for signed and
unsigned arithmetic on SLV, (std_logic_signed and std_logic_unsigned).
These new packages will have the same issue of not working together
since they define the same operator on the same types, but otherwise
will work ok. I just use signed and unsigned types from the std_numeric
library. Life is good.

the sort of info I'd like to have on Verilog. I understand there are
default rules of how many thing operate in Verilog, but they are hard to
find out about. That is what I would like in a Verilog book.

As a verilog user, it's all obvious to me
Actually, if I had a suggestion, it just be Cliff's oldy but goody:
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

It's still relevant today, IMHO. Not sure if this is what you're
looking for, but it's golden.

Cliff's got many other great papers up on his website.

I've seen some of this before. I was mostly referring to the issues of
arithmetic. I believe Verilog has defaults for how the various details
of bit growth etc are handled. If you aren't aware of what is happening
you can have invisible trouble. In VHDL you have *very* visible trouble
for nearly anything you do wrong. lol

Crossposting to the VHDL group since this is as much about that as Verilog.

--

Rick