ATLAS-UK Level-1 Calorimeter Trigger Meeting

Thursday 23 January 2003 at RAL

Agenda

Click this side                               Click this side
for summaries                                for slides (pdf)
 
Hardware
Jet/Energy Module hardware and tests....................Uli
CMM, ROD, TCM, etc. hardware and firmware status......Viraj
Cluster Processor Module hardware...................Richard
Cluster Processor Module tests.......................Gilles
Updated schedule.......................................Eric
 
Online software
JEM software and simulation..........................Thomas
Software summary...................................Murrough
 
Recent meeting highlights
Trigger/DAQ Steering Group.............................Eric
 
Any other business
Date of next UK meeting

NOTE: As Mainz and Stockholm people were in the UK for tests of the Jet/Energy Module, this UK meeting included reports on their progress but was otherwise abbreviated in order not to take too much time.

Hardware

The second CPM has been assembled , powered-up, and supply voltages checked o.k. They are now awaiting JTAG testing. The new module has a serious bow, with the centre out of line by 3mm.

On the first CPM, control and clock functions are working, but occasionally the FPGA Configuration Controller (FCC) Locks-up. [Afterwards , it was discovered that this happens after a configured CPM is reset. Following a firmware modification in both the FCC and Serialiser, this problem has gone away.]

The DAQ G-link output appears to be running error free, although the received frames contain an extra unwanted word. The CPM or DSS could be at fault.

Sixteen LVDS inputs are working without problems into the Serialisers. Uli mentioned that Mainz were having problems using LVDS links when the TTCrx was connected by fibre, but this was later found to be caused by a mis-behaving TTCrx card and not the LVDS parts. All 80 LVDS inputs will need to be tested together, and real-time bit-error rates measured. For this, 10 new LVDS source cards will be made; we have five assembled but untested. [One of these was used later that day to drive a JEM, without problem]

On-board 160Mb/s transmission is working well, although routing problems within the CP FPGA prevent the calibration and timing circuit working reliably. Typical waveforms of the on-board and backplane 160Mb/s links were shown. Backplane 160Mb/s signals suffer from reflections and attenuation, which reduce the voltage margins at the receiving FPGA. However , this shouldn't be a problem on the next PCB as the FPGA will use receivers with narrower logic thresholds.

There are two different termination techniques on the module. To reduce the pin-count on the backplane and Serialiser, each incoming signal, from a neighbouring CPM, feeds up to three destination CP FPGAs. Series/source termination would need active fanout to provide 384 point-to-point signals from the 160 inputs. This would require an extra 24 packages.

Richard commented on the timing margins of the 160Mb/s links in the light of problems with the CP chips 4-phase calibration. A 2-phase calibration scheme had been offered, but this is a non-starter as there is a chance that both phase choices could be very close to the transitions in the incoming data. Using only one clock phase overcomes the routing problems in the CP FPGA (as each input register no longer receives its clock through a multiplexer), and could work for the on-board data which is timed to within 1ns, but the backplane inputs are delayed much later and need another phase (or two). (The 1-phase clock design has since been used for timing scans)

A reminder that both the RAL and Bham systems are suffering from interference caused by powering-up the 9U crate supplies. The data sheets claim the combined surge is limited but could be 70A. At Birmingham, the adjacent CPU crate power-unit sometimes reacts to this by reseting the CPU. Fitting an inline mains filter has reduced the frequency of interference. Staggering the power-up of the two power supplies will help reduce this further.

CPMs #3 & #4 will be assembled soon. These may include faster variants of the CP FPGA.

To summarise: no reasons not to use the current module in the slice tests.

The readot controller (ROC) of the CPM has been tested by sending RoI/DAQ data to a DSS populated with a G-link sink card. Data were recovered correctly but strange behaviour was observed: the length of data was always longer by an extra word, a copy of the last word. Bursts of data are recovered but not all of them, and the DSS memory does not seem to fill completely each time.

