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

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

ATLAS-UK Level-1 Calorimeter Trigger Meeting

Friday 1st December 2000 - RAL

Present: Panagiotis Apostologlou, Bruce Barnett, Ian Brawn, James Edwards, Eric Eisenhandler (chair), Tony Gillman, Bob Hatley, Stephen Hillier (minutes), Murrough Landon, Gilles Mahout, David Mills, Viraj Perera, Richard Staley, Bill Stokes, Alan Watson.
Apologies: George Anagnostou, Norman Gee, Ed Moyse.


Click for                                               Click for
summary                                            transparencies
                                                 *=ps #=pdf %=gif

Minutes of previous meeting

Hardware status summaries
CP "chip".............................................James 10'
Use of GTM for testing serialiser and CP chip...........Ian 10' #
Cluster Processor Module............................Richard 10' #
CP/JEP ROD prototype..................................Viraj 15' #
Timing Control Module and adapters......................Bob 10'
Common Merger Module...................................Tony 10' #
Summary of CP/JEP backplane FDR........................Tony 10' #
Short-term schedule and reviews update.................Tony 10' #

Software status
Diagnostic and DAQ software...........................Bruce 10' #
Summary of recent software meetings................Murrough 10' #

Other items
Analogue trigger cables................................Eric 10' #
Long-term milestones...................................Eric 10' #
Product breakdown structure............................Eric 10' #
CMS jet algorithm......................................Eric 10' #
Choice of DCS implementation.....................Discussion 15'

Any other business
Dates of next meetings

Hardware status summaries

CP "chip" - James

Ian and James' logic had been combined into the Xilinx Virtex chip, and the pin-out had been defined for Richard. The final latency was 7 ticks compared to the 6+/-1 quoted at Heidelberg - it could be made quicker by upgrading the FPGA at a cost of about 300 each to gain perhaps one tick.

Viraj stressed the need for test vectors. Alan and Bill are thinking about these at the moment, but there should perhaps be a team working on this. Input and output for the chips are needed, and ATLFAST does not simulate serialisation, just BCID so is insufficient.

Use of GTM for testing serialiser and CP chip - Ian

Ian showed the layout of the GTM and described the configurations needed to test both the serialiser and the CP chip, and the FPGA programs needed in each case. Details can be found in the slides.

The status of the work was that the GTM was to arrive at the lab on the day of the meeting, and would then be sent off for assembly. The firmware for the serialiser test set-up was almost complete, just the VME interface programming remained. Most of the CP test programming was still in progress, hopefully to be completed within a week. Ian was also keen to hear ideas on possible test vectors.

Cluster Processor Module - Richard

Richard showed an artist's impression of the module design, and described details of the LVDS input design, options for the fast links, and ratings for the onboard DC/DC converters. Details are available in the slides. The total power consumption of the module was estimated at 90W. Richard had investigated power connectors and found several options that should be compatible with the ratings and other requirements.

The timescale for CPM production had slipped, the schematic design had just been started at the time of the meeting, delays being caused by the need for extra parts in the library. Hopefully this should not run much beyond the start of January. Richard showed his revised schedule, and James questioned the four months estimate for the layout. Tony said there may be problems getting a slot at the right time in the drawing office. There was some doubt if there was sufficient time for testing on this plan.

Tony suggested checking up on lead-time for ordering components. The choice of CAN technology was still undecided, with the default course being to stick to the CPM specifications - see the later discussion.

CP/JEP ROD prototype - Viraj

Viraj briefly described the ROD and the tests performed so far in conjunction with the first ROD and a DSS module. The formation of S-Link packets from imitation CPM data had been tested, and the results seen in both the ROD spy buffers and the DSS input memory.

The next task would be to repeat this data-formatting test with the TTC system - this was to be done quickly before James absence. Then tests of zero suppression, RoIs, busy logic etc would be performed. A second ROD was now available, with two to be built. Murrough pointed out that the full slice test would require six or seven RODs, so we should order more.

The ROD was only programmed to handle DAQ data, and so work had to be done on RoI data formation. Similarities in format would mean some effort saving was possible - the new programming would be done by James in February or March.

