ClusterAlg.gif (577 bytes) The ATLAS Level-1 Calorimeter Trigger

[Home] [Architecture] [Meetings] [Participants] [Publications] [Software] [Search]

ATLAS-UK Level-1 Calorimeter Trigger Meeting

Thursday 21st February 2002 at RAL

Present: Ian Brawn, James Edwards, Eric Eisenhandler (chair), John Garvey, Norman Gee, Tony Gillman, Stephen Hillier, Murrough Landon, Gilles Mahout, David Mills, Viraj Perera, Richard Staley, Peter Watkins.


Click this side                               Click this side
for summaries                                for slides (pdf)
Hardware status
CP chip tests and simulation model....................James
Cluster Processor Module and test cards.............Richard
Common Merger Module....................................Ian
CP/JEP ROD prototype firmware.........................James
Timing Control Module and VME Mount Module....Eric for Adam
Stockholm, Mainz and Heidelberg status.................Tony
Test planning
CPM testing..........................................Gilles
CMM testing............................................Tony
Software status
Online software status.............................Murrough
Test vectors and simulation...........................Steve
Readout, RoIB, and DIG issues........................Norman
General items
FPGA damage from faulty code..........................Viraj
ASSO follow-up.........................................Eric
Items arising from talk given at LAr week............Norman
TileCal summing amplifier gain.........................Eric
PPRP review of ATLAS-UK................................Eric
Coming meetings
ATLAS week.............................................Eric
Heidelberg joint meeting...............................Eric 

Any other business
Next UK meeting

Hardware status

CP chip tests and siimulation model - James (slides)

Concerning CP chip tests on the Generic Test Module (GTM), James is unable to proceed any further without the real hardware, which in any case is imminent. He has investigated CP chip simulation in some detail, and found a way to compile the design into a standalone library for simulation with modelsim. Internal signals are fully accessible, and the source code is protected. Can supply some diagrams of structure. For people doing tests, this seems to be a reasonable compromise.

Birmingham people seem reasonably happy with this solution. The source code will be released when it is 'finished'. Similar things can and will be done for other FPGAs.

Cluster Processor Module and test cards - Richard

An assembled CPM is due into RAL on 1st March. A guide for setting-up the module for JTAG testing, (including initial checks on power supplies) is in preparation , and will be given to Richard Matson before the CPM arrives. CPM Firmware is being completed and checked with simulations.

Crate Slot Adaptors for DSS: CPM_emulator PCB has been ordered and is expected next week (28th Feb). Assembly to be done at Birmingham (1 day). CMM_emulator PCB layout done. Once ordered, delivery < 3 weeks. (Richard will delay the order until the previous PCB arrives.) The DSS GIO is at least a month away from manufacture; see next item.

Norman asked whether we could paint all the front panels so that they look attractive. Tony said it was still possible. We agreed to do it; different module types should not be the same colour.

Richard said he needed VME address space for the CPM defined. Murrough will do this with Norman and publicise it.

Common Merger Module - Ian (slides)

Ian said that 5 CMMs have been manufactured and 2 have been sent for assembly. These arrive back at RAL next week.

Rear Transition Modules (RTMs) are required to house the cables that will carry data between crate- and system-level CMMs. These have been designed, and layout will be finalised once it has been determined how these modules should be fixed to the rear of the crate, and hence how large they need to be. To determine this it is desirable to examine a processor crate and backplane, which should be available within 1-2 weeks.

The General purpose IO (GIO) cards for the DSS, which are required to test the CMM, are currently in the drawing office.

All of the required firmware for the CP-summing CMMs (crate- and system-level) exists for the Crate and System FPGAs and the VME CPLD. Firmware has not yet been developed for the I2C-controller and Flash-memory-controller FPGAs. This will be based upon similar firmware developed for the CPM, which Richard Staley will provide. Ian also presented some ideas for tests of the CMM to be performed the electronics lab. These tests will not be delayed by the initial absence of the RTMs or the DSS GIO boards.

CP/JEP ROD prototype firmware - James (slides)

