«

Hi,

I have some trouble with a wait statement in my testbench.
The testbench is based on procedures to read and write to the chip and
to wait for things to happen. The following code does not work:

WriteWord(PTESTREG,X"0000");
wait until int2n = '0'; -- <- The problem...
WriteWord(FILTCONTREG,X"0000");

The wait statement is only executed if int2n goes low after the
previous procedure call. If int2n is already low when the wait
statement is reached, execution stops forever at the wait statement.

I seems as "wait until" needs an event on int2n and doesnt evaluate the
expression. Is that correct or a bug in Modelsim?

Any suggestions?

Thanks in advance, Peter

Peter wrote:
> I seems as "wait until" needs an event on int2n and doesnt evaluate the
> expression. Is that correct or a bug in Modelsim?
> Any suggestions?

Hi Peter
This is perfectly correct in VHDL, the "wait until" statement
implicitly waits for the condition to *become* true. What I usually do
when I don't want to wait for an event is put it inside an if
statement:
...
if not condition then
wait until condition;
end if;
...

Nicolas

Peter,
I believe the behavior you are seeing is consistent with LRM. A wait
construct implicitly "derives" a sensitivity list as you've thought about
it. Some relevant LRM wording is:

------
The suspended process can also resume as a result of an event occurring on
any signal in the sensitivity set of

the wait statement.

----------

(Not quite close to your exact problem though). A solution is to check for
it not being 0, before wait i.e.

if (int2n /= '0') then
wait until int2n = '0';
endif

HTH,
Sri
--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
"Peter" <> wrote in message
news: ups.com...
> Hi,
>
> I have some trouble with a wait statement in my testbench.
> The testbench is based on procedures to read and write to the chip and
> to wait for things to happen. The following code does not work:
>
> WriteWord(PTESTREG,X"0000");
> wait until int2n = '0'; -- <- The problem...
> WriteWord(FILTCONTREG,X"0000");
>
> The wait statement is only executed if int2n goes low after the
> previous procedure call. If int2n is already low when the wait
> statement is reached, execution stops forever at the wait statement.
>
> I seems as "wait until" needs an event on int2n and doesnt evaluate the
> expression. Is that correct or a bug in Modelsim?
>
> Any suggestions?
>
> Thanks in advance, Peter
>

On 3 Aug 2005 01:23:23 -0700, "Peter"
<> wrote:


>WriteWord(PTESTREG,X"0000");
>wait until int2n = '0'; -- <- The problem...
>WriteWord(FILTCONTREG,X"0000");
>
>The wait statement is only executed if int2n goes low after the
>previous procedure call. If int2n is already low when the wait
>statement is reached, execution stops forever at the wait statement.
>
>I seems as "wait until" needs an event on int2n and doesnt evaluate the
>expression. Is that correct

Yes, it's precisely what VHDL defines.

You can easily make yourself a level-sensitive wait:

---- proc to wait until S=T, without requiring an event on S
procedure wait_level(
signal S: in std_logic;
constant T: in std_logic
) is
begin
if S /= T then wait until S = T; end if;
end;

and then you can write

wait_level ( int2n, '0' );

in your code in place of "wait until int2n = '0';".

It is probably a good idea to modify the procedure slightly so
it allows currently-active signal updates to take effect and
always waits for at least one delta, as follows:

procedure wait_level(
signal S: in std_logic; -- signal to test
constant T: in std_logic -- expected level
) is
begin
wait for 0 ns; -- allow current updates to take effect
if S /= T then wait until S = T; end if;
end if;
end;

This modification greatly reduces the risk of accidentally
introducing zero-delay infinite loops into your code.

Note also that you can put a timeout on any wait statement:

wait until S = T for 5 ns;

so that your testbench can proceed if the system gets stuck
for any reason. Of course, after the "wait" you then need
to test whether the wait was satisfied, or timed-out. Once
again you can easily write a procedure to encapsulate this
behaviour if you use it in many places.

Such procedures are completely general-purpose and can go
in a package for use anywhere in your environment.
--
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.

Hi Jonathan,
I liked your idea of "wait for 0 ns inside that procdure", sounds
(to me) similar to the idea of a postponed process, if I'm correct here,
then how about adding it as part of VHDL-200X - a "postponed procedure" -
just curious, of-course we need to see if there is a ROI in defining it as
part of language - especially given that it is easily do-able today.

Thanks
Sri
--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
"Jonathan Bromley" <> wrote in message
news:...
> On 3 Aug 2005 01:23:23 -0700, "Peter"
> <> wrote:
> It is probably a good idea to modify the procedure slightly so
> it allows currently-active signal updates to take effect and
> always waits for at least one delta, as follows:
>
> procedure wait_level(
> signal S: in std_logic; -- signal to test
> constant T: in std_logic -- expected level
> ) is
> begin
> wait for 0 ns; -- allow current updates to take effect
> if S /= T then wait until S = T; end if;
> end if;
> end;
>

The wait_level procedure is a nice solution.

I have also tried:

wait on clk until int2n = '0';

where my system clock is used to generate events.

Thanks to all of you.

/Peter

On Wed, 3 Aug 2005 14:54:06 +0530, "Srinivasan Venkataramanan"
<_spam.co.in> wrote:

>Hi Jonathan,
> I liked your idea of "wait for 0 ns inside that procdure", sounds
>(to me) similar to the idea of a postponed process, if I'm correct here,

Given that the procedure is passive, I guess that's right. But the
procedure is very likely to be called from a process that is *not*
passive, so I personally prefer to be explicit.

Of course, the "wait for 0 ns" may not necessarily be appropriate.
I was thinking about situations where, for example, the preceding
procedure call might have asserted a notification signal; the
"wait for 0 ns" gives a delta for that signal to update before
testing it. There are many tricks that you can play here -
waiting on 'transaction is useful too, although you can't
do it on signal-class arguments

>then how about adding it as part of VHDL-200X - a "postponed procedure" -
>just curious, of-course we need to see if there is a ROI in defining it as
>part of language - especially given that it is easily do-able today.

Well.... at risk of starting a flame war.... one of the joys of
VHDL is its very simple event processing model, unlike A Certain
Alternative HDL that has an event queue model of baroque
complexity, provided because people *think* they want all this
fussy stuff like postponed processes (and Preponed sampling, and
Reactive and Re-Inactive processing, and.... oh, please, don't
get me started! It raises my blood pressure too much!).
I would *always* prefer to find a simple explicit solution in
preference to using obscure stuff like postponed processes. So
the notion of a "postponed procedure" horrifies me. It sounds
just too much like a SystemVerilog "program" for comfort
--
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.