Finally, Viraj raised the subject of buying more S-Link cards, particularly as they have a three-month delivery time. At present there was only one in the lab. It was decided to stick to electrical S-Links as they were cheaper and we already understood the one in use. We need as many S-Links as RODs, but Paul Hanke has two already, and there may be some availability from the pool. It was decided to order four new electrical S-Link cards, and check at the software meeting on the exact needs for these and for PC/S-Link connections.

Timing Control Module and adapters - Bob

Bob stated that the schematics for the module were 80% complete, and for the adapter 100% complete. The work would hopefully be finished in two weeks. We are only responsible for making the adapters for the cluster and jet processing crates, the pre-processor needs a different adapter. Delays in the TTCrx chip production means that a new TTCrx ASIC package will be used. These have a one-month delay, but details are available and the TTC decoding will have to be revisited.

The drawing office had been booked for December, but this slot will have to be delayed. Much work for H1 was being undertaken there at the moment, so it is possible we may encounter scheduling problems. Norman said he might raise this issue at the upcoming management meeting.

Murrough asked if any thought had been put into crate design for 6U processors in the 9U crates - none as yet. Bob asked what sort of processors/connections should be catered for - it was thought just standard J1 and J2 VME should be assumed and not to worry about other exotic possibilities.

Common Merger Module - Tony

Norman had finished Draft 3 of the specifications with modest modifications, such as including Uli's idea for energy summation using a full linear scale, and corresponding changes to the readout format. The review was to be at RAL on 11th December, comments were still being received. The schematics review would be in February, and standalone tests in May/June - this schedule is clearly already tight. There was some question over where the resources for schematic capture would come from.

Summary of CP/JEP backplane FDR - Tony

The specifications had been reviewed at the Heidelberg meeting, although not all the points were covered, and this led to Sam writing version 0.51, the final version for the PDR. A summary of the PDR is presented in the slides. There remained some controversial issues, but the overall conclusion was that the design was now credible and well specified. Areas of significant discussion included multiple VME bus masters, termination of both VMEbus and CANbus, power distribution and grounding.

The way forward would be for the reviewers to all check connection compatibility with their own modules, followed by an informal engineering review at the end of January. It was felt worthwhile to pay the manufacturer to assess the final layout before production, which is planned for March. Areas of general worry were how to define a grounding scheme that would be compatible with all modules using the backplane, and the long lead-time for some backplane connectors.

Short-term schedule and reviews update - Tony

Tony summarised the status of the various PDRs. The backplane had been done, and CMM and JEM were planned for the near future. However, he pointed out that the JEM PDR was to some extent academic, since the layout was already complete, and the manufacture planned for the end of the year. In principle manufacture could be stopped if major flaws were found. Also the JEM design was not a full module-0 specification, and may not be fully functional as envisaged for the slice test.

For the PPM, draft specifications were in existence, and provisionally the PDR was planned for January. Tony also pointed out that there has to be a PRR for the pre-processor ASIC, but this has the usual problem of NRE costs having to be paid up-front before a prototype can be obtained for testing.

Software Status

Diagnostic and DAQ software - Bruce

At the recent level-1 software meeting, Murrough had reported on his initial investigations on a new CPU from Concurrent Technologies. The preliminary work suggests that this would be a good choice and more should be bought for RAL/Bham. An attempt was made to assign people to jobs for the long list of tasks for the year ahead. Despite the lack of a videoconference with Cornelius, the future of HDMC was discussed. There was also much discussion of the use of additional tools and the need to organise and formalise work and documentation in order to proceed in a coherent way.

Bruce described his work with the ROD module. He had repeated Viraj's tests using HDMC, and an illustration of how HDMC is used to do this was presented. He had not yet tried to use the ROD in the DAQ environment. The status was that several problems had been unearthed, these being a mixture of misunderstandings and genuine hardware bugs. Ongoing work included tests of more ROD functionality, and updating the DAQ with the new knowledge.

Eric asked Bruce how he felt about timescales. Bruce already felt there was little time to be fully ready for the ROD to ROIB tests in February/March - all the software and hardware needs to be fully debugged by then.

Summary of recent software meetings - Murrough

Murrough summarised the TDAQ Workshop and discussions held during the week. The integration plans leading to the TDR had been fleshed out, starting with bricolages leading to small then large TDAQ test beds. The plan assumes that the TDR can be delayed by about one year. On the readout system (ROS), a co-operative attitude is prevailing with a push for more commonality. Software should be available for PC reading S-Link cards by Christmas, which could be good news for us. Our plans were presented, more DCS software and functionality was presented and many more mailing lists were set up for interest groups.

