University of Oxford Department of Physics. Interim Report

Transcription

1 University of Oxford Department of Physics Interim Report Project Name: Project Code: Group: Version: Atlas Binary Chip (ABC ) NP-ATL-ROD-ABCDEC1 ATLAS DRAFT Date: 04 February 1998 Distribution List: A. Grillo UCSC D. Cambell RAL S. Cooper M. Goodrich Cambridge N. Kundu A. J. Lankford UCI G. Myatt G. Noyes RAL R. Nickerson A. Parker Cambridge A. Segar P. Shield R. L. Wastie A. R. Weidberg Additional copies may be obtained from S. Geddes (s.geddes1@physics.ox.ac.uk) 1 of 8

2 1.0 Related projects and documents 1.1 Projects NP-ATL-ROD-ABCDEC1-001-RPT NP-ATL-FEE-ABCRDOT ABC readout Oxford University NP-ATL-ROD-BIPHALD BiLED Oxford University NP-ATL-ROD-ABCDEC1 ABC decoder Oxford University 1.2 Documents [1] ABC (Atlas Binary Chip) Project Specification, D. Campbell, RAL, web page:- [2] SCT Off-Detector Electronics Requirements Document, A. J. Lankford, UCI, web page:- [3] NP-ATL-FEE-ABCRDOT-001-RPD, ABC Readout Report, N. Kundu, Oxford. [4] DORIC, A Front End Clock and L1 Distribution Chip, J. R. Gorbold and P. Seller. [5] DORIC (Digital Opto-Receiver Integrated Circuit) Project Specification, D. J. White, RAL. [6] LDC (LED Driver Circuit) Project Specification, D. J. White, RAL. [7] Trigger-DAQ Steering Group Requirement Document, web page: - [8] N-ATL-ROD-BLD-001-PRS, Biphase Mark Encoder and LED Drive Control Chip, R.L.Wastie, Oxford University. [9] Digital Readout Chip for Silicon Strip Detectors at SDC, K. Shankar, RAL, N. Kundu, Oxford. [10] NP-ATL-ROD-ABCDEC1-001-PRS, Atlas Binary Chip (ABC ) Project Specification, R.L.Wastie, Oxford University. 2.0 Introduction This document describes a ROD ABC based on one chip. This chip would be implemented with an FPGA or a cell based ASIC design. As shown in the ROD Data Paths ( page 7 ), a ROD would consist of four ABC ASICs each with it own external buffer (Buffer 1). These four buffers are read by one Event Builder which assembles whole events into an external buffer (Buffer2) supplying a 1Gbit/s ROD-ROB link (delivering event data to a ROB). There is a Host CPU for control, monitoring and various other housekeeping tasks. The ABC receives eight serial links form the front-end modules, decodes the data, check and handling various data errors and building the event fragments for each channel. These fragments are stored in chip/strip order in the external buffer (Buffer 1). 2 of 8

3 3.0 ROD Model 3.1 Physics Model The physics data was take from the TDR. Several assumptions have been made about the data, which are listed as follows: - The occupancy in the silicon detector is 2% (1% TDR) with a Poisson distribution to allow for fluctuations and to allow for any error in the Monte Carlo simulations. The distribution of strips hit in the module is assumed to be uniform with 50% of the hits having neighbours. The strip hit distribution don t affect the data rate. The L1 trigger rate is 100 khz with a exponential distribution of interval time. The decoder must not be the limiting factor in the data flow. That is it must take data at 40 Mbits/s or approx. 19 hits with 50% neighbours per L1 accept continues at 100 khz average trigger rate. Figure 1 shows the L1 trigger interval distribution with 10 6 L1 triggers 10s of LHC real-time. Figure 2 shows the distribution of the number of hits per trigger for the same simulation. The model generates data for one ABC module which is fed into all eight decoder channels. Figure 1 Distribution of L1 triggers Number of trigger 6000 Series Interval time us 3 of 8

