The ATLAS Level-1 Calorimeter Trigger

Minutes from the ATLAS-UK Level-1 Calorimeter Trigger Meeting

Thursday, May 11 2000 at 10 am,  RAL Conference Room 4 R27 (Atlas Centre)

Present: Eric Eisenhandler (EE), Reg Gibson (RG), Murrough Landon (ML), Ed Moyse (EM), [QMW]; George Anagnostou (GA), Paul Bright-Thomas (PBT), John Garvey (JG), Simon Pyatt (SP), Richard Staley (RS), Scott Talbot (ST), Alan Watson (AW), Peter Watkins (PW), [Birmingham]; Bruce Barnett (BMB), Ian Brawn (IB), James Edwards (JE), Norman Gee (NG), Tony Gillman (TG), Viraj Perera (VP), Azmat Shah (AS), Tara Shah (TS) [RAL].

Minutes generated by BMB

Agenda

Data Transmission

Hardware status summaries

Serialiser Ian

Ian showed a pin-out for the FG680, a larger device for use with the generic test board. The pin-out, although very preliminary, demonstrates that he can generate a sensible pin-out which separates inputs and outputs to different sides of the device. The simulation works at 160MHz, up to a maximum of 172 MHz. The design of the serialiser is essentially complete, with the final pin-out amongst the items that still needs to be decided.

Discussion: JG asked about the time-scale. Ian replied probably 3^rd quarter 2000: late summer. VP commented that the design, though, has not yet been signed off.
 

CP "chip" Viraj

Viraj commented that the specification has been updated, in particular having to do with a number of items pertaining to mask register definitions, reflecting the PDR. The co-ordinate system needs to be adapted to conform to PBT’s specification. An updated specification should be available within a couple of weeks.

Discussion: TG enquired as to design work. Viraj commented that Ian is doing some work on front end, BC de-multiplexing, readout and scan-path functionalities.

CP Module prototype Richard

Richard stated that the ‘dust was settling’ a little on the back-plane design. He is expecting comments back from Sam on the VME pin-out.

Discussion: TG commented that July is the desired time-scale for convergence, since the PDR is planned for July 10^th. NG mentioned that the design review doesn’t need all the detail in order to proceed. TG asked what else for the prototype needed finalising. Richard commented that some aspects of readout control needed finishing.

ROD prototype James

James stated that the ROD had been handed to the drawing office in the first week of April, essentially according to schedule, and that a mini design review had been completed. However drawing office difficulties stemming from their software upgrading of Cadence has blocked all progress on the project. Software patches to cure the problem have not been successful. This translates into a minimum 6 weeks loss of time for this and other projects (eg: the generic test module).

Discussion: There was much unhappiness that again the drawing office has, through questionable software maintenance policy, delayed a project significantly without at the very least keeping the responsibles (TG, NG …) informed. PW asked what feedback mechanism existed and was told that is was essentially oral. ML inquired why it hadn’t been decided to use the older s/w version in order to avoid delaying progress. The disadvantage of the way the s/w support proceeds (Euro-practice support through Paul Hardy) was mentioned as a source of delay, itself. PBT inquired whether it would be possible to use a commercial office. RS suggested there are not very many alternatives. JG suggested CERN. It was noted that the delays are not crucial but… JG asked about the policy concerning going outside for the work. Complicated boards need frequent contact in-house. Small boards are easier, but still stay in-house. Some (Richard Stevenson) send work outside frequently. NG questioned whether the low priority afforded Euro-practice support clients doesn’t negate the advantage of low cost.

Timing Control Module Bob

Norman commented, on behalf of Bob, who wasn’t present. An outline spec. exists, including VME display.

Discussion: TG stated that 3 TTC decoder cards were to be assembled with TTCrx chips from CERN (availability: 2-3 weeks). The TCM design allows use in all required crates, by use of personality cards.

Common Merger Module Norman

Norman presented the current status of the CMM, discussing aspects of the system and crate merging. His transparencies show the block functionality for each of these, which in both cases is now divided into forward and non-forward parts. Also, forward and backward modules (1,8,9,16) can now be handled independently. In the crate merging of jet hits, the forward hit information is routed for merging with the non-forward part with zero latency. In each of the forward and backward cases, the addends go to 4 separate 2-input 2-bit adders. If one assumes 4 thresholds and a maximum of 3 FCAL hits one arrives at 16 additional bits to be provided to CTP. At this time, the decision as to how many of which bits go to conventional or forward thresholding has not been made: the exact definition is determined at the point of FPGA download.

