The central, forward and rear tracking detectors, as well as the transition radiation detector, all use transputer systems. Since only the central tracking detector system is fully operational at the moment, we limit the discussion to it.
The central tracking detector electronic system consists of 5 312 channels. Two separate signal systems are used: a FADC-system allowing offline reconstruction of three dimensional track trajectories and a fast z-by-time difference system used by the central tracking detector first level trigger [11]. The second level trigger of the central tracking detector uses data from both electronic systems.
The central tracking detector second level trigger and data acquisition systems run on a network of transputers and are coded in the occam programming language [12]. The network and algorithm have been designed to exploit the natural parallelism inherent in the central tracking detector geometry. Transputer links provide the means of data transfer and communication within the system, and with the ZEUS experiment.
The trigger transputers plus transputers needed for
[
Fig. 3. The ZEUS uranium calorimeter readout and second level trigger system.
]
readout and monitoring comprise an array of more than 120 inter-connecting processors (Fig. 2). Data suppression, triggering and readout in 34 crates of electronics is performed concurrently by exploiting data parallelism and pipeline processing in the network architecture.
The readout of the central tracking detector is divided into 16 azimuthal sectors of the chamber. Each sector is mapped onto one z-crate and one FADC-crate of electronics. A readout module in each of the FADC-crates (FADC-ROC) has one transputer responsible for readout (ADC) and one for merging processor data (MRG) between crates and with the z-system crates. Data flows in one direction between the crates, while second level trigger decisions flow the opposite way. Similarly, one transputer in the z-system crates (Z-ROC) does the readout (ZRT), while the other merges data (MRG) between the crates.
There are three TRAM modules on each readout controller in the z-system crates for second level trigger processing. The three second level trigger transputers in each crate form a pipeline of processes. The first processor attempts to find track segments using FADC information only (SEG) and passes the segment parameters to the next processor which adds z-information to the segments (VHT). These segment parameters are then passed to the next processor which attempts to find tracks (TRK). Intermediate results from each stage are not passed along the pipeline in order to reduce the data volume. However, intermediate results can be passed in the opposite direction to the second level trigger data flow in each crate and be merged into the readout data stream for monitoring purposes.
The trigger processors are chained together by links connecting the track finding transputers in adjacent crates. Each track processor receives segment parameters from one of its adjacent crates and attempts to form tracks in an octant of the chamber. These track parameters are merge with those from the other adjacent crate and passed along the chain to a sub-system crate. The sub-system crate thus receives all the track parameters found in the 16 z-system crates
Global functions are performed by two additional readout controllers: the sub-system crate readout controller (SUB-ROC) responsible for final second level trigger processing and communication with the ZEUS global second level trigger, and the region-box readout controller (RBOX-ROC) responsible for first level trigger control and communication with the event-builder.
The system is data driven at the ZEUS first level trigger rate of 1 kHz and must provide second level trigger information after a mean processing time of 5 ms. Until recently the FADC electronics was absent from the system.
The system comprises a highly irregular asynchronous network topology with geometric, data and pipeline parallelism. The occam communication structure is used for merging processor data and no link switches are used [12].
The software system as a whole requires many hundreds of inter-communicating processes to be placed on the transputer array. To reduce the effort required to develop and maintain the code, tools have been developed to automatically insert code fragments into the programme bodies and to simultaneously generate the required communication channels and network configuration description.
The system has been extensively studied using Monte Carlo simulated data. Simulated background and physics processes, as well as, real data have been used to test the rejection power and efficiency of the trigger algorithms.