timeout in a procedure

A

alessandro basili

Guest
Hi everyone,
is there any way to introduce a timeout in the execution of a procedure?
I have a procedure which sends words on a serial link (ds-link) and is
triggered by an external clock which comes from my DUT. To fully
simulate the system I need to quit from the procedure after a certain
time the clock is stopped. How can I do that?

Al
 
alessandro basili wrote:
Hi everyone,
is there any way to introduce a timeout in the execution of a procedure?
I have a procedure which sends words on a serial link (ds-link) and is
triggered by an external clock which comes from my DUT. To fully
simulate the system I need to quit from the procedure after a certain
time the clock is stopped. How can I do that?
Click to expand...

procedure wait_for_rx
in the testbench here:
http://home.comcast.net/~mike_treseler/
 
Thanks Mike, but the problem is that I'd like to "interrupt" the
procedure in a given moment.
Is there anyhow a way to step out the procedure running?
Cheers

Al

Mike Treseler wrote:
procedure wait_for_rx
in the testbench here:
http://home.comcast.net/~mike_treseler/
Click to expand...
--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
alessandro basili wrote:
Thanks Mike, but the problem is that I'd like to "interrupt" the
procedure in a given moment.
Is there anyhow a way to step out the procedure running?
Click to expand...
I guess I don't understand your requirement.

In the example, the sim procedure either
loops waiting for edges or
exits for a handshake or
exits for a time out.

The handshake could represent an interrupt
or any other signal.

-- Mike Treseler
 
alessandro basili wrote:

Hi everyone,
is there any way to introduce a timeout in the execution of a
procedure? I have a procedure which sends words on a serial link
(ds-link) and is triggered by an external clock which comes from my
DUT. To fully simulate the system I need to quit from the procedure
after a certain time the clock is stopped. How can I do that?
Click to expand...
I'm not quite sure what you are getting at. In general, you don't have
to quit a procedure in order to end a simulation. You just must make
sure that no events are generated anymore. So stop all clocks, pulse
generators and so on, and the simulation will end on its own accord
by event starvation.

If you really want to implement a time-out, you can do something like
this:

CONSTANT time_out: delay_length := 10 us;
...
WAIT UNTIL rising_edge(clk) FOR time_out;
IF NOT rising_edge(clk) THEN
-- Time-out occurred
RETURN; -- quit the procedure
END IF;
...

--
Paul.
 
I guess there is no such thing like "step out" in hardware design.

alessandro basili wrote:
Thanks Mike, but the problem is that I'd like to "interrupt" the
procedure in a given moment.
Is there anyhow a way to step out the procedure running?
Cheers

Al

Mike Treseler wrote:
procedure wait_for_rx
in the testbench here:
http://home.comcast.net/~mike_treseler/

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Click to expand...
 
TigerJade wrote:
I guess there is no such thing like "step out" in hardware design.
Click to expand...
This is a sim, so hardware is not an issue.
I have no doubt that there is some
way to "step out", I just don't know
what that means.

-- Mike Treseler
 
In my procedure there is a loop like the following:

....

for i in data_buf'length - 1 downto 0 loop
wait until rising_edge (clock);
clkdouble := not clkdouble;
data_int := data_buf (i);
strobe <= data_int xor clkdouble;
data <= data_int;
end loop; -- i
....

and clock is a signal that my DUT will provide to this procedure in
order to have data and strobe signals out.
If I simply stop the clock they procedure will hang "waiting" the next
clock to come, while I need a way to exit out of it and starting again
if the clock stops for too long.
My system has this DUT which is connected to a peripheral which has an
analog reset on board that occurs if the clock stops. So my attempt is
to test my DUT with a testbench which will reproduce the behaviour of my
peripheral, is not hardware (as Mike said).
Any suggestions?
thanks

Al

Mike Treseler wrote:
TigerJade wrote:

I guess there is no such thing like "step out" in hardware design.


This is a sim, so hardware is not an issue.
I have no doubt that there is some
way to "step out", I just don't know
what that means.

-- Mike Treseler
Click to expand...
--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
Paul Uiterlinden wrote:
alessandro basili wrote:


Hi everyone,
is there any way to introduce a timeout in the execution of a
procedure? I have a procedure which sends words on a serial link
(ds-link) and is triggered by an external clock which comes from my
DUT. To fully simulate the system I need to quit from the procedure
after a certain time the clock is stopped. How can I do that?


I'm not quite sure what you are getting at. In general, you don't have
to quit a procedure in order to end a simulation. You just must make
sure that no events are generated anymore. So stop all clocks, pulse
generators and so on, and the simulation will end on its own accord
by event starvation.
Click to expand...
If you read carefully i have never spoken about quitting the simulation.
I have several procedures which are going on simultaneously and one of
this has to be "interrupted" if the clock for that procedure is not
running anymore for a specific amount of time. Is not a problem of
quitting the simulation, which is, to my opinion, something really
useless. I simply run the simulation for the time I want, letting the
testbench always loop, because sometimes logic errors can hide in the
second loop ;-)

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
It has limited value in an HDL process. I am assuming we are talking
about a test bench since this whole thing is not synthesizable. The
way a process works is that when an event triggers it, the code
executes all in the same moment of simulation time until a "wait" is
encountered. Then the simulator runs any other events that are queued
to the same moment and finally the results of the updates are reflected
in the signals before the simulator updates the time to the next delta
or real time increment. The "wait" can be either the end of the
process or an explicit wait statement.

