Testing Plan

We will test each module in three separate ways: 1) in simulation, 2) in hardware on our Altera DE2-115 tester boards and 3) on the DCRC itself when the board is complete and available.

For each module and for the entire trigger, we create a "test vectors" file, which drives inputs and indicates the expected outputs. The test vectors are processed both by the simulation testbench and by the test setup on the DE2-115 tester board. All cases in which the actual outputs do not match the expected outputs are reported, and the test is not considered successful unless all outputs are as expected.

A sequence of randomly-generated data is sent in to the inputs of the DF module. The time interval between inputs is set to be the same as it will be in the final real trigger. The software trigger simulation is run on the randomly-generated data to compute what the output will be, and this computed output is written in to the test vectors file along with the correct time intervals between outputs.

To test the Synchronizer module, we send inputs on one interface at a time until all 5 interfaces have gotten their data. Then we see all 16 outputs being sent. The data is hand-coded rather than random, and we check that the outputs match the inputs.

Second, we repeat the above except that we send inputs on all interfaces simultaneously. The input data is different so that we can verify that the output is not simply repeating the previous outputs. We check that the outputs match the inputs at the correct times.

Next, we test the error-checking mechanisms. For each error bit, if it is possible to do so, we cause the error condition, check that the error bit is set, then reset the module.

1. Error bit 0: Send inputs (first on individual interfaces and then simultaneously) without a start-of-packet signal and check for error bit 0.
2. Error bit 1: Send inputs (first on individual interfaces and then simultaneously) with two start-of-packet signals in a row, and then check for error bit 1.
3. Error bit 2: Send inputs (first on individual interfaces and then simultaneously) with an end-of-packet signal but no start-of-packet signal, and then check for both error bit 2 and error bit 0 (which also gets set in this condition).
4. Error bit 3: Send inputs (first on individual interfaces and then simultaneously) with the same channel number on two consecutive inputs. Then check for error bits 3 and 6 (which also gets set in this condition).
5. Error bit 4: Send inputs (first on individual interfaces and then simultaneously) with both a start-of-packet and end-of-packet signal. Then check for error bit 4.
6. Error bit 5 cannot be tested because all channel numbers are valid
7. Error bit 6: Send inputs on all interfaces that provide all the channels from each interface, and then send an extra copy of one channel on one interface. Then check for error bit 6.
8. Error bit 7: Send inputs on all interfaces that provide all the channels from each interface. Then immediately send the same inputs again with no delay. The first sequence of inputs causes the module to start to produce an output packet. Before that output packet is completely sent, the second sequence of inputs causes the module to begin a new output packet. Check for all

To test the LC module, we use randomly-generated data much like the downsample filter. First, coefficients are chosen randomly and input data is generated randomly. Then, the random coefficients and random input data are used in the software trigger simulation to compute what the output will be. The test vectors file is then written out for use in testing.

When the test vectors file is used, first the 64 coefficients (16 coefficients in each of 4 submodules) are set. Then, the input data is sent with short intervals between each input packet. The test vectors file indicates both what output data is expected and when it is expected. The tests check that the output data appears exactly when it is expected.

Last, we test the error-checking mechanisms. For each error bit, if it is possible to do so, we cause the error condition, check that the error bit is set, then reset the module.

1. Error bit 0: Send an input without a start-of-packet signal and check for error bit 0.
2. Error bit 1: Send an input with two start-of-packet signals in a row and check for error bit 1.
3. Error bit 2: Send an input with an end-of-packet signal but no start-of-packet signal, and then check for error bit 2 as well as error bits 0 and 4 (which also get set in this condition).
4. Error bit 3: Send an input packet with one channel sent twice and check for error bit 3.
5. Error bit 4: Send an input packet with one channel missing and check for error bit 4.
6. Error bit 5 cannot be tested because all channel numbers are valid.
7. Error bit 6: Attempt to write to register address 0x273, which is not a valid address, then check for error bit 6.
8. Error bit 7: Attempt to write a coefficient value which is larger than 8 bits, then check for error bit 7.
9. Error bit 8: Send two packets so close together that the outputs from the second packet begin before the outputs from the first packet are finished. Then check for error bit 8 as well as error bit 4 (which also gets set in this test).
10. Error bit 9: Send a malformed input packet with many copies of a very large number sent on one channel. This is the only way to get the accumulators to overflow or underflow. Then check for error bit 9 as well as error bit 3 (which also gets set in this test).

To test the FIR module, we use randomly-generated data much like the downsample filter and linear combination modules. Coefficients and input data are chosen randomly. The software trigger simulation is used to compute the expected output. Then, the random coefficients, input data, and output data are used to construct the test vectors file.

Unlike the other modules, because the FIR module tests take a long time, the error checking tests are done first.