Procedure exit - simulation result

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

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

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

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