To "step out" of a process can mean one of two things. Either it can
be stopping the process at a point which can be done with a wait of
some type, or it can be like a return() in C code. I don't think there
is anything like the C return() in VHDL, I can't say for sure about
Verilog, I suspect not. But this can be done by using the appropriate
controls, IFs and loop controls. Yeah, it can be messy. But if it is
messy, it likely means you should rethink how you are structuring your
code. Look for another approach that is not so messy.


TigerJade wrote:
I guess there is no such thing like "step out" in hardware design.

alessandro basili wrote:
Thanks Mike, but the problem is that I'd like to "interrupt" the
procedure in a given moment.
Is there anyhow a way to step out the procedure running?
Cheers

Al

Mike Treseler wrote:
procedure wait_for_rx
in the testbench here:
http://home.comcast.net/~mike_treseler/
Click to expand...
 
"alessandro basili" <alessandro.basili@cern.ch> wrote in message
news:egqoap$prj$1@cernne03.cern.ch...
In my procedure there is a loop like the following:

...

signal Timeout: BOOLEAN;
Click to expand...
signal All_Done: BOOLEAN;
....
All_Done <= FALSE;
for i in data_buf'length - 1 downto 0 loop
if not(Timeout) then
wait until rising_edge (clock) or Timeout; -- KJ added
Timeout
end if;
if not(Timeout) then
clkdouble := not clkdouble;
data_int := data_buf (i);
strobe <= data_int xor clkdouble;
data <= data_int;
end if;
end loop; -- i
All_Done <= not(Timeout);
-- KJ added process
process
constant Timeout_Period: time := 1 us; -- Or whatever timeout
you want; Could also be a variable if you want.
begin
Timeout <= FALSE;
wait until whatever event it is that will cause you to want to start the
timeout timing;
Timeout <= TRUE after Timeout_Period;
wait until Timeout'event or All_Done'event;
Timeout <= not(All_Done); -- Cancels the above assignment to Timeout
which might still be pending;
end process;

and clock is a signal that my DUT will provide to this procedure in order
to have data and strobe signals out.
If I simply stop the clock they procedure will hang "waiting" the next
clock to come, while I need a way to exit out of it and starting again if
the clock stops for too long.
My system has this DUT which is connected to a peripheral which has an
analog reset on board that occurs if the clock stops. So my attempt is to
test my DUT with a testbench which will reproduce the behaviour of my
peripheral, is not hardware (as Mike said).
Any suggestions?
thanks
Click to expand...
See above changes to your code which adds in looking for a new signal called
'Timeout' which will end up getting you out of your procedure. Timeout is
generated in a separate process that I've sketched out. The basic idea is I
think what you're trying to accomplish, the signal 'All_Done' is meant to
signal successful completion of the procedure and 'Timeout' to signal when
the procedure took too long. 'All_Done' gets set inside your existing
process and 'Timeout' in the new process and the two processes cooperate via
these signals to figure out if things are working or not.

KJ
 
alessandro basili wrote:

If you read carefully i have never spoken about quitting the
simulation.
Click to expand...
OK, that's clear now. My assumption, my fault. :)

I have several procedures which are going on
simultaneously and one of this has to be "interrupted" if the clock
for that procedure is not running anymore for a specific amount of
time.
Click to expand...
So, did you try my suggestion of using the "wait until
rising_edge(clk) for time_out"?

This wait clause will either terminate by a rising edge of clk, or due
to no rising_edge during the time time_out. To see what caused the
termination of the wait clause, just check if a rising edge has
occured or not. See my previous posting.

Is not a problem of quitting the simulation, which is, to my
opinion, something really useless. I simply run the simulation for
the time I want, letting the testbench always loop, because
sometimes logic errors can hide in the second loop ;-)
Click to expand...
I do agree with the observation that just letting run the testbench
sometimes reveals a bug. For regression testing however, the
testbench should be self-terminating, in my opinion. Else you end up
with the situation that for each testbench (or scenario) you must
know how long it must run. Also, a testbench/scenario should print a
PASSED/FAILED message at the end of the simulation. So that's another
reason testbenches should be self-terminating.

--
Paul.
 
On Sat, 14 Oct 2006 17:38:25 GMT, "KJ" <kkjennings@sbcglobal.net>
wrote:

"alessandro basili" <alessandro.basili@cern.ch> wrote in message
news:egqoap$prj$1@cernne03.cern.ch...
In my procedure there is a loop like the following:

...

