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

  2. No; it's very useful for describing small pieces of combinational
    logic.
    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
    That's a useful rule of thumb.
    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. Advertisements

  3. 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, Apr 1, 2005
    #3
  4. Just about everything you say agrees with my understanding, except...
    [ internal_clock <= source_clock; ]
    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).
    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.
    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.
    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, 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:
    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?
    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. 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.
    Fair enough, but of course in simulation that effect is achieved
    by evaluating the continuous assignment only whenever its
    contributing inputs change.
    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.
    No. I'm prone to typographical errors like everyone else,
    but this time I said exactly what I meant.
    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;

    Hmmm. How "intuitive" do you find Verilog's simulation model? ;-)
     
    Jonathan Bromley, Apr 3, 2005
    #6
  7. Taras_96

    Taras_96 Guest

    Hi
    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.
    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 :)
    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. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.