It appears that the symptoms that we observed in the last couple of weeks (CP_Slice-12) pertaining to corruption of data into the ODIN under assertion of LFF have disappeared. Unfortunately, new problems have arisen. Bruce has not yet analysed the errors extensively, but it appears that bursts of 64 1-slice fragments are now corrupted at some level at inter-fragment times of less than 100 microsecond. He hasn't yet quantified at what point things break. Further information from Bruce is required. That will enable James to target the problem, first by checking simulations then using ChipScope. James hopes to give a fast response.

Timing Control Module and VME Mount Module - Eric for Adam

The TCM is unchanged since the last meeting apart from a new firmware version for the data CPLDs. Three more modules are being populated at present. Adam would like some web space for updated documentation.

Simple tests have been done on the first VMM. The rotary panel switch has gone missing, and more seriously the VME connector (3-row) needs to be replaced by one that can do geographical addressing. Note that external reset pulses must be TTL, not NIM. The external reset was not being pulled up - resistors have been added - and various other small fixes done. A total of six PCBs are being updated.

CANbus - Dave (slides)

No further progress with the Fujitsu micro. Dave is currently awaiting some example code from a Swedish contact. A CAN to USB interface device has been ordered and should be arriving at QM soon. This will enable faster debugging and testing of CAN devices.

Dave also showed several slides of various CAN devices, including the CANDIP devices suggested by Heidelberg. He commented that although most of the devices were functionally similar to the single CAN Fujitsu devices, they lacked enough IO pins to allow connection to the VME backplane as currently happens in the CMM and TCM designs.

Stockholm, Mainz and Heidelberg status - Tony (slides)

Heidelberg status: The PPr ASICs and MCMs are in fabrication, with completion in March. The PPM design is nearly complete, with LVDS fanout, ReMFPGA and CAN needing more work. The Heidelberg TCM arrived safely - its Adapter Link Card is now being designed. 160 "serial LVDS" data cables are available for the Slice Tests.

Mainz status: Two JEM0 modules are now assembled, with no. 1 approaching real-time data-path tests and no. 2 starting JTAG tests. Two more are needed - is there time for a design iteration before Slice Tests? The module still has to be incorporated into the HDMC framework. TTCdecs may be needed for the JEM0s (not enough TileCal variants), requiring design of a new interposer card. Jet algorithm latency has been reduced by 0.5 BC (in simulation).

Stockholm status: The four backplanes are nearly complete, with delivery by end-February. The first UK crate/backplane should be at RAL in early-March, ready (once assembled with PSU) for CMM/CPM JTAG tests. The second (for Birmingham) will be shipped about one week later. Two PSUs will be shipped from RAL to Mainz and Stockholm for their crate/backplanes. Two new students are starting work on JEP simulation.

Test planning

CPM testing - Gilles (slides)

The part file necessary for HDMC to access the register layer of the CPM is nearly completed. In this file, the submodule layout introduced by Bruce has been used to describe CP chips and Serialiser chips as submodules of the CPM. With Regbuild, classes of registers are automatically created and will be useful to implement the different module services of the CPM.

Some firmware codes need to be finalized. For example, a register with the firmware version need to be implemented, but the format must be defined. B'ham received the timing simulation of the CP algorithm 3 weeks ago. Modelsim has been used to read the code but the PC is too weak to handle it. So a new PC has been ordered and has been received. Unfortunately, there is a problem of license which makes it impossible to run the code. Paul Hardy, of Europractice has been contacted to understand the problem. Meanwhile, at a slow pace on the old machine, a test bench to drive the CP has been written.

First results are not satisfying and Gilles will need to investigate with James if the testbench is correct or faulty. For example, simple VME access to retrieve the CP firmware version does not seem to work. Finally, to test the CP algorithm with the hardware, an idea was to design a passive board driving signals of other CP chips from the backplane to send to the CP chip under test. This idea has been abandoned as it required collecting signals from all other chips, which will raise timing problems. A simple board is still envisaged to be built in order to read and check fanned-out data of the backplane.

CMM testing - Tony (slides)

There are broadly six phases of CMM tests, ranging from standalone through to system-level real-time operation producing CTP data. Several extra modules (and associated firmware + software) will be needed throughout this programme, starting immediately with a powered 9U crate/backplane.

