Questions on VHDL

Hello group,

I will appreciate it if somebody could help me out with my question.
I'm from a computer science background and now planning to get into
embedded system programming so now I've started learning digital
design. Of course, few years ago I took some courses in this field but
barely I can remember important topics in it.

Currently I'm taking VHDL class and I found a free compiler or maybe I
must call it something different as ModelSIM PE Student Edition
6.2g.

Question:

1) Is this enough to start learning VHDL programming?
2) where can I learn some basic concepts about sync an async ?
3) My 2nd project is about a state machine to recognize strings of 0's
and 1's which it seems doable but I'm told doing it by "asynchronous
reset". What is that and how can I understand it?


your help will be appreciated greatly,

regards,
ak

Amit

Okay, gang, I'll take this one, both to give something back to the
community, and to test my understanding of VHDL and digital logic. More
experienced people feel free to drop in corrections and clarifications.

Amit wrote:
> 1) Is this enough to start learning VHDL programming?

ModelSim should allow you to "compile" your design and simulate it.
This should be enough to get you started and learning, for as long as
you are learning device-independent concepts, and as long as you are
only interested at looking at waveforms your design produces.

While we are at it, I would recommend using emacs as the editor for VHDL
code. The VHDL mode (i.e. support) in emacs is great, and using it will
give you long-lasting benefits. Of course, you are free to choose any
other editor if you so prefer.

> 2) where can I learn some basic concepts about sync an async ?

