Concurrent Assignment

Hi all

I've just started to learn VHDL having previously coded a bit in
Verilog. I'm aiming to write synthesisable VHDL code at RTL. I'm
having trouble getting my head around concurrent signal assignments.

>From what I've read about VHDL, concurrent seems to be a bad
description. One might be tempted to interpret the concurrent
assignment:

a<=b
c<=a

As at the same time a gets assigned the value of b, and c gets assigned
the OLD value of a. Would a better way of describing concurrent
assignment be "the order of assignment doesn't matter" - this is
because of the event processing/process execution cycles, right?

I'm pretty sure that concurrent assignment from a synthesisable VHDL
point of view just represents how signals will be 'wired'.

a<=b
c<=a

just describes the fact that b is wired to a, and a is wired to c:

----------------b------------
|
a
|
----------------c------------

something like:

a<= b or c
d <= a and c

would represent something like

-----b----------|---|
|OR |-----a-----|----|
-----c----------|---| |AND |
| | |--------d--------
-----------------------|----|

Does this stuff sound right?

Thanks in advance

Taras

PS: I realise I posted not too long before this message. I decided to
put it all into one message would be too big.

Taras_96

On 31 Mar 2005 23:20:37 -0800, "Taras_96" <> wrote:

>>From what I've read about VHDL, concurrent seems to be a bad
>description.

No; it's very useful for describing small pieces of combinational
logic.

> One might be tempted to interpret the concurrent
>assignment:
>
>a<=b
>c<=a
>
>As at the same time a gets assigned the value of b, and c gets assigned
>the OLD value of a.

No. A concurrent assignment is exactly a process, sensitive to
all signals used in its right-hand-side expression. Consequently,
the sequence of activity is....

* when signal 'b' changes, the assignment "a<=b" is triggered
* this schedules an update on 'a' for one delta cycle later
* when signal 'a' updates, the second assignment is triggered
* this schedules an update on 'c', using the NEW value of 'a'
of course, for one delta cycle later

> Would a better way of describing concurrent
>assignment be "the order of assignment doesn't matter" - this is
>because of the event processing/process execution cycles, right?

That's a useful rule of thumb.

>I'm pretty sure that concurrent assignment from a synthesisable VHDL
>point of view just represents how signals will be 'wired'.
>
>a<=b
>c<=a
>
>just describes the fact that b is wired to a, and a is wired to c:

Correct. Note, however, that each concurrent assignment introduces
a delta-cycle delay (roughly the same as the delay between executing
a nonblocking assignment in Verilog and its signal being updated).
By contrast, the Verilog continuous assignment effectively uses
blocking assignment and introduces no delay whatsoever (unless
you specify one, of course). This is VERY important if you try
to create gated clocks.
--
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, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
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.

Jonathan Bromley

Jonathan Bromley wrote:
> Note, however, that each concurrent assignment introduces a
> delta-cycle delay (roughly the same as the delay between executing a
> nonblocking assignment in Verilog and its signal being updated). By
> contrast, the Verilog continuous assignment effectively uses blocking
> assignment and introduces no delay whatsoever (unless you specify
> one, of course). This is VERY important if you try to create gated
> clocks.

Someone creating gated clocks (hopefully) knows that care is needed or
their synthesis results won't work. The real "gotcha"s, IMHO, happen
when you run a clock through a "wire" for some reason.

I've never been 100% clear on just when delta delays get introduced, so
someone please tell me I get something wrong in what follows.

Connections made during instantiation via a port map do not introduce a
delta delay but connections inside an architecture, even a "wire" like
"a<=b" do. A result of this is that you have to be careful about some
kinds of structures that may make sense from a structured
programming/code re-use viewpoint.

In particular, be careful of using generics and generates to choose
which input is used as a clock. e.g.:

if generic_use_clock_a generate
module_clock <= input_clock_a;
end generate;
if generic_use_clock_b generate
module_clock <= input_clock_b;
end generate;

This kind of thing adds a delta delay to your module's clock. The
consequence of this is your clocked processes may now be scheduled at
the same time as inputs that are clocked outputs of other modules. This
results in a race condition with indeterminate results since the order
of execution of events with identical deltas is left up to the
simulator. I've seen cases with multiple inputs from another module
where some inputs will be treated as "arriving" at a process before the
clock, and others after. Even more interesting is that this before/after
order may change following a recompile. The consequence is a debugging
nightmare.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