In private discussions, Dave Francis was made aware of our specific issues with regard to ROD crate DAQ, and we should be able to keep in good contact. There was a very positive discussion with Beniamino Di Girolamo about the TileCal DAQ leading to ideas and potentially help with both DAQ and calibration issues.

Other Items

Analogue trigger cables - Eric

Paul had had a discussion with Bill Cleland about the manufacture of cables for the trigger signals. It would be cheaper to sort out a joint order for all the cables at the same time. Originally the LAr community wanted standard lengths with connectors put on at the factory. Technical co-ordination objected to this on the grounds of difficulty of cable feed-through and 'losing' the excess cable. The idea now is to order double length cables (with connectors) and cut to length, installing connectors on the open end in situ.

Eric proposed that we should follow the same procedure for the short cables from the receiver stations. Sten will try to find out the tile position, and we can then finalise numbers and lengths. Note that Bill Cleland is not so keen on this solution for various reasons as shown in the slides.

Long-term milestones - Eric

It was discussed in Heidelberg that many of the milestones set out in the TDR are now inappropriate. It is proposed to ask LHCC to approve a re-definition of milestones in line with the discussion and later comments. Eric presented a possible new version. One area of difficulty was the number of PRRs. It is proposed to tie them to the FDR, meaning the FDR/PRRs would need CERN involvement. The overall pattern is:
  • 2001: slice test
  • 2002: FDR/PRR for fully specified modules, PDR for others (eg ROD)
  • 2003+: similar to before but with dates re-scheduled

Comments on the new version included the fact that integration, either with Detectors or DAQ, is not really addressed and there are no software milestones. Software schedules are to some extent tied to hardware, but some clarification may be necessary.

Product breakdown structure - Eric

There was a request from Technical Coordination via Nick for a more detailed PBS for the project, and Eric presented his attempt to produce one. The main problem in doing such an analysis appears to be that there could be several correct ways of breaking down the project, depending on your point of view. Eric had not attempted to define some of the vague areas of the project - for example, computing infrastructure is not well defined.

CMS jet algorithm - Eric

Eric had been browsing through the newly available CMS Level-1 TDR. One point of specific interest was that they had changed from the old jet algorithm (non-sliding, non-overlapping) to one which looked far more like the ATLAS one, the main difference being the size of the cells - 1.04 by 1.04 in eta-phi, rather whereas our biggest option is 0.8 by 0.8. They also have a tau algorithm using the jet logic, looking for localised energy deposits in the cluster. Another interesting difference from their original design is more reliance on FPGAs rather than ASICs. Eric said he would look at their current latency estimates given that they still have the extra work to do on ordering energy deposits.

Choice of DCS implementation - Discussion

Richard was keen to try an alternative to the DCS standard ELMB solution on the CPM module. His proposal, using a Fujitsu chip set, has the major advantage of requiring far fewer components and therefore board real estate. Disadvantages of the standard ATLAS ELMB kit include:
  • The choice of 8 or 64 channels seems either too small or too large.
  • The hardware is unnecessarily large and outdated.
  • The seven-bit address field is probably insufficient for our system.
Good points for ELMB include:
  • It is the standard ATLAS choice.
  • Standard software, support and spares would be available.
  • The price is not a problem.
Uli had been to the DCS workshop, and was planning to use ELMB on his boards and it was thought Paul might try the Fujitsu route. It was decided that rather than being a duplication of effort, it would actually be a useful test of the alternatives to have a mixture for the slice test, but a single choice should be made for the final system. It was pointed out in general that we should stick to ATLAS standards when reasonable.

At Heidelberg there had been a plan to list what properties were required to be monitored. The Heidelberg group had produced both a short and a long list, to correspond to the ELMB sizes. The Fujitsu device has 20 channels, so suitable proposals of quantities such as device temperature, air temperature etc should be drawn up. It was commented that we should not go over the top, as the emphasis on temperature monitoring was stressed when the system contained mostly G-Links.

Any other Business

There were no other issues raised.

Next meetings

Tuesday 23 January ....... UK meeting at RAL

1 - 3 March .............. Joint meeting at Birmingham

NB:  There will probably be no UK meeting between these dates

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