Front End Electronics. Level 1 Trigger

Transcription

1 0. CMS HCAL rigger and Readout Electronics Project he overall technical coordination for the HCAL trigger and readout electronics (ri- DAS) project will be located in the Maryland HEP group, led by Drew Baden (WBS Level 3 manager). In addition to this project management task, Professor Baden will also be supervising the design of the system, and the HCAL rigger and Readout (HR) cards. hese cards will receive the raw data, maintain the Level pipeline, transmit trigger primitives to the Level system, and transmit Level accepted data to a concentrator board (in the same VME crate) for buering and transmission to Level 2 and DAQ. his project is described below. 0.. Introduction he HCAL upper level readout system is dened as everything between the optical bers carrying the HCAL data from the detector, and the input to the L2/L3 processor Farm. he overall system design and its context within CMS HCAL and rigger is shown in gure. Parameters are as in table. he full readout system consists of 24 VME crates. Each crate will be responsible for receiving HCAL data, maintaining the 40MHz pipeline, maintaining synchronization via the C, and preparing and transmitting the data for both Level and Level 2/DAQ. o do this, the HCAL readout crate will contain: HR { HCAL Readout and rigger cards: these cards are the workhorse for receiving and processing raw data for the Level trigger, as well as perparation for Level. DCC { Data Concentrator Ccard: this card receives Level 2 data from each HR card in the crate in preparation for transmission to Level 2 and the CMS DAQ network. HRC { HCAL Readout Control card: this card is responsible for fast and slow monitoring, as well as ancillary trigger control distribution and whatever functionality is not in the HR and DDC card. his card will have an onboard CPU. Each crate will consist of 8 HR cards, DCC, and HRC card, and will service a single Device Dependent Unit (DDU), mounted as a PCI mezzanine card (PMC) on the DCC, for Level 2/DAQ feeding. he optical bers supplying the readout crates are not included in the system. he trigger links, however, are included, and possibly the HCAL DDU as well although this has not been entirely settled as of this time. Buer sizes and transmission requirements will all be based around an expected average Level accept rate (LA) of 00kHz. he Level 2 accept rate is irrelevant for these considerations. Crates will reside in a room near the detector, but below the surface Upper Level Readout Crate he readout crate is mechanically a U x 400 mm VME crate. he P3 area is completely user denable, and will be used by HR cards (see section 0..3) for transmission of trigger primitive data to Level, possibly via auxiliary backplane cards but also possibly via direct connectors, eliminating any P3 backplane and associated auxiliary cards. he latter approach is seen as a cost savings. We anticipate that we will need the middle row of P2

2 FED Front End Electronics Link to Level 2/DAQ Gbps fibers (2 channels/fiber) H R C D C C H R H R 8 HR Cards H R H R C Level 2/Raw Data 200 Mbps per link Level rigger Data Vitesse,Copper Link, 20m cables, Gbps Level rigger Figure : HCAL Readout and rigger Crate. (for VME 32) for calibration and monitoring I/O, involving the particular implementation for the VME crate CPU card. HCAL data arrives at each crate via optical ber links which delivers data at approximately Gbps using the HP G-Links protocol. Each ber will deliver 2 or 3 channels worth of data, to be determined (it depends on whether we run the bers at 800 Mbps or.6 Gbps). As described above, there will be a total of 8 HR cards per VME crate, and each HR card is anticipated to service 2 or 6 ber inputs. Once arrived, the data is transformed, buered, and pipelined in the HR card. While in the pipeline, data is prepared (Level \trigger primitives" are constructed) and transmitted to the Level framework over copper cables. hese trigger primitive cables will carry approximately 2 \trigger towers" per cable, with each trigger tower constituting the signal in both the front and back section of an HCAL physical tower. his results in 8 cables per HR card, or 44 per crate. he maximum average L accept rate is required to be approximately 00kHz. If the L trigger passes the event, the data stored in the pipeline buers is collected, processed and transmitted to the DCC for concentration over simple channel-link copper cables, one per HR card, where it waits until it can be transferred to the DAQ system via DCC input cards. he DCC will hold approximately 000 events in its internal buers. he HRC card serves as the interface in the crates for both slow and fast monitoring, as well as providing 2

3 HCAL readout crates DCC cards per crate HRC cards per crate HR cards per crate 8 Input bers per HR 6 (2) HCAL channels per ber 2 (3) HCAL channels per HR 32 (36) HCAL channels per crate 576 (648) OAL HCAL channels 3,824 OAL HR cards 463 (43) OAL DCC cards 35 (26) able : HCAL upper level readout system parameters. a home for a C receiver (CRx). C signals will be delivered by the HRC card to the 8 HR cards in the crate, insuring synchronization he HR Card In this section we discuss the HR card, which consist of an input section for raw data receiving, a Level Path containing the Level preparation and transmission capaibility to the Level framework, and a Level 2/DAQ Path consisting of the pipeline storage and Level accept buering used for transmission to the DCC. he HR design takes advantage of the current (and projected) availability of large aordable FPGA chips with 0 6 gates and 0 3 I/O pins. his design (as opposed to having separate cards for the separate receiving and trigger functions) allows a merging of the readout and trigger preprocessing functionality into a single card, decreasing the engineering and production costs (fewer dierent cards) and allowing for fewer channels per card (more cards with readout capability). Input Section he HCAL calorimeter signals are digitized at each crossing (40 MHz). Each HCAL QIE channel will produce a 7-bit number per crossing as a measure of the energy in the HCAL element. he digital 7-bit value is a variant oating point format, consisting of 2 bits of scale (exponent) and 5-bits of ADC digitization (mantissa). Since there are 4 capacitors per QIE output, there will be an additional 2 \CAP" bits transmitted with the QIE digital number. he CAP bit will be used to correct for the variation in each sampleand-hold capacitor. ransmission will be via ber optics using the HP G-Links protocol running in encoded mode with 20 bit frames. Each frame will consist of the data from 2 QIE channels (2x7=4 bits) plus the 2 CAP bits for a total of 6 data bits per frame. he rate of transmission will be at 40 Mframes/sec for an total data transmission bandwidth of approximately 700Mbit/sec[]. he bers which deliver data to the HR cards will plug into the front panel. his scheme alleviates engineering R&D necessary for successful input over the P3 backplane, 3

4 and takes advantage of the G-links built-in receiving and deserializing capability. As shown in gure 0..3, the receiver section of the HR card will add a \frame bit" which will tag transmission errors. Synchronization errors in the cap bit will be agged and transmitted during those buckets that come in the orbit gap, in the form of an error code[]. A PLD will receive the 6 bits of data along with the frame bit, and transmit simultaneously to the Level and Level 2 paths for processing. Note that the PLD will have the C timing information available. Figure 2 shows a schematic overview of the HR card. (366.7mm x 400mm) Point-to-Point x to DCC L input fromc Level 2 Path with Pipeline and Derandomizer buffers VME J VIPA J0 VME J2 Level rigger Primtives Path 6 HP G-Links Fiber+Rx chip Output to Level Framework Figure 2: HR card layout Level Path he L tap needs to be processed and summed with its other depth segments for that eta-phi tower before being sent to the L trigger. he HCAL signals are collected over a period of 5 crossings. he rst two are for baseline subtraction, the last three are the time it takes to collect the energy. he tapped L signals must be processed to giver the energy in 4

5 HP G-Links: 6 bits data 20 bit frames 40 Mframe/sec Fiber Input Rx 7 2 Crossing Ch A data Cap bits Frame bit PLD Ch A data Level Path 7 Ch B data PLD Ch B data Level 2 Path Crossing Figure 3: HR input section. the single beam crossing which created the energy. he MCM contains a simple processor for this purpose. However, we should develop an algorithm for implementation in a gate array as an alternative should we not use the MCM. he summing is done by acombination of the readout card and trigger card. For the barrel, there are only two depth segments for each tower. his sum is performed on the readout card. For the endcap calorimeters there can 2,3 or 4 segments which need to be added. No more then two are done on the readout card, further summing is done by thetrigger cards. he forward calorimeter is even more complex. After summing, the 0 bits with least count of.5 GeV are picked out of the 6 and sent to the adjacent trigger card by parallel connection across the front panel. he Level Path is fully pipelined with no buering. As shown in gure 4, channels which correspond to the two HCAL depths in a single HCAL tower will be added together into a 7-bit data word and passed through a Level \lter" which will determine what energy to be associated with what beam crossing, producing a 6-bit word. he lter will implement ascheme involving the energy in ve consecutive buckets. he most likely scheme will involve adding the energy in the 5 towers A, B, C, D, and E with the weights such that the output will be given by Output = :0 (A + B + C) ; :5 (D + E) thus integrating over the three buckets which had real energy, subtracting any common baseline. We plan to implement this lter using an FPGA, since these weights involve only factors of 2. he resultant 6 bits of data is then assigned to a particular crossing (maintaining the pipeline). A \muon bit", the result of a window calculation for the presence of a muon, is then produced and added to the data as a \feature bit". he 6 bit HCAL tower energy is then subject to a truncation and overow calculation, eliminating 6 bits, and then sent through a non-linear transformation further reducing the tower energy to 8 bits. Along with the feature bit, these bits are combined with bits of data from another tower and merged into a 24 bit Level format for transmission. As detailed in table 2, the 24 bits of Level data will include bits each from2towers, plus 5 bits of Hamming code for error recovery, plus an addition bit signifying the abort gap. Level 2/DAQ Path 5

6 ChA data ChA error Ch2A data Ch2A error 6 6 SUM or Error (FPGA) 7 ChA data n(=5?)-bucket memory Level "Filter" 6 ChB data ChB error Ch2B data Ch2B error 6 6 SUM or Error (FPGA) 7 ChB data Level "Filter" 6 ChA data Muon Window 6 Feature bit Feature bit Overflow & truncation 0 Non-linear 8 Xform Level Formatter 24 8 bits tower E feature bit tower 8 bits tower2 E feature bit tower2 5 bits Hamming abort gap flag Level Framework ChB data Muon Window Overflow 6 0 & Non-linear 8 truncation Xform Crossing Crossing SYNC ASIC histogramming to check bunch structure Figure 4: HR Level Path. As mentioned above, all data enters both the Level and Level 2 /DAQ paths in parallel, and data consists of 6 bits HCAL energy and 2 bits for cap and frame errors. Figure 5 shows a schematic of the Level 2/DAQ path. Data is rst put into RAM awaiting a Level decision from the Level framework. A decoder will determine from the level answer, beam counter signal, and pipeline delay which data is associated with which level accept, producing a address pointer to the RAM for the HCAL channels. An appropriate set of 0 data values will then be moved into a \derandomizing buer" which serves as a vector buer holding all 0 data values and associating these values with a particular level accept. his buer will have to be able to hold 0 channels of 8 bits each and some number of level accepts. he architecture of the HR card will have all 32 channels' derandomizing buers read out over a common internal data bus, and passed into a Level 2 lter which has the same function as that for Level, with more precision (hence the need for the additional 5 HCAL channels) Level 2 lter constructs the appropriate sum, the data is ready for formatting and sending to Level 2/DAQ. Each of these components are discussed below. 6

7 Purpose Bits ower energy 8 owermuon ag ower 2 energy 8 ower2muon ag Abort gap ag Hamming bits 5 otal 24 able 2: Format for the 24 bits of Level data prepared by the HR cards. Ch data Ch error Ch data Ch error RAM 32 channels total RAM + + "N" data buckets Level Accepts N (+ bits) N (+ bits) L2 Xmit Control ("SUM"s are calculated here) 6 FIFO 6 x DCC Level Framework LA Crossing LA decoder Address pointer 2 Crossings 2 bits 2 derandomizing buffers Consists of6-bit words: Header: Event ID () crossing/"data state" () Data: Data buckets (N 0) SUM from filter () Address/error () Figure 5: HR Level 2/DAQ Path Derandomizing Buer 0..5 Level 2 Filtering As discussed above, the Level 2 ltering is expected to be more precise than that use for Level. he lter will use as its input the values of a single channel for some number of buckets, and combine them into an energy and associate that energy with a particular beam crossing. he lter will have the form: NX Output = i= w i D i where N is the number of channels involved in the sum (e.g. 0), w i corresponds to the weights and D i corresponds to the 6 bit sum in channel i. For instance, for the Level lter, N = 5, w = w2 = w3 = :0 and w4 = w5 = ;:5. A Monte Carlo study will determine the optimum weights and number of channels. Note that we plan to implement this lter using the ECAL ASIC. 7

8 0..6 Status he current eort at Maryland, led by Professor Baden, is concerned with demonstrating the functionality needed by CMS. Specically, since CMS is a fully pipelined front-end trigger and DAQ experiment, it will be up to the Maryland group to demonstrate that the current design will have the capability of accepting data at the prescribed rate, maintaining the pipeline, establishing which data from which bucket belongs to which interaction (at least 8% of the data for the HCAl will be spread over 3 time buckets), producing Level trigger primitives, sending these trigger data to the Level trigger framework, wait for a Level accept or reject, and transmitting accepted data to the data concentrator for a DAQ readout cycle. he Maryland group is also charged with organizing a working readout system for the Summer 200 HCAL source calibration project at FNAL. During these tests the HCAL will be read out at 40MHz for the rst time using the demonstrator system we are building. A pipeline is not necessary for this test, however the front-end and DAQ system will be exercised. At this time (Spring 200) we have produced a rst demonstrator prototype of the HCAL rigger and Readout (HR) card (see gure 6). his card will consist of 8 (out of 32) input channels (2 channels per ber, 2 bers per O-to-E converter, 2 converters) and a large Altera Apex 20k400 FPGA. All CMS timing information, which comesin over the rigger iming Control (C) system will be present on this card, facilitating our learning the CMS C system. All rmware (including VME) will be written here at Maryland by ullio Grassi (lead engineer) and Professor Baden. he HCAL front-end will be emulated using a Front End Emulator (FEE) board designed and built at Maryland (see gure 7). his board provides for fake data (8 bers, which would drive 2 demonstrator boards), output over ber, and all required timing signals. Plans call for the demonstrator system to be integrated by the summer 200, after which we will bring a working system to FNAL for the source tests sometime in late summer. his is a full-time research eort, as we are building a 40MHz pipelined DAQ system from scratch. We will be using a U VIPA VME crate, with a Pentium 3 CPU board running Linux (RedHat or SUSE) which will have VME drivers. We are working on the hardware, rmware for the hardware FPGAs (both cards), and DAQ system with help from UIC and Princeton. he Data Concentrator Card (DCC) is being built by the Boston University group (Professor James Rolf and Eric Hazen) and this card will be integrated into the demonstrator system along with all the other cards. By the fall of 2002, we will have a full-channel production card in progress to meet the ocial CMS HCAL project milestones. Current analysis requires approximately 450 of these cards to be built and delivered to CERN including spares (the number of cards can still change depending on some nal design decisions). References [] Waiting for the FNAL group's DR on the QIE. 8

9

10