Hmmm, I am not sure if I can refer you to an internationally acclaimed
book that talks about this at length. I know enough good books about
the subject, but these tend to be in obscure languages. I do remember,
however, that the Art of Electronics
(http://www.amazon.com/Art-Electronic.../dp/0521370957) had
a very accessible and sane introduction to both synchronous and
asynchronous circuits. This book however has lots of other things you
don't need if you want to learn VHDL, so maybe you want to look for
something else.

However, the basics of synchronous and asynchronous designs are not that
difficult to grasp, so I'll try to give a quick intro.

In a synchronous system, all events (e.g. state changes) occur in
lock-step to changes of some reference signal.

For digital circuitry, this signal is usually called the 'clock'. With
background in computer science you should recall that practically all
the CPUs do use some or other clock.

In an asynchronous system, there is no requirement that the reference
signal must exist.

The fundamental difference between these two systems is that synchronous
systems, while more restrictive in their operation rules, are more
powerful as they can compute things asynchronous systems can not (see
e.g. http://www.teamten.com/lawrence/290.paper/node3.html). They are
also easier to analyze, and as a consequence, automatic tools typically
cope better with synchronous designs.

For everyday use though, some practical concerns are more interesting,
as follows.

[Note here that I am trying to eschew talking in terms of logic gates.
This is because although VHDL is used to describe things you may want to
put into programmable logic chips, its real domain is events and their
scheduling. To be fair though, it must be said that the reality of
using VHDL to ultimately describe the configuration of programmable
gates does give more reasons to stick to synchronous descriptions. ]

The synchronous circuits are more predictable than their asynchronous
counterparts. The predictability has to do with the physics of the
devices that implement logic gates, which is below our abstraction
radar. Looking at say
http://en.wikipedia.org/wiki/Metasta...in_electronics may provide
some clues that the predictability concerns are real.

The predictability I mentioned is important for the construction of
physical memory elements, such as latches and flipflops. Memory
elements take in a value, and can 'remember' it indefinitely (i.e., as
long as power lasts, and special circuits like non-volatile memories can
remember even longer). The memory property always relies on some sort
of internal feedback in the element, combined with its physical
properties. This unfortunately means that some unfortunate input
pattern combos to memory elements can cause the it to become
'metastable', i.e. to oscillate between the logic values, a state that
can last unpredictably long. In this state, the element is useless
for practical purposes. This is a realistic scenario in asynchronous
circuits and designing a (large) functioning circuit that eschews this
problem becomes cumbersome and ultimately impractical.

The way out is in the discipline of synchronous design. Typically, in
synchronous designs, memory elements are offered a value to remember,
but will accept it only at the time an event having to do with a
reference signal occured.

There are several conventions for this, the so-called 'edge' is the most
frequently seen. In the 'edge' convention, the value is accepted at
rising (or falling) edge of the reference signal.

As an added constraint, the value offered to the memory element must be
present at the memory element input for long enough before and after the
reference signal trigger (more details are here:
http://en.wikipedia.org/wiki/Flip-fl...)#D_flip-flop).
This, combined with a special way the memory elements are made, greatly
reduces the metastability problem, to the point where it becomes
practically solved. In all fairness, it never really goes away, you can
only make it extremely improbable.

Therefore, you typically want your designs to be synchronous so as to
stay out of trouble. Your tools want synchronous design too, because
they can analyze synchronous circuits easier, and can be of more help
for producing the final output.

There are exceptions to this rule of thumb. You want synchronous design
for monolithic systems (e.g. describing CPUs). You may want
asynchronous design for interfaces (e.g. asynchronous transceivers).
Actually making the design would even require you to dig into the manual
of the chip you will be putting your design into. It pays to know at
least a little about how the gates are made, so as to make right design
decisions.

VHDL allows you to make both synchronous and asynchronous designs and
you as the designer must know which one is appropriate for a given problem.

> 3) My 2nd project is about a state machine to recognize strings of 0's
> and 1's which it seems doable but I'm told doing it by "asynchronous
> reset". What is that and how can I understand it?

I assume that you are familiar with the concept of a state machine, your
background being computer science. You will make a state machine, use
combinatorial circuits to compute the new state from the inputs and the
state (in general, though people tend to distinguish between Mealy and
Moore state machines http://en.wikipedia.org/wiki/Mealy_machine ;
http://en.wikipedia.org/wiki/Moore_machine depending on the exact way
the values are computed), and store new state values at each clock event
(e.g. rising edge).

You will probably use flip-flops as memory elements to remember the
state of your machine. These flip-flops accept a value synchronously
(with reference to the clock signal). A by-product of the way the
flip-flops are made is that they typically have two additional
asynchronous inputs, which can be used to set and reset the value of a
single flip-flop, disregarding the clock events.

The same also can be done while honoring the clock signal. This is
called a synchronous set/reset. See for example
http://en.wikipedia.org/wiki/VHDL#D-type_flip-flops for examples of both
of these in VHDL.

The way you describe your requirement 'by asynchronous reset' does not
shed much light on what exactly is required from you to do.

One thing that comes to mind is that you need to use asynchronous
set/reset method to set the initial state in your machine. If so, the
links I gave above will explain how you can do this.

I can think of other ways to understand your requirement too, such as
abusing asynchronous flip-flop inputs to completely disregard the clock
signal, but that, although doable, seems to be a dirty trick that would
learn you little about good practices.

Given that the assignment is coursework and is thus supposed to be
instructive, I suppose that the first possibility is the right one.

HTH,
f

Filip Miletic

On Apr 10, 5:48 pm, Filip Miletic <fil...@gmTRIPail.com> wrote:
> Okay, gang, I'll take this one, both to give something back to the
> community, and to test my understanding of VHDL and digital logic. More
> experienced people feel free to drop in corrections and clarifications.
>
> Amit wrote:
> > 1) Is this enough to start learning VHDL programming?
>
> ModelSim should allow you to "compile" your design and simulate it.
> This should be enough to get you started and learning, for as long as
> you are learning device-independent concepts, and as long as you are
> only interested at looking at waveforms your design produces.
>
> While we are at it, I would recommend using emacs as the editor for VHDL
> code. The VHDL mode (i.e. support) in emacs is great, and using it will
> give you long-lasting benefits. Of course, you are free to choose any
> other editor if you so prefer.
>
> > 2) where can I learn some basic concepts about sync an async ?
>
> Hmmm, I am not sure if I can refer you to an internationally acclaimed
> book that talks about this at length. I know enough good books about
> the subject, but these tend to be in obscure languages. I do remember,
> however, that the Art of Electronics
> (http://www.amazon.com/Art-Electronic.../dp/0521370957) had
> a very accessible and sane introduction to both synchronous and
> asynchronous circuits. This book however has lots of other things you
> don't need if you want to learn VHDL, so maybe you want to look for
> something else.
>
> However, the basics of synchronous and asynchronous designs are not that
> difficult to grasp, so I'll try to give a quick intro.
>
> In a synchronous system, all events (e.g. state changes) occur in
> lock-step to changes of some reference signal.
>
> For digital circuitry, this signal is usually called the 'clock'. With
> background in computer science you should recall that practically all
> the CPUs do use some or other clock.
>
> In an asynchronous system, there is no requirement that the reference
> signal must exist.
>
> The fundamental difference between these two systems is that synchronous
> systems, while more restrictive in their operation rules, are more
> powerful as they can compute things asynchronous systems can not (see
> e.g.http://www.teamten.com/lawrence/290.paper/node3.html). They are
> also easier to analyze, and as a consequence, automatic tools typically
> cope better with synchronous designs.
>
> For everyday use though, some practical concerns are more interesting,
> as follows.
>
> [Note here that I am trying to eschew talking in terms of logic gates.
> This is because although VHDL is used to describe things you may want to
> put into programmable logic chips, its real domain is events and their
> scheduling. To be fair though, it must be said that the reality of
> using VHDL to ultimately describe the configuration of programmable
> gates does give more reasons to stick to synchronous descriptions. ]
>
> The synchronous circuits are more predictable than their asynchronous
> counterparts. The predictability has to do with the physics of the
> devices that implement logic gates, which is below our abstraction
> radar. Looking at sayhttp://en.wikipedia.org/wiki/Metastability_in_electronicsmay provide
> some clues that the predictability concerns are real.
>
> The predictability I mentioned is important for the construction of
> physical memory elements, such as latches and flipflops. Memory
> elements take in a value, and can 'remember' it indefinitely (i.e., as
> long as power lasts, and special circuits like non-volatile memories can
> remember even longer). The memory property always relies on some sort
> of internal feedback in the element, combined with its physical
> properties. This unfortunately means that some unfortunate input
> pattern combos to memory elements can cause the it to become
> 'metastable', i.e. to oscillate between the logic values, a state that
> can last unpredictably long. In this state, the element is useless
> for practical purposes. This is a realistic scenario in asynchronous
> circuits and designing a (large) functioning circuit that eschews this
> problem becomes cumbersome and ultimately impractical.
>
> The way out is in the discipline of synchronous design. Typically, in
> synchronous designs, memory elements are offered a value to remember,
> but will accept it only at the time an event having to do with a
> reference signal occured.
>
> There are several conventions for this, the so-called 'edge' is the most
> frequently seen. In the 'edge' convention, the value is accepted at
> rising (or falling) edge of the reference signal.
>
> As an added constraint, the value offered to the memory element must be
> present at the memory element input for long enough before and after the
> reference signal trigger (more details are here:http://en.wikipedia.org/wiki/Flip-fl...)#D_flip-flop).
> This, combined with a special way the memory elements are made, greatly
> reduces the metastability problem, to the point where it becomes
> practically solved. In all fairness, it never really goes away, you can
> only make it extremely improbable.
>
> Therefore, you typically want your designs to be synchronous so as to
> stay out of trouble. Your tools want synchronous design too, because
> they can analyze synchronous circuits easier, and can be of more help
> for producing the final output.
>
> There are exceptions to this rule of thumb. You want synchronous design
> for monolithic systems (e.g. describing CPUs). You may want
> asynchronous design for interfaces (e.g. asynchronous transceivers).
> Actually making the design would even require you to dig into the manual
> of the chip you will be putting your design into. It pays to know at
> least a little about how the gates are made, so as to make right design
> decisions.
>
> VHDL allows you to make both synchronous and asynchronous designs and
> you as the designer must know which one is appropriate for a given problem.
>
> > 3) My 2nd project is about a state machine to recognize strings of 0's
> > and 1's which it seems doable but I'm told doing it by "asynchronous
> > reset". What is that and how can I understand it?
>
> I assume that you are familiar with the concept of a state machine, your
> background being computer science. You will make a state machine, use
> combinatorial circuits to compute the new state from the inputs and the
> state (in general, though people tend to distinguish between Mealy and
> Moore state machineshttp://en.wikipedia.org/wiki/Mealy_machine;http://en.wikipedia.org/wiki/Moore_machinedepending on the exact way
> the values are computed), and store new state values at each clock event
> (e.g. rising edge).
>
> You will probably use flip-flops as memory elements to remember the
> state of your machine. These flip-flops accept a value synchronously
> (with reference to the clock signal). A by-product of the way the
> flip-flops are made is that they typically have two additional
> asynchronous inputs, which can be used to set and reset the value of a
> single flip-flop, disregarding the clock events.
>
> The same also can be done while honoring the clock signal. This is
> called a synchronous set/reset. See for examplehttp://en.wikipedia.org/wiki/VHDL#D-type_flip-flopsfor examples of both
> of these in VHDL.
>
> The way you describe your requirement 'by asynchronous reset' does not
> shed much light on what exactly is required from you to do.
>
> One thing that comes to mind is that you need to use asynchronous
> set/reset method to set the initial state in your machine. If so, the
> links I gave above will explain how you can do this.
>
> I can think of other ways to understand your requirement too, such as
> abusing asynchronous flip-flop inputs to completely disregard the clock
> signal, but that, although doable, seems to be a dirty trick that would
> learn you little about good practices.
>
> Given that the assignment is coursework and is thus supposed to be
> instructive, I suppose that the first possibility is the right one.
>
> HTH,
> f


Hello Filip,

I truly appreciate your concern and thanks indeed for such a detailed
explanation!
I read your text but I need to go thru it one more time to get a
better understanding.

There are several links that need to be reviewed one by one. However,
I'm still confused
about something here. If in a circuit 'signal' (clock) is ignored then
how could it be driven?
As far as I remember all waves are based on signals created by clock,
so how does this work?

Meantime, I am going to study and review F/Fs along with VHDL coding
but it would be great
if you could let me know what else I need to be aware of.

Once again thanks for your response and looking forward to have your
advice.

Sincerely,
Amit

Amit

Amit wrote:

> I'm from a computer science background and now planning to get into
> embedded system programming so now I've started learning digital
> design.
> Question:
> 1) Is this enough to start learning VHDL programming?

An editor and simulator is all that is needed to
learn a hardware description language. Having
access to the RTL viewer from Quartus or ISE is a plus.

Note that hardware description languages are used for
hardware synthesis and verification, not for data
or file processing. The word "programming" has
the wrong connotation.

> 2) where can I learn some basic concepts about sync an async ?

