Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
1. Syntax. ':=' is used only if the left hand side of the assignmentNot 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...
Instead of "global scope" I should have said "architecture-wide2. Scope. A variable can't be declared with global scope inside an
architecture, whereas a signal can. (more or less.)
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
One way to think of this is that variables are assigned sequentially,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.
I hate it when people say that.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.
Fair enough - I was not thinking of such situations. But thinking about"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?
I'm a relative newbie at VHDL myself (I've done a bit more Verilog), so I am"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.
--
Fair comment.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.
Let's start by limiting the problem to processes that have a"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 ?
Sorry - I had been assuming these limitations in the first place, since I'm"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.)
Again, I've been thinking in terms of synthesis rather than simulationGiven 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.
It was a good thing it did, since you've clarified the difference betweenThis 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