Electronic – Hardware test of FPGA, thousands of combinations

fpgatesting

My colleagues longtime ago have designed an FPGA (using VHDL) for a special purpose.
Another colleague prepared the test scenarios.

Now they want me to test this FPGA board following these written scenarios. The test bench is ready. So I have nothing to do except reading these scenarios, changing the Analog switches placed in the test bench (ADC is used in the test bench) and see the DIGITAL output on a monitor (an application was developed to show the result of FPGA computation on pc monitor)

My question is:

What is the name of this type of testing?

I searched several hours in Amazon book store to find in chapters of books written for FPGA design, something about real way of testing an FPGA with no success.

I have 5 analog inputs and the ADC will create let's say 20 digital variables for the FPGA. These test scenarios specific for this FPGA test not all the input combination (2^20=1048576)but at least 1000 combination.

So I should perform 1000 tests manually:

reading the scenario, manually changing the analog switch values, read the digital result on monitor)

But how about FPGA’s that have more inputs? should we test hardwarely all the possible combinations of the inputs?

Please help me. If you know a chapter of a book explaining the way we test physically (hardware) the FPGA or if we use other ways I’ll appreciate.
The keywords help me too

Best Answer

When done in simulation, this type of testing would be called "directed testing". In other words...

If I put in data A, I expect result B.

If I out in data C, I expect result D.

etc...

(where all of the sets of data (A, C, ...) and results (B, D, ...) have been determined beforehand.

Normally one would try to find a way to eliminate the human (that's reading and checking the result on the monitor) from the loop - partly because humans are less reliable than computers, and partly for speed reasons.

However, the "constrained random testing" mentioned by others is generally the way to go if possible. In this, you generate randomised input, work out what the result should be for that input (using an independent model of the design), and check that the result from the FPGA matches what you expected. You will generally get much better coverage this way than by directed testing (although directed testing can still be useful for "hello world"-type bringup tests and for hitting specific corner cases.

For constrained random testing, you really need an automated mechanism for checking the result.

Related Solutions

Electronic – about the code for fir filter

Add to your testbench a monitor process that watches the output and compares it to the expected value, allowing for the delays through the filter.

Your VHDL style is better than some - even better than some textbook examples I have seen, but still: a few comments :

Using named rather than positional assignment for the "dff" component instantiations would save possible confusion between inputs and outputs for anyone trying to follow the pipeline. This doesn't really matter here, because :
you can eliminate the dffs altogether; replace them with lines of the form Q1 <= MCM3; in the same clocked process as Yout <= add_out3; that greatly simplifies the whole filter.
You can reduce number of conversion functions by making H0..3 integer types; and if they are constant, make them constants! As multiplication between signed and integer is defined,no other changes are required.

type coefficient is new integer range -128 .. 127;
constant H0 : coefficient := -2;
Lose the redundant parentheses in if ( rising_edge(Clk) ) then - this isn't C!
The DRY principle applies in VHDL too... there are several ways to apply it to the testbench : my choice would be a local procedure.

   stim_proc: process

      procedure Input(D : in integer range -128 .. 127) is
      begin
         Xin <= to_signed(D,8); 
         wait for clk_period*1;
      end Input;

   begin        
      wait for Clk_period*2;
        Input(-3);
        Input( 1);

Electronic – How to best “synchronize” image producer/consumer to handle different FPS

In programming this technique is called double buffering. You have two memory buffers between the camera and the monitor. While the camera fills one of them the other is displayed on the monitor (whatever time it costs - 1, 2 or more frames). When the first buffer is full (the whole frame is read from the camera) the two buffers are swapped and the second buffer now is read from the camera and the first one is displayed on the monitor.

This way, some of the camera frames will be displayed 2 monitor frames long, some only 1 (if the camera is faster than half of the monitor frame rate) or 3 monitor frames (if the camera is slower than half of the monitor frame rate) but the synchronization will be automatically provided.

I hope, this explanation is clear enough and I understood the problem correctly.

Best Answer

Related Solutions

Electronic – about the code for fir filter

Electronic – How to best “synchronize” image producer/consumer to handle different FPS

Related Topic