ATLAS Level-1 Calorimeter Trigger

Hardware Progress Meeting - 29 February 2000

Minutes

Present: Bruce Barnett, Eric Eisenhandler, Norman Gee, Tony Gillman, Bob Hatley,

Viraj Perera, Richard Staley

1. Birmingham hardware

Richard reported that the ATLAS Note on his CMOS backplane transmission studies is now on the Web, but has not yet been entered into the EDM system at CERN. He would like people to check it through before then.

The LVDS link tests have not yet been carried out running from the TTC system. Viraj noted that in any case the DSS mother-board has an on-board PLL feeding the LVDS Tx (or G-link Tx) daughter-cards, and its data-sheet gives its jitter figure as 200 ps p-p (maximum), so the TTC jitter might well be masked. Richard will measure the actual figure for this DSS PLL jitter.

It was decided that the next LVDS Tx daughter-card design will incorporate a low-jitter PLL specifically to feed the LVDS Tx chips, and Richard will present an outline of the other improvements planned for this card at the next Hardware meeting.

Richard did not have an update on the status of the new LVDS Rx daughter-cards currently in the RAL Drawing Office - he will check on progress before the next meeting.

Richard also noted that the Birmingham PC running Linux is now communicating correctly with the VME hardware.

2. G-link tests

Bob reported that he has all the necessary coaxial cable and connectors to assemble four 25m sections. It was again noted that we must test G-link operation in asynchronous burst-mode, for which the DAQ software must be appropriately configured.

There was also some discussion about the effect on the trigger of bit-errors on the CPM (JEM) to ROD links, and it was agreed to ask Paul Bright-Thomas to look into this question.

3. CPM prototype specification status

Richard reported that he would update the specifications on the Web before the next Hardware meeting. Several issues still need to be resolved – e.g. backplane connector pin-out and the specification of the read-out controllers for the Serialiser and CP ASIC/FPGA.

4. ROD prototype design status

Viraj reported that Kevin is currently working on the schematics, and James is designing the PCI core (reminder – Norman will check with M. de Vyvre in the ALICE DAQ group about the possibility of CERN’s purchase of PCI core firmware).

Overall, Viraj noted that the ROD prototype design was still on target for submission to the Drawing Office at the end of March.

5. Serialiser and CP FPGA status

Viraj presented some drawings of the proposed generic test module for these two chips. There would be a new daughter-card design needed for CMS, using Channel-link, which could also be interesting for level-1 if there emerged problems (availability, etc.) with G-link. The plan would be for Azmat to design the new mother-board, and extra design effort, beyond our current team, would be made available to the project. We requested that Viraj prepare a short summary of the proposal for the next Hardware meeting, showing projected costs, effort and timescales.

There was some discussion about an alternative test scenario, using the CPM prototype as a test-bed, but it was considered too risky as it might prove impossible to factorise out the problems with individual elements in what would be a very complex system. It was noted that the proposed generic test module would in fact emulate much of the functionality of the CPM prototype, but obviously excluding features like 160 Mbit/s backplane communication and data fanout, thereby making the chip testing much more straightforward.

6. CMM status

Norman reported that he had prepared a "context" block diagram of the module, showing its functional blocks and its interfaces to other sub-systems, which he will present at the forthcoming "brainstorming" meeting at Heidelberg. He noted that there are still some outstanding issues – e.g. the possibility of a 17^th JEM – to be resolved before a final complete specification can be written.

7. TCM

Bob noted that he had received no more comments on the TCM and TTCdec specifications. The electrical details were now complete, but the obvious questions of module size (6U or 9U) and backplane pin-out remained unanswered. He noted that because of these continuing uncertainties the timescale was starting to slip, although it was not yet on the critical path for the rest of the prototype system. The exact details of card size and connector pin-out will be needed by the end of March when the ROD prototype goes to the Drawing Office for layout, but it was noted that the TTCvx could feed the ROD TTCdec directly if the TCM were not available in time for the ROD tests.

The specification documents would be posted to the Web before the next Hardware meeting.

8. Computing infrastructure

Bruce presented a short summary of the status of computing at RAL.

a) Hardware infrastructure:

i) The Linux box at RAL is now known as atlun01 when running under Linux. The name hepntw97 is an alias referring to its NT alter-ego. This machine is stable, with a few utilities (xv, nedit, lesstif) having been added of late. Problems with ARLA, the AFS

client s/w which we use, relating to stale tokens have been observed. The Transarc

product (for RedHat 6.1)is available at RAL and will be installed in the hopes that its

use alleviates these problems.

ii) LynxOS on hepvme2 - Problems experienced in the VME access from this machine early in the year were due to a reconfiguration of the system's application software. A crucial routine "set_vme_mapping" which configures the VMECHIP2, governing mapping of the mvme167's address space to the outside world was missing. This was reinstalled in the boot-up sequence.

iii) Linux on m68k - The use of this OS would alleviate constraints on software

development (e.g.: HDMC daemon). A diskless version of this OS has been installed on

hepvme5. The RAL diagnostics compile/link and run correctly (in VME daemon mode and also full native mode). Qt, Qwt and the HDMC software compiles/links, but currently fails due to a loader error the cause of which has not yet been isolated. Murrough at QMW has installed a system on disk to complement these tests.

b) Software infrastructure:

i) We are reminded that the official distribution (v205a) made available on the AFS repository by Tara contains Kithsiri's TTCvi diagnostics. Enhancements, as provided by

Kithsiri, will be made available. The code does not run (or compile) on a native LynxOS

machine.

ii)Old DAQ - Following slimming of the code, Bruce is prepared to implement VME bus

access over the HDMC daemon for the DSS. The suggestion is to do this at the lowest

possible class level to start, and then evaluate the use of higher-level HDMC classes in

a more OO implementation of the DSS. Bruce commented that plugging into HDMC classes at a higher level might force a procedural style which might be better avoided.

9. Agenda for Heidelberg "brainstorming" meeting

Following some discussion, a number of issues were proposed to act as a framework for the Heidelberg meeting:

LVDS links:

- TTCrx timing jitter - solutions?

- LVDS signal fanout options

- Plans for further link tests in Birmingham, Heidelberg and Mainz

"Common" modules:

- PPM "Module 0" specifications

- Common Merger module specifications

- Use of TTCdec cards and TCMs by all 3 sub-systems

- PPr and CP/JEP prototype RODs

Alternative link architectures:

- "Front-end" links - Virtex-E + Paroli proposal

- Fall-back options for "front-end" links

- "Back-end" link options - G-link or Channel-link

Issues to be resolved urgently (* may need more work/time):

Prototype CP/JEP backplanes to "Module 0" specification

Prototype module/crate format - 6U or 9U

Backplane connectors and pin-out

VME specification *

LVDS link cables *

10. Any other business.

There was none.

Next meeting - Tuesday 7th March at 13.30 in CR01, R1 at RAL.

Tony Gillman