VHDL signal activity and attributes ?

Discussion in 'VHDL' started by whygee, Apr 13, 2010.

  1. whygee

    whygee Guest

    Hello,

    I search a way to safely detect that all the signals
    of my entities have settled before my testbench
    fires another clock cycle. I find no way in the
    langage to indicate that there is no delta cycle
    left, so the time can advance to the next step.
    And even in the next step, I can't know if activity
    has been scheduled to happen :-/

    I could XOR_reduce all the signals I want to observe
    and then apply a simple attribute, but the closest
    I come is the 'active attribute, that won't even
    tell me if the signal is scheduled to change in the future.

    All I could do is assume things about the tested design,
    and these assumptions are dangerous and not future-proof
    or fool-proof. Or else I could remove all the timing
    information from the model, but this would remove
    all value or interest in the model :-/

    If anyone has a trick or idea, i'll gladly read it !

    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Apr 13, 2010
    #1
    1. Advertising

  2. whygee

    whygee Guest

    Hi !

    Alan Fitch wrote:
    > A postponed process is guaranteed to run after all deltas have passed -
    > would that help? I'm not sure I quite understand what you're looking for,

    oh yes, that's one idea.
    It does not solve all my issues but it's an interesting method.
    I don't have my reference books and must rely on the 'net
    to find the informations.

    Another side of the problem is :
    how are the processes executed ?
    I mean, if I write a process without sensitivity list,
    which loops continuously, is the process executed
    at every delta time ? Or does it loops continuously
    inside the delta ? I imagine that the order in which
    the processes are executed inside the delta is not
    easily controlled but that can be circumvented.


    > regards
    > Alan

    thank you,
    yg

    --
    http://ygdes.com / http://yasep.org
     
    whygee, Apr 13, 2010
    #2
    1. Advertising

  3. whygee

    whygee Guest

    hi !

    Alan Fitch wrote:
    > All postponed processes are guaranteed to run after all non-postponed
    > processes.
    > If you have more than one postponed process they will run in an
    > unspecified order.
    > A postponed process may not cause another delta.


    OK, this confirms what I just read in other places.

    "A postponed process can't cause another delta"
    _at the same clock time_, but what if it causes
    a delay and then causes another delta ?
    I believe that it is ok because it avoids
    the time paradox.

    My current idea is to drop all the timing specification
    of the model (I'll see later) and use something like :


    signal clk : std_logic;

    postponed process
    begin
    -- delay
    wait for 1ms;
    -- cause delta
    if (clk='0')
    then
    clk<='1';
    else
    clk<='0';
    end if;
    end process;

    Of course, this is not the end of the story,
    since something as simple as this does
    not require "postponed". Some side-effect-prone
    stuff will be added later.

    The fact that this postponed process is the only
    timing controller helps things, but the tested
    model might contain delayed signals which could
    cause the whole thing to fall apart. I could
    wait for more than 1ms, like 1 day or something "long"
    but who knows what nasty side effect this could cause...

    thanks for the hints, I knew I missed something :)

    > regards
    > Alan

    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Apr 13, 2010
    #3
  4. whygee wrote:

    > Hi !
    >
    > Alan Fitch wrote:
    >> A postponed process is guaranteed to run after all deltas have passed -
    >> would that help? I'm not sure I quite understand what you're looking for,

    > oh yes, that's one idea.
    > It does not solve all my issues but it's an interesting method.
    > I don't have my reference books and must rely on the 'net
    > to find the informations.
    >
    > Another side of the problem is :
    > how are the processes executed ?


    They are all executed at simulation start (time=0, delta=0) and run until
    they encounter a wait statement, which will suspend the process. A
    sensitivity list is an implicit wait statement at the end of the process.
    The process resumes after the wait statement is fulfilled.

    Reaching the end of a process causes execution to continue at the top again.

    > I mean, if I write a process without sensitivity list,


    and without a wait statement...

    > which loops continuously, is the process executed
    > at every delta time ?


    No.

    > Or does it loops continuously inside the delta ?


    Yes. And because the process never suspends, no delta cycle occurs anymore.
    In other words: the simulator hangs, until you kill it.

    Always a nice situation to debug, as you cannot break the simulator to
    continue with single stepping, to find exactly where the error is. At
    least, that's my experience with ModelSim.

    > I imagine that the order in which
    > the processes are executed inside the delta is not
    > easily controlled but that can be circumvented.


    The order of execution of processes that resume at exact the same delta is
    undetermined. The delayed update of signals (one delta, or some real time,
    like 1 ns) makes sure that this undeterministism is not a problem and does
    not create a race condition. Unless of course you are mucking around with
    shared variables, but that's another story.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Apr 13, 2010
    #4
  5. whygee

    whygee Guest

    Paul Uiterlinden wrote:
    > Reaching the end of a process causes execution to continue at the top again.

    without waiting for another delta time,
    if i understand correctly (and your post is clear about it)

    >> I mean, if I write a process without sensitivity list,

    > and without a wait statement...

    yes (it's not mentioned, it's not implied)

    >> which loops continuously, is the process executed
    >> at every delta time ?

    > No.
    >
    >> Or does it loops continuously inside the delta ?

    > Yes. And because the process never suspends, no delta cycle occurs anymore.
    > In other words: the simulator hangs, until you kill it.

    ouch...

    >> I imagine that the order in which
    >> the processes are executed inside the delta is not
    >> easily controlled but that can be circumvented.

    > The order of execution of processes that resume at exact the same delta is
    > undetermined. The delayed update of signals (one delta, or some real time,
    > like 1 ns) makes sure that this undeterministism is not a problem and does
    > not create a race condition. Unless of course you are mucking around with
    > shared variables, but that's another story.

    oh, it's probably worse than that ;-)

    i've see "wait for 0ns" somewhere, i'll have to try too.

    thanks,
    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Apr 13, 2010
    #5
  6. whygee

    Tricky Guest


    >
    > > Or does it loops continuously inside the delta ?

    >
    > Yes. And because the process never suspends, no delta cycle occurs anymore.
    > In other words: the simulator hangs, until you kill it.
    >
    > Always a nice situation to debug, as you cannot break the simulator to
    > continue with single stepping, to find exactly where the error is. At
    > least, that's my experience with ModelSim.
    >



    I was always under the impression that one loop of a process is 1
    delta. If a process never waits, it will go for infinite delta's,
    which is why you set an iteration limit inside modeslsim to prevent
    loops like this occuring.
     
    Tricky, Apr 14, 2010
    #6
  7. Alan Fitch wrote:

    > A delta consists of
    >
    > 1. All runnable processes run until they suspend (e.g. hit a wait, or in
    > the case of a sensitivity list reach the bottom - which is of course an
    > implicit "wait on")
    >
    > 2. Once all processes suspend, signals update (possibly creating events,
    > which trigger processes to be runnable again - a new delta).
    >
    > This code
    >
    > process
    > begin
    > end process;
    >
    > gets stuck at time 0 ns delta 0 and can never escape.


    And that's why ModelSim (don't know for other simulators) generates a nice
    warning for such a situation:

    ** Warning: [2] stuck.vhd(8): (vcom-1090) Possible infinite loop: Process
    contains no WAIT statement.

    And to get more explanation, run "verrror 1090":

    vcom Message # 1090:
    A process that has no sensitivity list, contains no wait statements,
    and contains no calls to procedures that contain wait statements will
    execute forever without advancing time.

    IEEE Std 1076-2002, 9.2 Process statement:
    The execution of a process statement consists of the repetitive
    execution of its sequence of statements. After the last statement in
    the sequence of statements of a process statement is executed,
    execution will immediately continue with the first statement in the
    sequence of statements.

    This message can be suppressed with the vcom option -nowarn 2.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Apr 14, 2010
    #7
  8. whygee

    whygee Guest

    whygee, Apr 14, 2010
    #8
    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. Michael Pronath
    Replies:
    1
    Views:
    1,245
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    504
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    691
    Jonathan Bromley
    Jan 30, 2007
  4. afd
    Replies:
    1
    Views:
    8,565
    Colin Paul Gloster
    Mar 23, 2007
  5. Nicolas Moreau
    Replies:
    9
    Views:
    3,372
Loading...

Share This Page