How to manage large VHDL testbenches

testing, vhdl

Solution

Separating test bench code in manageable procedures is possible, but maybe the compiler complained because a procedure tries to access signals that were not in scope ? If a procedure is to controls a signal that is not in scope, then the signal can be given as argument to the procedure, as shown for the `procReset` example below.

A test bench structure, with multiple levels for easier maintenance, is shown below:

--==========================================================
-- Reusable procedures

-- Reset generation
procedure procReset(signal rst : out std_logic; ...) is
...

--==========================================================
-- Main test control procedure in test bench
process is

  ------------------------------------------------------------
  -- General control and status

  -- Reset device under test and related test bench modules
  procedure genReset is
  begin
    procReset(rst, 100 ns);  -- procReset declared elsewhere
    -- Other code as required for complete reset
  end procedure;

  ------------------------------------------------------------
  -- Test cases

  procedure testClockSignals is
  begin
    genReset;  -- Apply reset to avoid test case interdependency
    -- Test code here, and call genErr if mismatch detected
  end procedure;

  procedure testDigitialIO is
  begin
    genReset;  -- Apply reset to avoid test case interdependency
    -- Test code here, and call genErr if mismatch detected
  end procedure;

  procedure testDACSignals is
  begin
    genReset;  -- Apply reset to avoid test case interdependency
    -- Test code here, and call genErr if mismatch detected
  end procedure;

begin

  ------------------------------------------------------------
  -- Run test cases
  testClockSignals;
  testDigitialIO;
  testDACSignals;
  -- End of simulation
  std.env.stop(0);
  wait;

end process;

There are several levels in the structure:

Run test cases: Where the procedures for each test case is called. It is thereby possible to comment out one or more of the test cases during development and debugging.

Test cases: Test test case code itself, which is written as separate and independent procedures. Interdependence between run of the different test cases is avoided by reset (using `genReset` procedure) of the device under test and related test bench support modules.

General control and status: Reusable test bench specific procedure, for example reset of device under test and test bench support modules.

Reusable procedures: Does not control or use test bench signals directly, but only through procedure arguments. These procedures may be located in packages (other files) for reuse in other test benches.

The test bench file may still be quite a number of lines, since all the test case code still have to be in the same file with the above approach, if this test bench code need direct access to test bench signals in order to control or check the signals values. If signal values can be passed to test case procedures through arguments, as done for the `procReset` call, then it is possible to move the test case code to another package.

Problem

Original source