Concerning the CP chip and its links with the Serialiser, new firmware was released by James, where two phases are used instead of four. The number of errors has been reduced but there are still a few. A new version has now been written with just one phase and, providing the right delay has been selected via TTC between the Serialiser and the CP chips, all data are recovered correctly. A scan in time, by moving the previous clock between CP and Serialiser in steps of 104 ps, has been performed to identify the range where the CP chip receives correct data. The length of this time window is 3.5 ns, and the window repeats every 6 ns, which agrees with a data rate of 160 MHz. Similar patterns have been observed on two other chips.

Problems have been found on the Serialiser: the playback memory generates FFFF data from time to time. It does seem to happen to only one chip, and could be a defective chip or faulty connection. Unfortunately, during testing something happened which damaged the testing procedure. No error free zone has been recovered. This loss of regime has to be investigated.

On the software side, all previous tests have been performed thanks to the integration of the CPM services with the Online Run Controller software. It's foreseen to do similar tests with the ROC. In the long term, soak tests will be performed on LVDS Rx, with modified firmware in the Serialiser to do bit-error rate measurements.

Three new CPMs are to be available soon, one fully populated, and twoothers only populated with Serialiser chips. Full investigation of the backplane will then be performed, and the CP algorithm completely tested. More material is also needed to perform these tests, and a list can be found on the last slide.

In discussion, it was strongly suggested that a similar list of test equipment for use at RAL would help in our planning. The biggest discrepancy between what we need and what we have seems to be DSS modules and daughtercards.

Schedule - Eric Eisenhandler

Eric pointed out that in schedules discussed at the previous meeting, not enough notice was taken of the calorimeter installation timetable. We need to have at least a few Preprocessor Modules installed soon after the Tile barrel and electronics are commissioned, and so we cannot afford the luxury of assembling the entire Preprocessor before sending it to CERN.

Online software

JEM software and simulation - Thomas Trefzger

Thomas gave a brief summary of the software situation for the JEM at the tests going on at RAL. Scripts from Jürgen Thomas and Cano Ay were being used, and HDMC and module services software was being developed. A test-vector reader was being developed. The emphasis at Mainz has been on energy summation, but jet tests must also be added. As yet, no timing calibration software has been written, so UK CPM will be adapted.

Test vectors to simulate the realtime data path exist, together with expected results. The simulation needs to be integrated into Steve Hillier's framework.

Software summary - Murrough Landon

Murrough gave a brief summary of the recent work done by the various members of the software group before and during the Mainz/Stockholm visit to RAL. The main points were that the CPM tests are now running via the run control, TTCrx chips can be configured via the TTCvi, work was in hand to support DSS with two LVDS cards, and there was good progress on modules services and test vector readers for the JEM. Some tests were performed on RODs with new firmware, but so far these were not successful.

The most urgent tasks relate to multistep runs, e.g. to make timing calibrations in both JEM and CPM. This requires support in database, run control, and test vector readers. Work on CMM software should restart now that the first CMM is about to be released to us.

Murrough added that he is now a member of two TDAQ working groups. Documents and TDR chapters were being produced on the subjects of both monitoring, and error handling & fault tolerance. We should look again at these issues for our system – but time was too limited at this meeting. He was also invited to give a talk about our database requirements at the forthcoming database workshop.

Recent meeting highlights

Trigger/DAQ Steering Group - Eric Eisenhandler (slides)

Eric said a few words about the recent meeting of the Steering Group. He had given a long and thorough status report on the calorimeter trigger, including timetable and effort problems, and it had been sympathetically received. He also mentioned the line-up of meetings for the February ATLAS week, the forthcoming database workshop, and the deadline in May for papers at the IEEE annual meeting.

Any other business

Uli urged people to register for the Mainz meeting, as the hotel block booking runs out soon.

Next UK meeting

The next UK trigger meeting was tentatively set for Thursday, 27th February. Although planned for Birmingham, this was later altered to RAL.

Eric Eisenhandler, 3 February 2003

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