First, learn your editor and simulator.
Pick a synthesis template and find some examples.
Here is one source: http://home.comcast.net/~mike_treseler/
Find a good testbench example and run it on your tools.
Use an RTL viewer for a hardware view of the synthesis code.

> 3) My 2nd project is about a state machine to recognize strings of 0's
> and 1's which it seems doable but I'm told doing it by "asynchronous
> reset". What is that and how can I understand it?

Simulation is much easier when all registers
are initialized to a known value. The reset
type is a detail of the synthesis template
and the device you choose.
Don't let this detail sidetrack you.

As a practical matter, even flops with
asynch resets must be driven
from a strobe that is synchronized
to the clock.

Note that the easiest way to a serial
pattern recognizer is with one shift
statement and one comparison statement
in a synchronous process.

-- Mike Treseler

Mike Treseler

On Apr 11, 1:49 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Amit wrote:
> > I'm from a computer science background and now planning to get into
> > embedded system programming so now I've started learning digital
> > design.
> > Question:
> > 1) Is this enough to start learning VHDL programming?
>
> An editor and simulator is all that is needed to
> learn a hardware description language. Having
> access to the RTL viewer from Quartus or ISE is a plus.
>
> Note that hardware description languages are used for
> hardware synthesis and verification, not for data
> or file processing. The word "programming" has
> the wrong connotation.
>
> > 2) where can I learn some basic concepts about sync an async ?
>
> First, learn your editor and simulator.
> Pick a synthesis template and find some examples.
> Here is one source:http://home.comcast.net/~mike_treseler/
> Find a good testbench example and run it on your tools.
> Use an RTL viewer for a hardware view of the synthesis code.
>
> > 3) My 2nd project is about a state machine to recognize strings of 0's
> > and 1's which it seems doable but I'm told doing it by "asynchronous
> > reset". What is that and how can I understand it?
>
> Simulation is much easier when all registers
> are initialized to a known value. The reset
> type is a detail of the synthesis template
> and the device you choose.
> Don't let this detail sidetrack you.
>
> As a practical matter, even flops with
> asynch resets must be driven
> from a strobe that is synchronized
> to the clock.
>
> Note that the easiest way to a serial
> pattern recognizer is with one shift
> statement and one comparison statement
> in a synchronous process.
>
> -- Mike Treseler