signal Timeout: BOOLEAN;
signal All_Done: BOOLEAN;
...
All_Done <= FALSE;
for i in data_buf'length - 1 downto 0 loop
if not(Timeout) then
wait until rising_edge (clock) or Timeout; -- KJ added
[snip]
See above changes to your code which adds in looking for a new signal called
'Timeout' which will end up getting you out of your procedure. Timeout is
generated in a separate process that I've sketched out.
Click to expand...
Don't forget you can also do this...

...
wait until rising_edge(clock) for 100 ns; -- 100 ns timeout???
if rising_edge(clock) then
-- it was OK, we saw a clock edge
...
else
-- No clock edge, we timed-out
error_flag := TRUE;
return;
end if;


--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Thanks a lot to both of you! I got the point, unfortunately I work
almost on my own designing VHDL, so it's hard to improve without a
reference.
I think this group is just what i needed since long time!
Thanks guys

Al

Jonathan Bromley wrote:
On Sat, 14 Oct 2006 17:38:25 GMT, "KJ" <kkjennings@sbcglobal.net
wrote:


"alessandro basili" <alessandro.basili@cern.ch> wrote in message
news:egqoap$prj$1@cernne03.cern.ch...

In my procedure there is a loop like the following:

...


signal Timeout: BOOLEAN;
signal All_Done: BOOLEAN;
...
All_Done <= FALSE;
for i in data_buf'length - 1 downto 0 loop
if not(Timeout) then
wait until rising_edge (clock) or Timeout; -- KJ added

[snip]

See above changes to your code which adds in looking for a new signal called
'Timeout' which will end up getting you out of your procedure. Timeout is
generated in a separate process that I've sketched out.


Don't forget you can also do this...

...
wait until rising_edge(clock) for 100 ns; -- 100 ns timeout???
if rising_edge(clock) then
-- it was OK, we saw a clock edge
...
else
-- No clock edge, we timed-out
error_flag := TRUE;
return;
end if;
Click to expand...
--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
Paul Uiterlinden wrote:
So, did you try my suggestion of using the "wait until
rising_edge(clk) for time_out"?
Click to expand...
Unfortunately I missed that "for timeout", this time I didn't read
carefully ;-)
I do agree with the observation that just letting run the testbench
sometimes reveals a bug. For regression testing however, the
testbench should be self-terminating, in my opinion. Else you end up
with the situation that for each testbench (or scenario) you must
know how long it must run. Also, a testbench/scenario should print a
PASSED/FAILED message at the end of the simulation. So that's another
reason testbenches should be self-terminating.
Click to expand...
I think this is a major problem of understanding "when and how" the
check should be done to print out PASSED or FAILED. I think that all the
software control that you can implement will surely lack of some
features that you haven't thought in the moment you wrote the control.
As an example, I am working on a space-station experiment and the whole
system is thought to "monitor", in principle, without taking any
automatic actions on its own. This is because it can happen something
that you haven't foreseen on ground, and how your control will handle a
non-foreseen state? our assumption is that basically it will fail and
the branch in which it finished, in the tree error recovery, it is
unpredictable.
That's why our approach is to test without putting any constraints,
because those constraints are wrong! (sort of the Murphy's law)

Anyway, thanks a lot for your suggestion.
Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
alessandro basili a écrit :
In my procedure there is a loop like the following:

...

for i in data_buf'length - 1 downto 0 loop
wait until rising_edge (clock);
clkdouble := not clkdouble;
data_int := data_buf (i);
strobe <= data_int xor clkdouble;
data <= data_int;
end loop; -- i
...
Click to expand...
Hi
You could write:
....
.... loop
wait on clock for xx ns; -- replace xx with your timeout value
if not clock'event then
exit; -- exit if clock is idle for too long
elsif rising_edge(clock) then
...
end if;
end loop;
....

Nicolas
 
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:8f34j2lps2aabm3mckspdteuk9fkrmdd1o@4ax.com...
On Sat, 14 Oct 2006 17:38:25 GMT, "KJ" <kkjennings@sbcglobal.net
snip
Don't forget you can also do this...

...
wait until rising_edge(clock) for 100 ns; -- 100 ns timeout???
if rising_edge(clock) then
-- it was OK, we saw a clock edge
...
else
-- No clock edge, we timed-out
error_flag := TRUE;
return;
end if;
Click to expand...
Yeah, it dawned on me later that I had proposed an overcomplicated solution.
In part that was because I wasn't totally sure that I understood what the
problem was....but from the subsequent posts it looks like what I had was on
the right track, thanks for sprucing it up to something cleaner.

KJ
 
On Sun, 15 Oct 2006 12:52:23 +0200, alessandro basili
<alessandro.basili@cern.ch> wrote:

unfortunately I work
almost on my own designing VHDL, so it's hard to improve without a
reference.
Click to expand...
I hope you have access to a copy of "The Designer's Guide to VHDL"
by Ashenden, probably the most useful reference for the sort of
thing you are asking about. Also, Ben Cohen's "VHDL Answers
to Frequently Asked Questions" is a great source of interesting
ideas and details of some of the less obvious aspects of the
language.

I think this group is just what i needed since long time!
Click to expand...
It's always good to see interesting questions relating to
interesting applications.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top