Need help on Automatic self checking testbench

Discussion in 'VHDL' started by Sreenivas J, Feb 28, 2011.

  1. Sreenivas J

    Sreenivas J Guest

    Hi all,

    I am working on self checking automated test bench. Here i have
    testbench having each step implemented in VHDL which includes
    processor READ and WRITE actions developed in package and calling into
    testbench.

    Example:

    Step_no<=1;
    por_n<='0';
    wait for 100 ns;
    por_n<='1';
    wait for 100 ns;

    Step_no<2;
    WRITE(<Address>, <Data_val_32bit>; <related signals: clocks, ...etc);

    Step_no<=3;
    READ(<Address>);


    My intension is to create Automated testbench golden reference file
    which can read all the step's expected results from the main testbench
    and compare with the actual results with step number reference.

    At some extent i tried to create a model using VHDL TEXT IO's but i am
    getting difficulties at READ and WRITE actions.

    Please suggest me some good process to follow,...that will be a gr8
    help.

    Thanks,
    Nivas.
    Sreenivas J, Feb 28, 2011
    #1
    1. Advertising

  2. Sreenivas J

    KJ Guest

    On Feb 28, 12:22 pm, Sreenivas J <> wrote:
    >
    > My intension is to create Automated testbench golden reference file
    > which can read all the step's expected results from the main testbench
    > and compare with the actual results with step number reference.
    >


    I find it more productive to create a VHDL model of the system under
    test rather than reading expected results from a file. Add assertion
    checking at will to check everything that needs checking.

    > At some extent i tried to create a model using VHDL TEXT IO's but i am
    > getting difficulties at READ and WRITE actions.
    >


    Unless you can explain "getting difficulties", it will be difficult
    for anyone to help.

    > Please suggest me some good process to follow,...that will be a gr8
    > help.


    1. Ask yourself how you are going to generate the expected results
    2. Ask yourself if it wouldn't be easier to encode the process of #1
    within your testbench in the first place and skip reading/writing
    files

    Kevin Jennings
    KJ, Feb 28, 2011
    #2
    1. Advertising

  3. Sreenivas J

    Andy Guest

    Hint: Read() could take an argument (default to others => '-'). with
    which to compare the results, and then it could report failures. Read
    could also have an output parameter to allow collecting the read data
    and analyzing as a whole after all the data is received.

    Andy
    Andy, Feb 28, 2011
    #3
  4. Sreenivas J

    Sreenivas J Guest

    On Feb 28, 11:01 pm, KJ <> wrote:
    > On Feb 28, 12:22 pm, Sreenivas J <> wrote:
    >
    >
    >
    > > My intension is to create Automated testbench golden reference file
    > > which can read all the step's expected results from the main testbench
    > > and compare with the actual results with step number reference.

    >
    > I find it more productive to create a VHDL model of the system under
    > test rather than reading expected results from a file.  Add assertion
    > checking at will to check everything that needs checking.
    >
    > > At some extent i tried to create a model using VHDL TEXT IO's but i am
    > > getting difficulties at READ and WRITE actions.

    >
    > Unless you can explain "getting difficulties", it will be difficult
    > for anyone to help.
    >
    > > Please suggest me some good process to follow,...that will be a gr8
    > > help.

    >
    > 1. Ask yourself how you are going to generate the expected results
    > 2. Ask yourself if it wouldn't be easier to encode the process of #1
    > within your testbench in the first place and skip reading/writing
    > files
    >
    > Kevin Jennings


    Hi kevin,
    Thanks for your response.
    The aim of this is when we run for simulation we can see the responses
    in waveform file from Modelsim,
    so those responses or exptected results i have to capture in a text
    file and compare with actual results.

    reg,
    Nivas
    Sreenivas J, Mar 1, 2011
    #4
  5. On 2/28/2011 9:22 PM, Sreenivas J wrote:
    > The aim of this is when we run for simulation we can see the responses
    > in waveform file from Modelsim,
    > so those responses or exptected results i have to capture in a text
    > file and compare with actual results.
    >


    I had this idea in mind long time ago, thinking it would be a *great*
    (not gr8) way to test any dut, providing input patterns from a file and
    comparing output patterns with my "expected results" neatly stored in
    another file.
    Then I realize the file needed a format (wow!) and the procedure to read
    the file would have needed a way to check the format for typos (ouch!).
    Then I realized that I needed more than just a series of values to check
    since the logic would have processed the data after some time, so I
    would have needed to synchronize the reading of the next value with the
    logic...
    In no longer than a couple of days I realized I was writing a scripting
    language and the result was far away from what I wanted. The file
    approach was more of a burden rather than a help.

    In my mind you need to:

    1. identify first the interfaces to your dut (serial/parallel
    communication, hand-shake protocol, bus interface), all the means that
    give you a handle on the dut.
    2. write procedures to communicate with the dut (read/write)
    3. identify all the output of the dut (data streams, serial/parallel
    interfaces, etc.), all the means that make you "see" what the dut is doing.
    4. write procedure to sample the output and evaluate the result.

    Now you have a way to stimulate your dut with several operations and
    check the results.
    Use as much as possible existing models in your testbench, so if you
    have a spi interface try to find an existing implementation and use it.

    Just bear in mind that when your design is implemented you will only
    have inputs and outputs on your board, nothing else.
    If a state of the design cannot produce a transition on any output it
    means the state is not "observable" and you will spend the rest of your
    life trying to figure out what is your logic doing.
    If a state of the design cannot be forced through a series of inputs it
    means that state is not "controllable" and most probably you will not be
    able to perform what you wanted.

    > reg,


    what is reg? is it a register? if it stands for "regards" why not
    writing so? are you afraid to use the bandwidth of your internet
    connection efficiently? In this last case I spoiled your intent I
    believe ;-)
    > Nivas
    Alessandro Basili, Mar 1, 2011
    #5
  6. Sreenivas J

    BeesNotIncluded

    Joined:
    Mar 25, 2012
    Messages:
    1
    Location:
    England & Canada
    I have to agree with Alessandro:

    Ultimately, every DUT has different requirements on the type, timing, sequence and number of input and output signals. Hoping to write a generic test bench to cover all these cases is no small undertaking.

    While it is not possible to reliably auto-generate the test bench, it is possible to save a considerable amount of time and typing by using a script to automatically generate a template test bench file containing:

    1. All the DUT port signal definitions
    2. The instantiated DUT
    3. The port mappings between test bench and DUT
    I am currently working on such a project and have a perl script mostly written to do this. You might like to check it out and see if you could use such a script or something similar to achieve savings in the time taken to prepare test benches.

    If you are interested you can read more here:

    http://www.beesnotincluded.com/2012/03/automating-vhdl-testbench-creation.html
    BeesNotIncluded, Mar 25, 2012
    #6
    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. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    561
    Lonnie Princehouse
    Jul 11, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    18
    Views:
    580
    Bengt Richter
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    2
    Views:
    389
    Dan Sommers
    Jul 12, 2005
  4. falcon
    Replies:
    0
    Views:
    360
    falcon
    Jul 31, 2005
  5. Bart Kastermans
    Replies:
    6
    Views:
    386
    Bart Kastermans
    Jul 13, 2008
Loading...

Share This Page