Testing the CONV-TTL-BLO
This page contains details about how we tested the TTL to blocking conversion system. It gives details about the various field tests where the conversion systems are employed, and finally stress tests we did in the lab. It also summarizes the automated production test suite (PTS), which is used for series production testing, the interested reader should look for more information on the PTS project page.
Production Test Suite
The Production Test Suite (PTS) is the automated test environment shipped by CERN to production companies. It is used to test boards right after they come out of the production line. It consists in a set of Python programs to access the device under test and usually gateware for the on-board FPGA is used to test the various peripherals on the board.
For more information, see the PTS project page.
Field tests
Field tests are performed around CERN experiments to test the interoperability of the pulse conversion systems with other systems. By placing the systems in the field, driving actual devices in the CERN installations, new tests can be performed, ones that we cannot perform ourselves in the laboratory.
The installations where test pulse conversion systems have been placed are listed below.
- Test system in 354
- This is a full test system that contains:
- a CTRV for pulse generation
- an old pulse repeater for interoperability checking
- a CONV-TTL-BLO module (front + RTM), configured in TTL-BAR repetition mode
- a VTSM module for retrieving timestamps
- Connection diagram
- crate name on CERN network: cfvm-354-ctblo
- gateware version (consult board status register for up-to-date version): v2.2
- building: 354
- This is a full test system that contains:
Gateware release test
This is the test that should be performed every time a new gateware release is made. It tests the basic pulse conversion features of the board.
Lab tests
In the lab, we can perform "stress" and long-term tests of the board. We normally use the CONV-TTL-BLO with a latest release gateware and optionally other boards, like an extra CONV-TTL-BLO, to drive stimulus into the device under test. We also usually use Python programs to control stimulus generation.
The most important points about lab tests are:
- Use gateware on the Spartan-6 FPGA on-board the CONV-TTL-BLO
- Occasionally use a separate CONV-TTL-BLO with special test gateware
- Gateware versions for test gateware start from v15.15 and count down:
- Python programs communicate to the FPGA and control running of the tests
How to find the source code
For the test gateware, the code can be found under the gateware sub-project (which is a sub-module of the main repository), under the following folders:
- pulse repetition test: pulsetest/
- communication test: regtest/
See the Folder Structure section in the HDL guide for more information on finding modules in the repository.
The Python programs controlling the gateware can be found in the software/* folder of the main repository
- pulse repetition test: software/pulsetest/
- communication test: software/regtest/
- diagnostics scripts: software/diag/
List of tests
Test number | Description | Result |
Test 01 | Tests long-term pulse repetition | |
Test 02 | Tests if the TTL input breaks when a blocking signal is input | PASS: TTL input resistant to blocking-level input |
Test 03 | Tests if the TTL-BAR input breaks when a blocking signal is input |
PASS: TTL input resistant to blocking-level input Two pulse cycle delay between signal at TTL input and signal at TTL/blocking output |
Test 04 | Tests if the blocking power supply does not break when all blocking outputs are loaded | PASS: Blocking power supply can withstand loading all outputs |
Test 05 | Tests if the TTL input breaks when a DC high-level blocking voltage is input | Termination resistors smoke at the beginning, but hold for more than approx. 10 minutes |
Test 06 | Tests if the blocking input breaks when a DC high-level blocking voltage is input | Termination resistors smoke at the beginning, but hold for more than approx. 10 minutes |
Test 07 | Short circuit the same output on the TTL side, see if the output holds | PASS: TTL output works after short circuit |
Test 08 | Short circuit the same output on the blocking side, see if the output holds | PASS: Blocking output works after short circuit |
Test 09 | Additive pulses: "output M shape" | PASS: M-shaped created |
Test 10 | Additive pulses: "input M shape" on blocking input | PASS: Only one pulse generated on both TTL and blocking outputs, PMISS error set |
Test 11 | Additive pulses: "input M shape" on TTL input | |
Test 12 | Additive pulses input at a certain frequency | |
Test 13 | Trigger on both TTL and blocking inputs at the same time | |
Test 14 | Trigger on both TTL-BAR and blocking inputs at the same time | |
Test 15 | Toggle power to the CONV-TTL-BLO in TTL pulse repetition mode and make sure no pulses are generated on startup | |
Test 16 | Toggle power to the CONV-TTL-BLO in TTL-BAR pulse repetition mode and make sure no pulses are generated on startup | |
Test 17 | Input an RF signal into the TTL input and see the outcome | |
Test 18 | Input an RF signal into the blocking input and see the outcome | |
Test 19 | Long-term testing of I2C communications |
Test 01: Long-term pulse repetition
Purpose:*
- test that no pulses are missed in the long term
Procedure:*
- For testing the pulse repetition, a second (stimulus) TTL to blocking converter system is used, as shown in the diagram below. Here we have used channel 6 of the first converter system, but using the pulse test gateware it could have easily been any of the channels. The blocking output of channel six gets fed into the blocking input of channel six of the device under test (DUT), and a daisy-chain is formed up to channel 1 of the DUT. Finally, the TTL output signal from the DUT is fed back into the TTL input of the stimulus, where the input counter value can be checked versus that of the output counter of channel 6, to see if any pulses have been missed. If the CH6 output counter value is equal to that of the CH1 input counter, this means no pulses have been missed.
- A Python program controls the gateware based on user input. The program goes through the six channels in sequence and asks whether to enable it and for the frequency, if the channel gets enabled. Pulse width is set to the typical blocking pulse width of 1.2 us. Delay is not controllable (for now) and is always set to zero. After this, the user inputs the amount of time the test should run, after which testing runs automatically.
- After the amount of time the user has selected elapses, the values of the pulse counters are read and stored in an output file.
Results:*
Test 02: Blocking into TTL
Purpose:*
- See if a blocking pulse breaks the TTL input when the board is in TTL pulse repetition mode
Procedure:*
- Use CH1 of a second CONV-TTL-BLO (board 2) with pulsetest gateware to generate the pulses for the first board (board 1)
- TTL switch ON (TTL pulse repetition) on both boards
- For the first part of the test, the following connections will be
made:
- board 2 CH1 TTL out to board 1 CH1 TTL in
- board 1 CH1 blo. out to board 1 CH2 TTL in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Test that the number of pulses sent from board 2 is received on
board 1 channel 2
- using pulsetest.py
- generate pulses out of CH1
- frequency: 4160 Hz
- runtime: 1 minute
- using rdchxpcr.py
- check that the input counters on both CH1 and CH2 are equal to the pulsetest gateware counters
- using pulsetest.py
- Test (using an oscilloscope) if there is a signal on the blo. output of board 1 channel 2
- Run the clrchxpcr.py script on board 1 to clear its input channel counters
- For the second part of the test, the following connections will be
made:
- board 2 CH2 TTL out to board 1 CH2 TTL in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Test that the number of pulses on board 1 and board 2 are
the same
- using pulsetest.py
- generate pulses out of CH2
- frequency: 4160 Hz
- runtime: 1 minute
- using rdchxpcr.py
- check that the input counters on both CH1 and CH2 are equal to the pulsetest gateware counters
- using pulsetest.py
- Run the clrchxpcr.py script on board 1 to clear its input channel counters
- Repeat the test, this time with a pulsetest.py runtime of 10 minutes
Results:*
- Blocking pulses input on the TTL inputs do not break the TTL input stage
- Sample output files:
Test 03: Blocking into TTL-BAR
Purpose:*
- See if a blocking pulse breaks the TTL input when the board is in TTL-BAR pulse repetition mode
Procedure:*
- Use CH1 of a second CONV-TTL-BLO (board 2) with pulsetest gateware to generate the pulses for the first board (board 1)
- TTL switch OFF (TTL-BAR pulse repetition) on both boards
- For the first part of the test, the following connections will be
made:
- board 2 CH1 TTL out to board 1 CH1 TTL in
- board 1 CH1 blo. out to board 1 CH2 TTL in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Test that the number of pulses sent from board 2 is received on
board 1 channel 2
- using pulsetest.py
- generate pulses out of CH1
- frequency: 4160 Hz
- runtime: 1 minute
- using rdchxpcr.py
- check that the input counters on both CH1 and CH2 are equal to the pulsetest gateware counters
- using pulsetest.py
- Test (using an oscilloscope) if there is a signal on the blo. output of board 1 channel 2
- Run the clrchxpcr.py script on board 1 to clear its input channel counters
- For the second part of the test, the following connections will be
made:
- board 2 CH2 TTL out to board 1 CH2 TTL in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Test that the number of pulses on board 1 and board 2 are
the same
- using pulsetest.py
- generate pulses out of CH2
- frequency: 4160 Hz
- runtime: 1 minute
- using rdchxpcr.py
- check that the input counters on both CH1 and CH2 are equal to the pulsetest gateware counters
- using pulsetest.py
- Run the clrchxpcr.py script on board 1 to clear its input channel counters
- Repeat the test, this time with a pulsetest.py runtime of 10 minutes
Results:*
- Blocking pulses input on the TTL inputs do not break the TTL input stage
- A delay of two pulse cycles appears when inputting a blocking
signal into a TTL input with TTL-BAR repetition enabled
- Due to a peculiarity in the TTL input stage
- Sample output files:
Test 04: Load all outputs
Purpose:*
- See if the blocking power supply can resist generating blocking pulses on all three blocking outputs of each channel
Procedure:*
- Use two CONV-TTL-BLO boards
- board 1 -- device-under-test (DUT)
- board 2 -- pulsetest gateware
- if previous two tests passed Connect one blocking output to a TTL input of board 2
-
Board 2 sends pulses simultaneously to all six TTL input
channels:
- use pulsetest.py
- frequency: 4160 Hz
- runtime: 1 minute
- Connect 50 ohm termination resistors on all board 1 blocking outputs
- See if the blocking power supply fails in any way
- Measure (using an oscilloscope) the blocking power supply for ripples
- Repeat test, with a runtime of 10 minutes
Results:*
- The blocking supply can withstand generating pulses out of all 18 outputs
- There is a 200mV dip (shown below) in the power supply when pulses are generated out of all 18 outputs
- This dip is not affected by whether the channel is loaded or not
- Sample output files
Test 05: DC high-level blocking signal into the TTL input
Purpose:*
- See if the TTL input stage can resist a DC-level 24V signal
- Make sure only one pulse is generated when this signal is input
Procedure:*
- Connect a LEMO cable between CH1 TTL output and CH2 TTL input
- Connect a LEMO cable between CH1 blocking output and CH3 blocking input
- Configure a voltage source to output DC 24V
- Input this voltage to the CH1 TTL input
- Leave it in there for a few seconds
- Take it out
- Use the rdchxpcr.py script to make sure only 1 pulse was received on CH2 and CH3
- Input a normal TTL signal
- See if any pulses are generated at the TTL and blocking outputs
- Repeat, leaving the DC high-level in for a few minutes
Results:*
- Test was run for approx. 10 minutes
- Termination resistors smoke at the beginning
- Inputting normal TTL pulses afterwards yields that the input stage together with the termination resistors still work
Test 06: DC high-level blocking signal into the blocking input
Purpose:*
- See if the blocking input stage can resist a DC-level 24V signal
- Make sure only one pulse is generated when this signal is input
Procedure:*
- Connect a LEMO cable between CH1 TTL output and CH2 TTL input
- Connect a LEMO cable between CH1 blocking output and CH3 blocking input
- Configure a voltage source to output DC 24V
- Input this voltage to the blocking input
- Leave it in there for a few seconds
- Take it out
- Use the rdchxpcr.py script to make sure only 1 pulse was received on CH2 and CH3
- Input a normal blocking signal
- See if any pulses are generated at the TTL and blocking outputs
- Repeat, leaving the DC high-level in for a few minutes
Results:*
- Test was run for approx. 10 minutes
- Termination resistors smoke at the beginning
- Inputting normal blocking pulses afterwards yields that the input stage together with the termination resistors still work
Test 07: TTL output short circuit
Purpose:*
- See if the TTL output stage can withhold a short-circuit on the output
Procedure:*
- Make a short circuit on a TTL output via a LEMO Y splitter and a short cable
- Connect a TTL signal at the input
- Run for one minute
- Remove short circuit
- Connect TTL output to the oscilloscope
- Check that the output still works
Results:*
- TTL output works normally after short circuit
Test 08: Blocking output short circuit
Purpose:*
- See if the blocking output stage can withhold a short-circuit on the output
Procedure:*
- Make a short circuit on a blocking output via a LEMO Y splitter and a short cable
- Connect a blocking signal at the input
- Run for one minute
- Remove short circuit
- Connect blocking output to the oscilloscope
- Check that the output still works
Results:*
- TTL output works normally after short circuit
Test 09: Additive pulses on blocking outputs
Purpose:*
- Create an "M-shaped pulse" to use in the next tests
Procedure:*
- Two pulse sources are needed (use two channels of a second CONV-TTL-BLO with pulsetest gateware)
- The first source is connected to the TTL input of channel 1 of the CONV-TTL-BLO DUT
- The second source is connected to the TTL input of channel 2 of the CONV-TTL-BLO DUT
- The parameters of the pulse are:
- 1us length
- 3.3V
- Pulse rise of channel 2 is delayed 2us with regard to channel 1.
- Via a LEMO Y splitter, connect the blocking outputs of DUT channel 1 and two
- Check whether an "M-shaped waveform" appears on the oscilloscope:
- 1.2 us high value
- 0.8 us low value
- 1.2 us high value signal
Results:*
- M-shaped pulse created:
Test 10: Additive pulses on blocking inputs
Purpose:*
- Make sure that only one pulse is generated as consequence of an "M-shaped pulse" on the blocking input
Procedure:*
- Input the signal above to the blocking input of channel 3
- Make the following connections (in addition to the connections
above)
- DUT CH3 blocking out to DUT CH4 blocking in
- DUT CH3 TTL out to pulsetest CH3 TTL in
- ** DUT CH3 blocking and TTL outputs to an oscilloscope
- Check that only one pulse is generated on blocking output of channel 3
- Check that only one pulse is generated on TTL output of channel 3
Results:*
- Two pulses received at CH3 input
- Only one pulse generated at CH3 blocking output
- Only one pulse generated at CH3 TTL output
- Pulse miss error set on CH3, due to the second pulse in the M-shaped pulse arriving during the pulse generator's pulse rejection phase
- Sample output file:
Test 11: Additive pulses on TTL inputs
Purpose:*
- Make sure that only one pulse is generated as consequence of an "M-shaped pulse" on the TTL input
Procedure:*
- Input the signal above to the TTL input of channel 3
- Make the following connections (in addition to the connections
above)
- DUT CH3 blocking out to DUT CH4 blocking in
- DUT CH3 TTL out to pulsetest CH3 TTL in
- ** DUT CH3 blocking and TTL outputs to an oscilloscope
- Check that only one pulse is generated on blocking output of channel 3
- Check that only one pulse is generated on TTL output of channel 3
Results:*
-
Only one pulse received at CH3 TTL input
- Due to a peculiarity in the TTL input stage
- Only one pulse generated at CH3 blocking output
- Only one pulse generated at CH3 TTL output
- Pulse miss error set on CH3, due to the second pulse in the M-shaped pulse arriving during the pulse generator's pulse rejection phase
- Sample output file:
Test 12: Additive pulses at a frequency
Purpose:*
- Make sure that the second part of an "M-shaped pulse" is cut
- Make sure that the TTL input does not break as a consequence of an M-shaped pulse
- Make sure that the blocking input does not break as a consequence of an M-shaped pulse
Procedure:*
- Create an "M-shaped waveform" as above, but now with a frequency
- Input the waveform to blocking channel 3 and an oscilloscope in parallel
- Check on the oscilloscope that the additive part of the pulses is blocked
- Input the waveform to TTL channel 3 and an oscilloscope in parallel
- Check on the oscilloscope that the additive part of the pulses is blocked
- Input a normal blocking signal to blocking channel 3
- Check that the blocking input did not break
- Input a normal TTL signal to blocking channel 3
- Check that the TTL input did not break
- Increase the frequency of the M-shaped pulse and repeat the test
Results:*
- Additive part of pulses gets blocked
- Sample output files
Test 13: Trigger on TTL and blocking inputs at the same time
Purpose:*
- See what happens when an input arrives on both TTL and blocking inputs at the same time
Procedure:*
- Using a second board (board 2) with a pulsetest gateware, generate pulses (1.2 us, 1Hz) on CH1 TTL output
- Connect as follows:
- board 2 CH1 TTL out to board 1 CH1 TTL in
- board 1 CH1 TTL out to board 1 CH2 TTL in
- board 1 CH1 blocking out to board 1 CH2 blocking in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Check using pulsetest.py and rdchxpcr.py:
- whether the input pulse counter on board 2 CH2 is the same as the output pulse counter on board 2 CH1
- whether the input pulse counters on board 1 CH1 and CH2 are equal
Results:*
Test 14: Trigger on TTL-BAR and blocking inputs at the same time
Purpose:*
- See what happens when an input arrives on both TTL-BAR and blocking inputs at the same time
Procedure:*
- Using a second board (board 2) with a pulsetest gateware, generate pulses (1.2 us, 1Hz) on CH1 TTL output
- Both boards should have the TTL-BAR switch OFF
- Connect as follows:
- board 2 CH1 TTL out to board 1 CH1 TTL in
- board 1 CH1 TTL out to board 1 CH2 TTL in
- board 1 CH1 blocking out to board 1 CH2 blocking in
- board 1 CH2 TTL out to board 2 CH2 TTL in
- Check using pulsetest.py and rdchxpcr.py:
- whether the input pulse counter on board 2 CH2 is the same as the output pulse counter on board 2 CH1
- that board 1 channel 2 misses pulses (due to the blocking output falling edge arriving while the pulse generator is in pulse rejection state)
Results:*
Test 15: Long-term no pulses on startup (TTL)
Purpose:*
- Make sure no pulses are generated on TTL outputs on startup
- Make sure no pulses are generated on blocking outputs on startup
Procedure:*
Test 16: Long-term no pulses on startup (TTL-BAR)
Purpose:*
- Make sure no pulses are generated on TTL-BAR outputs on startup
- Make sure no pulses are generated on blocking outputs on startup
Procedure:*
Test 17: RF signal on TTL input
Purpose:*
- Input an RF signal to the TTL input and see the outcome
Procedure:*
- Input an RF signal to the oscilloscope to see its characteristics
- Establish a possible outcome of it being input to the CONV-TTL-BLO TTL input
- Input the RF signal to the TTL input
- See the outcome
Result:*
Test 18: RF signal on blocking input
Purpose:*
- Input an RF signal to the blocking input and see the outcome
Procedure:*
- Input an RF signal to the oscilloscope to see its characteristics
- Establish a possible outcome of it being input to the CONV-TTL-BLO blocking input
- Input the RF signal to the blocking input
- See the outcome
Result:*
Test 19: Long-term communication tests
Purpose:*
- Find errors in the I2C protocol, either on the SysMon or CONV-TTL-BLO side.
Procedure:*
A summary of the gateware and the Python program running the test is given below. More details can be found by consulting the code in the repository.
-
regtest
gateware
- I2C bridge component
- 1024*32-bit RAM spanning the addressing space supported by the I2C protocol
- Python program (software/regtest/regtest.py)
- writes values to successive addresses
- reads back and compares to written values
- counts the number of errors
Results:*
Theodor-Adrian Stana, May 2014