Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > testbench question

Reply
Thread Tools

testbench question

 
 
Shannon
Guest
Posts: n/a
 
      07-13-2009
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
 
Reply With Quote
 
 
 
 
Shannon
Guest
Posts: n/a
 
      07-13-2009
On Jul 13, 10:09*am, Shannon <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      07-13-2009
Shannon wrote:

> 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

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      07-21-2009
Jonathan Bromley wrote:

> 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.

--
Paul.

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      07-22-2009
On Jul 22, 2:59*am, Jonathan Bromley <(E-Mail Removed)>
wrote:
>
> 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
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      07-22-2009
Jonathan Bromley wrote:

>>> 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.

>
> 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.

--
Paul.
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      07-23-2009
On Jul 22, 2:43*pm, Paul <(E-Mail Removed)> wrote:
> Jonathan Bromley wrote:
> >>> 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.

>
> > 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.
>
> --
> Paul.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Testbench Question: Internal signals. BLF VHDL 6 02-06-2009 02:40 AM
question regarding passing generics in testbench madmax VHDL 1 10-04-2008 11:31 PM
testbench question Salman VHDL 1 06-21-2006 08:55 PM
Re: Testbench question Mike Treseler VHDL 0 11-18-2005 02:11 PM
[VHDL] a testbench question (bringing out states) - noob Yttrium VHDL 7 10-15-2003 06:03 PM



Advertisments