Discussion: Several additional comments (ML, EE, PBT) questioning the ability of CTP to make good use of this number of addition jet hit bits were made. The suggestion was to lay traces for these bits, and then assume that an appropriate subset is to be selected by the CTP patch-panel. PW noted the use of L/R in Norman’s diagrams. The ATLAS convention is supposedly A/C for Anti-clockwise and clockwise, but the correct convention should be checked. EE suggested that Norman should mention to R. Spiwoks the number of bits that might be provided to gauge the reaction. ML asked as to the nature of the patch-panel (physical or some kind of zero-latency router): EE thinks this is just a cable patch-panel.

Back-plane, connectors and cables Richard

Richard commented briefly. There are no big changes, with a couple of proposed versions of back-plane design existing. Sam is working on it. The most recent design is the most compact physically (but dropped some pins it shouldn’t have). A number of pins have been recovered, so that only one custom type connector (B19) is required. Geographical addressing pins are available, shielding rules are observed and the guide pins are now adequate.

VME—specification Norman

The specification has been on the web for some time now. The list of pins has been established, and the precise use of the geographical addressing pins needs to be defined. 49 pins are required (excluding power and ground) including 6 geographical addressing pins. Careful use of the VME data strobes has resulted in part of the additional savings.

Norman commented that VME64 specifies the use of physical keys to force certain modules to be slot specific. The question as to whether this is compatible with the standard CERN crate was raised (TG): Chris Parkman should be consulted.

The following pins are used in the reduced-VME:

• 39 Address/Data
• 6 Geographical Addressing
• 1 strobe
• 1 dtack
• 1 write
• 1 reset

The reset line is most likely to be under the control of the TCM.

Discussion: PBT commented that Sam should take care that the grouping of traces and pins for module interconnect satisfies the required topology (groups of 16). Regarding the time-scale for the back-plane Norman mentioned (as previously noted) July.

Schedule and reviews update Tony

Tony summarised the status of anticipated hardware reviews and commented on the system test strategy.

• Tony pointed out that an FDR for the PPr ASIC is needed. Technically a PRR is also demanded, but the hopes are to avoid this by having a one of the reviewers being a representative of the ATLAS technical team. This review should take place in early June. The proposed names are H. van der Bij, PBT, Magnus Engstrom and VP. The appropriate scope will be discussed with Philippe Farthouat.
• The CPM prototype PDR is scheduled for 10 July, just after the QMW meeting. Reviewers are BMB, Paul Hanke, VP and Uli Schaefer. The review will be held at RAL or Birmingham, to be coupled with the JEM prototype PDR.  Documentation should be on the web by June 23^rd.
• For the JEM prototype, a PDR is to be held at RAL on July 11^th. Proposed reviewers are PBT, NG, Paul Hanke and RS. Documentation is to be on the web by June 23^rd.
• The CP/JEP back-plane PDR is anticipated for September 2000 (Stockholm). Reviewers will be NG, Paul Hanke, VP and RS.
• CMM prototype PDR is to be held in August/September 2000. Proposed reviewers EE, Uli Schaefer, Sam Silverstein and RS.
• PPM Module-0 requires a PDR, to be held in Heidelberg in October 2000. Proposed reviewers are BMB, PBT, Uli Schaefer and RS.

Regarding system tests, the strategy was outlined. Tony proposed that stage 1 tests could be carried out at the home institutes. These tests would involve hardware designed at these institutes. Stage 2, "Full Slice" tests should be carried out at a single institute. A number of arguments have been put forward in favour of RAL/Birmingham or Heidelberg and each is strong in its own way. One proposal is to perform these tests initially at Heidelberg where a good analogue source is available and then transfer them to RAL for Level-2 integration studies.

Discussion: NG commented that the duration of the stage 2 tests (possibly several months) will require a specific source of travel funding. Norman has made application for this. Concerning the later tests incorporating the RoI builder, the precise programme can be specified when the hardware is closer to being available

EE commented that some redefinition of PRRs may be necessary in order to accommodate the now large number of modules shared between the sub-systems. JG asked about time-scale. The stage 2 tests are anticipated for June/July 2001. NG pointed out that the common stage 2 tests presupposed preliminary integration and debugging in the UK [as is supposedly the case for other elements in the full slice tests] prior to transport. JG addressed the question how crucial the level-2 tests were. NG pointed out that a significant part of the present level-2 test-farm would still be available and he had understood that the RoI builder can be brought on request.

Decisions concerning the location(s) of the stage 2 tests will be made at the QMW joint meeting.

A short discussion on the longer term commissioning issue and location was pursued: there are some constraints concerning the optimisation of effort. EE thought it important to distinguish between commissioning and prototype testing. A pre-assembly at CERN, other than in USA-15, would require lab space (always a premium), and consume travel funds. Some offline thought is required to find the best overall approach.

Online software

Heidelberg diagnostic software evolution Murrough

Murrough outlined the status of HDMC. A new version of the software is available, with many improvements or the frameworks for the same. Cornelius is at the moment very busy with h/w work and V. Schatz is doing his diploma. Some progress on the implementation of module views has been made. Murrough has completed a facility for the automatic generation of register classes. Software meetings are taking place about once a fortnight, with the occasional use of video conferencing being deemed successful.

DAQ software and DAQ –1 Bruce

Bruce spoke briefly on the progress of work with the new level-1 DAQ. He outlined the relationship between various components of the new DAQ, which is to be largely based on services provided by DAQ-1. Initially, the old buffer manager will be maintained for sharing of events, and the old database will be maintained for the provision and recording of module set-up and configuration information. Eventually, even that will be replaced by the DAQ-1 Information Service (IS).

Bruce and Norman have moved the RAL installation of DAQ-1 to the newest version of that software (008). This has required some database changes (in the DB controlling process management) as well as environment variable re-definitions and local code fixes. The DAQ-1 process manager can be used to start an xterm controlling the ‘old’ database, to allow its use in the integrated environment.

DAQ work planning Norman

Norman displayed a Gant chart illustrating the tasks to be addressed in the construction of the new DAQ, along with their critical relationships. The chart emphasises the need for efficient use of the available effort. The chart illustrates, as well, the difficulty anticipated in meeting an early June target date corresponding to the ROD arrival that had been expected: at least until the announcement of the new drawing office delays.

Use of ROOT in DAQ analysis Tara

Tara presented an overview of ROOT in the DAQ. ROOT provides a framework of proven software on top of which rapid prototyping can proceed. Designed with HEP in mind, it provides a large number of useful classes, tools such as object browsers and thereby an efficient basis for moving from an old DAQ based on an old paradigm to an OO world. Tara presented sample GUI and histogram displays.

Discussion: Bruce asked about the NT support status, realising that with a large installed base of such machines at RAL an integrated system might be useful. NT seems now to lag behind the mainstream developments in ROOT [probably partly because of the renewed enthusiasm for Linux within the HEP community], but support and active interest does exist within the ROOT community.

Trigger simulation

Conversion of simulation to OO Ed

Ed summarised some ideas that had emerged, at least in part, from an informal meeting between QMW and Birmingham members (ML, EM, AW,) concerned with moving the trigger simulation into the new ATLAS OO framework that is just emerging. Ed presented requirements (Critical and Useful) for the implementation as well as a preliminary diagram illustrating the main EM/Tau trigger entity relationships.

Discussion: NG questioned whether the event format, as it emerges from the s-links, is to be reproduced. AW commented that a discussion of how ‘online’ the simulation should be did arise. All data will be produced, but not all details will be simulated: the goal is physics performance understanding [not necessarily the generation of test vectors]. In any case, methods can be provided to reformat data as necessary.

NG asked where the thinking was going in the direction of event definition. AW answered that as the new ATLAS candidate framework is only just being demonstrated, it is too early to say what parts of that framework might be useful at which trigger level. The filter people, in any case, are already trying to understand this question in the light of their own work at this time.

The question of whether the simulation shouldn’t adhere closely to the hardware/module model was asked. AW maintained that this wasn’t strictly necessary. If you need to understand dead areas in the detectors it may not be at the level of the hardware that the problems should be marked. TS remarked that these questions also have to do with the question of granularity in the simulation: whether you need intermediate results or not. NG added that settings in the h/w are done run-by-run: module level simulation allows reproduction in the h/w world of the effects of parameter changes. PBT reminded the group that in the area of BCID simulation Ullrich Pfeiffer has already done an OO simulation: this work should be incorporated if possible.

Out of the rut

How well does OO work online and offline in BaBar? Alan/Paul

Paul made a presentation on behalf of Alan and himself containing their assessment of the success achieved by the Babar OO approach. This started with an overview of the BaBar

experiment and the current running status. To date, BaBar has assembled the world’s largest OO database (130 Tbyte, or about an eighth of ATLAS yearly data yield). He described the Babar environment, supporting a number of UNIX flavours: the selection is marshalled

by the availability of commercial tools. A note is that BaBar has been forced to deprecate support on at least one platform (HPUX) due to the cessation of specific tool support. Many good tools, though, are in use to facilitate development, some public domain and others commercial. Of note are several tools for maintaining high software quality (eg: Purify which catches memory access errors or memory leaks).

The AFS basis upon which BaBar is founded causes many problems and some lessons (such as separation of the objectivity database by federation according to function) have had to be learned in handling OO databases. The OO framework itself has proven particularly powerful in cases where experienced individuals had time to develop good designs, but much of the software suffers from the demands for a rapid development cycle. This said, the software is becoming mature enough to use without fear of updates, although the lack of adequate documentation hinders the newcomer. There is a resultant tendency for some to become disenfranchised from the code development process, in a way that is not necessarily healthy.

