Concurrent Assignment

Discussion in 'VHDL' started by Taras_96, Apr 1, 2005.

  1. Taras_96

    Taras_96 Guest

    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, Apr 1, 2005
    #1
    1. Advertising

  2. 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, Apr 1, 2005
    #2
    1. Advertising

  3. 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, Apr 1, 2005
    #3
  4. 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, Apr 1, 2005
    #4
  5. Taras_96

    Taras_96 Guest

    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, Apr 3, 2005
    #5
  6. 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, Apr 3, 2005
    #6
  7. Taras_96

    Taras_96 Guest

    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, Apr 4, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pep
    Replies:
    6
    Views:
    826
  2. jason12
    Replies:
    0
    Views:
    597
    jason12
    Jul 29, 2007
  3. Torsten Landschoff

    Concurrent signal assignment vs. port mapping

    Torsten Landschoff, Jul 28, 2008, in forum: VHDL
    Replies:
    1
    Views:
    596
    Mike Treseler
    Jul 28, 2008
  4. sam.green
    Replies:
    3
    Views:
    2,923
    jeppe
    Oct 8, 2008
  5. Replies:
    5
    Views:
    1,325
    Michael Hermann
    Dec 30, 2011
Loading...

Share This Page