Design and test of the track-sorter-slave ASIC for the CMS drift tube chambers

Drift Tubes Chambers (DTCs) are used to detect muons in the CMS barrel. Several electronic devices installed on the DTCs will analyse data at every bunch crossing, in order to produce a level-1 trigger decision. In particular, the Trigger Server system has to examine data from smaller sections of a DTC, in order to reduce the chamber trigger output by a factor of 24. The basic elements of the Trigger Server system are the Track-Sorter-Slave (TSS) units, implemented in a 0.5 micron CMOS ASIC. This paper describes the way the project of the TSS ASIC has been carried on, with emphasis on the methodology used for design verification with IC simulation and prototypes test. I. THE TRACK SORTER SLAVE In the CMS muon barrel, the DTCs represent an important detector to produce a level-1 trigger decision [1]. The DTC trigger system is made of a chain of several devices that are placed on the chambers and arranged on 1080 trigger boards. Each chamber can have up to seven trigger boards. Each trigger board allocates a TSS unit. The full functionality of the TSS is described in [2]. Essentially, it works as a processor with the following main tasks: • Track quality sorter. It selects two out of 8 tracks, based on their quality (transverse momentum, number of hits, correlation, etc.). • Background filter. It rejects ghost tracks that can be erroneously reconstructed within small angular windows. • Data watcher. It allows on-line monitoring of the trigger data, permitting, for example, to exclude noisy channels from the trigger decision. • Tx/Rx unit. The TSS is mounted on a trigger board, which covers about (at least) a seventh of a chamber. The TSS controls the link between the trigger board and the chamber’s Control-Board. In order to decide which technology is more convenient to use for the device implementation, the following boundary conditions were taken into account: 1. 1200 TSS needed for the whole detector; 2. A device needs 90 I/O pads, among which 40 pads are bidirectional; 3. Reduced power dissipation. The device has to be allocated on the chamber itself and cooling will not be very effective and powerful. 4. Event processing has to complete within 25 ns, i.e. the TSS latency has to be 1 BX; 5. The whole functionality is quite complex. In addition to many base functionalities it has to account for remote programmability and on/off-line monitoring. It has to include a built-in self-test and a connectivity test (Boundary Scan). 6. Radiation tolerant. The total dose expected for the TSS in 10 LHC years is not very big, around 0.01 krad (with a factor 10 as uncertainty). Instead, Single Event Effects (SEE) could cause serious problems to the whole system, for example a bus direction flip. Based on the previous conditions (especially 4-6) we considered appropriate to implement the device as an ASIC. In the IC design particular effort has been devoted to speed optimisation, remote programmability and monitoring. Programmability allows choosing among different processing options, depending on the local trigger demands of each DTC section, and permits to partially cover for malfunctioning trigger channels. Since TSS units will be hosted onto the DT chambers and their access will not be easy or frequent, much effort has been dedicated to redundancy of remote programming and monitoring logic. In particular, two independent access protocols, via serial JTAG and/or via an ad-hoc 8-bit parallel interface, allow programming and exhaustive monitoring of each device. In Figure 1 a block diagram is shown to summarize the TSS functionalities.