HOW TO TEST A BYPASS BOARD

Description of the test

The ByPass receives two inputs (one from channel A and one from channel C) and outputs two identical streams (in normal SVT operations only one of the two outputs is used).

To test the board we need to provide the ByPass with the two inputs, to look at the output data and to compare them with what we expect in output from a board simulation.
So a minimum of two additional Mergers (the Senders) are needed to perform the test. The Receivers are instead optional. If no Receiver is present the test program checks if the data in the ByPass output spybuffer are correct.

Set up of the test in SVT crates

In SVT, the ByPass receives the inputs from two MRG boards, the XTFB splitter and the Final Merger, and it sends the output to the GhostBuster board.

We have the ByPass and the two mergers: the Final Merger and the XTF Splitter
The OUTPUT1 of the XTFB Splitter goes into the INPUTA of the ByPass
The OUTPUT2 of the Final Merger goes into the INPUTC of the ByPass
One can also use a third MRG to act as a Receiver of the output of the ByPass. This allows one to perform a more complete test; we really check that the data coming out of the ByPass is correct (and not only that the content of the output SpyBuffer is ok.

We need to set the input and output Dip Switches (DS) of the ByPass. This can be done using the command:
    python ~zanetti/python/mrg_setds.py <cratenumber> <slot> <DS configuration>

To check the status of the DS you can run
    python ~zanetti/python/mrg_status.py 'crate' 'slot'

The <DS configuration> is given in hexadecimal number. So the command:
    python ~zanetti/python/mrg_setds.py b0svt06 14 25
sets the DS values to:

OUTPUT2	OUTPUT1	INPUTD	INPUTC	INPUTB	INPUTA
1	0	0	1	0	1

If the boards have the following locations:

ByPass: b0svt06 slot 14
XTFB splitter: b0svt07 slot 21
Final Merger: b0svt06 slot 20
Receiver of the ByPass output: b0svt06 slot 12

we have to run these commands:

setup svtvme -d
python ~zanetti/python/mrg_setds.py b0svt06 14 25
python ~zanetti/python/mrg_setds.py b0svt07 21 18
python ~zanetti/python/mrg_setds.py b0svt06 20 27
python ~zanetti/python/mrg_setds.py b0svt06 12 08

If no receiver board is used, the DS of the ByPass have to be set to 05 (no output) otherwise the ByPass sets the output hold.

Configure the software

First of all, you need to copy in your directory the byp_random_test.c program (a frozen version of the source program is here).

>cp /cdf/onln/home/zanetti/bypass/byp_random_test.c . Then you have to compile it:

>cc byp_random_test.c -I $SVTVME_DIR/include/ $SVTVME_LD_PATH/svtvme_th.o -lm -lVISIONclient -L $FISION_DIR/Linux-2/i686/ -o byp_random_test This command produces in your directory the byp_random_test program.

Running:

>./byp_random_test you get the syntax here reported:

>./byp_random_test <two_mrgs> <change_cables> <change_slots> <max_iter> <add_gaps> <in_file> 

 two_mrgrss  :     0 ==> test only one MRG 
                   1 ==> test 2 MRG's at the same time

 change_cables:    0 ==> use previous cabling config. 
                   1 ==> change cabling configuration

 change_slots :    0 ==> use previous crate/slot config. 
                   1 ==> change crate/slot configuration

 max_iter     :   -1 (or missing) ==> infinte loop 
                  >0              ==> number of iterations before stop

 add_gaps     :    0 (or missing) ==> do not add gaps 
                  >0              ==> add gaps in data sending

 in_file      :    missing   ==> generate random data 
                   file_name ==> load each sender from given file

The first 3 options are the more frequently used ones.

Run the test in SVT crates

To run the test you need to have no data going through the boards and no SVTMon running in the crates, because it checks the SpyBuffers and you are using them for the test. If the SVTMon read the SpyBuffers you can get an error just because the test doesn't find the data it expects in the SpyBuffer. So:

Ask the ACE to remove SVT crates from the partition (In principle you need to control all the crates containing boards that are connected to the one you are testing - taking all of them is a good solution :-) )
Start the RC and configure it for a FAKE_HITS run
Then just partition

The first time you have to run

./byp_random_test 0 1 1 1

then a menu will ask you about the position of each board and the connections between them.
Beware that the most common mistake is to define a configuration not consistent with the setting of the DS: so, if the program exits with errors, first double check all the settings.
After you configured everything the test makes 1 cycle. In the directory you find the

MRG_RANDOM_TEST_CONFIGURATION

containing all the settings. From now on you can run

./byp_random_test 0 0 0

The absence of the fourth parameter allow for infinite cycles... let the test run for 1 hours and cross the fingers. When you are bored and feel confident that the board is good do ctrl-C.
The program produces the log file: log_mrg_test_random.txt.
Furthermore, in case of errors, the programs dumps several files *_data to help in debugging the problem.

REMEMBER TO FLAG THE BOARD AS BAD/GOOD, PUT A NOTE IN THE E-LOG and, IF THE BOARD IS BAD, SEND an E-MAIL to Anna Maria.

Stefano Torre & Anna Maria Zanetti

Last modified: Feb 20,2006