CERN QMUL
L1Calo Software video conference on 11 June 2002
Present: Bruce, Eric, Gilles, Murrough, Norman, Steve, Thomas.Actions from previous meetings
- Bruce has now stored the module services packages in CVS including the example module which can be used as inspiration for the CPM and JEM.
- Norman has further updated his overview document of the DAQ. He will circulate it for further comments.
- Other actions are carried over.
Bruce: module services, ROS installation
Bruce has split the module services code into a number of CMT packages which are now stored in CVS. The main package containing the base classes is "moduleServices". Each different type of module has a separate package depending on that and there is a cpRodTests package which contains the "looper" code. A testVectors package contains the interface to test vector generators. Bruce reported there were still a couple of technical problems, and one routine ought to be moved back into HDMC.Working with Murrough, the module services have also been integrated with the database package (confL1Calo) though some doubts remain over the best interface between the two.
Bruce has also successfully installed the ROS software using the new distribution and has given feedback to the authors. At the moment the ROS software needs an old Linux kernel and an old version of the Online software. A version for a later kernel and the current Online release should be available soon.
His next steps are to prepare the CPROD test code in a state suitable for others to use to test the new set of ROD modules, to work on documentation and to consider the API between the database and module services.
In discussion, the issue of the HDMC CVS repository was raised. The Heidelberg university firewall no longer allows outside access to CVS which has made tentative plans to move the HDMC repository to RAL (or CERN) more urgent. The new module services require updates to HDMC which Bruce cant save to Heidelberg. Instead, for the moment, an updated version of HDMC can be found via AFS at /afs/rl.ac.uk/atlas/groups/level1/hdsw/hdmcRal10Jun02.tgz (this version also contains the VMEBusCERN part required by Thomas).
Norman: overview document, CMM module services
As reported in the actions, Norman has updated the overview document and will circulate it for comments. The brief section on calibration will need further update when we have settled on calibration procedures with the calorimeters.Norman has also started working on the CMM module services. He has completed most of the code to configure the module and in the process has come up with a number of questions which we discussed later (see below).
Murrough: databases
Murrough has been away on holiday and at courses since the last meeting, so progress with databases has been small. The main developments have been extra classes for the CMM and other new module services packages.The recent integration of the database package with the module services is not yet debugged. To help with this, Murrough tried compiling the software on a Solaris machine at QMW with the aim of trying an evaluation copy of Purify. However the compiler needs updating. He will look into using Insure++ instead.
His next steps include continuing integration work with Bruce and in the slightly longer term starting to develop the framework for running sets of tests.
Gilles: CPM parts
Gilles has been involved in testing the CPM. As part of this he has developed a new HDMC part for loading the CPM flash RAMs. This is specific to the CPM, but could be adapted for other modules.He hoped to find an existing part for loading memories from a file, but as this facility does not yet exist within HDMC he will develop a new part for that too.
Now that Bruce has released the module services packages he plans to start developing the CPM module services.
Steve: simulation
Holiday, courses and a new born baby have left Steve little time, but he has been working on moving the simulation code into a CMT package.He has also had some communication with the Stockholm students. It appears they have been using a rather old compiler and thus having problems compiling templates. It seems a little worrying that they have gone on so long with this problem.
However according to an email from Sam, his students have made good progress in writing the JEM code and they expect to present their work at the Stockholm meeting.
Thomas: JEM
Thomas has been using a mixture of HDMC (to access the DSS) and standalone code using the VMELinux driver directly to load sets of test vectors into the JEM memories. Unfortunately its not possible to run both programs at once which makes it very inconvenient to work.It is thought the problem is due to the VMELinux driver not being shareable, so he has installed the driver from CERN and will try using that. He will need the latest HDMC updates from Bruce in order to have the VMEBusCERN part which accesses the CERN driver.
Thomas: calibration discussions
Thomas reported on the discussions that he, Norman and Murrough had at CERN with Rupert Leitner and Bob Stanek from the TileCal and (separately) Pascal Perrodo and Isabelle Wingerter from the LAr calorimeter.The two calorimeter groups are at different stages in their development and seem to be taking different paths. In particular the LAr approach is centred around standalone runs with local triggers which would be difficult for us to use.
Norman has prepared an outline document on our calibration requirements and procedure which Thomas will fill out with text and diagrams, some of which can be taken from existing documents. We expect to have a further meeting with the TileCal who also need to send us more information about their system.
In the discussion, Norman mentioned the ATLAS combined run scheduled for 2004 where both calorimeters will be present in the same test beam. We must ensure we take part in this.
Schedule, integrations, next steps
Murrough has not (yet) done anything more formal on the project schedule. However he recapped the next integration steps he thought we should make. In the discussion it was agreed that these needed defining in more detail, but in essence the first priority is to integrate the module services with the run control and demonstrate a minimal working system. Next to integrate that with the simulation. Adding the ability to run test sequences, monitor the event output via the ROS (eg to derive timing calibrations) and to organise sets of tests would be the later stages.Software workshops and visits
Thomas suggested it would be useful to him if he could visit us, eg Bruce at RAL, to gain some experience in how we have been testing our modules. At a later stage it would also be useful to have an internal training session on our software, eg how to develop module services for other modules.A software training session might be useful also to others, but takes time to organise and would probably be best a bit later. Meanwhile Thomas will come to RAL next week (17-18 June).
At this point, the video conference with Mainz ended.
Suggestions from project management course
Bruce, Murrough and Norman all attended a course on software project management recently. We briefly discussed some of the issues raised:- Assessing the project risks (eg consequences of misunderstanding our requirements and of incorrect assumptions, schedule slips, turnover of personnel, etc). Murrough will try to make a list.
- One suggestion, even for small projects, was to assign certain roles within the project. We didnt discuss this.
- A number of issues relating to scheduling. We have had the problem of our schedule being linked to lengthening hardware schedules, but we have still not done much to analyse our own work breakdown, interrelation and priorities of different tasks. We havent set milestones etc. Murrough will have another go at a Gantt chart and also try to list a few steps in the evolutionary delivery of our complete software.
- We havent done much in the way of quality control reviews, walkthroughs etc.
- We may find it useful to try a CRC session (roleplay of the responsibilities of objects), eg around the issues of calibration.
- We should think about where our project lies on the triangle of time, scope and money.
Normans questions
Norman had circulated a list of questions relating to the expected behaviour of the module services, the run control and the relations between them. The discussion was quite extensive and the following is only a brief summary.- Q: when compiling packages, can we suppress the normal output
in order to see warnings more clearly?
Murrough will look into this. - Q: can we assume run control will go through the modules in
a defined order?
The present design of the run controllers implements a defined order within the crate, according to the order the modules are listed in the database. Between crates, the run control hierarchy can be arranged to be ordered or not as required. - Q: should module services read back values in registers to
ensure they were set correctly?
The best place to do this would be at a low level, eg in the HDMC Register part. However at present the parts file syntax doesnt pass the information about read only and read/write bits to the Register part, so this cant be done yet. It should be an aim for the future. - Q: what should module services do if it detects an error?
What state is the module left in after an error?
At the moment the easiest thing would be to throw an exception. The run controller must catch all exceptions (which may also be thrown from lower layers, eg in the case of bus errors). If the exception class contains details of the error, the run controller can issue a suitable MRS message. The module should not "know" its state - the run control keeps track of this. Each module state transition action effectively assumes it is starting from the previous state. However, if a state transition action is allocating memory on the heap, then the module would need to catch exceptions itself. - Q: should module services include some low level register
tests to be optionally executed by the run control at startup?
Some essential sanity checks should be performed at initModule time, but probably more extensive tests should be kept as separate test programs, eg to be run for single modules by the Online software Test Manager and for groups of modules via special test runs. The HDMC Part class already has some infrastructure for making "verify" tests on a Part and its child Parts. This may be useful for implementing such tests. - Q: does a module maintain and report its state? Does someone
insert this into the Information Service (IS)?
The module service class does not maintain its state, but can report its state (eg module present, link state, link errors, parity errors, FPGA versions, etc) when requested by the run controller. It will return an private object which the run controller will copy into an IS object. - Q: any hints on handling common TTCrx infrastructure?
We had discussed a while ago implementing an HDMC Part for the TTCrx but this was never done. The idea is that this should present the TTCrx registers we need (two phase registers, one combined delay register and maybe the status register) and hide the implementation via the I2C bus (which already exists as an HDMC Part). The TTCrx part should also hide the conversion of desired clock phase to the required register bits using the function provided by the TTC group. Gilles offered to develop this part. - Q: what is supposed to be done in module services on each
transition?
Our software note 001, stuck at draft 0.3 since last February, contain some tables suggesting actions at the crate level for the different crates. The tables followed suggestions by the Online group for the type of activity in each transition (eg read the database only at load(), access hardware only at configure(), download run type dependent settings at start()).
However we now expect to need more states to set up the hardware correctly (in particular the readout chain via Glink, ROD, Slink). The tables should be extended to show how the crate actions map to module services actions which should give the details. The necessary steps in initialising the readout chain should be added to the section on synchronisation issues. - Q: who launches the simulation?
In previous discussions we expected this would be done by the run control at a suitable point in the run control hierarchy. - Q: what is the general procedure for handling replay mode?
We didnt have time to consider this. It requires more detailed discussions in future.
Next meeting(s)
The next meeting will be in Stockholm, although several of us will be not be able to be there. Following that we should aim for a videoconference with Heidelberg before Oliver leaves.Actions
Actions from this and previous meetings:- Bruce: complete Module Service document and submodule syntax description
- Bruce/Murrough: define required HDMC improvements
- Murrough: tackle project management issues: eg schedule (Gantt chart, stages of evolutionary delivery), risks, etc
- Murrough: write database user guide
- Murrough: complete run control design document
- Murrough/Bruce/Oliver: merge HDMC and other L1Calo CVS repositories?
- Norman: distribute DAQ overview document for others to comment
Last updated on 11-Jun-2002 by Murrough Landon