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

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



ATLAS-UK Level-1 Calorimeter Trigger Meeting

Tuesday 23rd January 2001- RAL


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




Last Meeting (December 1, 2000)
This meeting (January 23, 2001) as pdf and its original agenda

Hardware status summaries

CP "chip"..........................................Viraj 10'
Generic test module..................................Ian 10'
Cluster Processor Module.........................Richard 10'
CP/JEP ROD prototype...............................Viraj 15'
Timing Control Module and adapters...................Bob 10'
Common Merger Module status.......................Norman 10'
Common Merger Module design plans....................Ian 10'
Short-term schedule and reviews update..............Tony 10'

Software status

Diagnostic and DAQ software under development......Bruce 15'
Online software strategy........................Murrough 10'
Work on new trigger simulation software...............Ed 10'

Other items

Work on Fujitsu CANbus solution.....................Dave 10'
TileCal trigger towers..............................Eric 10'
Preparation for ATLAS week 19-23 Feb................Eric  5'
Preparation for Birmingham joint meeting.....B'ham group 10'

Any other business

Comments on presentation formats.....................ALL 10'

Dates of next meetings



Hardware status summaries

CP "chip" - Viraj

      Viraj reported on the status of the CP chip design. James has completed the design, and successfully targeted it to an XCV1000E device, which has a footprint compatible with the XCV-2000.

      The latency is 6 ticks. There is, however, some ambiguity (really 6, or actually 7?) in this number due to some questions concerning latch implementation. If necessary, a tick could be saved through the use of a faster part, with an additional penalty of 60 percent in cost.

      Additional simulations are anticipated, using A.W's test vectors, extending back to the BC-muxed data.

      Eric commented that it is worth noting that the cost figures mentioned by Viraj (assuming the slower part) are already below break even when compared with an ASIC design. 


Generic test module - Ian

      Ian reported on the status of the GTM. Due to a component mix-up on the part of a distributor there will be a delay in the manufacture of the board to accomplish a re-work requiring removal of the VirtexE BGAs. The distributor will bear the cost of the re-work. As a result, delivery of the board will be a week late.

      Norman asked whether we will have the opportunity of seeing the board after removal of the wrong part. No, but the distributor will perform quality control to ensure that there is no board damage. It was noted that the positive aspect of this error is that we will gain some first hand experience of BGA rework. There was interest in obtaining a statement of the cost of this replacement operation.


Cluster Processor Module - Richard 

      Richard presented a summary of the CPM prototype design.

      First was a discussion of the status of CPLD/FPGA design. The VME interface CPLD and CPM control FPGA designs are complete. For the ROC and hit-counting logic there exist preliminary Altera designs, but the buffer memory has yet to be addressed.

      Richard then presented some changes in TTC power-up address specification for the I2C bus and VME addressing. The TTCrx register space will not be memory mapped, but rather accessible through a simple register and a software protocol.

      Richard has completed part testing, as well, on DC-DC power converters required for the CPM. He has found parts with good regulation and verified absence of overshoot on power-up.

      Richard outlined a revised schedule for the board, indicating first availability for tests in Birmingham by June.

      Bruce asked what the correct procedure was to deal with design points requiring changes to the PDR approved specification. It was agreed that such changes should be fed back to the panel so that possible repercussions can be considered. Murrough emphasised that the TTCrx chips should appear the same throughout our system so that if software was needed it would be uniform.

      Concerning time-scales, it was pointed out that some delay relative to the Merger Module is tolerable, as it is the latter which is currently on the critical path. Nevertheless, concern was expressed about the generally slipping timetable.


