Mirrors CERN QMUL |
ATLAS Level 1 Calorimeter Trigger Software | |
L1Calo Software | Minutes: 17 February 2004 | |
![]() |
Software phone conference on 17 February 2004Present: Adrian, Bruce, Cano, Florian, Gilles, Jürgen, Murrough, Steve, Thomas.Making an L1Calo software releaseWe had previously agreed to make a release of the present state of the L1Calo software before moving to the next version of the Online and Dataflow software. This should be a very light process as we will continue to use the HEAD version of packages from CVS. We decided not to try to make any major changes for the release. The only exception is that the current JEM firmware bit files could be included in the jemServices package and installed into the installed/firmware area as is done for the CPM. The procedure will be as follows. The release will be l1calo-00-01-00. All package authors should tag their packages with a 00-01-00 version suffix (ie confL1Calo-00-01-00, etc) by 16:00 GMT tomorrow (Wednesday 18 February). The release will be built that evening and we will try it at Rutherford on thursday. Moving to the new Online/Dataflow releaseAfter the release we will try to move to the new Online and Dataflow releases. We would like to move to the very latest Online release (00-21-00) though the corresponding Dataflow release is not yet available. This probably does not matter except at RAL where we want to use the ROS. We will probably have to stick with online-00-20-00 at RAL for the moment. There are a number of changes in the new Online releases.
The schedule for the migration will depend on the results of tests we still have to make at RAL to see which combinations of online/dataflow releases work together (without the ROS) and which we can therefore use outside RAL. People will have to install the new Online and Dataflow versions on their machines. Some instructions for doing this and for rebuilding the drivers will be circulated by Murrough and Bruce. HDMC, VMEBus and A32 addressingThe PPM, the 9U ROD and the TCM with VME64 adapter card will all live in crates with A32 addressing. Although most of the registers will be accessed via A32, the A24 configuration space defined in VME64 needs to be accessed first to set each modules A32 address. At the moment HDMC only supports A24 access to VME. This needs to be changed, most urgently for the PPM which will be available in a few weeks time. Just before the meeting Bruce had circulated a list of the issues involved. The options for implementing A32 involve changing either the AddressD8,16.32 classes or the Bus class (or both?). Adding an attribute to the Bus class seemed preferable but still leaves the problem of A24 access in A32 crates. Florian had also raised the issue of how to incorporate the homebrew CPU. We would prefer to use the CERN VME driver only if possible. At present in HDMC we use memory mapped access to the VME driver and we are not presently checking for bus errors (which dont work very well - if at all - in this mode). It was suggested we should consider moving to the programmed IO mode instead. PPM related issuesFlorian has started looking at loading the RemFPGA on the PPM. Existing HDMC parts can be used but need to be subclassed to override register offsets in the base class. We ought to make the base class a more abstract interface. There is also scope for rationalising the ways the various modules load their FPGAs. Florian would also like to add an HDMC panel for configuring the PPM via HDMC. Ideally this should use the database rather than private files and hence should live in the hdmcDb package. However Murrough needs to do some extra work to make the L1Calo database object available to GUI panel classes. MonitoringAdrian has started studying the training for the Online software. He has also arranged to visit CERN for some discussions in March. Steve and Dimitri have started using the Online histogramming package (OH) to present histograms from the CPM timing scans. Its easy as long as you use exactly the right version of ROOT as list in the Online training guide. Steve raised the issue of the eformat package and versions of our ROD firmware. Bruce will check to see if the latest revision of the event format document issued last week (with additional run number word in the ROD fragment header) is the one expected to be used in the test beams. If so, we will need further changes to the ROD firmware. Next meeting(s)To be arranged. We will perhaps have one more phone conference before the Heidelberg meeting which will include the usual software slot on Wednesday morning (10 March). Last updated on 17-Feb-2004 by Murrough Landon |