Dear all,
we just connected the first readout boards in the cavern to an FLP machine in CR1.
At this point I would like to check the quality and error rate of the optical link between the GBTx chips and the CRU, since the optical fibers have been freshly pulled and not yet tested after installation.
Is there a way to do this with the O2 tools?
Thanks a lot in advance!
Cheers, Andrea
Hello,
Do you have a side way to put the GBTx chips in loopback mode , i.e. they forward what they receive? If yes use the gbtx-checker.py script in https://gitlab.cern.ch/alice-cru/cru-sw/blob/master/COMMON/gbtx-checker.py.
You can first test the script with a direct fiber loopback
Cheers
Hi Olivier,
thanks for the hint! Should I enable “loop C” in the figure below for the gbtx-checker to work?
Has anyone direct experience with this, and could suggest the exact GBTx register(s) and values(s) that should be set?
I could only find this in the GBTx manual, but there is no mention of which registers control the three loops:
Thanks!
Hello,
I would say loop A works as well. I had once a script to configure the GBTx with the USB dongle, but I forgot to save the file when I exchanged the server, so I can’t provide it to you. I’ll ask @tunguyen if he has what is required.
Cheers
Hi @bourrion, @tunguyen has provided me a GBTx configuration file that I have loaded via IC commands. Could you tell me how exactly I should invoke gbtx-checker.py and what is the expected output?
Thanks!
Hello,
If the GBTx is in loopback mode then you can use ./loopback.py (gbtx-checker checks data that is generated in the GBTx chip):
./loopback.py -i 2:00.0 --link 0-5 --mode gbt --stat cnt --rst
(modify the pcie id and the links)
If you use “–stat fec” then it’ll show you the corrected errors (cnt displays the errors that coud not be corrected), in both cases you should see constant zeros on every link
https://gitlab.cern.ch/alice-cru/cru-sw/tree/develop/COMMON#loopbackpy
Some example outputs below in the three stat modes
flp@lpsc-flpgrenoble COMMON]$ ./loopback.py -i#0 -s cnt -mode gbt -rst -l 0-11
seconds error:0 error:1 error:2 error:3 error:4 error:5 error:6 error:7 error:8 error:9 error:10 error:11
1 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
2 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
3 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
4 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
5 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
6 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
7 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
8 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
9 0 0 0 0 0 0 0 0 0 s_datadown s_datadown s_datadown
[flp@lpsc-flpgrenoble COMMON]$ ./loopback.py -i#0 -s fec -mode gbt -rst -l 0-11
seconds fec:0 fec:1 fec:2 fec:3 fec:4 fec:5 fec:6 fec:7 fec:8 fec:9 fec:10 fec:11
1 0 0 0 0 0 0 0 0 0 0 0 0
2 0 0 0 0 0 0 0 0 0 0 0 0
3 0 0 0 0 0 0 0 0 0 0 0 0
4 0 0 0 0 0 0 0 0 0 0 0 0
[flp@lpsc-flpgrenoble COMMON]$ ./loopback.py -i#0 -s all -mode gbt -rst -l 0-6
seconds RX EC/FEC #0 RX EC/FEC #1 RX EC/FEC #2 RX EC/FEC #3 RX EC/FEC #4 RX EC/FEC #5 RX EC/FEC #6
1 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
2 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
3 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
4 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
5 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
6 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0 0/ 0
@tunguyen @bourrion
Thanks for the hints.
After loading the GBTx configuration via IC (and getting a systematic failure when writing register 30), this is the output I am getting:
[flpproto/latest-o2-dataflow] ~/cru-sw/COMMON $> ./loopback.py -i af:0.0 -s cnt -mode gbt -rst -l 1
Note: standalone must have been executed first...
seconds error:1
1 0
2 lockedtodata
3 0
4 2098
5 157
6 77
7 lockedtodata
8 0
9 lockedtodata
[flpproto/latest-o2-dataflow] ~/cru-sw/COMMON $> ./loopback.py -i af:0.0 -s fec -mode gbt -rst -l 1
Note: standalone must have been executed first...
seconds fec:1
1 1015
2 1015
3 1015
4 1015
5 1015
6 1015
7 1015
8 1015
9 1015
10 1015
[flpproto/latest-o2-dataflow] ~/cru-sw/COMMON $> ./loopback.py -i af:0.0 -s all -mode gbt -rst -l 1
Note: standalone must have been executed first...
seconds RX EC/FEC #1
1 2109/ 0
2 lockedtodata/ 0
3 lockedtodata/ 0
4 lockedtodata/ 0
5 1778/ 0
6 0/ 0
7 lockedtodata/ 0
8 lockedtodata/ 0
9 416/ 1607
10 lockedtodata/ 0
11 lockedtodata/ 0
12 lockedtodata/ 0
13 2005/ 0
14 lockedtodata/ 0
Also, linkstat.py tells me that the link is DOWN after some time… I suspect that the configuration is not properly loaded in the GBTx chip (and probably cannot be loaded at all via IC), because immediately after writing GBTx register 29 (corresponding to “Select data path through TX logic A” in the GBTx manual) all the subsequent registers cannot be properly set and read back.
I think this can only be done via a dongle…
If that is really the case, are there other possibilities to check the quality of the optical link between the CRU and the GBTx? For me, this seems to be something that needs to be systematically done for all the GBTx equipments that will be connected to CRU in the cavern, right?
Hi,
Indeed when did this kind of tests, we used the USB dongle. @tunguyen and I are not sure we can configure this via GBT-IC. May be @costaf knows a better way (he’ll be available on Monday).
In the meantime can you do physical loopback to check the fibers instead of going through the GBTx? It is not equivalent, but it would rule out the fiber from your uncertainties.
Cheers
I would rather prefer not to unplug/re-plug the fibers if possible… instead, I can do some systematic test by reading/writing GBTx registers and/or doing repeated I2C transactions. However, I have no idea how sensitive would be such tests to issues in the optical transmission trough the fibers. Any idea?
With the help of @costaf we managed to find the good GBTx configuration on order to run the CRU loopback test.
For the records, the “trick” was to set GBTx registers 29, 30 and 31 to 0x35 (or 53 decimal), in order to enable the loopback path marked in green in the below picture:
After that, the loopback.py script shows non-zero but constant RX EC/FEC values when running in -s all mode.
Thanks!
