Mirrors CERN QMUL |
ATLAS Level 1 Calorimeter Trigger Software | |
L1Calo Software | Minutes: 27 May 2004 | |
![]() |
Software phone conference on 27 May 2004Present: Adrian, Bruce, Dimitri, Eric, Florian, Gilles, Kambiz, Murrough, Norman, StefanR, Steve.PPM softwareFlorian has again updated the HDMC register list with recent changes and has made corresponding changes in the XML tree structure for loading them. This is now parsed by a new class PpmCal. At the moment this class is part of ppmServices but for use by ppmSim it should be moved to dbL1Calo and the DbPpm class changed to return an instance of it. So far the ppmServices have not been used on real hardware but this will happen soon - first loading the FPGA. HDMC issues: A32 and regbuildFlorian created a variant of the VMEBusCERN with a larger address map for A32 access. Meanwhile Bruce created another variant using programmed IO instead of memory mapped access. Reserving the lowest 16Mb of the available A32 space for A24 accesses, this can handle both A24 and A32 accesses as long as the module addresses are arranged suitably. It also offers better bus error protected and in tests at RAL didnt show any obvious performance penalty. We agreed that the programmed IO bus should become the default with the two memory mapped buses renamed and kept as alternatives. After the last meeting there was an email discussion about changes to the API of regbuild classes. However the feeling now is that it is not appropriate at the moment to change the API, even in a backwards compatible way. The only change made, thanks to Bruce, has been to use the correct gen_read and gen_write calls which take account of ReadOnly and WriteOnly access to registers. PPM simulationThis is now complete, including the readout, except for all the configuration parameters. These can be added when the database changes above have been made. CVS repositoryThe hepunx machine at RAL is down, suspected of being hacked, so we currently have no pserver access to our CVS repository. If this is not restored soon we may need to consider alternatives. At some point we should move to the CERN CVS servers - this may be useful for the test beam? The CERN CVS servers are accessed via Kerberos and SSH so at least would not be vulnerable to pserver weaknesses. Murrough should ask Andrei Kazarov about moving (on some as yet undecided timescale). JEM softwareStefan proposes to rename the old jemServices package eg to jem0Services and put the new JEM software into jemServices. There will be some renaming to be done in other packages including the database where a new class will be required. We agreed to coordinate making these changes on Tuesday 1 June. Among the jemServices developments is a new class moduleFIFO for memories accessed as a FIFO. This is a generic class so could be moved into halCore. Stefan has tried moving the HDMC GUI panels for the JEM from hdmcL1Calo into allModules since they will now use jemServices code. But at the moment there is some problem with this - to be investigated. It was suggested that it might be cleaner to have a separate package. If there is good progress with the JEM and its software, the new JEM will be brought to RAL for tests in the week starting 7 June. Simulation and databaseSteve has recently added capability in the simulation to use L1A generated from the trigger itself. This needs some database work to provide a CTP object to which cables from the CMMs can be connected. Some database mods are also needed to allow testing the CMM outputs by looping them back into the CMM itself. MonitoringAdrian reported that his software is now almost completely moved into the CMT environment. There is still a problem with generating code with rootcint - a CMT make fragment is needed. There are two applications. One is the monitoring task framework. This has two threads: one analysing events with support for user code to produce either Raw or Root histogram objects, the other periodically (at lower frequency) updates the histogram objects in an IS server. The second application is the histogram display. This also contains features that can be customised by user code. Adrian is currently writing documentation for both of them The next steps will be looking at eformat. Now that the event formats are all defined in the recent ROD spec, work on decoding can begin. There should be discussions about this on the at1soft list so we can converge on an agreed architecture. Adrians code needs some modifications to the online software (two oh header files need fixing). There is another bug which should be reported: the monitoring factory doesnt clean up properly if a monotoring program exits with an event request still outstanding. Also, the reporting of monitoring statistics to IS irritatingly keeps creating new IS variables. There is still a pending action is to collect other documents. The monitoring requirements have recently been updated. We also need to integrate the the various calibration documents. ROD Crate DAQMurrough has done a little more investigation, so far just accumulating questions. Its still not clear whether migrating will be hard or not. Given the overcrowded slice test schedule the only reasonable week to make a migration would be that starting 14 June. We should decide by the end of next week (4 June) whether or not to make the move in that week. There was some feeling that we should concentrate on testing modules and not make any more changes than strictly necessary. Conditions DatabaseThere has not been time to look into the Conditions Database any further since the last meeting. As with ROD crate DAQ its not clear how much effort is involved in using it. Murrough estimated several weeks. There was a feeling that it would be desirable to keep track of calibrations as they evolve in time and to have them easily available to offline processing. However again it is effort and perhaps we can continue to live with existing ad hoc solutions (ie OKS) and/or flat files. It may be possible to live with just one (or a few) sets of calibration settings for the near/medium future. It was suggested that Murrough investigates further and presents a recommendation at Stockholm. Online/Dataflow migrationThe latest online-00-21-02 and DF-00-09-00 releases, intended as the test beam standard releases, are already in use at RAL. A ROD firmware issue for version 2.4 of the event format is being worked on. We should therefore get all sites to move to the latest versions, complete with several patches each. The dataflow release needs some extra to its setup script. We should distribute a fixed version. Next meeting(s)Another phone conference was arranged for Wednesday 9 June at 14:00 UK time (15:00 german time). The usual number +44 (0)1235 44 5420 and arrangements will apply. Last updated on 15-Jun-2004 by Murrough Landon |