Procedure exit - simulation result

[ALuPin]

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é

 

[Mike Treseler]

I have tried one fix out:
Mr Bromley suggested the following:

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

 

[Jonathan Bromley]

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:[email protected]
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.

 

[Mike Treseler]

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