Skip to content

C
Conv TTL Blocking - Testing

Home

Last edited by Dimitris Lampridis
Page history

Testing project for the CONV-TTL-BLO system

< Back to parent project

Introduction

This part of the conv-ttl-blo project describes the testing procedures used for the design and production phase of the board.
Testing can be divided in two types:

  • Tests for developers: They are carried it out in the lab and include procedures and test scripts. They are needed in order to check that the behaviour of the board agrees with its functional specification. They are used by hardware and gateware developers before the release of a new update to the design.
    • Testing the CONV-TTL-BLO has information about all the testing performed on the CONV-TTL-BLO, including robustness tests.
    • Of particular interest is the Gateware test procedure, which should be followed at each new release of the CONV-TTL-BLO gateware.
  • Production Tests: This type of tests are post-production hardware tests, called a Production Test Suite (PTS). They are required to check that the boards conform to the schematic and layout files, that they have been assembled correctly and that the fundamental operation of the board can be performed.

What will follow in this page focuses on the PTS of the conv-ttl-blo, it provides design files and documents as well as the user manual.

Production Test Suite

Since a TTL-to-blocking converter system comprises two boards, there is one PTS system for each card:

Front Module PTS

The PTS for the CONV-TTL-BLO is intended to be mounted inside a 19'' rack, containing a laptop and a VME crate. The laptop drives special firmware on the CONV-TTL-BLO FPGA, which is used to run the various tests. For more information, read the guides in the following sections.

Design and user documents

Other documentation

Rear-Transition Module PTS

PTS system

Unlike the rest of the PTS systems, that for the CONV-TTL-RTM-BLO is for now not designed for sending to the assembly facility. Instead, we will be testing the boards right here at CERN once they arrive upon shipment.

The test system is really simple. It comprises the following components:

  • CONV-TTL-RTM-BLO with piggyback under test
  • CONV-TTL-BLO with dedicated PTS bitstream
  • two signal loopback boards, described in the hardware guide
  • dedicated Python scripts

Tests

Number Name Description
test01 RTM Read RTM lines and compare versus RTM detection table
test02 Pulse repetition Send seven pulses on each channel and check input versus the number of pulses that should be received on each channel
test03 LEDs Light each rear panel LED in sequence and ask the user whether they light

Running

You should follow these steps to get started with the CONV-TTL-RTM-BLO PTS. Note that the steps are performed under Ubuntu Linux.

# Unpack the archive from the folder-struct/ folder in the repository to a location of your choice

# Go to the newly unpacked folder-struct/ and edit the file pyts/pts.py at lines 67, 68, 69:

##-------------------------------------------------------------------------------------------------
## ELMA crate hostname and password
##-------------------------------------------------------------------------------------------------
def_hname = "" # Add the hostname or IP of the ELMA crate here
def_pwd   = "" # Add the admin password of the ELMA crate here
def_slot  = 0  # Add the slot number where the CONV-TTL-BLO is placed
  1. Run the make-links script in the newly-unpacked folder-struct/
  2. Plug a CONV-TTL-BLO in an ELMA crate of your choice
  3. Connect a JTAG cable to the CONV-TTL-BLO
  4. Format a USB key and format it as pts

Now, you're ready to run the script:

# Run the pts.py script in the unpacked folder-struct/

%> ./pts.py
Hello and Welcome to the CONV-TTL-RTM-BLO PTS!

# Scan or type the 1st and second barcodes

--> Scan the 1st barcode: 1234
--> Scan the 2nd barcode: 

--> Plug the CONV-TTL-RTM-BLO board '1234-0' into the VME crate.
  1. Connect two RTM board testers to the RTM under test, one between CH1-3 and one between CH4-6
  2. Now, plug the RTM board under test in the rear part of the ELMA crate and type "ok"
  3. A new xterm window will open up, informing you on the results
  4. When testing is finished, the xterm window will close and the output file will be copied to the stick
  5. In case of errors, they will be output to the console
  6. Unplug the card, disconnect the RTM board testers and place the RTM in its box

Debugging

FATAL ERROR: VME Crate: Unable to switch ON

  • Have you properly set the ELMA crate IP, username and password in pyts/pts.py?
    • after changing, run remove-links to remove the links to the Python scripts
    • run make-links to re-create links to correct Python scripts (including your change)

Other errors

LED errors should be pretty straightforward to debug, since you see which LED doesn't work.

However, errors on the pulse LED test can be harder to debug, but not too hard.

First things first, swap the RTM board testers between them and try the test again.

If that doesn't work and the test outputs indicate the same errors, check the connection diagram of the RTM interface testers to pinpoint the error:

Output Input Input Outputs
O1 I1 I2 I3 I1 O11 O32 O23
O2 I2 I3 I1 I2 O21 O12 O33
O3 I3 I1 I2 I3 O31 O22 O13
O4 I4 I5 I6 I4 O41 O62 O53
O5 I5 I6 I4 I5 O51 O42 O63
O6 I6 I4 I5 I6 O61 O52 O43

The outputs of the test program show you the number of pulses sent and received on each channel:

good : O1 =  7 / I1 =  7
good : O1 =  7 / I2 =  7
good : O1 =  7 / I3 =  7
good : O2 =  7 / I1 = 14
good : O2 =  7 / I2 = 14
good : O2 =  7 / I3 = 14
good : O3 =  7 / I1 = 21
good : O3 =  7 / I2 = 21
good : O3 =  7 / I3 = 21
ERROR: O4 =  7 / I4 =  0 - expected  7
ERROR: O4 =  7 / I5 =  0 - expected  7
ERROR: O4 =  7 / I6 =  0 - expected  7
ERROR: O5 =  7 / I4 =  0 - expected 14
ERROR: O5 =  7 / I5 =  7 - expected 14
ERROR: O5 =  7 / I6 =  0 - expected 14
ERROR: O6 =  7 / I4 =  0 - expected 21
ERROR: O6 =  7 / I5 =  7 - expected 21
ERROR: O6 =  7 / I6 =  7 - expected 21

Using these test program outputs and the above connection diagram, we can find which connection is wrong.

Getting the files

* Clone the repository:

git clone https://www.ohwr.org/level-conversion/conv-ttl-blo/conv-ttl-blo-tst.git
cd conv-ttl-blo-tst/
git submodule update --init

Other documentation