Tim Hubberstey

On Fri, 01 Apr 2005 19:01:57 GMT, Tim Hubberstey <>
wrote:

>Jonathan Bromley wrote:
>> Note, however, that each concurrent assignment introduces a
>> delta-cycle delay (roughly the same as the delay between executing a
>> nonblocking assignment in Verilog and its signal being updated). By
>> contrast, the Verilog continuous assignment effectively uses blocking
>> assignment and introduces no delay whatsoever (unless you specify
>> one, of course). This is VERY important if you try to create gated
>> clocks.
>
>Someone creating gated clocks (hopefully) knows that care is needed or
>their synthesis results won't work. The real "gotcha"s, IMHO, happen
>when you run a clock through a "wire" for some reason.
>
>I've never been 100% clear on just when delta delays get introduced, so
>someone please tell me I get something wrong in what follows.

Just about everything you say agrees with my understanding, except...

>This kind of thing
[ internal_clock <= source_clock; ]
> adds a delta delay to your module's clock.

Yes.

>consequence of this is your clocked processes may now be scheduled at
>the same time as inputs that are clocked outputs of other modules.

I'm not quite sure what you mean here - perhaps I can rephrase it:
"your clocked processes are now scheduled to run in a delta cycle
when clocked outputs of other modules have already been updated".
A VHDL delta cycle proceeds in two completely separate phases
that absolutely do NOT overlap: updating of signals (which may in
turn cause sensitive processes to bee scheduled for execution in
this or future deltas), and execution of processes (which, of
course, may schedule new signal updates in future deltas).

>This
>results in a race condition with indeterminate results since the order
>of execution of events with identical deltas is left up to the
>simulator.

I simply don't understand this. I absolutely agree that the
scenario you describe will give results that are different from
what you wanted, and indeed that it can give rise to a synthesis/
simulation mismatch. But I cannot see how it is indeterminate.
The two-phase delta cycle essentially forbids that.

You are right that "order of execution of events with identical
deltas" (i.e. processes ready for execution in the same delta
cycle) is indeterminate. But regardless of their order of
execution, all those processes will see the values of signals
exactly as they were at the end of the current delta's
signal-update phase. No updating of signals takes place
during the process-execution phase, so there can be no
indeterminacy - unlike Verilog, in which blocking assignment
can update "signals" during the execution of a single process.

> I've seen cases with multiple inputs from another module
>where some inputs will be treated as "arriving" at a process before the
>clock, and others after.

Sure; it depends how many signal assignments those signals have
been through on the way. In VHDL it's very common to have an
internal signal in a module that is finally assigned to an
output of the module using continuous assignment (because it's
impossible to read "out" ports). Such a signal will arrive
at its "process(clock)" destination TWO deltas after the
clock edge that updated it. So a one-delta delay in the second
block's clock will not hurt for that signal, but would give bad
behaviour for a signal that was directly assigned on the
original clock edge.

> Even more interesting is that this before/after
>order may change following a recompile.

In Verilog yes; in VHDL, no way. Find me an example and I'll
eat humble pie, but I reckon I'm on safe ground unless EITHER
(a) you're comparing a gate-level sim with an RTL sim, OR
(b) you used shared variables or files in a dodgy way.

Cheers

--
Jonathan Bromley

Jonathan Bromley

Hi everyone

Thanks for your replies. Jonathan, what I meant by saying "concurrent
is a bad description" was that concurrent was a bad word to use to
describe the mechanims of the assignment (not that its not useful) -
concurrent means to me that it happens at the same time, which your
example shows that the assignments don't (they are separated by delta
delays) - bad choice of words. You've answered my original questions,
but just for discussion I suppose:

> "the Verilog continuous assignment effectively uses
> blocking assignment and introduces no delay whatsoever (unless you
> specify one, of course). "

In programming verilog, I viewed continuous assignments as assignments
that were 'always true' at all points of the simulation cycle. Perhaps
you mean the Verilog blocking assignment?

Also, as I understand it the issue with clock gating is that it often
involves signal assignment between clocks:

clock_a<=clock_b