The initial module "health checks" should conclude with a full VME checkout, verifying all registers and memories, before handover to the PPD group working in Lab 12.

To check readout functioning (Stage 3), pre-loaded data patterns (ramps, etc.) should first be scrolled through the CMM in Playback mode under the control of a TCM, and checked in I/O memories via VME when clocks are stopped. Each channel needs independently checking. These tests should then be repeated in L1A triggered mode via a ROD.

Moving on to check real-time data-flow, for crate-level merging (Stage 4) the CPM data sources can be emulated with CPME2 test cards driven from a DSS/GIO. Again, known data patterns in the DSS can stimulate each of the 16 CPM/JEM crate slots in turn, and correct data capture via the backplane into the CMMs (slots 3 and 20) can be checked via VME with the TTC clocks stopped. Timing margins can be explored. As for Stage 3, these tests can be repeated in triggered mode into a ROD. (N.B. Stages 5 and 6 figure captions have been accidentally reversed on the foils)

For Stage 5, we would explore system-level merging in a single crate, by using a pair of CMMs fed from a pair of CPME2s. CMM no.1 would be emulating a CMM in a second crate (Crate CMM) and communicate with CMM no.2 (System CMM) via an external cable, using a pair of Rear Transition Modules (RTMs). Again, the same series of tests would take place, but this time the System CMM would need its Pipeline Delay timing tuned to merge external and internal data correctly. The final stage of testing would involve the use of a pair of (tested) CPMs sourcing HIT data directly via the backplane into the Crate and System CMMs, with a DSS/GIO sinking the resultant merged HITs from the System CMM by emulating the CTP.

In conclusion, the programme will be lengthy, with the various phases being only loosely delineated. Not all the necessary hardware yet exists, and much of the firmware isn't yet written. A dedicated team effort is needed, with hardware, firmware and software expertise.

Software status

Online software status - Murrough (slides)

Murrough presented the status of software developments. Bruce has extended the HDMC parts file syntax for the Module Services package
which is now being used by Gilles for the CPM.

Murrough has done further work on databases, adding description of connections and restarted work on calibration data. He has also extended the main run control GUI to show our run control parameters.

Steve has completed work on the core simulation package and the CPM simulation. He has also provided both user and reference documentation.

A scheme for organising (sub)system test and test vectors has been discussed. This still needs implementing.

There is still a lot more work to do, in particular integration of the separate developments of our component packages. This is likely to take a couple more months (at least).

Test vectors and simulation - Steve

The simulation framework has now reached a reasonable level of maturity, and no large changes or developments are foreseen, although work is still needed on developing module code. The major recent progress in the simulation has been the production of full documentation. Both an introductory user guide, and more detailed reference documentation exist for the framework. Also a web page has been set up at: which acts as a base for links to information about obtaining and developing simulation code.

Other news is that Steve has now been contacted by the two students at Stockholm who intend to work on the JEM simulation.Not much about progress, but they have hopefully got all the code and information they need.

At the recent software meeting, more thought had been put into how to integrate the test-vector generation and simulation into the DAQ, concluding that the simulation should work in close cooperation with the database. Murrough and Steve intend to make the first attempt to run a simulation from a database description in the near future.

Readout, RoIB, and DIG issues - Norman

Work on the ROD crate DAQ has been to prepare a definition which should lead to a usable product by Summer 2002. The definition paper runs to 27 pages, and comments from ROD task force members are being incorporated prior to distribution to detector groups for comment. ROD crate DAQ is regarded as an integral component of ATLAS DAQ, for use in lab tests, test beams, and as part of installed ATLAS. The ideas will be presented in the DIG forum next week. Note that a 'ROD' crate could contain other modules as well, and possibly (like our trigger crates) no RODs at all.

A new RoI builder is being designed, and Norman has been invited to act as reviewer. The new system will connect to RODs using Gigabit-ethernet S-Links for I/O, in a scalable system with multiple boards to populate larger numebrs of Level-2 supervisors.

General items

FPGA damage from faulty code - Viraj (slides)

Damage to FPGAs can occur due to:

1. Bad designs