The necessarily high design/testing/documentation overhead in OO code development was mentioned, but it was not clear how to deal with this in the face of effort limitations.

Paul commented that the online OO work suffered particularly from effort limitations. This said, the online prompt reconstruction is better documented than most code.

Discussion: TS noted that the best user documentation is usually written by users, anyway, but the technical reference manuals do need to be there [also in order that the user docs be be written consistently.] NG asked about interactive development environments (IDEs). None other than the standard UNIX tools is in use. BMB mentioned a commercial product "Sniff++" that he believed had been used at CERN in some of their OO development work.

Other short items

Co-ordinates & nomenclature Paul

Paul commented briefly. Before proceeding with the work reported at the Mainz meeting, Paul needs additional information to arrive concerning the implementation of the Pre-processor system, in particular about the way that EM and hadronic calorimetry signals are mixed within the system. He noted that J. Thomas is trying to use the convention for his labelling scheme on the JEM layout. A document will appear on the web.

Discussion: ML expressed some surprise that there is some signal mixing. In any case the situation should be clarified shortly.

Spares policy update Norman

Norman has updated the information on the web to reflect the input from the discussion at the Mainz meeting. In the context of FPGAs, the document now requires an extra 25% contingency for all BGA components. Module spares: 10%. Power Supplies: 4 working supplies required as spares. If Chris Parkman arrives at a solution for spares (with appropriate supply levels/specs) having the scope of global ATLAS needs this should be included in the planning.

In terms of costing, the agreement arrived at in Mainz is that the CMM is a shared item, with institute contributions proportional to use. New JEM costing is included. The newly-updated pre-processor costing has not yet been included.

Trigger/DAQ reorganisation status Eric

This was discussed at some length. The project leader nominations closed at the end of March and there is currently one nominee under consideration (A. Lankford). The Trigger/DAQ community is eager for a resolution to the question and there is expected to be some movement (and hopefully convergence) by the time of the next IB, currently sheduled for June 13^th.

Status of ATLAS notes

   There are four notes in various stages of completion:

• RS: submitted and is now a note
• AW: A draft. It will be submitted as a communication for response, then eventually as a note. It emerged that the draft did not reach some people. Alan will re-send it to the mailing list, and submission will be deferred slightly to allow comment.
• PBT: The note needs some alterations. It should be out for comment the week of 16 May. There is a draft available at his web site.
• EE: His notes on configuration parameters are to be fleshed out and submitted. He awaits comments on the work.

LEB and IEEE papers for 2000: summary Eric

There are 4 papers in total, with abstracts and summaries available on the level-1 web page. The LVDS paper contains the full author list. Papers from Heidelberg (reduced author list) address the topics of MCM, Pre-processor ASIC and HDMC.

Discussion: PBT inquired whether the submission cycle should be considered soon for the round next year. EE thought yes, especially as there is expected to be much available for presentation then.

News system Paul

Paul commented that a basic hyper-news set-up has been set up at Birmingham.

 

ATLAS overview week in Dubna Eric
 

Two representatives from level-1 will go. PBT will prepare a pedagogical talk of length 15 minutes for presentation at the Trigger/DAQ plenary session. EE commented that the level of attendance at this, the first such meeting outside of CERN (and that an overview week), is disappointing.

Joint meeting at QMW Eric

The next level-1 calorimeter joint-meeting is to be held July 6-8 at QMW. Wednesday, 5^th July should be reserved for a possible brainstorming meeting. Accommodation will be on campus, with a registration form to appear shortly on the web. Cost will be 30-odd pounds per night, including breakfast and some contingency. As the accommodation is not a hotel as such, the cost depends on block booking, and hence an early response is requested.

Discussion: With review meetings in the UK the week after, it was considered whether some bookings over Sunday night might be necessary. Any suggestions of good eateries are encouraged.

LHCC Review of ATLAS Eric

Cashmore has reorganised the format to consist of a single large review per year. The review is scheduled to take place July 3^rd and 4^th (Monday and Tuesday) with the TDAQ contribution to be a 1 ½ hour stint on Tuesday morning. The exact arrangements (who should attend, etc.) need to be decided. As the last review was just 9 months ago there are few big changes, but the importance of this one should not, even in view of that, be underestimated. This session is closed, with an open session taking place a couple of days later.

Any other business

None.

Dates of next meetings

• RAL, 15 June, R1-Conference Room 2
• Tentative. 27 July

This page was last updated on 16 December, 2013
Comments and requests for clarification may be sent to
E-mail:
Telephone: