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.

Testing in simulation

For simulation (Altera Modelsim), a file is needed describing the inputs as a function of time. Then, the simulation software produces a file describing all the internal and output signals as a function of time. For any given set of inputs, we can calculate what the output should be by hand, and compare it to the simulated output.

The simulation has two modes: functional and timing simulation. The functional simulation does not attempt to simulate propagation or switching delays, and treats all logic and signal propagation as instantaneous. This allows one to check that the logic is implemented correctly. The timing simulation, on the other hand, does simulate propagation and switching delays, which allows one to make sure that the design will actually work on a physical chip. We will first use the functional simulation, and then repeat the same set of tests over again using the timing simulation.

We will use a few different files to test the module in simulation:

1. The first test will involve only a single set of 16 inputs, along with 2560 (plus a few) clock ticks. This will allow us to test the most basic functionality without worrying about whether it breaks when a sequence of inputs is provided. We will try out a variety of different values for the 16 inputs (for example, set all but one of the inputs to zero), and also try re-ordering the arrival of the 16 inputs.
2. Once we are satisfied that that works, we will make a longer file that contains two sets of 16 inputs, along with 2× 2560 clock ticks, in order to test the sequential functioning of the module.
3. That test will be followed by longer sequences of inputs.

We will also test with "bad" inputs:

1. We will test with an input file that only contains 15 inputs, to check how the module responds when one input fails to arrive.
2. We will also test with an input file in which one channel has two inputs that arrive during the 2560 clock tick synchronization window, to check how the module handles that case.

In both cases, the design specifies how the module should behave, so we will check that it in fact does behave this way.

We will also test the reset function. Specifically, we will make an input file that includes a reset signal along with the normal data inputs. We will check that the reset signal correctly causes the clock tick counter to start over, and the input registers to be set to 0.

Testing in hardware with tester board

Our Altera DE2-115 tester boards have, among other features, an audio subsystem. The audio subsystem includes a pair of ADCs (for stereo audio input). This gives us the opportunity to stream data to the board via an analog audio connection. We can use this stream of data to test this module in actual physical hardware.

To perform this test, we will use a computer to play an audio file, which will be transferred over a standard 1.5mm analog audio cable to the microphone input plug on the tester board. There, it will be digitized by the tester board's internal ADCs, whose output samples will be sent directly to the LC module (no DF module, since we will be testing the LC module in isolation). The LC module output will be stored for later read out using the Altera On-Chip FIFO Memory Core. Since we will control the inputs and the coefficients, we will be able to calculate the expected output (modulo noise) of the LC module and compare that to what we read out.

Note that, since the tester board only has two ADCs, we will only be able to connect two of the LC module inputs to

We will make a few different audio files. For example, one audio file might have both the left and right channels set to the same (constant) level, lasting for one second to allow us plenty of time to capture the output. Another file could contain square waves or triangle waves, allowing us to make sure the module responds to changing inputs. Lastly, we plan to make a file that contains data-like pulses, with a constant value of 0 in between. This last file will be especially important for testing the entire trigger system as a whole, although less important for testing the LC module in isolation.

We will also test the reset function by connecting an on-board button (momentary switch) to the reset signal. We will then press the button during our audio-file tests, to verify that the output is as expected and that the module returns to normal running after the reset signal ends.

Testing on DCRC

We will also test all the L1 trigger modules as a whole in hardware on the DCRC. Pulses will be sent to the input channels using the miniBOB, and triggers will be read from the FIFO via MIDAS.