a. Use of internal busses can cause contention if the external signals enabling the busses are enabled incorrectly on power up

b. Not considering the maximum power dissipation of the package

2. Generating incorrect bit files. If for example a new design is done then use the correct pin allocation file to prevent I/O being assigned incorrectly, since the I/O will be fixed and connected to other devices on the board.

3. Loading incorrect bit files from VME. This can happen in three possible ways and this seems to be the most likely way to damage the FPGAs

a. Bit files generated for similar devices can be mixed up. For example on the CMM there are two similar FPGAs, the crate FPGA and the system FPGA. If the two bit files were incorrectly loaded then it can damage the devices due to different I/O connectivity between the devices and to other devices.

b. Bit files generated for different package types also can be loaded incorrectly. For example CP Vs CMM.

c. Bit filse generated for different devices can be loaded. For example XCV600 Vs XCV1000. Here since the internal gates will be enabled and connected in an unknown fashion internal contention can damage the device due to high current draw.

Prevention: for all things that are flexible, the chances of inadvertent failure are increased. Hence some mechanisms should be in place to prevent these.

1. In the CPM and the CMM the temperature of the devices are monitored using the FPGA internal temperature diode.

2. More importantly, the loading of the incorrect bit files has to be protected with software by cross-checking the bit file header information.

Discussion centred on the possibility of introducing some positive ID information into the bit file header information, which was felt to be an important protective mechanism. Also, care should be taken with file naming so that one-character typing errors or mistakes cannot lead to the wrong file being loaded.

ASSO follow-up - Eric (slides)

The main action items for the short term are: (1) to appoint a calibration contact person and to get the names of calibration contacts from the calorimeters. Thomas Trefzger of Mainz has now agreed to be our contact; this should be ratified by the Management Committee at the Heidelberg meeting. (2) Preparation of documents on connections from the LAr and Tile calorimeters to the Preprocessor. Steve and Murrough volunteered to do this.

Items arising from talk given at LAr week - Norman

Norman's talk at the Lar-week plenary on 7th Feb was generously received. It covered the algorithms, hardware status, our calibration needs, software, and testing plans.

On Calibration, Norman proposed that a LAr-L1Calo working group be set up to flesh out the details of how the different types of calibration activity (Pulse timing, Pulse Shape, Pulse Energy, Tower builderdelay & Gain, Tower Switching) can be done together using the tools available and others. Norman has told the LAr people that he personaly believes that a further joint test-beam run is needed. This should be further discussed in Heidelberg; actual test-beam may not be the best place.

TileCal summing amplifier gain - Eric (slides)

The FDR/PRR for the amplifiers had picked up on our objection that the amplifier gain is a bit too high (8 not 7), leading to concern that for large eta the saturation in ET might be below 256 GeV. However, Rupert has produced simulations for both 1 TeV and now 150 GeV jets and single pions that indicate that a large fraction of the energy at high eta goes into dead material, with the result that the deposition in the end of the barrel and throughout the extended barrel is uncannily flat and certainly does not seem to follow 1/sin(theta) as expected. See slides 2 and 3 for plots of this. The result is that the amplifier gain is probably all right for us, though it drives home the point that so much energy is not seen that we may have to do some compensation in our energy calibration.

PPRP review of ATLAS-UK - Eric

The periodic (normally about every two years) review of ATLAS and CMS by the PPRP (ex-PPESP) was scheduled for 25 March, but due to the current financial crisis the grant round has been postponed by a few months and the review is postponed until September. This has the drawback that a lot of the preparation will have to start in August when a lot of people are away.

Coming meetings

ATLAS week - Eric

The next ATLAS week is at CERN next week, Monday 25 February through Friday 1 March. Eric, Norman, Murrough and Steve will be going.

Heidelberg joint meeting - Eric

The next joint meeting is at Heidelberg, 14-16 March. A web site has been prepared and most people have now registered.

Any other Business

There was no other business.

Next UK meeting

The next UK trigger meeting will be on Tuesday, 16 April at Birmingham.

Eric Eisenhandler, 27 February 2002

This page was last updated on 16 December, 2013
Comments and requests for clarification may be sent to