1 Introduction
The Daya Bay Reactor Neutrino Experiment (DBRNE) is designed to measure the neutrino mixing angle θ13 to a precision of 0.01 at 90% confidence level, an improvement of about one order of magnitude over the past experiments[1]. Its anti-coincidence detectors are composed of Water Cherenkov detector and RPC (resistive plate chamber) detector. To achieve the experiment accuracy, the efficiency of RPC system should be >90%. The basic experimental architecture of DBRNE consists of three underground experimental halls linked by horizontal tunnels: two near halls at Daya Bay Nuclear Power Plant (NPP) and Ling Ao NPP, and the far hall that is 1900 meters away from Daya Bay NPP and 1600 meters away from Ling Ao NPP. In the far hall, the RPC detector is a square array of 9×9 overlapping RPC modules, while in both near halls. It consists of 6×9 RPC modules. Every RPC module has 4 horizontal layers, each layer consisting of 8 readout strips, yielding 2592 and 1728 readout channels for far and near halls, respectively.
The goal of RPC electronics is to generate the local triggers when a cosmic-ray passes through a RPC module, process the triggers, and acquire corresponding hit information[2]. The architecture of the Daya Bay RPC electronics is shown in Fig.1.
Every RPC module is assembled with a front end card (FEC), which processes analog signals from the module’s 32 readout strips distributed among the 4 layers. The analog signal of each strip is transferred to its corresponding comparator on the FEC. After discrimination, the digital signal is transferred to a field programmable gate array (FPGA) which is assembled on the FEC. A coincidence signal is generated when trigger requirement is met[3]. Coincidence signals are sent to a 9U VME RPC trigger module (RTM) via a specialized readout transceiver (ROT). The RTM generates local triggers that tell which FECs should be readout based on the coincidence signals from FEC and sends the local triggers back to the related FECs via ROTs. When the local trigger arrives at an FEC, the hit data buffered in the FEC FPGA will be selected and transferred to the event buffer. All data in the event buffer are sent to the ROM through the ROT. The ROT is a readout transceiver which receives signals from FECs via a 20-pair twisted round cable, and sends the signal to the ROM and RTM via optical fiber. It also receives commands from the ROM and trigger information from the RTM, and sends these signals to FECs. Each ROT can connect to a maximum of 15 FECs. Each ROM and RTM can connect to a maximum of 6 ROTs.
2 System requirements
In order to reduce noise, attain a desirable signal-to-noise ratio and utilize the RPCs efficiently, the RPC electronics adopts a 3 out of 4 (3/4) or 2 out of 4 (2/4) trigger mode for each RPC module[4]. The trigger mode is selectable through firmware configuration. A 3/4(2/4) trigger mode is that when 3(2) of the 4 layers of one RPC module have hits, a coincidence signal is generated and the hit information is readout from the corresponding RPC module and its four most adjacent modules according to the coincidence signal. Respective rates of 3/4 and 2/4 triggers are estimated at 20 Hz and 5.6 kHz in the far hall and 200 Hz and 4 kHz in the near halls, respectively. So the maximum trigger rate is 5.62 kHz in far hall. From the maximum trigger rate and data package size, the maximum data rate is about 2.2 MB·s-1. According to expected physical requirements, the following electronics requirements were proposed:
– Data transfer rate is approximately 2.2 MB·s-1,
– Event loss in 8 h should be less than 2 packages,
– Running stably and reliably,
– Buffer over flow protection against data loss due to accidental high trigger rates,
– Can read status of each FPGA via VME bus,
– Can mask hot and dead channels,
– Can update FEC firmware online through the VME bus.
In order to handle the maximum data transfer rate and make event loss less than 2 packages in 8 hours, both the ROM and RTM should not have significant dead time due to data processing. Based on the event loss ratio calculation[5] and data processing mechanism, the event buffer depth is set at 8, and the RTM data loss ratio and the ROM data loss ratio are 6.365×10-13 and 1.725×10-12, respectively. Then, we can calculate that there is no data lost in an 8 h interval at a 99.99% confidence level.
For the buffer overflow protection, when either the ROM or RTM buffer is almost full, the RTM should stop receiving coincidence signals and generating new local triggers until the buffer has enough free space. In order to read back the status of each FPGA, the status register should be set in every FPGA in both the ROM and RTM, and the register data should have a data transfer channel to send it back. To mask hot and dead channels, we should first encode every FEC.
3 The RTM and ROM
The RPC trigger and readout modules are 9U VME modules dedicated to processing signals and data from the RPC system front end electronics. The modules are described in details as follows.
3.1 RTM
As shown in Fig.2, an RTM is assembled with one Interface FPGA (IF) and three Control FPGAs (CFs). The IF is in charge of the communication with the VME bus while the CFs receive coincidence signals from FECs and package the trigger information. Each CF is connected to two fiber child boards, communicating with one ROT of each board.
Near the IF on an RTM, a flash memory stores the firmware data for the CF, so the CF firmware can be updated online through the VME bus. There is a status register in every FPGA for the status feedback. The buffer depth in each CF is 256, being big enough for system calculation requirements. Tests show the buffer is also big enough for the trigger rates.
One main function of the RTM is to treat coincidence signals from the FECs. Three CFs produce a trigger map of totally 81 FECs (in the near halls, we use 2 CFs and totally 54 FECs). As shown in Fig.3, the trigger map logic is to accept coincidence signals from FECs and determine the map of the local triggers according to the adjacent readout mechanism. The local triggers are sent back to the FECs to initiate readout of the hit data from the RPC modules.
Another function of RTM is to generate trigger map data with a timestamp when there is a coincidence signal from an FEC. Then it sends data to DAQ system via VME bus. The timestamp comes from the clock system, which is coded in Manchester[6].
The RTM accepts the buffer signal from the ROM via the VME bus, and when the buffer in the RTM or ROM is almost full, the RTM stops generating the local trigger and trigger map data to ensure protection against data loss.
3.2 ROM
As shown in Fig.4, the ROM has one IF and 6 CFs. Each CF is connected to one fiber child board, which is linked with one ROT. Near the IF on ROM, a flash memory stores the firmware data for the CF, so the CF firmware can be updated online through the VME bus. There is a status register in every FPGA for the status read back. The firmware data for FECs can be transferred to the IF via the VME bus. After the data is transferred to the CF via serial data transfer line, it is sent to ROTs via the fiber. The buffer depth in each CF is 4096 (273 for each FEC on average).
The main function of the ROM is to get data from up to 81 FECs via the fiber child, then to re-organize the data in an FPGA and finally send the data to the DAQ system via VME bus. Due to hardware limitations, we adopt serial data transmission. For each CF, there are at most 15 FECs sending data back, so we use the polling mechanism (Fig.5) to acquire the data from FECs. When serial data is recognized in the shift register, the data is changed to parallel format and put into the FEC data register. The polling module scans the FEC data registers to see if there is hit data. If yes, the polling module put the data in the buffer.
It takes the polling 30 clock cycles to scan the 15 FECs data register, while it takes 80 clock cycles to transfer one FEC serial data, so the polling mechanism does not introduce any additional dead time. And no additional dead time can ensure that the system can process the maximum data transfer rate. In fact, the data transfer from CF to IF in both the ROM and RTM adopt the same approach to avoid additional dead time and save resources.
The buffer almost full signal in the ROM is transferred to RTM via the VME bus. For the IF in the ROM and RTM and the Control FPGA in the RTM, we use the Cyclone I EP1C6Q240C8 for its appropriate memory[7], LE (logic elements) and pin resources as well as its inexpensive cost. But for the Control FPGA in the ROM, we choose the Cyclone III EP3C25Q240C8 FPGA for its more abundant memory and LE resources[8].
3.3 Data transmission to DAQ
When the ROM received a certain amount of data (RTM data is always less than ROM because of the trigger mechanism), it sends the interrupt request to the VNE Power PC controller in the VME crate. When the power PC responds to the interrupt request, it starts the chain block transfer (CBLT) to get data from both ROM and RTM. The operating system in the power PC is embedded Linux and the software programs that run on it are prepared by the DAQ group.
4 Results and discussion
4.1 Self-test
In self-test mode, every FEC generates digital signals simulate the inputs digital signals generated by comparators. Then, a coincidence signal is generated and sent to the RTM. We set the trigger rate for each FEC at 1 kHz which is much larger than the expected trigger rate in the experiment. There is no data lost in a 24-hours self-test.
4.2 Data processing rate
In self-test mode, with a 2 kHz FEC trigger rate, corresponding to a 4 MB·s-1 data rate (which is bigger than the estimated maximum data rate of 2.2 MB·s-1), the system ran stably without data lost.
In joint testing for 24 h with RPC detector, no data lost was observed.
4.3 Buffer overflow protection against data loss test
This function was tested under self-test mode. The FEC trigger rate was set at 10 kHz which is much more than the work frequency. The almost full flag is tagged for testing data and the data is not consecutive, as we expected.
4.4 Status read back
At the beginning of every run, we read back the status of the IF and CF from both the ROM and RTM to check, for example, that synchronization is "Ok" and CF configuration is "Done" .
4.5 Joint test with RPC detector in a near hall of Daya Bay
The joint test with the RPC detector was done in the near hall at Daya Bay NPP. Fig.6a shows the hit map for 54 FECs, 1728 channels (32 channels per FEC). No hot or dead channels were observed. Fig.6b shows the efficiency of the 54 RPC modules. The efficiency of each RPC module is over 90%. From the results, we can be sure that the RPC electronics works as designed.
5 Conclusion
Until now, the test results of Daya Bay RPC readout electronics indicate that the VME system is efficient and reliable for data acquisition and trigger processing tasks. Up to now, all functions needed or desired have been achieved through upgrading the firmware.
RPC module detector for Daya Bay and its measurement for background, PhD. Thesis
of