Procedure exit - simulation result

Discussion in 'VHDL' started by ALuPin, Jan 5, 2005.

  1. ALuPin

    ALuPin Guest

    Unfortunately I could not respond to the post "Procedure exit on
    global signal_" directly, so I had to open a new one.

    First of all I want to thank you for the suggestions.

    I have tried one fix out:

    Mr Bromley suggested the following:
    >In this case you have only one "wait" so it's quite easy to fix:
    >
    > OuterLoop: for i in 0 to 4 loop
    > while not rising_edge(clock) loop
    > wait on clock, order_burst_data;
    > exit OuterLoop when order_burst_data_in='1';
    > end loop;
    > end loop; -- OuterLoop


    I have simulated it with the VHDL code shown at
    http://mitglied.lycos.de/vazquez78
    This VHDL code is basically the code I showed in the last post.
    Additionally there is a state machine included in the procedure.

    The simulation plot shows that the loop "Outerloop" is left although
    the exit condition order_burst_data_in='1' does not occur.

    Is there some problem with the setup of the clock as Mr Lewis
    explained ?
    Or does the problem arise from clocking the state machine and waiting
    on
    rising_edges of the clock within the particular state ?

    I would be very thankful for your explanation.
    Rgds
    André
    ALuPin, Jan 5, 2005
    #1
    1. Advertising

  2. ALuPin wrote:

    > I have tried one fix out:
    > Mr Bromley suggested the following:
    >> OuterLoop: for i in 0 to 4 loop
    >> while not rising_edge(clock) loop
    >> wait on clock, order_burst_data;
    >> exit OuterLoop when order_burst_data_in='1';
    >> end loop;
    >> end loop; -- OuterLoop


    Maybe ( not rising_edge(clock) ) is always false
    since this "OuterLoop" is inside of this:

    for i in 0 to 4 loop
    wait until rising_edge(clock);

    I find that tracing code is a good way
    to debug this sort of problem.

    -- Mike Treseler
    Mike Treseler, Jan 5, 2005
    #2
    1. Advertising

  3. On Wed, 05 Jan 2005 07:56:00 -0800, Mike Treseler
    <> wrote:

    >ALuPin wrote:
    >
    >> I have tried one fix out:
    >> Mr Bromley suggested the following:
    >>> OuterLoop: for i in 0 to 4 loop
    >>> while not rising_edge(clock) loop
    >>> wait on clock, order_burst_data;
    >>> exit OuterLoop when order_burst_data_in='1';
    >>> end loop;
    >>> end loop; -- OuterLoop

    >
    >Maybe ( not rising_edge(clock) ) is always false


    Oh, I'm sorry. My stupid error. As soon as you get a
    rising edge on the clock, the "for i in 0 to 4" will
    iterate in zero time.

    My intention was to do something like this...

    OuterLoop: for i in 0 to 4 loop
    ClockEdgeLoop: loop
    -- Hang around until something interesting happens
    wait on clock, order_burst_data_in;
    -- If we got an abort, we're done...
    exit OuterLoop when order_burst_data_in='1';
    -- But if it was a clock edge, just count:
    exit ClockEdgeLoop when rising_edge(clock);
    end loop; -- ClockEdgeLoop
    end loop; -- OuterLoop

    Some people dislike this style, on the grounds that
    all the "exit" statements are potentially confusing.
    On the other hand, it separates event detection
    from event action. A state machine coding style
    or "inverted control structure" is possibly even
    better:

    EventLoop: loop
    -- Wait for something to happen
    wait on clock, order_burst_data_in;
    -- Advance the state machine based on what happened:
    if order_burst_data_in = '1' then
    <do burst_data action>;
    elsif rising_edge(clock) then
    clock_count := clock_count + 1;
    if clock_count = 4 then
    <do timeout action>;
    clock_count := 0;
    end if;
    end if;
    end loop; -- EventLoop

    Horror of horrors, this is starting to look like the
    kind of event loop programming that Windows and X
    programmers are forced to adopt.

    >I find that tracing code is a good way
    >to debug this sort of problem.


    You're right, but I find that thinking carefully
    is even better. It's just that I don't always
    do that :-(
    --
    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, Jan 5, 2005
    #3
  4. Jonathan Bromley wrote:

    > Horror of horrors, this is starting to look like the
    > kind of event loop programming that Windows and X
    > programmers are forced to adopt.


    Yes. It is for this reason that I now
    make all testbench processes synchronous,
    with the exception of the clock generator.

    The downside is I have to handle my own
    step counters instead of using waits.
    The upside is that I don't have to
    think so hard.

    -- Mike Treseler
    Mike Treseler, Jan 5, 2005
    #4
    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. =?Utf-8?B?U2FuZHk=?=

    Code to Exit Web App and Exit Internet Explorer

    =?Utf-8?B?U2FuZHk=?=, Aug 3, 2005, in forum: ASP .Net
    Replies:
    7
    Views:
    7,874
    =?Utf-8?B?U2FuZHk=?=
    Aug 5, 2005
  2. Joe Smith
    Replies:
    4
    Views:
    65,788
    sandeep1976
    Nov 8, 2006
  3. jasperng
    Replies:
    0
    Views:
    1,293
    jasperng
    Nov 27, 2008
  4. J.Ram
    Replies:
    7
    Views:
    639
  5. Michael Tan
    Replies:
    32
    Views:
    932
    Ara.T.Howard
    Jul 21, 2005
Loading...

Share This Page