4 Figure 2 Hit Distribution The mean is 23 hits per trigger Series Model Data Number of Hits per trigger The ADC model can handle all the physics data types and all the ABC error codes. The configuration data is not included yet. The data is written into the output buffer (buffer 0) as -bit words. The data format is as Table 1. If there is an odd number of hits the 2 nd hit will be padded by zeros. Each block of data for an event (L1 accept) is written in the buffer with a header word at the beginning which contains the trigger information. At the end of the event a trailer word is written into the buffer as shown in Table 2. This format allows for a variable number of hits to be identified in the buffer. There can be several events in the buffer. This is an intermediate data format used by the event builder. 4 of 8

5 Table 1 Packet Hit data Chip Strip Hit data Chip Strip type addesss address addesss address [31:28] [27:25] [24:21] [20:14] [13:11] [10:7] [6:0] tttt ddd cccc sssssss ddd cccc sssssss nd hit data 1 st hit data Table 2 Packet L1ID BCID type LLLL bbbbbbbbbbbb Header Word Trailer Word Errors Error handling is implemented in the model in a limited fashion. One or many errors can be selected to be counted in one error counter. The counter can be masked to count only selected errors if required. Errors are also written into a buffer, but that is as far as this implementation is modeled. I need to know from the wider ATLAS community what error information is need at the ROB/DAQ level. Buffers The results of the simulation show that the buffers sizes are relatively small. Buffer Zero the internal buffer in the decoder would have a depth of 2 by bits for each channel. Buffer One the buffer between the decoder and the event builder would have a depth of 416 by bits for each channel. Buffer One would have to be implemented as 512 x bits. Data is read from buffer zero for each decoder channel in turn starting with channel one. When channel eight has been read out there is a delay equivalent to the readout time of 24 decoder channels. This was done to simulate the event builder handling decoder channels. L1 & BC The checking of the L1ID and BCID would best be implemented in the event builder. I came to this conclusion from evaluating the first decoder architecture. In that architecture the check was implemented for each receiver channel (module). This 5 of 8

6 required that each channel needed a LIID/BCID buffer, consequently this made the design much larger that the second approach. 4.0 Model simulation results Total number of L1 Accepts Total number of Hits Average hits 23 b Maximum hits per trigger 66 Number of errors a Maximun nuber of L1 s waiting 16 Maximum words in Buffer Zero 2 Maximum words in Buffer One Channel Max Words Note a These errors are ABC buffer overflow errors. This happens when the number of triggers in the ABC event FIFO exceeds eight. This number of errors is a 0.51% data loss. Note b This is an occupancy of 3%. 5.0 Further work Module To improve the model the module data would have to be generated for each decoder channel separately and with different data. The issue of the error data needs to be addressed, where and what to do with the error data. There needs to be a global look at errors, and where they are processed. Some errors could be better handled in the event builder or somewhere else. Then the error handling can have a more complete implementation. Event Builder 6 of 8

7 The formatting of the event packets to the slink is still to be implemented. The amount of data to the slink is far to high, data compression encoding schemes to reduce the data to an acceptable level will need to be investigated. 5.0 Document Control All documentation will be archived according to the ATLAS Document Management Protocol. All documents will be kept for the lifetime of the ATLAS experiment. 7 of 8

8 ROD Data Paths Slink Fibre Tx 1Gb/s Fibre to ROB For Local Data readout during Barrel testing. Host Bus: Event Builder Setup Trigger Type Module ID Control Status Error Statistics Errors Derandomizing FIFO Kx EVENT BUILDER Buffer 2 L1ID BCID Data WR1 RD0 RD1 BCR VME Host CPU Buffer 1 WR1 0 WR1 1 WR1 2 WR1 3 DUAL PORT DUAL PORT DUAL PORT DUAL PORT RAM RD1 RAM RD1 RAM RD1 RAM RD1 4Kx 4Kx 4Kx 4Kx 4 16 Host Bus: s Setup Channel Masking Control Status Error Statistics Errors 0 ABC 8 of 8 1 ABC RD0 2 ABC RD0 A RD0 RD0 3 ABC 8 Links 8 Links 8 Links 8 Links Buffer 0