CP/JEP ROD prototype - Viraj  

      Viraj described the status of the CP/JEP ROD. Two modules have been assembled and tests are in progress. He described a design problem with the TTCrx daughter card, for which a solution had been found before Christmas. He then described problems discovered in the R1 lab in the behaviour of the module's pulse register, probably arising from the implementation of a state machine in the FPGA code. [Viraj has provided a temporary fix to allow tests to continue, and will ask James to look at the problem on his return.]

      Viraj described modifications to the DSS firmware which allow either slice or RoI data to be produced depending on software control of a control register bit. One can switch between internal and L1A event generation, or between generated data and preloaded test vectors.

      Future work includes the design of firmware required for modules other than the CP-ROD (ie for JEM and CMM). Two more modules will be assembled. Two (or four) PCBs and components will be needed for slice tests.

      Eric brought up the question of how to decide how many additional RODs we will need in the near future. Norman mentioned that the topic of configuration had been discussed at recent s/w meetings. Eric pointed out that this is a major item which needs to be considered at the forthcoming Birmingham meeting. Diagrams could be made ready for the next h/w meeting at RAL.

      Concerning numbers of RODS, Murrough pointed out that 6 is sufficient for slice tests, but one would need a spare (7). So one might as well go ahead and manufacture and fabricate the 8.

      Concerning S-links, Viraj has ordered double speed, optical ODINs (6 each source and destination) in anticipation of the needs of the slice tests. Murrough noted that we need to obtain some PCI adapters, also, for use in a PC based ROD-crate DAQ [or with components thereof] when one becomes available.

      Viraj noted that we should consider whether more G-links are required as well. We have 4 sets and Bob reminded us that we have an additional set which has been lent to Mainz for the "duration".


Timing Control Module and adapters - Bob

      Bob updated the group on the TCM status and associated work. The data entry is 95% complete. There remain a few changes in the VME display, and mechanical layout is yet to be done, as is a final design check.

      Associated work includes that on adapter link cards (ALCs). He has one for the CP/JE crate to design and an additional one (PP crate) to specify. Both these items have been started. Work on a final item, the crate processor host module, has not yet been begun.

      Tony pointed out that a processor adapter module is required for two types of system. The question of responsibility should be settled: although that may have been assumed until now to lie with the UK, we should not accept such responsibility if to do so is inconsistent with available resources.


Common Merger Module status - Norman

      Norman commented briefly on progress with the CMM. The module was reviewed before Christmas. 75% of the comments have been incorporated and, although this will be later than the target date, the work is expected to be complete by the end of January. Of these comments many were detailed but none revealed essential flaws in the specification of the module.


Common Merger Module design plans - Ian

      Ian discussed the status of the design of the CMM. Preliminary design has started on items which are not sensitive to details of the specifications. The hit counting has been considered in a preliminary way. Most of that which can be done without the final specification has, so the full specification is awaited. 


Short-term schedule and reviews update - Tony

      Tony brought us up to date on the schedule and review front. In his slides he outlines the nature of the amendments arising from the review and the salient issues. A general comment is that the CMM has "evolved into a well-specified generic design", although one whose scheduling is tight so as to place it on the critical path for timely achievement of the slice tests.

      A number of important points stemmed from that review, including a statement of module/crate numbering scheme and the decision to adhere entirely to LVDS technology for cable I/O. The FDR is anticipated for 04/2001 and testing expected 07/2001.

      Also in December 2000, the PDR for the JEM took place. The document presented by Mainz was comprehensive and illustrated a sound design framework, but nonetheless a number of important amendments arose from the review. It was observed that the aggressive schedule for the realisation of the design prevents significant design changes. There are some concerns as to the Module-0 conformance of the design, and whether that will result in slice-test integration problems.

      The design went out for manufacture before Christmas, with board delivery expected in January.

      Amongst other upcoming reviews:

        • the PDR for the PreProcessor Module and ROD are expected to take place in February 2001.
        • The FDR for the PreProcessor MCM is anticipated in March 2001.
        • A "Low-key" PRR for the PreProcessor Asic had already been agreed, but a revised plan now is to hold a PRR including results from tested MCMs in September 2001, after an engineering run of 3 wafers in April-May allowing wafer probe testing in June and the construction of sufficient MCMs for slice tests. Full production of the ASICs will follow the slice test.

      Tony then reviewed the system schedule. The CMM schedule is such as to cause it to fall on the critical path. In this case it is consistent with a later delivery date for the CPM than originally forecast. Norman noted that significant tests with other modules excluding CMM could start earlier, with the implication that not the whole of the slice test schedule is retarded by a late CMM.

      In addition, of course, we anticipate a test in conjunction with the RoIBuilder to take place sometime in March. This represents a priority inversion over our other constraints only in an emphasis on RoI rather than slice readout.

      One still anticipates that tests with Heidelberg may start mid. November.

      Richard queried Tony concerning the latest news on the backplane. Tony has tried to determine this from Uli or Sam. Expected availability is the end of April or beginning of May. (BP will be needed in June at Birmingham for their tests).