This introduces a delta delay between clock_a and clock_b

Could someone provide an example of this happening?

>Sure; it depends how many signal assignments those signals have
>been through on the way. In VHDL it's very common to have an
>internal signal in a module that is finally assigned to an
>output of the module using continuous assignment (because it's
>impossible to read "out" ports). Such a signal will arrive
>at its "process(clock)" destination TWO deltas after the
>clock edge that updated it. So a one-delta delay in the second
>block's clock will not hurt for that signal, but would give bad
>behaviour for a signal that was directly assigned on the
>original clock edge.

I agree with Jonathan about the race conditions not being possible
because of the non-overlapping signal assignment & event processing
stages (not because VHDL is my area of expertise its intuitive to me
I suppose)

Thanks everyone

Taras

Taras_96

On 2 Apr 2005 18:17:17 -0800, "Taras_96" <> wrote:

>Hi everyone
>
>Thanks for your replies. Jonathan, what I meant by saying "concurrent
>is a bad description" was that concurrent was a bad word to use to
>describe the mechanims of the assignment (not that its not useful) -
>concurrent means to me that it happens at the same time,

Curious. I (and, I think, most people) think of "concurrent" to
mean "at the same time as other things". Your interpretation
would be better phrased as "immediate" or "instantaneous", no?
VHDL concurrent signal assignments are concurrent with all
such other concurrent assignments, and all other processes.

>> "the Verilog continuous assignment effectively uses
>> blocking assignment and introduces no delay whatsoever (unless you
>> specify one, of course). "
>
>In programming verilog, I viewed continuous assignments as assignments
>that were 'always true'

Fair enough, but of course in simulation that effect is achieved
by evaluating the continuous assignment only whenever its
contributing inputs change.

> at all points of the simulation cycle.

what do you mean by this? It makes no sense to me. If I write
(in Verilog)

assign a = b;

then there is a point in the simulation cycle when 'b' has
changed, but 'a' has not yet changed. It doesn't matter; you
can't make any effective use of it; but it happens.

> Perhaps you mean the Verilog blocking assignment?

No. I'm prone to typographical errors like everyone else,
but this time I said exactly what I meant.

>Also, as I understand it the issue with clock gating is that it often
>involves signal assignment between clocks:
>
>clock_a<=clock_b
>
>This introduces a delta delay between clock_a and clock_b
>
>Could someone provide an example of this happening?

process (clock_a) begin
if rising_edge(clock_a) then
FF1 <= d; -- FF1 is delta-delayed relative to clock_a
end if;
end process;

clock_b <= clock_a; -- clock_b is delta-delayed

process (clock_b) begin
if rising_edge(clock_b) then
FF2 <= FF1; -- OOPS: here we read the UPDATED value of FF1
end if;
end process;


>I agree with Jonathan about the race conditions not being possible
>because of the non-overlapping signal assignment & event processing
>stages (not because VHDL is my area of expertise its intuitive to me
>I suppose)

Hmmm. How "intuitive" do you find Verilog's simulation model?
--
Jonathan Bromley

Jonathan Bromley

Hi

>Curious. I (and, I think, most people) think of "concurrent" to
>mean "at the same time as other things". Your interpretation
>would be better phrased as "immediate" or "instantaneous"

It's not really important, but when I think concurrent, I think:

a <= b //a is scheduled to get the old value of b
d <= a // *at the same time* d is scheduled to be assigned the old
value of a
//all of the data from the right hand side flows to the left hand side
at the same
time - it is concurrent

which, of course, is not the case.

> what do you mean by this? It makes no sense to me.

Probably nothing - just bad wording. I should have put a disclaimer at
the start
of the post that I certainly do not consider myself a Verilog expert -
I worked with
Verilog for about 4 months, which isn't that long. I seem to remember
(from about a year ago - so don't quote me on this) that the difference
between
regs and wires is that regs *can* have memory (in the computer
simulation sense)
- they don't need to be continously driven by an input .. I think this
is what I was
referring to.. but again, don't read too deep into my explanations

> How "intuitive" do you find Verilog's simulation model?

I remember that once you get rid of the timing control, the simulation
model isn't
too hard to understand - however, this was a year ago, maybe I've
forgotten more
things than I think.

Taras

Taras_96