testbench question

Discussion in 'VHDL' started by Shannon, Jul 13, 2009.

  1. Shannon

    Shannon Guest

    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, Jul 13, 2009
    #1
    1. Advertising

  2. Shannon

    Shannon Guest

    On Jul 13, 10:09 am, Shannon <> 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
     
    Shannon, Jul 13, 2009
    #2
    1. Advertising

  3. 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
     
    Mike Treseler, Jul 13, 2009
    #3
  4. Shannon

    Paul Guest

    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.
     
    Paul, Jul 21, 2009
    #4
  5. Shannon

    Andy Guest

    On Jul 22, 2:59 am, Jonathan Bromley <>
    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
     
    Andy, Jul 22, 2009
    #5
  6. Shannon

    Paul Guest

    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.
     
    Paul, Jul 22, 2009
    #6
  7. Shannon

    Shannon Guest

    On Jul 22, 2:43 pm, Paul <> 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
     
    Shannon, Jul 23, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yttrium
    Replies:
    7
    Views:
    2,589
    Yttrium
    Oct 15, 2003
  2. Mike Treseler

    Re: Testbench question

    Mike Treseler, Nov 18, 2005, in forum: VHDL
    Replies:
    0
    Views:
    576
    Mike Treseler
    Nov 18, 2005
  3. Salman

    testbench question

    Salman, Jun 21, 2006, in forum: VHDL
    Replies:
    1
    Views:
    450
    Mike Treseler
    Jun 21, 2006
  4. madmax
    Replies:
    1
    Views:
    847
    madmax
    Oct 5, 2008
  5. BLF
    Replies:
    6
    Views:
    1,634
Loading...

Share This Page