Software Status

Diagnostic and DAQ software under development - Bruce

      Bruce gave a quick reprise on the status of DAQ and software, the general progress of which has lagged a little with the demands of ROD testing taking precedence. The current status of the readout-level code was described as "HDMC enhanced with DAQ-classes".

      A description of the continuing ROD tests was given. In progress are tests involving the use of ROD and DSS together with clock and L1A distributed by the TTCvi/rx. Bruce described the nature of problems already encountered, but noted that even these were in any case providing valuable experience with the hardware, and in the strengths and weaknesses of HDMC.

      Priorities for future work include integration and evaluation of Bill's test vectors. In parallel, DAQ software integration needs to proceed in order to allow stress-testing of the ROD, and of course, implementation of tests in March.

      Bruce mentioned plans to purchase an additional PC for the Lab and new PC-based crate servers (see also Murrough's talk).

      The state of s/w manpower was discussed briefly in the contexts of both the loss of certain key individuals, and the participation in common developments with outside institutes.


Online software strategy - Murrough

      Murrough presented the other half of the software picture, concentrating on the longer term scenarios. He discussed preparations needed for the slice tests, in two areas in particular: specification and documentation.

      In the area of specification, the exact nature of the tests and the corresponding hardware configurations need to be defined. These need to be documented, and indeed a number of draft proposals are available.

      Murrough also outlined the software required for slice tests, with a particular focus on the implementation of DAQ-1 run controllers within the level-1 framework. He has been involved with discussions with the DAQ-1 people concerning data base issues pertaining to the latter.

      The question of software manpower also arose, with Murrough outlining who was doing what and, with the departure of Cornelius, who wouldn't be doing what any more.

      Hardware-wise, Murrough reported the decision to buy 3 additional crate CPUs from Concurrent Technologies (Intel architecture). He mentioned plans to investigate PCI-bridge solutions suitable for the incorporation of larger numbers of S-link interfaces into a ROS solution from CERN (when available.)

      There was some discussion of how to use TTC commands for system synchronisation outside the scope of DAQ-1. It is clear that such real time synchronisation will be required, but the exact extent is yet clear. What is clear is that there is a need to implement a clean architectural separation between such activity and set-up activity which normally proceeds via the VME path.


Work on new trigger simulation software - Ed

      Ed reviewed the status on his work of incorporation of ATRIG into the ATHENA framework of ATLAS. A TriggerTowerMaker has been written, and an interface to RoI objects is in the process of definition. There is a technical problem here with the back reference to the original towers, a solution for which needs to be found. Ed also commented on the RoI class definition, noting that the generic RoI is essentially only an interface definition.

      Limitations in the use ATLFAST software used in the generation of trigger towers are its representation of the calorimeter as flat and single layered. UCL people are addressing the latter problem.

      Ed has documented his work and is using doxygen for the code documentation, as are others in the level-1 software community.

      Remaining areas of work are the finalisation the RoI interface, the completion of trigger algorithm and TriggerTowerMaker coding, and the completion of his documentation.




Other items

Work on Fujitsu CANbus solution - Dave

      Dave presented the status of his development of CANbus solutions for our DCS monitoring. The Fujitsu micro-controllers offer a single chip solution, with onboard flash, up to 3 independent multiple CANbus interfaces and an on-chip 10/8 bit ADC.

      The development environment is a C/Assembler cross development system. Dave remarked that example code from other implementations has been difficult to find, as may people prefer the 8051 based micro-controller from Philips.

      He is using a demonstration board to develop a simple voltmeter (in debugging) which will eventually interface to CAN. He has two boards, now, so a dual node system can be constructed.

      Norman asked whether the development tools available under another OS might be better. Essentially not, and in any case the DCS end close to hardware is dealt with by NT machines. ML asked whether a CANOpen software layer will be used. Hopefully, but it isn't clear what is available for the (proprietary) Fujitsu controller: some CAN development solution will be needed.

      The question of from where crate voltages should be monitored was addressed (an extension of an earlier question concerning powering (on/off) of a crate.) Is a crate voltage 'owned' by a crate or rack controller? JCOPS may have a view here. ELMB might provide a good solution, easy to implement outside the environs of the crate. ML suggested that such an implementation might present a good case in which to test the ELMB.


TileCal trigger towers - Eric

      Eric reported on an issue which has arisen concerning the Level-1 interface with the TileCal.

      The good news is that Sten Hellman has assumed the rôle of level-1 contact- person which was left vacant with Paul Bright-Thomas' departure. PBT left very detailed notes about the status of our relationship with that group. Hence, it came as a great surprise to Sten when he realised that the current TileCal Trigger Tower specification (Eric's second slide) differs in significant ways from the previous status (Eric's first slide) which had reflected a post-design-review of the adder.

      In particular, the numbers of towers in the barrel and extended barrel has been changed from (9/6) to (10/7). In addition, it is stated in the new document that Level-1 has agreed to provide summing of tower signals from the overlap region, which is NOT the case.

      Jim Pilcher has been asked to clarify the situation from the TileCal perspective.

      An additional concern is that the TileCal people who had intended to try to order cables so as to benefit from a bulk order for LAr, seem now in no rush to do so (and apparently are willing to incur the additional financial penalty that that might imply).


Preparation for ATLAS week 19-23 Feb - Eric

      Eric expressed disappointment that there were no firm plans for ATLAS week TDAQ meetings, other than a PESA meeting on the Wednesday. The steering group has yet to meet, the DIG sleeps, the IB needs a new chair. In addition the timing of this meeting the week before our Birmingham joint meeting makes the timing awkward.

      Murrough and Ed plan to attend for the whole week, and Eric will attend much of the week. Bruce may attend, depending on the distribution of meetings and other commitments.

      Nick plans to be at RAL on Monday February 5: this will provide an additional forum in which to discuss pending issues with Level-1.


Preparation for Birmingham joint meeting - Birmingham group

      The arrangements for the joint meeting in Birmingham are well underway, with a nicely designed information and registration page. It is hoped to provide a laptop computer and a projection system for the convenience of the participants (see below). Attendees should be aware that no network access will be available in the meeting rooms

      The question of the need for a brainstorming session arose, but there is apparently no call for one at the moment.

      The usual format, with a software meeting Thursday morning, will be maintained. It is expected that much of Saturday morning will be devoted to discussions of details concerning slice tests expected in 2001. 




Comments on presentation formats - all

Ed suggested that we should try to move away from foils as our primary method of displaying presentations: direct projection of same has become quite comfortable in the last years. Norman observed that this is true if the projection hardware is modern, but in some cases it renders details difficult to see. On the other hand this technique allows immediate reference to technical documents, earlier talks and so on, depending on the degree of preparation and availability of network resources. (In the absence of networks, floppies or CDs would be the obvious media).

Heidelberg experience has indicated that powerpoint or PDF formats are most convenient. Landscape format, is of course, most appropriate.

Some individuals expressed concern that overindulgence in multimedia should be discouraged at this point!


Next Meetings

19 -  23 February: ATLAS Week at CERN
1 -   3 March:     Joint meeting at Birmingham
6 April:           Next UK group meeting (RAL).






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