ATLAS-UK Level-1 Calorimeter Trigger Meeting
Friday 1st December 2000 - RALPresent: 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
*=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' #
Diagnostic and DAQ software...........................Bruce 10' #
Summary of recent software meetings................Murrough 10' #
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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
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
- 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.
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.
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.
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:
Good points for ELMB 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.
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
- It is the standard ATLAS choice.
- Standard software, support and spares would be available.
- The price is not a problem.
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.
There were no other issues raised.
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