如何管理大型VHDL测试平台

Question

One problem I've seen again and again on different VHDL projects is that the top-level testbenches are always large and difficult to keep organized. There is basically a main test process where EVERY test signal is controlled or validated from, which becomes HUGE over time. I know that you can make testbenches for the lower-level components, but this question mainly applies to top-level input/output tests.

I'd like to have some kind of hierarchy structure to keep things organized. I've tried implementing VHDL procedures, but the compiler was very unhappy because it thought I was trying to assign signals from different sections of code...

Is there anything available in VHDL to achieve the behavior of c programming's inline-function or #define preprocessor replacement macros? If not, what can you suggest? It would make me happy to be able to have my top-level test bench look like this:

testClockSignals();
testDigitialIO();
testDACSignals();
...

Having the implementation of these functions in a separate file would be icing on the cake. Haha...I'd just like to write and simulate the test benches in C.

Answer 1

It is a VHDL requirement that the either you write the procedures in the process (as @MortenZdk suggests) or you pass all the IO to it.

My preference is to put my procedures only in packages, so I use the pass all IO approach. To simplify what is passed, I use records. If you reduce it to one record, it will be inout and require resolution functions on the elements of the record.

For more ideas on this approach, goto: http://www.synthworks.com/papers/ and see the papers titled: "Accelerating Verification Through Pre-Use ..." (near the bottom) and " VHDL Testbench Techniques that Leapfrog SystemVerilog" (at the top)

Another key aspect is to use a separate process for each independent interface. This way stimulus can be generated concurrently for different interfaces. This is also illustrated in the papers.

Answer 2

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:

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

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

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

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

Answer 3

If you have lower level testbenches for each block, then you can make use of them at the top level.

By making the key lower level test elements entities in their own right, you can compose them into higher level test items which are often just a small shim to convert the pin-level data into the test-level data you were originally using.

For example, in an image processing FPGA, you would have some image-sourcing and data-checking code to check out the algorithmic parts. These could be used as is, or with some wrapping to provide the data to the top-level FPGA pins, and then decode the pin outputs back to the format that the original checking code requires.

The register setup code that was no doubt tested at the lower level, can be wrapped in some more code with wiggles the FPGA pins appropriately and interprets the pin-wiggling results.

The combination of the two sets of code allows you to check the end-to-end function of the image processing pipeline and the register configuration of that pipeline.