Testbench and waits

Rickman

unread,

Jun 8, 1998, 3:00:00 AM6/8/98

to

I give up. I am trying to write an interactive testbench and need a
process to wait for a handshake signal from my device under test (DUT).
The code I am using for this is:

wait until (READYiN = '0');

where READYiN is the std_logic signal output from my DUT. When this line
of code is excuted, READYiN is already at a '0' level. This process then
waits at the above line forever.

Does this syntax result in waiting for the edge of "anystate" to '0'
transistion? What am I doing wrong here.

Here is the code:

LBIControl: process -- Define the SDI Data input (record)
variable SDICntr : std_logic_vector (7 downto 0);

begin
ADSN <= '1';
DEnN <= '1';
LWRN <= '1';
BLastN <= '1';

wait until (falling_edge (LRESEToN));
wait until (rising_edge (LCLK));

wait until (falling_edge (LCLK));
LAD <= X"0400_0080";
ADSN <= '0';
LWRN <= '1';

wait until (falling_edge (LCLK));
LAD <= X"0000_00f0";
ADSN <= '1';
DEnN <= '0';

wait until (READYiN = '0');
wait until (rising_edge (LCLK));
wait until (falling_edge (LCLK));
LAD <= (others => 'Z';
ADSN <= '1';
DEnN <= '1';

end process;

All of the signals are either std_logic or std_logic_vector.

I also tried to perform a wait until an absolute time. This also seemed
to hang the process.

wait until (NOW = 350 ns);

Is this not valid VHDL code?

Signed, Frustrated in Frederick... =<

--

Rick Collins

ric...@XYwriteme.com

remove the XY to email me.

Rickman

unread,

Jun 8, 1998, 3:00:00 AM6/8/98

to

Another piece of info on this, I changed the type of cycle to one that
has a wait state (READYiN high for one cycle) and the problem went away.
So it looks like the wait until (READYiN = '0') has to see an edge, at
least in the Orcad simulator.

Of course this doesn't help since I still have to simulate the bus
transfer without wait states.

Paul J. Menchini

unread,

Jun 8, 1998, 3:00:00 AM6/8/98

to

Rickman (spamgo...@yahoo.com) wrote:
: I give up. I am trying to write an interactive testbench and need a
: process to wait for a handshake signal from my device under test (DUT).
: The code I am using for this is:

: wait until (READYiN = '0');

: where READYiN is the std_logic signal output from my DUT. When this line
: of code is excuted, READYiN is already at a '0' level. This process then
: waits at the above line forever.

: Does this syntax result in waiting for the edge of "anystate" to '0'
: transistion? What am I doing wrong here.

Yes, "wait until <signal> = <value>"; is EDGE sensitive, not level
sensitive. It's exact meaning is the same as "wait on <signal> until
signal = <value>;", which devolves to

loop
wait on <signal>; -- wait until <signal>'Event = true;
exit when <signal> = <value>;
end loop;

A common mistake....

To get level sensitive behavior:

if <signal> /= <value> then
wait until <signal> = <value>;
end if;

BTW, you're perhaps better off by testing To_X01(READYiN) instead of
READYiN....

: Here is the code:

: LBIControl: process -- Define the SDI Data input (record)
: variable SDICntr : std_logic_vector (7 downto 0);

: begin
: ADSN <= '1';
: DEnN <= '1';
: LWRN <= '1';
: BLastN <= '1';

: wait until (falling_edge (LRESEToN));
: wait until (rising_edge (LCLK));

: wait until (falling_edge (LCLK));
: LAD <= X"0400_0080";
: ADSN <= '0';
: LWRN <= '1';

: wait until (falling_edge (LCLK));
: LAD <= X"0000_00f0";
: ADSN <= '1';
: DEnN <= '0';

: wait until (READYiN = '0');

See above. You probably want:

if To_X01(READYiN) /= '0' then
wait until To_X01(READYiN) = '0';
end if;

: wait until (rising_edge (LCLK));

: wait until (falling_edge (LCLK));
: LAD <= (others => 'Z';
: ADSN <= '1';
: DEnN <= '1';

: end process;

: All of the signals are either std_logic or std_logic_vector.

: I also tried to perform a wait until an absolute time. This also seemed
: to hang the process.

: wait until (NOW = 350 ns);

: Is this not valid VHDL code?

It is, but it's meaning is identical to

wait;

Again, look at the fully expanded version, which is

wait on <null list> until Now = 350 ns;

which is the same as

loop
wait;
exit when Now = 350 ns;
end loop;

You MUST have a signal in the condition in "wait until <condition>;",
else you merely have "wait;". Another little known fact....

Paul

Paul J. Menchini

unread,

Jun 8, 1998, 3:00:00 AM6/8/98

to

Rickman (spamgo...@yahoo.com) wrote:
: Another piece of info on this, I changed the type of cycle to one that

: has a wait state (READYiN high for one cycle) and the problem went away.

: So it looks like the wait until (READYiN = '0') has to see an edge, at

: least in the Orcad simulator.

Or in any conformant simulator.... (It's the definition of the language.)

Rickman

unread,

Jun 9, 1998, 3:00:00 AM6/9/98

to

Paul J. Menchini wrote:
>
> Rickman (spamgo...@yahoo.com) wrote:
> : I give up. I am trying to write an interactive testbench and need a
> : process to wait for a handshake signal from my device under test (DUT).

...snip...

> : I also tried to perform a wait until an absolute time. This also seemed
> : to hang the process.
>
> : wait until (NOW = 350 ns);
>
> : Is this not valid VHDL code?
>
> It is, but it's meaning is identical to
>
> wait;
>
> Again, look at the fully expanded version, which is
>
> wait on <null list> until Now = 350 ns;
>
> which is the same as
>
> loop
> wait;
> exit when Now = 350 ns;
> end loop;
>
> You MUST have a signal in the condition in "wait until <condition>;",
> else you merely have "wait;". Another little known fact....
>
> Paul

Thanks Paul,

Once again, you have saved a frustrated engineer! Any suggestions on how
to write the wait until NOW = 350 ns ???

In this case I am attempting to synchronize with the clock following an
absolute time. I guess I could write

loop
wait on (Clk) until (rising_edge (Clk));
exit when (Now >= 350 ns);
end loop;

This would exit the loop on the first rising edge of Clk that happens
after 350 ns absolute time. Correct?

Just out of curiosity, how did you come by your voluminous knowledge of
VHDL? I am new to it and am finding it a bit difficult to learn. I have
mastered several programming languages, but this is not much like
anything I have used before. But then maybe I am not finding the right
sources.

Paul J. Menchini

unread,

Jun 9, 1998, 3:00:00 AM6/9/98

to

Rickman (spamgo...@yahoo.com) wrote:
: Thanks Paul,

No charge (:-)

: Once again, you have saved a frustrated engineer! Any suggestions on how

: to write the wait until NOW = 350 ns ???

: In this case I am attempting to synchronize with the clock following an
: absolute time. I guess I could write

: loop
: wait on (Clk) until (rising_edge (Clk));
: exit when (Now >= 350 ns);
: end loop;

: This would exit the loop on the first rising edge of Clk that happens
: after 350 ns absolute time. Correct?

That would work, but this is simpler:

wait until rising_edge(Clk) and Now >= 350 ns;

: Just out of curiosity, how did you come by your voluminous knowledge of

: VHDL? I am new to it and am finding it a bit difficult to learn. I have
: mastered several programming languages, but this is not much like
: anything I have used before. But then maybe I am not finding the right
: sources.

Well, you'd be hard pressed to duplicate my sources....

The short answer: I wrote the LRM, led the development of the first
commercially successful analyzer/library manager for VHDL, and have
helped to integrate a number of simulators with the aforementioned
tool. I've also taught VHDL to over 6000 engineers.

A longer answer: In 1981, I was asked to attend something called "The
Woods Hole Summer Study on Hardware Description Languages." It was a
DoD-sponsored workshop whose aim was to develop the requirements for
an as-yet unnamed DoD-standard HDL. I was with Intel at the time and
spoke about our work in functional verification and the formalization
of design methodologies.

Although I did not participate in the contract that eventually lead to
VHDL, I did participate in all public reviews of the nascent VHDL.
When the IEEE standardization effort was started, I was invited to
participate, which lead to my employment by CLSI. At CLSI, I
contributed a few sections of the '87 LRM, wrote the aformentioned
analyzer/library manager, did some training, and integrated some
simulators, among other things.

Since 1992, I've been on my own as a consultant, primarily in VHDL.
I've developed a bunch of VHDL-related software, VHDL models, trained
even more people, and written the '93 LRM and the changes for the IEEE
1076a shared variable fixes. (An incomplete list!) I'm also working
on VHDL'98, VHDL'200x, VHDL PLI and will write the LRMs for these
standards. I also occasionally find the time to write and article or
paper....

And, one of these years, I'll find the time to become more active in
SLDL....

Paul Uiterlinden

unread,

Jun 10, 1998, 3:00:00 AM6/10/98

to

Rickman wrote:

> I also tried to perform a wait until an absolute time. This also seemed
> to hang the process.
>
> wait until (NOW = 350 ns);
>

The most simple way is:

WAIT FOR 350 ns - now;

You might want to embed this in an IF statement, if there is a chance
the WAIT statement will be called when simulation time already has
passed 350 ns:

IF now < 350 ns THEN
WAIT FOR 350 ns - now;
END IF;

--
Paul Uiterlinden

Lucent Technologies
Bell Labs Innovations

Botterstraat 45 Tel : +31 35 687 4911
P.O. Box 18 Fax : +31 35 687 5964
1270 AA Huizen Email : uiter...@lucent.com
the Netherlands

Rickman

unread,

Jun 10, 1998, 3:00:00 AM6/10/98

to

Paul Uiterlinden wrote:
>
> Rickman wrote:
>
> > I also tried to perform a wait until an absolute time. This also seemed
> > to hang the process.
> >
> > wait until (NOW = 350 ns);
> >
>
> The most simple way is:
>
> WAIT FOR 350 ns - now;
>
> You might want to embed this in an IF statement, if there is a chance
> the WAIT statement will be called when simulation time already has
> passed 350 ns:
>
> IF now < 350 ns THEN
> WAIT FOR 350 ns - now;
> END IF;
>
> --
> Paul Uiterlinden

This is great!

I was trying to put various statements in a procedure to modularize my
code and had trouble getting a WAIT UNTIL (RISING_EDGE (LCLK));
statement to actually see changes on LCLK. I haven't gotten back to that
code to see if some other suggestions make a change, but do you think
your code will work OK in a procedure? Since it is more than one line of
code, it would be more readable as a procedure call, e.g. WAIT_UNTIL
(350 ns);

I have been writing C for a long time and have a style for modularizing
things. I would like to do this with VHDL, but I haven't been able to
get much to work other than simple inline code.

Paul Uiterlinden

unread,

Jun 11, 1998, 3:00:00 AM6/11/98

to

Rickman wrote:

> I was trying to put various statements in a procedure to modularize my
> code and had trouble getting a WAIT UNTIL (RISING_EDGE (LCLK));
> statement to actually see changes on LCLK.

One reason I can think of is that LCLK is not declared as a signal in the
parameter list of the procedure. It then defaults to CONSTANT (when the mode
is IN), so events on the actual signal will not be relayed to the formal
parameter LCLK, so the WAIT will wait forever.

> I haven't gotten back to that
> code to see if some other suggestions make a change, but do you think
> your code will work OK in a procedure? Since it is more than one line of
> code, it would be more readable as a procedure call, e.g. WAIT_UNTIL
> (350 ns);

Sure, that would work fine. Perhaps you could even add an ELSE branch,
to report that simulation time already has passed the requested time.

>
> I have been writing C for a long time and have a style for modularizing
> things.

That is a healthy principle, which is valid in any programming language.

> I would like to do this with VHDL, but I haven't been able to
> get much to work other than simple inline code.

You have to keep in mind a few things, when you're using WAITs in procedures
(like declaring a formal parameter as a signal, if you want to put a WAIT on
it).

Rickman

unread,

Jun 12, 1998, 3:00:00 AM6/12/98

to

Thanks, Paul. I have been multitasking as I keep running into Orcad
problems. Some of those problems have gone away and I am getting back to
my main task. I'll let you know how this testbench works out when I get
back to it.

Thanks to Paul Menchini too. Both of you have helped a lot!