Hello Mike,

Thanks for your advice. I found a free (student version) software to
start (from Mentor Graphics Corporation)
you can check it out at http://www.model.com/products/products_pe.asp.
I'm hoping this is what you meant from
editor and simulator.

Also, you mentioned that "Having access to the RTL viewer from Quartus
or ISE is a plus. " Now, where can I get
these? or are they part of the software I'm using (ModelSIM )?

What do you mean from "synthesis template" ? or let's say what
template means here?


Thanks,
amit

Amit

Amit wrote:

> Thanks for your advice. I found a free (student version) software to
> start (from Mentor Graphics Corporation)
> you can check it out at http://www.model.com/products/products_pe.asp.
> I'm hoping this is what you meant from
> editor and simulator.

That simulator is fine.
The editor is ok to get started.

> Also, you mentioned that "Having access to the RTL viewer from Quartus
> or ISE is a plus. " Now, where can I get
> these? or are they part of the software I'm using (ModelSIM )?

No. That's altera.com or xilinx.com.
The RTL viewer may require having a license.

> What do you mean from "synthesis template" ? or let's say what
> template means here?

For me it means:

-------------------------------------------------------------------------------
-- Process Template -- Always exactly the same:
-------------------------------------------------------------------------------
begin -- process template
if reset = '1' then -- Assumes synched trailing edge reset
init_regs; -- procedure
elsif rising_edge(clock) then
update_regs; -- procedure
end if; -- Synchronous init optional
update_ports; -- procedure
end process sync_template;
end architecture synth;
-------------------------------------------------------------------------------

Study the examples I gave you for details.

-- Mike Treseler

Mike Treseler