Castelo, J

González, V

Martos, J

Sanchis, E

Torralba, G

Torres, J

CERN Document Server

On the developments of the Read Out Driver for the ATLAS Tile Calorimeter.J. Castelo1, V. González2, E. Sanchis2, J. Torres2, G. Torralba2, J. Martos21IFIC, Edificio Institutos de Investigación - Polígono la Coma S/N, Paterna, Valencia, SpainJose.Castelo@ific.uv.es2Dept. Electronic Engineering, Univ. Valencia, Avda. Dr. Moliner, 50, Burjassot (Valencia), SpainVicente.Gonzalez@uv.es, Enrique.Sanchis@uv.es, Jose.Torres@uv.es, Gloria.Torralba@uv.es, Julio.Martos@uv.esAbstractThis works describes the present status and futureevolution of the Read Out Driver for the ATLAS TileCalorimeter. The developments currently under executioninclude the adaptation and test of the LiAr ROD to Tile Calneeds and the design and implementation of the PMC boardfor algorithm testing at ATLAS rates.The adaptation includes a new transition module with 4SLINK inputs and one output which match the initial TileCalsegmentation for RODs. We also describe the work going onin the design of a DSP-based PMC with SLINK input for realtime data processing to be used as a test environment foroptimal filtering.I. INTRODUCTIONAt the European Laboratory for Particle Physics (CERN)in Geneva, a new particle accelerator, the Large HadronCollider (LHC) is presently being constructed. In the year2006 beams of protons are expected to collide at a center ofmass energy of 14 TeV. In parallel to the accelerator, twogeneral purpose detectors, ATLAS and CMS, are beingdeveloped to investigate proton-proton collisions in the newenergy domain and to study fundamental questions of particlephysics .This new generation of detectors requires highly hardenedelectronics, able to deal with a huge amount of data in real oralmost real time. The work we present here is included in thestudies and development currently carried out at theUniversity of Valencia for the Read Out Module (ROD) of thehadronic calorimeter TileCal of ATLAS.II. THE TILECAL ROD SYSTEMTileCal is the hadronic calorimeter of the ATLASexperiments. It consists, electronically speaking, of 10000channel to be read each 25 ns. Data gathered from thesechannels are digitized and transmitted to the data acquisitionsystem (DAQ) following the assertions of a three level triggersystem [1].In the acquisition chain, place is left for a module whichhas to perform preprocessing and gathering on data comingout after a good first level trigger before sending them to thesecond level. This module is called the Read Out Module(ROD).For TileCal, the ROD system will be built most probablyaround custom VME boards which will have to treat around 2Gbytes/s of data. Intelligence will be provided to do somepreprocessing on data.For the reading of the channels we are working on abaseline of 64 ROD modules. Each one will process morethan 300 channels. The studies currently going on at Valenciafocus on the adaptation of the first prototype of the LiArgROD to TileCal needs.The basic schema to use is based on the ROD crateconcept in which ROD modules are grouped into VME cratesjointly with a Trigger and Busy Module (TBM) and possiblyother custom cards when needed. This ROD crate interfaceswith the TileCal Run Control and the ATLAS DAQ Runcontrol. Figure 1 shows this structure schematically [5].Figure 1: TileCal ROD SystemThe basic functions and requirements of all ATLAS RODcan be found in [1] and may be summarize saying that theROD board receives the data from the FEB which after someprocessing are sent to the ROB. These data may be bufferedto be able to work with the maximum LVL1 trigger rate (100KHz) without introducing extra dead time.For each particular detector, some preprocessing could bedone at ROD level. For TileCal, RODs will calculate energyand time for each cell using optimal filtering algorithmsbesides evaluating a quality flag for the pulse shape (χ2).RODs will also do the data monitoring during physics runsand make a first pass in the analysis of the calibration dataleaving the complete analysis to the local CPU of the RODcrate.In some cases data will not be processed and will flow rawto LVL2. These include interesting events, large energydepositions in a cell or debugging stages.It will be also desirable to have the functionality to applycorrections to the energy or time estimators for example tocorrect the non-linearities in the shaper or in the ADC.Finally ROD will monitor the Minimum Bias and pile-upnoise and will have the possibility of working in special runsat reduced trigger rate.III. LIARG ROD AND TILECAL RODAs mentioned before, our work develops now in thedirection of adapting the first LiArg ROD prototype [7] toTileCal needs exposed before. The main reason to do this isthe great similarity of the two detectors and the greatdifference in the requirements which make LiArg solutionssuitable, with modifications, for TileCal.The basic differences in the ROD concept for LiArg andTileCal rise, in a first approximation, in the working baselinewhich is summarized in table 1.Table 1: ROD baseline for LiArg and TileCalROD LiArg ROD TileCalBaselineInput links (32 bits @40 MHz2 4Number of channelsper board256 154(2*64b+2*31eb)Number of DSPProcessing Units4 4Number ofchannels/DSP PU64 46b or 31ebOutput Links (800Mb/s)1 1(1,14 Gb/s, expected)The block diagram of the LiArg ROD prototype is shownin figure 3. It is based in a 9U VME motherboard which holdsfour DSP-based processing units (PU) as mezzanines. Thesemezzanines are based on TI C6202 DSPs at 250 MHz withsome external logic: FIFOs, FPGAs and memory. Figure 2shows the block diagram of the PUs [8].The input and output of data is place on a 9U transitionmodule. For the first prototype this module has only twoinputs and one output.To adapt this solution to TileCal needs we need toreconsider the following aspects:• Data input/output format and rates: we need 4 inputsand one output at the transition module. This impliesa new design of this transition board.• Processing power: because of its great number ofchannels, LiArg DSP PU have a lot more computingpower than needed in TileCal. This issues thequestion of whether it is necessary to use exactly thesame type of PUs or we could use cheaper ones evennot based on DSPs but on FPGAs.Because of the modularity of the LiArg solution, our workfocuses on the design of a new transition module, leaving thedecision about the PU postponed.Figure 2: Block diagram of the DSP Processing Units.IV. THE TM4PLUS1 TRANSITION MODULELets now get into the description of the new design carriedout to adapt TileCal inputs to the LiArg motherboard. Thisnew transition module is called TM4Plus1.O u tp u t t o R O B( S - l i n k , . . . . )I n p u t F r o m F E B( o p t i c a l o r C u )I n p u t F r o m F E B( o p t i c a l o r C u )P 1P 2P 3P 0P 2P 3M o th e r b o a r d T r a n s ie n t M o d u leFigure 3: LiArg ROD prototipeThis module has been developed and implemented at CERNby the EP/ATE group. Its block diagram is shown in figure 4.F2TransceiverF1LedsF3 Ref.AlteraAux.AlteraFifoFifoFifoFifoFigure 4: TM4Plus1 block diagram.The transition module is a modified version of the oneused by LiArg that includes 4 input SLINK channels in PMCformat and 1 GLINK output integrated in the PCB. The PMCinput channels are capable of reading 4x32 bits at 40 MHzand allow us to test different input technologies. The outputwill also run at 40 MHz with a data width of 32 bits [4] [6].On the board there are also 4 input FIFOs, 4Kwords each,to accommodate the differences between input speed andprocessing on the FPGAs.These lasts are implemented on two ALTERA devices.The tasks of each of the FPGAs are:• Reformatting Altera: data multiplexing and SLINKcontrol. This devices will reformat and merge data ina 4 to 2 manner to produce data similar to what themotherboard is expecting if used with LiArg detector.• Auxiliary Altera: it holds the code for the integratedODIN output. The free space left will be used inconjunction with the reformatting Altera.The data flow to these FPGAs is shown in figure 5.Following the tasks division the reformatting Altera receivesthe data from the 4 input channels to perform the 4 to 2multiplexing. Data is sent to the motherboard through P2connector on the VME backplane with the same format asLiArg.Signal mappingReformattingAltera(247pins)(+10conf.pins)AuxiliaryAltera(243+10pins)J2AUTDO, UDW0/1,URL[3..0] 739bufferCLK34*2*7*bufferCLKG-LINKcorner4568 Signals tothe G-LINKJ2BJ3AJ3B4*397UTDO, UDW0/1,URL[3..0]LD, UXOFF, URESET,LCTRL, LWEN, LCLK,LDERR, LDOWNUD, LFF, URESET, UTEST, UDW0/1, UCTRL,UWEN, UCLK, LRL[3..0], LDOWN, RSVD**LD[0..31], LCTRL, LDERRREADEN, EMPTY,FULL, UXOFFURESET,LDOWNFIFO AS-LINK A395*: these lines count 4 times, onefor each S_LINK or FIFO.**: LSC and LDC signals defined in the S-LINK specifications;3 BUSM, FWFT,MRESET*Same lines toFIFO B, C, DUTDO, UDW0/1,URL[3..0]ConfigurationPins104Figure 5: Data flow on the TM4Plus1.The other Altera receives some lines from the first andhold the ODIN output code. Data once processed at themotherboard is sent through P3 connector to this FPGA to besent to ROBs.The basic data processing on the reformatting Alterarelates to the forma conversion between TileCal and LiArg.Fortunately, front-end data format on both detectors is quitesimilar and we have to deal only with a data width problem.This problem is due to the fact that on the motherboard, the32-bit path of P2 connector is splitted into two 16-bit pathseach one going to a PU. For TileCal with have 32-bit pathsalready in the front-end data, so we have to divide these datainto 16-bit blocks and send them consecutively to themotherboard.There is also a problem with data control due to the waythe LiArg motherboard controls the data flow. Situations mayarise when we could have data only on one of the two inputprovided to first check if this occurs and second to solve it.Our proposal implements a time-out activated on thearrival of the first data on one of the input links to bemultiplexed. If after the time out no data are received, thespace for that channel is filled with zeros and a flag is set onthe header to let the PU treat these data as no-data instead ofzeroes.These two processes are depicted schematically in figure6.ABDC11ALTERACADB 11TimeSLINK-1SLINK-215ABDCALTERA0A0BTimeSLINK-1SLINK-2delayData multiplexing Data present on linksFigure 6: Data multiplexing using FPGAsV. PRESENT DEVELOPMENTSAt IFIC and University of Valencia there are threedevelopment fronts undergoing.The main is related with the tests and developments for theTM4Plus1 board and the final ROD prototype, the secondgoes towards the design and implementation of a PMC cardfor algorithm tests and the third deals with the software issuesat the ROD controller.Lets review now the current status on each of thesedirections.A. The TM4Plus1 board and final RODprototypeThe tasks on the TM4Plus1 board currently going on areof two kinds:Hardware:•Test of motherboard and PUs. This is already finished.•Test of the TM4Plus1 transition module: not yetfinished.•Design of a custom FPGA based PU: starting.Software:•TM4Plus1 FPGAs: going on. This work refers to theimplementation of the processing commented before on thetwo Alteras•PUs: we need to reprogram the DSPs to do optimalfiltering and also the input FPGA.For the final ROD prototype we are currently designing anew PU based on FPGA instead of DSPs. These will imply areduction in cost, because the DSP PU are the most expensivecomponent in the LiArg ROD, and an increase on parallelismas we will not be limited by the DSP architecture but by theFPGA capacity. Our working block diagram for a finalTileCal ROD prototype is shown in next figure.Transition ModuleAuxiliary Altera (APEX 20k)SLINKControlIntegrated G-LINKEnergy & timecalculation unit "x"Energy & timecalculation uni "y"EnergyFragmentBuilder J2BLVL2 DataReformatting Altera (APEX 20k)BCID, TtypeextractionEnergy & timecalculation unit "m"Energy & timecalculation uni "n"EnergyFragmentBuilder J2AParoty, CRC &data alignmentCHECKFIFO/SLINK ControlS2PROD MotherboardProcessing Unit (PFGA Unit)Ttype &BCIDCheckTtype&BCIDFIFOFragment FIFOProcessing Unit (PFGA Unit)Ttype &BCIDCheckTtype&BCIDFIFOFragment FIFO P1P2P3J2A---J2BJ3FEB DataS-LINK A - LDCS-LINK B - LDCS-LINK C - LDCS-LINK D - LDCFIFOFIFOFIFOFIFOProcessing Unit SlotNot USEDOutputControllerProcessing Unit SlotNot USEDVMECommTTC FPGA & TTCrxFigure 7: Final TileCal ROD prototype.As it can be seen we keep the LiArg motherboard to haveVME access and the TM4Plus1 board, but substitute the DSPPUs by new FPGA based ones. Also a redistribution of tasksoccurs, placing almost all processing issues on the FPGAs ofthe transition module where energy an timing estimation willtake place. On the motherboard only data integrity checkingand TTC operation will be done.By processing data on the transition module we reducedata volume flowing to the motherboard. This opens thepossibility of increasing the number of input channels on thetransition module by previously integrating them on the PCB(no more PMCs).B. The SLink PMC cardParallel to these activities we are also involved in thedesign and development of the DSP based PMC card withSLINK input for testing the optimal filtering algorithms on acommercial VME processor.The basic idea is to have a PMC with SLINK inputcapability and with some intelligence deployed on a FPGAand a TI 6X DSP [2]. We are currently working on thefollowing block diagram.S-LINKinterfacePCI interfaceFIFO EMIFMcBSP1 McBSP0PCIinterfaceBCIDLook up tableCPUInterfaceS-LINKData reordeningBCID checkingFPGA XILINX TEXAS INSTRUMENTSBCIDL1 IDBCIDFigure 8: PMC block diagram.For the DSP we are currently designing for theTMS320C6205 which includes a PCI interface that save usthe task of implement this interface on a FPGA. For theFPGA we are designing with XILINX X2CS100 device.The DSP will load TTC data (BCID, EventID and TriggerType) using two serial channels to make the data integrityoperation and output data formatting, while the FPGA willtake care of the SLINK interface, data reordering, BCIDsequence check and the EMIF communication with the DSP.C. The ROD ControllerActivity in this field is focuses on the adaptation of theLiArg ROD software libraries to the setup at Valencia basedon a BIT3 VME-PC interface as ROD controller and theTileCal ROD integration with DAQ-1.The adaptation of the LiArg libraries is already finishedand has required some effort on the driver side. For the DAQ-1 integration the work foreseen is the development of theLocal ROD VME software, the online software and ROSdataflow. We expect to start this work very soon.VI. REFERENCES[1] ATLAS Trigger and DAQ steering group, “Trigger and Daq Interfaceswith FE systems: Requirement document. Version 2.0”, DAQ-NO-103,1998.[2] TEXAS INSTRUMENTS, “TMS320C6205 Data sheet,” ApplicationReport SPRS106, October 1999[3] K. Castille, "TMS320C6000 EMIF to external FIFO interface,"Application Report SPRA543, May 1999[4] J. Dowell, M. Pearce “ATLAS front-end read-out link requirements,”ATLAS internal note, ATLAS-ELEC---1, July 1998[5] C. Bee, O. Boyle, D. Francis, L. Mapelli, R. MacLaren, G. Mornacchi,J. Petersen, “The event formatr in the ATLAS DAQ/EF prototype-1,”Note number 050, version 1.5, October 1998[6] O. Boyle, R. McLaren, E. van der Bij, “The S-LINK interfacespecification,” ECP division CERN, March 1997[7] The LArgon ROD working group, “The ROD Demonstrator Board forthe LArgon Calorimeter”[8] S. Böttcher, J. Parsons, S. Simion, W. Sippach “The DSP 6202processor board for ATLAS calorimeter”

On the developments of the Read Out Driver for the ATLAS Tile Calorimeter

Abstract

Similar works

Full text

Available Versions

CERN Document Server