Speaker
Description
Summary
The purpose of JUNO [1] is to determine neutrino mass hierarchy and precisely measure oscillation parameters by detecting reactor neutrinos, supernova neutrinos as well as atmospheric, solar and geo-neutrinos. To transcend the border knowledge of these phenomena the new observatory is built around a central detector consisting of 20 kton LAB based liquid scintillator surrounded by 18000 PMTs dip in a water pool. The data readout architecture and the desired resolution better than 0.1 photoelectron (pe) are a challenge of primary importance for the success of the experiment. The baseline structure of the data readout architecture states that each PMT embeds the High Voltage (HV) unit together with the readout electronics in a standalone manner inside a water-tight box communicating with the external world by means of 100 m Ethernet cable [2]. The GCU represents the core logic of these smart PMTs thanks to the on-board FPGA whose capabilities are augmented in terms of fast data buffering, elaboration and control by bridging the Ethernet network to several different peripherals like a Time Delay Counter, Clock Data Recovery, temperature sensors, power monitor, HV unit controller. The front-end inaccessibility after installation highlights the importance to design high reliability hardware and to adopt strategies for recovering from stalling situations due to firmware bugs (or firmware corrupted during the reprogramming phase itself). The GCU hosts an ASIC that digitizes the signal received from the PMT and must be able to issue trigger primitive requests to the off-water trigger system, to store data waiting for a trigger validation and consequently send events fragments to the remote event builder unit via Ethernet link. The worst case scenario in terms of events readout bandwidth requirement comes from triggers due to dark current, about 25 Mb/s, well in the range of Fast Ethernet bandwidth. The adoption of the fast Ethernet standard for data readout and slow control opens the possibility to use two unallocated twisted pairs of the cat-5e cable as synchronous and fixed latency links. One of these two links is used to communicate with the Central Trigger Processor (CTP) that collects trigger primitives generated by GCUs. The second is used to distribute the 62.5 MHz system clock to the GCUs; each GCU local time must match the global time within 16ns of resolution. The requirement of GCU synchronization is related to the distributed nature of data readout. The GCU project is in an advanced prototyping stage. An overview about the main features of the custom hardware platform will be given together with the first data readout from a PMT and the description of the test set-up with multiple GCUs.
[1] Introduction to JUNO, 2013-09-12. http://english.ihep.cas.cn/rs/fs/juno0815/.
[2] Juno proposal for PMT readout – GCU, M. Bellato at all, INFN and University of Padova, 11/12/2015.
