Dallavalle, G M

Montanari, A

Odorici, F

Travaglini, R

CERN Document Server

Design and Test of the Track-Sorter-Slave ASIC for the CMS Drift Tube Chambers F. Odorici  and G.M. Dallavalle, A. Montanari, R. Travaglini I.N.F.N. and University of Bologna, V. B. Pichat 6/2, 40127 - Italy Fabrizio.Odorici@bo.infn.it Abstract 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 bi-directional; 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.     TRACOselectTSMpreview TRACOpreviews4 x 9 bitJTAGcontrollerJTAGserial lineI/Opads2 wordcompx 10REGREGREGGhost1Buster11 bit5 bitREGInputmaskPriorityEncoderGhost2BusterQualityFilter4 x 9 bit9 bitConfigurationRegistersParallel InterfaceProgrammodeTESTregsSNAPregs8FBTSBTFBT = First Best TrackSBT = Second Best TrackCarryI/OpadsI/Opads Figure 1: Block diagram of TSS functionalities.   II. THE EXECUTIVE PLAN The TSS project has been carried on by following a three-step plan: • Working Rules. Firstly, define rules that fully describe the TSS functionality. Some of these Rules are the outcome of the Trigger simulation. • Design Joined Approach. Design a “machine” which satisfy the Rules using two independent formalisms: – A logic description (VHDL); – A software Device Emulator (C language). • Software Tools Common Base. In order to master and verify the considerable design complexity, we developed a common base of software tools for IC simulation and prototype (also production) testing phases. The common base consists of an event generator, a device emulator and an output comparator.  The above approach gives several advantages. For example, the two independent formalisms allow to perform a reciprocal verification of the design and to correct for “wrong” or “missing” Rules. The Device Emulator allows to produce an exhaustive test vector set and becomes a certified “bug-free” software for prototype verification.  More generally, a common base of software tools gives advantages in terms of development time and code correctness.  In Figure 2 the methodology adopted during the development of the project is shown as a flow diagram. The test software tools are shared between IC simulation and prototype test phases.  Figure 2: Methodology used to develop the TSS device. III. WORKING TOOLS The basic tools we adopted during the project life were: • ASIC development system (Synopsys). To implement the VHDL design and IC Simulation at various levels (VHDL, Gate, Post Layout). • Layout & Prototypes were made via Europractice (IMEC), which offers low rates for no-profit institutes.  For the same reason also the mask and the small volume (less than 10 kpcs) production is made via Europractice.  • Custom Test-Software (programs and libraries) was implemented in C language. • Custom Test-Hardware was based on a programmable I/O Pattern Unit VME module, able to operate well beyond the LHC bunch crossing frequency, i.e. up to 100 MHz. The Pattern Unit is a very flexible instrument; in fact, we designed it as a general testing tool for digital electronic devices. The device controls up to 128 I/O channels and has many features and programmable options that make it a suitable tool for both a prototype test bench and for a test-beam set up.  In Figure 3 a Pattern Unit is shown and a complete description of its functionality can be found in [3]. The device under test (DUT) is connected to the Pattern Unit through a piggy board, inserted on appropriate socket strips.    Figure 3: Pattern Unit hosting the DUT interface board.  The DUT interface board can also be used with a remote connection to the Pattern Unit. For example, we used the remote connection in the radiation test set up (see Figure 4). In that case, data were injected and monitored via JTAG. In correspondence of the chip die (4.5x4.5 cm2) the interface board has a 16 mm diameter hole in order to minimize attenuation effects due to extra material.  Figure 4: Radiation Test set up on 60 MeV protons beam. The test was made at the Cyclotron facility (CRC) in Louvain la Neuve (Belgium). IV. PERFORMANCES AND RESULTS The adopted technology for the TSS is the Alcatel-Mietec 0.5 µm CMOS. A picture of the TSS layout is shown in Figure 5.  Figure 5: layout of the final TSS device.  An important aspect of the device implementation is the completeness of the IC simulation and prototype test. For many digital processors, as well for the TSS, the number of possible I/O patterns and internal device configurations is so large that an exhaustive test pattern set can easily get over millions of events.  Moreover, hardware tests usually require long term (hours) observations in order to verify temperature stability and noise immunity. For those reasons it is useful to dispose of fast simulation system and fast test chains. For the TSS the IC simulation was performed within the Synopsys CAD, running on a Sun Ultra 10 workstation. The prototype test was controlled by our custom software, running on a PC (Pentium-II, 333 MHz), embedded on the same VME crate that houses the Pattern Unit. The performances of our systems are reported in Table 1. Table 1: performances of the simulation and test systems. Performances IC simulation Prototype Test Event generation negligible negligible Event injection negligible 10 Mevt/h (VME limited) Event processing 10 Kevt/h (CPU limited) negligible (40 Mevt/s) Output analysis negligible negligible Full test ∼ 1 Mevt > 100 Mevt The behaviour of the TSS under radiations has been verified using a 60 MeV proton beam at the Cyclotron facility (CRC) in Louvain la Neuve (Belgium). We find the IC to be fully tolerant (the drawn current is stable) up to 30 krad, while the rate of single event effects (SEEs) was observed to be: σSEE = 8.4 x 10-15 cm2/bit . For the TSS, which is placed on the muon drift tube chambers, the expected integrated flux is moderate (0.01-0.1 krad/10 LHC years). Since also the number of SEEs expected for about 1000 TSS is negligible (less than 1 in 10 LHC years), we can exclude problems related to radiations for the TSS. The TSS project, during his development, required the implementation of two prototypes, the first one with reduced functionality. Each step of the project required a variable amount of manpower, with different distributions for the two prototypes. The manpower, expressed in terms of “full time work”, is reported in Table 2. The total R&D full time work corresponds to more than 4 years, excluding the time invested for trigger simulation. Most of the manpower has been devoted to implement the Test System and the Test Software. Table 2: manpower dedicated to each project step, for the two prototypes, expressed in terms of "full time work".  Project steps ASIC v. 1 (f.t.w.) ASIC v. 2 (f.t.w.) Rules definition 0.1 y 0.1 y VHDL design 0.4 y 0.3 y Device Emulator 0.3 y 0.1 y IC Simulation 0.2 y 0.3 y Test System 1.2 y 0.1 y Test SW 0.5 y 0.1 y Interface board 0.1 y 0.1 y Prototype tests 0.1 y 0.1 y (undergoing) Total R&D 2.9 y 1.2 y  V. CONCLUSIONS The Track-Sorter-Slave, the basic element of the Trigger Server system for the trigger chain of the CMS Drift Tube Chambers, has been implemented in a 0.5 micron CMOS ASIC. The project has been organized on a long term perspective, because different steps of the realization  (milestones) have been affronted: two prototypes with increased complexity, radiation tests, test-beams and integration tests. The R&D work dedicated to the project involved about 4 years of manpower. Most of the job was dedicated in developing software and hardware test tools, which were not, as usual, commercially available. REFERENCES [1.]  CERN LHCC-2000/038, CMS Collaboration, “The Level-1 Trigger, Technical Design Report”; [2.] CMS TN 1996/078, G. M. Dallavalle et al., “Track Segment Sorting in the Trigger Server of a Barrel Muon Station in CMS”;   CMS IN 2001/xxx (in preparation),  A. Montanari et al., “Track Sorter Slave reference manual”. [3.] CERN LHCC 1998/036 291, G. M. Dallavalle et al. “Pattern unit for high throughput device testing”;  CMS IN 2001/xxx (in preparation),  F. Odorici et al., “A high throughput Pattern unit as a testing tool for digital Integrated Circuits”. 

Design and Test of the Track-Sorter-Slave ASIC for the CMS Drift Tube Chambers

Abstract

Similar works

Full text

Available Versions

CERN Document Server