f



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

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


0
jk
1/21/2004 6:51:11 AM
comp.lang.vhdl 6430 articles. 2 followers. Post Follow

8 Replies
788 Views

Similar Articles

[PageSpeed] 1

On Wed, 21 Jan 2004 17:51:11 +1100, "jk"
<z3015094NOSPAM@student.unsw.edu.au> wrote:

>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.
0
Allan
1/21/2004 7:45:20 AM
On Wed, 21 Jan 2004 18:45:20 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

>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.
0
Allan
1/21/2004 9:25:08 AM
"jk" <z3015094NOSPAM@student.unsw.edu.au> wrote in message
news:bul7ai$o6l$1@tomahawk.unsw.edu.au...
> 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:
alan.fitch@doulos.com
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.

0
Alan
1/21/2004 9:34:02 AM
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:6oas001o3en6turjvihkt3o3kktvrf1qmj@4ax.com...
> On Wed, 21 Jan 2004 17:51:11 +1100, "jk"
> <z3015094NOSPAM@student.unsw.edu.au> wrote:
>
> >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))
>
>

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.


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


0
David
1/21/2004 11:38:59 AM
"David Brown" <david@no.westcontrol.spam.com> wrote in
message news:bulo3t$eqj$1@news.netpower.no...

> 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: jonathan.bromley@doulos.com
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.



0
Jonathan
1/21/2004 1:35:48 PM
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:bulv9m$mt$1$830fa78d@news.demon.co.uk...
> "David Brown" <david@no.westcontrol.spam.com> wrote in
> message news:bulo3t$eqj$1@news.netpower.no...
>
> > 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?
>

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 ?



0
David
1/21/2004 2:55:20 PM
"David Brown" <david@no.westcontrol.spam.com> wrote in
message news:bum3k8$k5e$1@news.netpower.no...
> >   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.

Fair comment.

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

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.
--
Jonathan Bromley




0
jonathan
1/22/2004 4:41:00 PM
<jonathan.bromley@doulos.com> wrote in message
news:buougv$14k$1$8300dec7@news.demon.co.uk...
> "David Brown" <david@no.westcontrol.spam.com> wrote in
> message news:bum3k8$k5e$1@news.netpower.no...
> > >   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.
>
> Fair comment.
>
> > > "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 ?
>
> 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!

> 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.
> --
> Jonathan Bromley
>
>
>
>


0
David
1/23/2004 10:35:39 AM
Reply: