Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > vhdl for beginners

Thread Tools

vhdl for beginners

vipin lal
Posts: n/a
VHDL tutorial site for beginners..many vhdl tips are explained in a
simpler way.
Reply With Quote
Posts: n/a
On Mar 10, 9:04*pm, vipin lal <(E-Mail Removed)> wrote:
> VHDL tutorial site for beginners..many vhdl tips are explained in a
> simpler way.

Why is it that as soon as someone manages to get a piece of VHDL code
through a simulator without encountering a "blue-screen-of-death" that
they think that they are some sort of 'guru' and need to blog it?

Reply With Quote
Andy Peters
Posts: n/a
On Mar 10, 10:04*pm, vipin lal <(E-Mail Removed)> wrote:
> VHDL tutorial site for beginners..many vhdl tips are explained in a
> simpler way.

A "guru" wouldn't use the deprecated std_logic_arith, and a guru
wouldn't use "if (clk'event and clk='1')" when "if rising_edge(clk)"
is available.
And a guru would figure out how to show code using a proper font.

Reply With Quote
Posts: n/a
On Mar 15, 4:36*pm, Andy Peters <(E-Mail Removed)> wrote:
> On Mar 10, 10:04*pm, vipin lal <(E-Mail Removed)> wrote:
> > VHDL tutorial site for beginners..many vhdl tips are explained in a
> > simpler way.

> A "guru" wouldn't use the deprecated std_logic_arith, and a guru
> wouldn't use "if (clk'event and clk='1')" when "if rising_edge(clk)"
> is available.
> And a guru would figure out how to show code using a proper font.
> -a

That's giving Guru's too much credit...

I looked over some of the examples, and it is pathetic. This is one
beginner's site you DON'T want a beginner to be exposed to. The
problem is, a beginner won't know just how bad that site's advice
really is.

Reply With Quote
Posts: n/a
Andy Peters a écrit:
> On Mar 10, 10:04*pm, vipin lal <(E-Mail Removed)> wrote:
>> VHDL tutorial site for beginners..many vhdl tips are explained in a
>> simpler way.

> A "guru" wouldn't use the deprecated std_logic_arith, and a guru
> wouldn't use "if (clk'event and clk='1')" when "if rising_edge(clk)"
> is available.
> And a guru would figure out how to show code using a proper font.

And a guru wouldn't say a program for a piece of VHDL code...

Reply With Quote
vipin lal
Posts: n/a
first of all,sorry for spamming this newsgroup.After sending the mail
only I realized that I have done something wrong.
Let me write what I think:
1)I dont think that I am VHDL guru.I am just a beginner.But the site
was named just for the sake of a good can say a "SEO" method.

2)Its true that I have not encountered a "blue-screen-of-death" in
VHDL.But when I was learning VHDL I faced so many problems.I had to
research through many forums.When I had problems ,errors etc while
coding I tried googling for them.sometimes it worked.Some times
not.That is why I thought I will write what I have found out,when
learning VHDL , in a blog.

3)If I wait till I learn everything about VHDL,then probably this blog
will never come out...

4)I know that there are many mistakes in my codes.Such as the ones you
specified of not using rising_edge(clk),using libraries like
std_logic_arith etc.Thanks more mentioning them.I will keep them in

5)about highlighting the VHDL syntax I am looking for a VHDL syntax
highlighter which I can use with havent got one yet.As
soon as I get one,I will put it.I know it is very difficult to read a
code without syntax highlighting.

6)Once again sorry for spamming.

Thanks for the suggestions...
Reply With Quote
jakob jakob is offline
Junior Member
Join Date: Mar 2010
Posts: 1
vipin lal, you are right to blog, for so many reasons:
  • You may get constructive criticism like you got from your peers here. Now you can refine your posts.
  • There is so little good beginner level information on the Internet on VHDL development. Or is it just hard to find?
  • When you blog about something, you, yourself thinks more clearly about the topic.

However, it can be hard both to find constructive criticism and to go back and edit your posts into something better.

However people such as, d_s_klein, Andy Peters and Vince may not even bother to comment, if they discover they have to correct the same mistakes over and over again.

