Concurrent Assignment

[Taras_96]

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]

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]

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