CERN QMUL
Home
|
L1Calo Software meeting on 7 August 2003
Present: Bruce, Cano, Eric, Gilles, Murrough, Norman, Thomas.The meeting was a long discussion which touched on a range of interlocking agenda issues. These minutes try to cover the main points, not necessarily in the original order.
Programme for the next two or three months
Many people will be away during August/September. A recent UK discussion tried to optimise the work that could be done. Next week (Tuesday possibly extending to other days) will be testing the L1A generation at RAL with RODs. Jürgen may be interested in tests with JEM 0.1 before it returns to Mainz. A ROD may go to Birmingham for CPM/ROD tests while Bruce is away. In September we continue to build up the slice test at RAL. In October we aim to test CMM to CTPd connection.A programme for JEM tests should be agreed with Uli, but may include more detailed timing studies with LVDS input and CMM output for some different positions in the crate. Testing with the jet algorithm is also needed. Some firmware issues in the JEM readout still need resolving.
Norman suggested we should draw up detailed checklists of tests to be performed and that we should also set up a testing mailing list.
Missing software required for this programme?
It was asked what software are we still lacking to carry out this programme?One area is the generation of L1As. This is nearly ready but needs finishing. A working DSS/GIO at Birmingham has helped. Some details were discussed later in the meeting (see below) and updated code will be tested next week.
Another useful component is TTCrx support code. Gilles has implemented a ModuleI2CRegister which can be used to provide an interface to a TTCrx register via Richards I2C VME interface. Unfortunately the CMM and CPM programming models implement this differently which must be fixed. The common solution can be used for JEM1. Putting together a set of ModuleI2CRegisters for all useful TTCrx registers into an HDMC SubModule (or custom part) with its own GUI would be a useful further development. A way of reporting I2C problems is desirable.
Sam has prepared a list of detailed backplane tests. Some may be tried in Birmingham. What tools are required for this?
In many areas we need a generic tool for timing measurements. This is not yet available - though many of the components are there. The infrastructure for multistep runs is available but untested and updated timing calibrations can be stored back to the database.
We have some custom tools for histogramming the results of eg CPM timing windows. We should develop these further and integrate with the run control. Its been a long time since any of us looked at the Online histogramming utilities.
Lisbon TDAQ workshop
We have been asked to say what topics relevant to level 1 should be discussed at the Lisbon workshop in October. Also whether we think there should be a dedicated level 1 parallel session.Norman suggested that many of the issues raised by the TDAQ Global Issues Working Group had not yet been resolved and should be discussed. For example general support for calibration and runs with many phases, run states (with hidden states), error handling and recovery. Also the status of databases relevant to TDAQ (in particular tools for competent but less than totally expert users) and the issue of scalability of the existing database and run control systems. Some aspects such as dynamic partitioning are under discussion or development but dont exist yet.
TDAQ meetings rarely have dedicated level 1 sessions. Issues for such a session may include use of common trigger menus and the trigger simulation in ATHENA. Also how level 1 will provide cosmic triggers, how we handle calibrations together with other detector partitions, and any common preparations for providing L1As at the 2004 combined test beam. There may also need to be discussion of the trigger rates.
Norman expects to go to this meeting, Bruce may (visa renewal permitting). Pete and Murrough may be able to attend part of the meeting.
Remote working
Can some tools to aid remote working help with our multisite development problems? For example, either passive viewing of screens to follow activities at the RAL slice setup from elsewhere, or active remote control of the RAL system from other sites (after due negotiation).Storing firmware
We have needed, but so far failed to agree on, a common solution for giving the software access to the firmware bit files we need to loaded into our modules.In the past there has been some reluctance to put them into CVS along with our software and suggestions were made to download them from websites maintained by firmware developers. But keeping them in CVS now seems like the most acceptable approach. To save wasting CVS repository space we should only store relatively stable versions, not all intermediate debug versions. To save having endless historical versions in checked out packages, we propose to store successive versions of the same firmware with the same name. A simple tool (eg hex dump!) to extract the version from the bit file should be enough, though some people would still prefer to keep the version also in the filename. In that case the database needs to be updated to match and old filenames should be deleted from CVS. The bit files should go into a subdirectory named "firmware" of each module services package.
If aspects of this proposal prove unsatisfactory, they can be changed later, but we should move to an initial common solution now.
Storing test vectors
The various test vector inputs (Bill files or generator control files) are also not yet handled very well. However discussion on this issue was less conclusive.Many of the generator control files are just intended as examples to be edited. They may also be simple enough to be moved into the database and be set by run control.
The original CPM "Bill file" syntax is more complex and would need to remain as files. However the present organisation by partition is not necessarily the best one. Maybe by run type would be better. At the moment some of these files are actually in CVS in various packages (eg cpRodSim/data and dbSim/data). However they are not installed to a common location.
We will also still want to use already generated files, eg from previous or future physics simulations. We will need converters from ATHENA output formats to our input files.
The issue needs more discussion in a future brainstorming.
JEM test issues: Cano
Cano has been using run control to carry out recent JEM tests. He reported a number of outstanding issues.The TTCvi module services dont yet handle broadcast commands configured in the run types. Murrough has written the code but this is not yet committed and tested. This should be done soon. Bruce remarked that the issue of use of TTC broadcast commands bits by all our modules should be reviewed.
Cano also needs an extra flag in the run type to specify whether his test runs in a playback look or a single shot. This needs to be added to the database.
Database issues
We discussed the problems of preparing databases for a number of different tests.The original idea had been to make separate partitions for different sets of tests with similar hardware configurations. However the tendency has been to grow the same partition (eg RalTest) rather than clone and maintain separate ones.
Some aspects of our use of the database (eg complex objects structures such as our run type system) make duplicating and modifying run types rather hard. This is partly due to lack of support from the database GUI tools (at least in past versions of the Online software). Also the proposed naming convention for modules in crates, while suitable for final ATLAS, may not be the best for allowing test setups to be used at both RAL and external sites with minimal modification. Some ideas for possible changes need to be examined.
To make it easier to reconfigure the cabling, Bruce requested that database CableConnections have an "enabled" attribute so the cable object doesnt need to be deleted while not needed and added back later. This was agreed.
Even though modules can be disabled, the DSS services need to make VME accesses while the HDMC parts file is read. The DaqModuleFactory should check the physical presence of a module before reading the parts file. This will only be possible for L1Calo modules which have a module ID.
Software update strategy
In an ideal world, we would keep the existing software setup (RedHat 7.3, online-00-19-xx) for the slice tests. However we also need to prepare for the 2004 combined test beam which is expected to use later OS and online versions. CERN is expected to certify RedHat 10 later this year. Meanwhile the forthcoming Online release due in September will start making significant changes to database and run control.One possible window for an update may be after the CP/JEP slice is reasonable well tested, but before the PP system is integrated.
On this subject it was reported that the RAL (and QMUL) setups have now updated to online-00-19-01 with various patches. This is basically a minor update, mainly providing various bug fixes. However among the patches is a new version of the event dump with a changed API. Dave Kant has updated his edL1Calo package so that it works with both old and new APIs. The updated online software is reported to fix some bugs in the event monitoring system.
CMM software: Norman
Norman has been working on both CMM services and simulation recently. The programming model has been updated again, the documentation updated and corresponding module services changes committed to CVS. There is one further known update required for the services to correctly enable the TTC. This may be done by Gilles as Norman is about to go on holiday.Meanwhile the simulation now runs the e/gamma algorithm in normal mode (ie no playback memories).
L1A generation details
After the phone meeting ended, we had a more technical discussion about the detailed implementation of the L1A generation via the DSS/GIO system. The DSS firmware permits a complex cycle where one orbits worth of signals can be repeated N times, followed by up to 8 further orbits each separately loaded into the remaining DSS memory. (The other way round would have been more convenient!). The whole cycle is then endlessly repeated.Steve proposes three basic modes, two of which have an initial implementation:
- Continuous mode. This is simply characterised by an average trigger rate. The exact rate needs to be tuned (by software) to optimise the simulation. Within the limits imposed by the simulation requirements and the two level DSS cycle, the L1As will be fairly evenly spaced. This mode has been implemented.
- Single shot mode. The intention is to provide a single train of a specified number of L1As at an average rate. Unfortunately the DSS firmware doesnt (yet) support this, but by making the number of initial orbits large, and making the run sequencer stop after a short time, eg during the first repeat of the initial orbits, a single shot mode can be emulated. If the average rate requested conflicts with the specified number of the events (and the DSS constraints) the latter is used. This mode is mostly implemented, but the extra long pause (of a number of whole orbits) needs to be added.
- Bursty mode. Here the average rate would be implemented as short bursts of a specified number of close L1As separated by longer gaps. The three parameters needed here are the rate, the number of events per burst and their separation. This mode is not yet implemented and is seen as lower priority (ie after August).
Since the parameters are read from a named IS variable, if there are two clients it would be better if the IS access was made at a single place, so this should be moved from dbSim into the L1CaloDatabase class.
Next meeting(s)
To be decided.Last updated on 07-Aug-2003 by Murrough Landon