CERN QMUL
L1Calo Software meeting on 11 September 2002
Present: Bruce, Eric, Murrough, Norman, Steve.Status of CPROD/DSS integration
Considerable progress has been made on integrating the software for the CPROD/DSS test system. The generation of test vectors, loading them into the hardware and simulating the predicted outputs is all handled by the run control and configured from the database. The run control also starts the "kicker" program to read out data from the DSS and compare it to the predicted outputs.Since the hardware is currently broken it has not been possible to verify the software properly. We hope to do this soon and to run a wide set of test vectors through the system. Steve has collected all of Bills example files into a set of six test description files (one each for RoI and different number of DAQ slices).
We should try to make a proper release of our software soon. This released version can then be used by Tony and Eric to test the new RODs and DSSes.
However there are a few improvements that would be good to make first. These include reporting an error if the kicker program dies and adding a new DataGenRecipe like class to indicate the overall test description file (or "Bill" file). It would also be good to add timeouts for some module services operations which currently have wait loops.
Following the first release a number of other enhancements are required. We need to improve the way in which sets of different tests can be easily executed. At present each test requires a separate database (at least two files changed).
We also need to allow multistep runs. These fall into two main categories. The simplest case is where we generate more test vector data than can be loaded into playback memories at once. Here the generation and simulation can all be done in advance and each run control step loads new data into the hardware. The other case is where we want to step through parameters, eg of the trigger menu. In this case it will be easier if the simulation is rerun with the new database values at each step.
Status of CP subsystem integration
The CPROD/DSS test bed work has provided essentially all the framework we need for testing the CP subsystem. However much of the implementation is still unfinished.For the CPM, more work is required on the CPM module services and in particular its used of the database. A "kicker" like program will also be useful for tests which read out the CPM scan path and the DAQ and RoI readout memories. A change to the simulation is also foreseen to cope with the readout of many DAQ slices properly.
For the CMM, both the module services and simulation are not complete - mostly because the documentation of the programming model for the two FPGAs is not yet available. We also still need to produce suitable test vectors for the CMM.
We also need some additions to the DSS module services to add (or bring up to date) support for some of the daughtercards (eg GIO, LVDS) which havent been used in the CPROD/DSS tests. The new DSS firmware for generating TTC signals also needs to be tested.
Standard platform
Following some recent exchanges on the mailing list we discussed the recommendation for our standard platform. The preferred option is to follow CERN and use RedHat Linux 7.2. This will be used at RAL and is the expected platform for the slice tests. However at other sites we may need to fit in with the preferences of the local system managers.It is not clear whether we also need to follow CERNs choice of the gcc 2.95.2 compiler (instead of gcc 2.96 which is the default on RedHat 7.2 and 7.3). Some parts of the Online software (which we dont yet use) dont work when built with gcc 2.96, but we have had no problems building our code with 2.96 and linking against the Online libraries built with 2.95.
CERN have made available an RPM of gcc 2.95.2 which installs into a separate area (not /usr/bin) and thus can be used along side the default gcc 2.96. The RPM is available at /afs/cern.ch/asis/RPMS/i386_redhat72/GNU.LANG_gcc-alt-2.95.2-1.i386.rpm
This exact CERN standard Linux is likely to be required for the ROS. We need to check if the ROS group have a distribution of a complete system (ie operating system, kernel patches, drivers, etc).
Common TDAQ CVS repository
Several of us felt that the proposal for one administrative account for the L1Calo group was too few, though the idea of restricting the granularity of write access to just the L1Calo part was supported. Moving our repository to CERN was felt to be a low priority project, perhaps to be left until the present state of rapid change was over.Calibration document
It was felt that we ought to include a more detailed concrete proposal of how we expect to do a calibration run (eg with the TileCal) into the document before sending it to the calorimeter representatives for comment. This should include the (long promised) sequence diagram and also a more specific (bulleted?) set of text in chapter 4 of the present document.We would also like to arrange a meeting with them soon. So the pressure is on Murrough and Norman to provide diagram and text respectively to submit to Thomas as soon as possible.
Timeouts and error handling
As mentioned above, all module service hardware actions invoked by the run controllers should have timeouts from any wait loops. The run controller must be able to find out, either by catching an exception or from a return code, that a transition has failed.At present the module services packages throw "new" exceptions which must be caught by pointer (unlike HDMC which throws temporary objects that must be caught by reference). We will not change this at the moment, but some catch blocks need to be corrected and should also delete caught ModServException).
Strategies for test vectors and comparing results
As mentioned above, the database needs a new class, like the existing DataGenRecipe, to provide the overall test description ("Bill" file) to the run controller responsible for the generation. It would also be useful for simulating internal data (which is not normally read out) if the DataGenRecipe data type could be officially available and extra data types defined.To run tests to check the internal CPM data (eg DAQ and RoI dual prt memories and the CP scan path) we will need a program similar to the existing CPROD/DSS "kicker". Like the CPROD/DSS tests, such CPM tests are expected to involve just a single module.
For test which involve more than one ROD we will require the ROS. We do not propose to extend "kicker" to cope with multiple DSSes.
Wrapped enum classes
We recently added a set of automatically generated classes to the infraL1Calo package which essentially wrap an enum. Many of these are used to convert database enumerations (lists of strings) into C++ enums.The originally agreed proposal for these classes included the concept of an uninitialised state which was however not included in the implementation. After some discussion this change was retrospectively agreed and we also agreed to remove the default constructor from the implementation too.
HDMC related issues
Norman suggested, some time ago, a change to the APIs of the register classes generated by the regbuild program. It would preferable to prepend "set" or "get" (or perhaps "write" and "read") to the method names that read or set each bit field. The present scheme uses egBitField() to read a bitfield and
BitField(value) to set it.
This can be confusing if the bitfield names include a verb, which is
frequently the case for pulse registers.
However the present syntax is used in a lot of existing code and it was felt that changing it now would be too much trouble. But we could investigate trying to protect against reading pulse registers by adding an extra attribute to the HDMC parts file, eg Pulse (ie WriteOnly) to the existing ReadOnly flag.
Other desirable changes include moving HDMC into the CMT framework. This is probably not too hard. The idea would be to make two packages, one for the hardware and one for the GUI. Obsolete code would not be moved into CMT, but would still be available in the old repository if required.
A more difficult change would be to replace the "MyStl" classes with the proper STL equivalents. This would mean our purely DAQ applications would no longer need the Qt libraries.
Lastly, it would be useful to have a little package which provided the HDMC binary linked with all our module services packages.
Website
We briefly discussed improving the website. Norman made some suggestions a few months ago: eg some reorganisation and renaming of the main headers and addition of a search facility. However it was felt that this was not a priority at the moment.Module inventory
We would like to find a simple web accessible database to record the whereabouts of all our modules, daughtercards etc. Norman will ask for the suggestions via the DIG.ATLAS meetings
Murrough intends to go to the next ATLAS week (6-11 October). There is also a software week (16-21 September) at Royal Holloway. Some of the CTP group may be there which will be an opportunity for private discussions.Next meeting(s)
To be arranged.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
- Norman: add calibration text to DAQ overview document and distribute it again
Last updated on 11-Sep-2002 by Murrough Landon