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
Minutes of previous meeting
LVDS test results with TTC clock Richard 10'
TileCal trigger cables Paul 5'
Hardware status summaries
Serialiser Ian 10'
CP "chip" Viraj 10'
CP Module prototype Richard 10'
ROD prototype James 10'
Timing Control Module Bob 10'
Common Merger Module Norman 10'
Backplane, connectors and cables Richard 10'
VME-- specification Norman 10'
Schedule and reviews update Tony 10'
Heidelberg diagnostic software evolution
Work on DAQ software and DAQ -1 Bruce/Norman 10'
Use of ROOT in DAQ analysis Tara 10'
Conversion of simulation to OO Ed 5'
Out of the rut
How well does OO work online and offline in
BaBar? Alan/Paul 15'
Other short items
Coordinates & nomenclature Paul 10'
Spares policy update Norman 10'
Trigger/DAQ reorganisation status Eric 5'
Status of ATLAS notes Eric/Alan/Paul/Richard 5'
LEB and IEEE papers for 2000: summary Eric 5'
News system Paul 5'
ATLAS overview week in Dubna Eric 5'
Joint meeting at QMW Eric 5'
Any other business
Dates of next few meetings
TileCal trigger cables Paul
A review is scheduled for July. PBT reported
that he is in contact with Marzio in order to supply specific information (bending radius,
stiffness, etc.) that they need. The choice of cable should be the same as for the LAr
system, with the exception that 10 pairs per cable are required for the TileCal choice.
TileCal is willing to pay for the cost of cable (approximately 100 KCHF) but has not other
resources (effort) to contribute.
Discussion: ML noted that Bill Cleland is
anticipating a patch-panel for mechanical reasons, in the case of LAr. PBT will contact
Bill to discuss the question of the design of the patch-panel for TileCal.
LVDS test results with TTC clock Richard
the status of the LVDS tests at Birmingham. Two new receiver cards with improved PS
filtering have been received, and exhibit BER < 10-13 without TTC and using
two 12.5 m Datwyler cables(33 W + 100 nH). With TTC, 7 links gave no errors, while a
single link exhibited 3 errors in a single cable (test duration 2 hours) - corresponding
to a BER of 10-12.
New source cards are also in the design process
(specification available). The design includes supply filtering, PLLs on incoming clocks
and LVDS fanout. (Both TI and NS now manufacture LVDS fanout parts.)
Richard also reported progress on a new LVDS
fanout demo PCB, which has been laid out by SP. It contains a single LVDS link, a hi-Q PLL
and uses the TI LVDS fanout device. Experience gained in the use of this device will be
incorporated into the DSS/LVDS source CMC design.
Finally Richard showed some information
available from NS pertaining to their LVDS demo kit. The test results shown for that board
(BER vs. Clock rate) in the frequency domain pertinent to us show limitations in the
test-board design, rather in LVDS in principle.
Discussion: EE commented that TTC jitter problem
requires further test. TG noted that the old TTC system is in use, not the DMILL version
which will be produced. It is not clear whether there are grounds to expect better
performance from that device. EE commented that one needs to demonstrate that a PLL will
clean things up. RS noted that he should be able to use a pin compatible and faster PLL to
see if the error rate improves. PBT asked for details on delivery of the source card. 1-2
weeks for layout and 3-4 weeks manufacture/assembly. There is a bottleneck, however, in
the RAL drawing office (no time slot available before July). EE suggested that one should
consider whether alternatives (in-house) exist. This is likely possible, but it should be
kept in mind that the system in use at RAL differs from that at Birmingham, so that
exchange of files at a future date will not be possible.
Hardware status summaries
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 3rd 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
PBTs specification. An updated specification should be available within a couple of
Discussion: TG enquired as to design work. Viraj
commented that Ian is doing some work on front end, BC de-multiplexing, readout and
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 10th. NG
mentioned that the design review doesnt 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 hadnt 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
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 doesnt negate the advantage of
Timing Control Module Bob
Norman commented, on behalf of Bob, who
wasnt 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
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
Normans 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
shouldnt 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.
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
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
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 23rd.
- For the JEM prototype, a PDR is to be held at RAL
on July 11th. Proposed reviewers are PBT, NG, Paul Hanke and RS. Documentation
is to be on the web by June 23rd.
- 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
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.
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
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
DAQ work planning Norman
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
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.
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
shouldnt adhere closely to the hardware/module model was asked. AW maintained that
this wasnt 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
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 worlds 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
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
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 13th.
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
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
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, 5th 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 3rd
and 4th (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
Dates of next meetings
- RAL, 15 June, R1-Conference Room 2
- Tentative. 27 July