Newbie: what's the difference btn ':=' and '<='

[jk]

Not too sure the difference, have used them somewhat interchangeably and
expect it will cause errors when I go to simulate...

some background information would be much appreciated...

- Kingsley

 

[Allan Herriman]

Not too sure the difference, have used them somewhat interchangeably and
expect it will cause errors when I go to simulate...

some background information would be much appreciated...

1. Syntax. ':=' is used only if the left hand side of the assignment
is a variable and '<=' is used only if the left hand side is a signal.

Your next question will be "what's the difference between a signal and
a variable?"

2. Scope. A variable can't be declared with global scope inside an
architecture, whereas a signal can. (more or less.)

3. Update model. A variable takes the value assigned with ':='
immediately when the simulator executes that instruction.
A signal takes the value assigned with '<=' when the simulator has
finished calculating all the new signal values for that simulator
cycle (delta). (more or less.)

Consider the following assigments *inside a clocked process*.

var2 := var1;
var3 := var2;
-- var1,2 and 3 now all have the same value

sig2 <= sig1;
sig3 <= sig2;
-- sig3 lags sig2 by 1 clock, and sig2 lags sig1 by 1 clock.
-- (this just inferred two flip flops (in synthesis))



My description is a bit rough, but it should give you some hints.
More details in the FAQ:
http://www.vhdl.org/comp.lang.vhdl/FAQ1.html

Regards,
Allan.

 

[Allan Herriman]

2. Scope. A variable can't be declared with global scope inside an
architecture, whereas a signal can. (more or less.)

Instead of "global scope" I should have said "architecture-wide
scope".

A truly global scope requires a signal to be declared in a package.

Regards,
Allan.

 

[Alan Fitch]

Not too sure the difference, have used them somewhat interchangeably and
expect it will cause errors when I go to simulate...

some background information would be much appreciated...

- Kingsley

:= is used for assignment to variables
<= is used for assignment to signals

regards

Alan

--
Alan Fitch
Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
(e-mail address removed)
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

The contents of this message may contain personal views which are not
the
views of Doulos Ltd., unless specifically stated.

 

[David Brown]

1. Syntax. ':=' is used only if the left hand side of the assignment
is a variable and '<=' is used only if the left hand side is a signal.

Your next question will be "what's the difference between a signal and
a variable?"

2. Scope. A variable can't be declared with global scope inside an
architecture, whereas a signal can. (more or less.)

3. Update model. A variable takes the value assigned with ':='
immediately when the simulator executes that instruction.
A signal takes the value assigned with '<=' when the simulator has
finished calculating all the new signal values for that simulator
cycle (delta). (more or less.)

Consider the following assigments *inside a clocked process*.

var2 := var1;
var3 := var2;
-- var1,2 and 3 now all have the same value

sig2 <= sig1;
sig3 <= sig2;
-- sig3 lags sig2 by 1 clock, and sig2 lags sig1 by 1 clock.
-- (this just inferred two flip flops (in synthesis))

One way to think of this is that variables are assigned sequentially,
whereas signals are assigned in parallel. You can swap the order of the
signal statements without it making any difference to the effect.

 

[Jonathan Bromley]

One way to think of this is that variables are assigned sequentially,
whereas signals are assigned in parallel. You can swap the order of the
signal statements without it making any difference to the effect.

I hate it when people say that.

process(...) process(...)
begin begin
S <= '1'; S <= '0';
S <= '0'; S <= '1';
end process; end process;

No effect when you swap the assignments, huh?

"Signals are assigned in parallel" is such a weak
intellectual prop that it should never be relied on.
It's not too hard to work out a better mental model
that gives much more reliable answers.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: (e-mail address removed)
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[David Brown]

I hate it when people say that.

process(...) process(...)
begin begin
S <= '1'; S <= '0';
S <= '0'; S <= '1';
end process; end process;

No effect when you swap the assignments, huh?

Fair enough - I was not thinking of such situations. But thinking about
these as parallel assignments would make it clear that this is not a simple
case.

"Signals are assigned in parallel" is such a weak
intellectual prop that it should never be relied on.
It's not too hard to work out a better mental model
that gives much more reliable answers.
--

I'm a relative newbie at VHDL myself (I've done a bit more Verilog), so I am
happy to be corrected. Do you have any other suggestings for models that
are simple enough to start with and are not too inaccurate ?

 

[Guest]

Fair enough - I was not thinking of such situations. But thinking about
these as parallel assignments would make it clear that this
is not a simple case.

Fair comment.

I'm a relative newbie at VHDL myself (I've done a bit more Verilog), so I am
happy to be corrected. Do you have any other suggestings for models that
are simple enough to start with and are not too inaccurate ?

Let's start by limiting the problem to processes that have a
sensitivity list (and therefore no wait statements in the body),
and assignments that don't have an associated "after" delay.
(Note that these are some of the restrictions that you
must obey for synthesisable logic.)

Given these restrictions, I think it's easiest to say:
* Assignments to any given signal are executed in sequence,
so that only the last-executed of any such assignments will
take effect.
* Signals are not immediately updated by assignments to them;
instead, the signals have a steady value whilst the process
executes. When all processes have finished executing at any
given moment of simulation time, ALL signals are updated
with the values that have been newly assigned to them.

I know that's not a short description, but it's reasonably
accurate and I think it's fairly clear and unambiguous.
The critical insight is the distinction between signal
ASSIGNMENT, which is instantaneous and is executed in the
normal "software-like" flow of a process, and signal UPDATE
which doesn't happen until all processes have halted because
they're waiting for their sensitivity lists or a wait statement.
This two-stage simulation cycle guarantees that all processes
see consistent values on all signals. It implies that each
signal has not only its current value that you can read, but
also a projected value that will be used in the future to
update the signal. Assignment modifies the projected value,
not the current value. (The "projected value" is actually
quite a lot more complicated than that, because it is
really a list of time/value pairs describing the scheduled
future behaviour of the signal, but we'll let that pass!)

In the special (but very important) case of clocked processes,
you can reasonably think of it in a slightly simpler way:
* Whenever you USE the value of a signal, you see its value
as it was at the moment of the clock edge;
* Whenever you ASSIGN to a signal, you are specifying the
new value the signal will take just after the clock edge.

I guess if you had said "signals are UPDATED in parallel"
instead of "signals are ASSIGNED in parallel", then you
would not have triggered my dodgy-assumptions alarm!

If you allow delayed signal assignments such as
Q <= D after Tco;
then things are a bit more complicated and you will need to
learn the full details of inertial delay.

If you use a process with no sensitivity list, for example
in a test bench, then you run the risk that a signal's
value will change during the life of a process. However,
it can change only during the execution of "wait" statements.
Life is still sane.

 

[David Brown]

Fair comment.
I

Let's start by limiting the problem to processes that have a
sensitivity list (and therefore no wait statements in the body),
and assignments that don't have an associated "after" delay.
(Note that these are some of the restrictions that you
must obey for synthesisable logic.)

Sorry - I had been assuming these limitations in the first place, since I'm
using vhdl for fpga synthesis. I hadn't really been thinking of
non-synthesisable cases.

Given these restrictions, I think it's easiest to say:
* Assignments to any given signal are executed in sequence,
so that only the last-executed of any such assignments will
take effect.
* Signals are not immediately updated by assignments to them;
instead, the signals have a steady value whilst the process
executes. When all processes have finished executing at any
given moment of simulation time, ALL signals are updated
with the values that have been newly assigned to them.

I know that's not a short description, but it's reasonably
accurate and I think it's fairly clear and unambiguous.
The critical insight is the distinction between signal
ASSIGNMENT, which is instantaneous and is executed in the
normal "software-like" flow of a process, and signal UPDATE
which doesn't happen until all processes have halted because
they're waiting for their sensitivity lists or a wait statement.

Again, I've been thinking in terms of synthesis rather than simulation
(i.e., trying to imagine what sort of logic gates are generated), but your
explanation does help - I think it might make it easier for me to understand
some simulation effects.

This two-stage simulation cycle guarantees that all processes
see consistent values on all signals. It implies that each
signal has not only its current value that you can read, but
also a projected value that will be used in the future to
update the signal. Assignment modifies the projected value,
not the current value. (The "projected value" is actually
quite a lot more complicated than that, because it is
really a list of time/value pairs describing the scheduled
future behaviour of the signal, but we'll let that pass!)

In the special (but very important) case of clocked processes,
you can reasonably think of it in a slightly simpler way:
* Whenever you USE the value of a signal, you see its value
as it was at the moment of the clock edge;
* Whenever you ASSIGN to a signal, you are specifying the
new value the signal will take just after the clock edge.

I guess if you had said "signals are UPDATED in parallel"
instead of "signals are ASSIGNED in parallel", then you
would not have triggered my dodgy-assumptions alarm!

It was a good thing it did, since you've clarified the difference between
variables and signals in simulation and not just synthesis. Thanks!