testbench question

[Shannon]

I'm a hardware guy so please excuse me if this question is too
simple. I working through writing my first non-synthesizeable (i.e.
testbench) code.

I have a process with no sensitivity list and a couple of wait
statements structurally like this:

process
begin
wait until Reset = '0';
while not endfile(commands) loop
... do stuff ...
wait until send_done;
end loop;
end process;

All works surprisingly well (to me) except for that last "wait until
send_done" part. I can't seem to get the process to notice send_done
has changed state. What am I doing wrong?

if you need to see more code I can post it but it will take a little
while for me to "sanitize" it for public release.

Shannon

 

[Shannon]

I'm a hardware guy so please excuse me if this question is too
simple.  I working through writing my first non-synthesizeable (i.e.
testbench) code.

I have a process with no sensitivity list and a couple of wait
statements structurally like this:

process
begin
wait until Reset = '0';
while not endfile(commands) loop
   ... do stuff ...
  wait until send_done;
end loop;
end process;

All works surprisingly well (to me) except for that last "wait until
send_done" part.  I can't seem to get the process to notice send_done
has changed state.  What am I doing wrong?

if you need to see more code I can post it but it will take a little
while for me to "sanitize" it for public release.

Shannon

AAAAAAARRRRRRRRRRRRRGGGGGGGGGGGGGGGGGHHHHHHHHH

ok. never mind. got it. I keep getting stuck on the concept that
signals won't update until the process suspends. It's just not
something I worry about with synth. code.

Shannon

 

[Mike Treseler]

I have a process with no sensitivity list and a couple of wait
statements structurally like this:

process
begin
wait until Reset = '0';
while not endfile(commands) loop
... do stuff ...
wait until send_done;
end loop;
end process;

I do the same thing, but use synchronous delays.

All works surprisingly well (to me) except for that last "wait until
send_done" part. I can't seem to get the process to notice send_done
has changed state. What am I doing wrong?

I would run a sim to see what is happening.
Here's how I exit a testbench:

procedure coda is
begin
results;
done_s <= true;
tic;
wait;
end procedure coda;

details here:
http://mysite.verizon.net/miketreseler/test_uart.vhd

Good luck.

-- Mike Treseler

 

[Paul]

Note one special gotcha:

wait until <expression>; -- with no signals in <expression>

This will never wake up, because the automatically constructed
sensitivity list is empty. A favourite error is...

wait until NOW = 3 us; -- - OUCH - stops forever

The correct formulation is, of course,

wait for 3 us - NOW;

Excuse me for stumbling in into this newsgroup after a too long
absence, finding your much appreciated and informative (as always)
writing, and not being able to restrain my self of making the
following remark:

The correct formulation is, of course,

if now < 3 us then
wait for 3 us - now;
end if;

It avoids a run time error if the simulation time already passed
the 3 us mark (been there, done that).

Next, be aware of 'TRANSACTION for signalling between
processes. It's a slightly odd idea, but works well. In
your example, "send_done" must be driven FALSE and then back
TRUE again in order to release the WAIT. That's tiresome.

And that's why in such cases I always use a signal of type BIT and
toggle it. No need for initialisation, no need to put it back to an
inactive state and you can even generate events in consecutive delta
times.

 

[Andy]

However, there's a more significant reason in favour of
using 'TRANSACTION:  It works with resolved signals
that have multiple drivers.  This means that you can
put a global signal in a package, and any part of your
testbench can notify using that global signal by
simply writing to it.  That's not something you want
to do all the time, of course, but it can be useful.

You can grow your own resolved signal using an XOR resolution
function, such that toggling any driver (more specifically an odd
number of inputs) will toggle the resolved value, which can then be
detected with 'event. But then if an even number of drivers get
toggled in the same delta, you're hosed...

Andy

 

[Paul]

Now that one is MUCH more interesting...

When I wrote the original comment, I was basically just
repeating our standard story about using 'TRANSACTION to
signal events from one part of a testbench to another.
Your response made me think about it some more. One
reason I like using 'TRANSACTION is that it seems to me
much more elegant to be able to write

done <= TRUE;

True. ;-)

than

done <= not done;

But you could easily get around that by writing

procedure notify (signal flag: inout bit) is
begin
flag <= not flag;
end;

Indeed. I use the perhaps not so elegant name "toggle" instead
of "notify". And I consistently use type bit for toggle signals. For
me that's clear enough.

However, there's a more significant reason in favour of
using 'TRANSACTION: It works with resolved signals
that have multiple drivers. This means that you can
put a global signal in a package, and any part of your
testbench can notify using that global signal by
simply writing to it. That's not something you want
to do all the time, of course, but it can be useful.

Ah, yes, that's a nice one.

Finally, an argument in favour of your version: You
can't detect 'TRANSACTION on procedure arguments. So,
for example, this doesn't work:

procedure wait_for_notify(signal s: in <something>);
begin
wait on s'transaction; -- illegal on procedure arg
end;

One of those silly limitation of VHDL...

But of course you *can* do that with 'EVENT and so this
is fine - the receiving end of the "notify" procedure:

procedure wait_for_notify(signal flag: in bit);
begin
wait on flag;
end;

Another reason not to use 'TRANSACTION: it gets lost with a signal
assignment. But the fact that it cannot be used in a procedure is the
main reason for me not to use it. Though I must admit, I had
forgotten that reason. Thanks for refreshing it.

 

[Shannon]

True.   ;-)







Indeed. I use the perhaps not so elegant name "toggle" instead
of "notify". And I consistently use type bit for toggle signals. For
me that's clear enough.


Ah, yes, that's a nice one.



One of those silly limitation of VHDL...



Another reason not to use 'TRANSACTION: it gets lost with a signal
assignment. But the fact that it cannot be used in a procedure is the
main reason for me not to use it. Though I must admit, I had
forgotten that reason. Thanks for refreshing it.

You know...it's threads like these that make me feel like I'm in my
garage working on the car. I ask my neighbor for some help tuning the
carburetor and the next thing you know half the neighborhood is in my
garage discussing the merits of fuel injection.

This is a great group. Thanks for the help and more. Oh and you are
right Jonathan, I was stressed about learning to write testbenches.
But now I'm finding it very liberating! Oh the junk I can get away
with now!

Shannon