1. TEL62 AND TDCB UPDATE JACOPO PINZINO ROBERTO PIANDANI CERN ON BEHALF OF PISA GROUP 14/10/2015

2. TDCB, PP and SL Firmware Summary TDCB Firmware (3.0.6) from 13/09/2015 PP Firmware (3.0.3) from 03/11/2015: Is working on all the TEL62 with the generic version and 4 TDCBs installed The only difference respect to (3.0.2) is the possibility to read the crc-code from the fpga PP Firmware (3.0.4) from 14/11/2015: Add a correction to the data compressor to solve the 10% drop seen in the rich and ktag SL Firmware (3.0.1) from 17/09/2015: A bug correction useful only to the primitive firmwares

3. The drop in the number of hits in the RICH At the last weekly meeting during the run (12/11/2015) Roberta shown a drop of ̴ 10% in the number of RICH hits in the RUN after the 17th September. The drop was due to a loss of leading or trailing caused by a bug in the PP firmware. Version 301 on all tel62 Version 301 on jura side Version 300 (before 17 September) After further investigation the same drop has been found also in KTAG in the same period.

4. The solution In the last days of the run a bug has been found in the part of the PP firmware wich prepares the data to be written on the DDR (data compressor). The bug has been fixed on Sunday (15/11/2015), loaded on tel62 as soon as possible and the drop was disappeared before the end of the run. KTAG RICH

5. Nominal beam intensity test (1) During the last week of the run the beam intensity has been increased up to the nominal one ( ̴33 x 10 11 ppp). As soon as the beam intensity was increased the two tel62 of the chanti started crashing (only few packets sent to the PCfarm). Due to the higher rate the dimension of the data packets increase, if a packet is too big, the gigabit fifo goes full with the consequent filling of the previous fifo up to the PP and the tel62 crashes with no more data extracted. With further increase of the intensity also the other tel62s start to crash for the same problem. As a first patch to this problem the fifos before the gigabit have been increased but this wasn’t the solution because the comparison between the 2 chanti boards (one with a new SL fw and the other with the official on) gives more or less the same number of crashes. This was the first time that we saw this problem because we never had this amount of data in lab, but now we are able to reproduce it using the PATTI board. To really solve the problem the last part of the SL will be modified to have a better and more efficient communication with the gigabit board, different implementations are under investigation.

6. Nominal beam intensity test (2) The goal of the TDAQ group during the run at nominal intensity was to understand possible limitations or problems arising with an increasing input rate. Due to the problem described in the previous slide a real and complete investigation of the behavior of the firmware at nominal rate was not possible because the crash due to the gigabit comunication arises before possible other problems. In order to be ready for the next year run, in Pisa, we are optimizing our test setup both concerning the input and the output side: Input: with the PATTI board we are now able to reproduce a pattern of hit in accordance with a structure similar to the NA62 beam (the beam structure along the burst and the “dangerous” peaks) Output: we are preparing a readout system ables to cope with the nominal 1 MHz trigger rate (for the moment we are using a standard readout system based on standard ethernet system, but we are preparing a system based on PF-ring analogous to the PCfarm)

7. Nominal beam intensity test (3) To cope with the high intensity and the beam peaks we use the TDCB Limiter on almost all the TEL62: It is necessary to get detailed information from each sub-detector group using TEL62s to assess the possible needs fro spreading more the channels over the hardware.

8. The goals of the tests in Pisa (1) As mentioned before a key thing to understand before the next year run is the real performances of the system not fully tested during the high-intensiy period of the run (the extraction of data from the DDR and the following pattern up to the gigabit). We already know the problem in the communication between the SL and gigabit and one aim of this test will be the validation of the new structure. During the run we have observed a failure of the system if more than 10 time slots around the trigger are requested, we have to understand why the sytem fails (in principle we can read up to 32 time slots). With these tests we have to understand the real performances of the data extraction from the DDR because this could be a possible critical point of the system and not really understood and tested during the last part of the run. In the offline recostruction almost all the bits (a part the lowest 8 bits) of a leading or trailing are checked.

9. The goals of the tests in Pisa (2) In order to understand the last point of the previous slide we are setting up the following procedures: We can use the data emulator inside the TDCB to produce a known pattern of leading and trailing in order to check on, after the gigabit on a PC, the quality of the acquired data comparing the input with the output. We can check to have a perfect match, any difference would indicate data corruption to be investigated. We can use the pulses coming from the PATTI board to perform the comparison between the input and the output, in this case we can’t predict exactly the leading or the trailing time (due to the limited resolution of the PATTI) but running for a long period we can check the behaviour of the least significant 8 bits (for the other the agreement shold be perfect) assuming that in normal conditions we can expect a flat distribution.

10. Conclusions During the last week of the run at high intensity up to the nominal one we find a crash caused by too big packet sent to the gigabit. In order to be ready for the next year run we are preparing an optimized test setup to check more thoroughly for possible data corruptions even if there is no way besides the beam to really test the system capability at full load and intensity. We have to solve the discovered bugs and problems (more than 10 time slots readout and SL-gigabit communication). Significant work is needed to remove the timing violations from the SL firmware as done during the run for the PP.