This is one reason I urge you to consider contributing your insights, comments and votes on a site like Overmapped.

Information there will not be lost in threads, and knowledgeable members get rewarded scores.
Reply With Quote
Posts: n/a

At least your heart is in the right place. I admire your initiative,
and have often wished I had the time to write a good tutorial/blog

It is just that, particularly on this site, there are a lot of us that
use design and coding techniques that many textbooks and college
courses have not (yet) adopted. Principles like single clocked
processs rather than two-process (combinatorial and clocked) methods.
Use of direct entity instantiation, rather than component
instantiation. Use of numeric_std or even the newer fixed_point
packages. Use of integer data types. Even use of variables.

Unfortunately, there is so much momentum behind some rather archaic
methods (after all, they are published in textbooks!), that it is very
frustrating for many of us to see yet another site dedicated to
beginners that just adds to that momentum.

I have a few constructive comments about some of your examples.

For instance, in your CRC example (what looks like almost a simple,
clocked process), you included data in the sensitivity list, and a
conditional based upon it ahead of the clocked clause (if
clk'event...). I'm not sure that most synthesis tools will handle that
the way you want to. I assume you want a synchronous enable function,
enabled only if data is non-zero. If so, remove data from the
sensitivity list, and then rearrange the order of the clocked
condition and the non-zero data condition. You can even combine them:

process (clk) is
if rising_edge(clk) and (unsigned(data_in) /= 0) then...


if rising_edge(clk) then
if unsigned(data_in) /= 0 then...

In clocked processes, conditionals before the clock condition are
usually assumed to be for asuynchronous set/reset, which does not
appear to be what you wanted.

Another area where your coding could use some help (and you mention it
in one of your other posts) is avoiding strings of zeroes or ones
(i.e. '00000000') when a numerical value or an others=> or
array'range => construct makes the code more writeable, readable and
maintainable (immune from data size changes). I hate counting digits,
and will do almost anything to allow the tool rather than me to do it.

Again in CRC, you have an internal counter. This is the perfect place
to do one of two things. Either declare the counter as unsigned in the
first place, or better yet, especially since it is only used to index
an array, declare it as an integer subtype in the first place. Beware,
integer counters will not silently roll over for you, instead you must
conditionally catch the roll-over and assign the next value, or you
can use the MOD operator.

You can use the range of an array as the range for the integer counter

signal counter1: integer crc_temp'range;

Declaring things like this makes it clear the relationship between
sizes of different things. In another example, your internal signals
are declared with explicit data widths. Are those widths associated
with port widths, or are they just coincidentally the same? Use a
'range or 'length attribute to make it clear to you and the reader.

Back to integer counters, etc... You have to use mod, /, and *
operators with 2**n operands to shift or strip portions of an integer
counter, instead of using index ranges for SLV/unsigned.

Then your CRC computation lines might look something like:

crc_temp(2) <= data_in(31-(counter1 mod 32)) xor crc_temp(7) xor

This is only my opinion, but I've often thought that the best, most
helpful way to present coding techniques in a tutorial or sequential
blog is to start with a single example, and then present successive
refinements of that example so that readers can follow the design/
coding changes, without also having to figure out what each new
example is trying to do. Sometimes you will have to switch to a
different example, simply because you will run out of things that can
be demonstrated within that context, but this should be infrequent
(i.e. the exception rather than the rule).

Hope this helps,

Reply With Quote
vipin lal
Posts: n/a
Hi Andy..
thanks a lot, for your reply.

For the CRC example as you said,I initially used just process(clk).But
when I synthesized it said "The following signals are missing in the
process sensitivity list".That is why I included the data_in in
sensitivity list.

I will keep in mind about the "declaring internal counter as
integer".That was one of the earlier programs I wrote.That time I used
only std_logic_vector for each and everything.I am trying to use sub
type integer nowadays.

I will keep all these points when I write my next code.

Is there any good site where you can get professional vhdl
codes.Different people code in different ways and I am confused about
Also some one told you have to use "numeric_std" instead of
"std_arith" and "std_unsignd".What is the reason for this?
Is it possible to write any code,using only "numeric_std".


Reply With Quote
Posts: n/a
The reason you got the sensitivity list warning is that the process
code "looks at" the data_in input before it figures out whether the
clock has changed. This order is typically used for asyncrhonous set/
reset logic (in which case the set/reset input would be included in
the sensitivity list). The change that makes the warning go away is
not necessarily the fix for the problem.

You have described something along the lines of an asyncrhonous clock
enable, and I'm not aware of a reliable mechanism for implementing
that, other than a gated clock, in which case the gate input is
rightly included in the sensitivity list. I'm really surprised the
synthesis tool didn't cough a bit on that too, though maybe it figured
out what you really wanted was a synchronous clock enable. I would not
rely on many tools making the same assumption. Most synthesis tool
will not warn about additional signals in the sensitivity list, but
the simulation will be slower. (It has to do with typical
optimizations in simulators).

std_logic_arith, etc. were packages written by Synopsis and included
in their tools' version of the ieee library, without the approval of
the ieee standardization body. The LRM reserves the ieee libarary for
officially balloted and approved packages for the vhdl language.
However, since the whole world started using synopsys first, and
everyone had started writing code dependent upon std_logic_arith being
in ieee, Synopsys refused to take it out of their implementation. And
since other tools were usually forced to work seamlessly with code
that worked with Synopsys, they followed suit. However, different
vendors implemented the package slightly differently, with some
problems in compatibility. Since there is no standard governing it, it
is subject to change at any time.

So, the IEEE decided to write and approve a standard package for
numerical operations on SL and BIT based vectors. Those packages are
called numeric_std and numeric_bit. These are ieee standard packages,
located in the official version of the ieee library, and their
behavior is governed by the standard, so compatibility is assured.

Numeric_std does not attempt to imply a numerical interpretation on
SLV, but rather defines related types UNSIGNED and SIGNED which have
both numerical and bitwise interpretations (i.e. AND and OR are also
defined for them). This avoids any confusion when needing to use both
signed and unsigned arithmetic in the same body (std_logic_arith
simply assumes all arithmetic is unsigned). Numeric_std defines
arithmetic operations between various combinations of signed, unsigned
and integer operands. In all cases(?) the size of the result is the
same as the largest signed/unsigned operand. Over/underflows are
truncated (rolled over).

The latest version of the vhdl standard does include a package similar
in function to std_logic_arith, etc., named numeric_std_unsigned,
which does define unsigned arithmetic on std_logic_vector operands.
Unfortunately, I know of no tools that support it yet.

Generally, if you can, create your entity interfaces using unsigned or
signed (or even integer)if they are uniformly numerically
interpretted. (i.e. a generic memory device may be able to store any
kind of binary data, so SLV may make more sense there, but a digital
filter has a specific definition of its input data in mind, and that
can be coded by using the appropriate type on the port. Using the
appropriate types on the ports makes it much easier to avoid
conversions within the body.

For example, if you used an SLV input port, and you need to add one to
it and output that on an SLV output port, you must convert twice:

output <= std_logic_vector(unsigned(input) + 1);

This converts the SLV input to unsigned (so that + is defined for it),
adds (integer) one to it (the result is unsigned too), then converts
the result back to SLV for the output port.

It would have been much easier if input and output had been declared
unsigned (or signed) in the first place:

output <= input + 1;

Many users will caution you not to use anything but SL and SLV on top
level device (physical) ports, since most synthesis/P&R tools will
create the gate level model with SL and SLV ports regardless of the
types used for those ports in the RTL. This makes it more difficult to
swap out the RTL model in the testbench with the gate level model,
since the port types on the two models may differ. In practice, it is
not difficult to modify a testbench, or build a wrapper around the
gate level model such that it still interfaces to your RTL-ready

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
Beginners VHDL: VHDLBABY VHDL 5 04-11-2006 10:47 AM
VHDL 2002 vs VHDL 1993 dude VHDL 1 03-23-2006 01:18 PM
multiD-vhdl: Multi Dimensional Arrays (allowing generics on each dimension) for VHDL (including ports) VHDL 2 03-21-2006 04:05 PM
what's the difference between VHDL 93 CONCATENATION and VHDL 87 CONCATENATION? walala VHDL 3 09-18-2003 04:17 AM