CERN QMUL
L1Calo Software Meeting at CERN on 17-18 October 2001
Present: Bruce, Gilles, Murrough, Norman, Oliver, Steve, Thomas.Survey of the system, software and timescales
As an introduction for Thomas, we started by briefly reviewing the slice test system, our proposed set of packages and the relevant timescales.We know that one of the urgent areas we need to address is still the set of interfaces between the Hardware Access Layer of HDMC, the Module Services, the Database and the Run Control. We discussed the module services package at some length later in the meeting (see below).
The work on test vectors and simulation is fairly detached from this and is well advanced for the CPM specific model.
Regarding timescales, we expect the first of the complex new modules to be delivered will be the CMM around December 2001, with the CPM following maybe Feb/March 2002, PPM by April 2002 and the new JEM perhaps a bit later (depending on the status of reworking the JEM0?).
Responsibilities
Thomas has the mandate at Mainz to be responsible for software for the JEM. In our software organisation that will include the relevant part of the module services package for the JEM and its subcomponents, and also simulation of the JEM for generating the expected outputs of test vectors. Mainz have a new student who may be able to help in this work.Oliver reported that he may have to carry out some urgent work on the PPROD in order to be able to test the RemFPGA code before Dominique leaves. Heidelberg is also hoping to recruit a student to work with the Online software.
Test Strategy
We briefly touched on the strategy for testing modules. While we need to be able to use standalone test programs, the focus should be on developing the tests in the distributed run control environment.Module Services
We had a longer discussion on the module services package, revisiting the talk given in a previous meeting.The overall class diagram presented there was generally agreed.
However it is still not clear what the best strategy for initialising the modules from the HDMC and/or Online software database is. It is also not agreed on the relative merits of staying with the HDMC parts manager is compared with creating a modules subcomponents directly in the module constructor.
While our modules will be largely fixed after the initial development phase, it may still be desirable to keep the flexibility offered by the parts file approach, especially where FPGA configurations may be changed.
Whatever approach we decide on, one aim should be to keep the coherence between the DAQ configuration and initialisation and the view seen in the interactive GUI.
Aside from issues of creation and initialisation of the module services object structure, we also discussed their behaviour by running through the use case for starting a run.
One of the main caveats here is that the Online software IGUI allows the run type to be changed at any time up to the Start transition. This was felt to be impractical in the long term. [After the meeting, Murrough and Bruce expressed this concern to the new Online group leader, Mihai Caprini].
Another issue, related to object creation, is when we should be able to reload FPGAs if required. We require that the programming models of the modules relating to FPGA loading must be stable. Where possible the alternate FPGA programs for different personalities of our common modules (CMM, CPROD) should present the same register interface.
A further requirement on the modules is that any action requiring synchronisation must be available as a TTC command (and must also be implemented as a VME command). It must also be possible to make a clean reset of the module. In some cases (eg RODs) this requires that the inputs can be disabled. [Is the ROD BUSY enough to stop unwanted input during initialisation?].
Although the intention of the Load step is to load databases and establish network connections, we anticipate hardware access to check the loaded database is correct and that the right FPGA versions are loaded. This may be required for correct module object creation.
Downloading of calibration and other settings (trigger menu) may be in either Config or Start transitions - depending on a decision about the run type issue. NB the first draft of what our transition actions may look like (described in software note 001) assumes almost all configuration is done in the Start transition. The lists in that document need to be reviewed.
Run Control
The relation between module services and run control was discussed. Our prototype run control package envisaged two classes for each module: one class with the interface seen by run control which implements transition actions by calling methods of the second, hardware related class.A scheme for handling run types probably needs changing to a simpler concept where a run type object contains sets of options which can be queried by the modules to steer the required transition actions. It is possible that the run tpe object will need to be passed to the modules subcomponents.
A practical disadvantage of the "two class" scheme is that the person responsible for a given module needs to maintain one class in the run control package as well as class(es) in the module services package. We would have to be very clear about the division of responsibilities.
However one advantage of this scheme might be a more natural relation between the run control module and the simulation of that module. It could also make the hardware module class less of a "monster class".
Specific issues
During the meeting a number of brief points were raised which need further attention:- Agreement on minimum contents and format of error (and other) messages generated by software components. The MRS component of the Online software may already provide some standard parts of each message.
- Fault tolerance in HDMC: in some operations HDMC is not robust against errors.
- Also, the bus error handling exception mechanism doesnt work. It was thought that is used to work in the past, at least on some platforms. To be investigated.
Another HDMC related issue which was raised previously by email concerns deficiencies in the automatic generation of register classes from the HDMC configuration file. The register descriptions dont include the read-only, read/write or write-only flag which is only marked in the parts file.
Coding Rules
We started, but did not finish, looking through the ATLAS C++ coding rules document. We agreed most of the rules on naming conventions. One or two points require clarification or thought, and a decision by us, eg use of namespace(s).Earlier the question of whether to use exceptions and templates (apart from STL) was raised.
Readout
At the preceding (UK) meeting, Norman had presented a draft document considering all the readout issues. Given the new uncertainties over the future direction of the Readout Subsystem (ROS) our decision becomes more difficult. Norman plans to present our requirements to the next DIG forum (during the NIKHEF TDAQ workshop).It was suggested that Norman might formalise his draft, incorporating the discussion notes collated by Bruce, into a Requirements for Readout document. This could form the basis for discussions with the DIG.
Actions
Actions from previous meeting(s):- Oliver: circulate thoughts on software process (NB the TDAQ Connect Forum will make proposals at the NIKHEF TDAQ workshop, so maybe we should wait for them?)
- Norman: find/define remaining data formats
- Steve: documentation for simulation package
- Steve: consider organisation of test vectors
- Bruce: identify run types in the present CPROD tests
- Murrough: circulate instructions for using the run control demo
- Murrough: investigate CodeWarrior code development tool
- Bruce/all: investigate other software development tools
- Murrough: document run control prototype package
- Murrough: update HDMC changes document with recent suggestions and include the proposed long term strategy
- Bruce: write draft document describing Module Service package (requirements, design issues and suggested options, example APIs?)
Next meeting
The next meetings will be held during the joint meeting at RAL between 7-10 November. We decided that we should treat the morning software session on Thursday 8th as another informal discussion, preceded by afternoon discussions on Wednesday 7th. The Wednesday morning is still available if people arrive early....Last updated on 23-Oct-2001 by Murrough Landon