CERN QMUL
L1Calo Software meeting on 25 July 2002
Present: Bruce, Eric, Gilles, Murrough, Norman, Steve. Also for video conference with Heidelberg: Karsten, Oliver.Video conference with Heidelberg
We held a short video conference with Heidelberg during part of the meeting.Oliver described his work on software for the Asic/MCM test system. He has written a small standalone DAQ system to configure and read the PPrAsic via dual port memory hosted in FPGAs on the MCM test board. In principle the Asic can be configured this way and the LVDS output or data read out via the serial link can be stored in ROOT files. However the firmware is not complete so the program has not been tested on real hardware.
It is not clear what the future of this program is, as once Oliver leaves, VME access to the Asic will be taken over by Ralf who is more familiar with using LabView as a diagnostic tool.
Karsten has been developing the firmware for the three FPGAs on the MCM test board. Work on this is suspended until he has written up his diploma thesis. He expects to stay on for a few months afterwards to complete this work.
Some disquiet had been expressed by UK colleagues about the move to use LabView. This is a very useful diagnostic tool (as also used at RAL), but it was agreed that it was not expected to be developed as a substitute for the software within the ATLAS DAQ framework which will be needed for the slice tests.
We wished Oliver all the best for his future travels.
Actions from previous meetings
- Murrough presented a draft schedule for "evolutionary delivery" of our software at Stockholm. We discussed it further later in the meeting.
- Other actions are carried over.
Report from TDAQ week
Norman and Bruce gave brief summaries of the recent TDAQ week. This was mainly organised as reviews of the subsystems. Norman and Bruce were involved in reviews of ROS and Online respectively.The global issues working group has issued three reports (on partitioning, definition of a run, and databases) which were felt to be useful but not yet agreed or mature. Eg checkpointing of changes in run conditions needs more work. One idea is to tag the run number in the RODs.
Among other items of interest to us, there is a new RoIB design proposal with separate input boards using full Slink protocol. We are invited to another test with them when this is ready.
Arising from the aim of having common ROS and Data Collection packages, there is work on a common threads package.
The next TDAQ week will be in November, possible preceded by a ROD workshop.
Evolutionary delivery
We discussed the last two slides from the talk Murrough gave at Stockholm. The sequence of steps and the (hoped for) timescale seems right.Calibration document
Thomas, Norman and Murrough have been writing a document on our proposals for joint calibration procedures with the calorimeters. This is still a bit sketchy. We need more "provocative detail".Overview document
Norman will add some words on calibration to his draft document and distribute it again. We would also like it to refer to some of our other documents but at the moment many of these need to be brought up to date.Murrough: package status
Murrough reported on the packages for which he is responsible. Some new functionality has been added to the L1CaloPolicy package. Theveryclean and instclean targets
were added some time ago.
More recently moc and uic document
types were added to run Qt code generation tools. These
(at least moc) will be useful in moving HDMC
into CMT. Their immediate use is to allow the primitive
trigger menu editor (in the confL1Calo package) to be built
again under CMT.
The only change in the rcL1Calo package has been the addition
of a very trivial run controller to run the simulation. This
has not yet been committed to CVS and will now wait for expected
changes in the simulation packages.
Several new scripts have been added to the scripts package.
The importpkg.pl script imports a new package into CVS
after making various checks and remoldver.pl cleans
the l1calo directory of older versions of packages.
The pkginfo.pl script has been rewritten internally,
mainly for use by the new makerel.pl script which
builds complete nightly or (eventually) stable versions of all
our software. This script has the facility of sending emails to
the authors of packages which fail to build. It was felt this
should not be enabled just yet.
Bruce: package status
Bruce reported on the developments in his packages and in HDMC. The HDMC GUI now reads his "daquery" files, now expected to have suffix.daq which specify lists of parts files to be
merged. The collection of parts files needed to use HDMC with
module services can now be read with a single menu operation.
Each module service package should now have an hdmc
directory containing .daq and .parts
files to be installed in a common area.
It should also have a .bits file to be incorporated
into the global default.conf file. These files are
processed by new CMT patterns added to the hdmcExternal package.
The DaqInterface class in moduleServices has been changed to pass the database class once to each module, rather than in each state transition call. This has necessitated changes in all other module services packages.
A new package "exceptL1Calo" has been added to provide a facility to use exceptions in a clean way. However in later discussions we agreed to incorporate this with some other common types and other infrastructure in another new package "infraL1Calo" which will be created by Murrough and Bruce in the near future.
Gilles: package status
Gilles has started updating cpmServices with the recent changes to moduleServices interfaces. However he sees a problem with the newly included "daquery" functionality in HDMC.He has developed, but not yet tested an I2C controller part and associated TTCrx submodule which should provide access to all TTCrx registers via the I2C bus.
The flash RAM loader part is not yet in CVS. This should be named to show that it is specific to the CPM (it contains internal register offsets). We should add this to CVS, but also aim to create an interface (virtual part) to define the generic functions for flash RAM loading which could then be the base class for similar parts specific to the CMM, JEM, etc.
Steve: package status
Steve reported the developments in the simulation packages. He has tidied up handling of the Glinks and has implemented a first version of the L1A handling. Each model module now has a TTCinfo data port which receives the L1A, bunch ID and event ID (but not ECR). The source of this information is a very simple file which presently just specifies the set of intervals between successive L1As. However we agreed this needs a little extension to implement the two buffers in the new DSS firmware.Steve also mentioned another significant change related to reading test vectors. In the past playback memories were effectively implemented by the file readers. Now the playback memories are included in the model of each module and are loaded once at initialisation from the test vector reader interface. This seems more elegant. One of the consequences is that we now need a (very simple) model of the DSS.
Extensive further discussion of the test vector reader interface continued later in the meeting.
Norman: package status
Norman reported that further work on the cmmServices is waiting for Ian to define the programming model for the playback memories. For the cmm simulation the next step is to provide a way of generating the test vectors. He would like to devise a suitable "Bill Stokes" like syntax. An alternative possibility would be to develop a few dedicated programs to generate particular patterns of test data.Test vector files
In discussing the input files to test vector readers, we agreed we should aim for a common format for these text files. The comment character should be # and we should consider using a common parser and syntax. Each file should identify the type of data it contains.We also need to define a directory and file naming scheme for organising collections of test vector files.
Test vector reader API
Recent changes to the API of the TestVectorReader class and associated factory methods proved a little controversial so we discussed them in detail. Some consequences for the package organisation are given in the next section, but first the agreed changes to the API are as follows.
- The select() method should be passed an object (not a string) which specifies the type and source of data requested.
- The next() method should not be const (to avoid having to use "mutable") and it should return "Word" not "Word&".
- The rewind() method is unnecessary and should be removed.
CMT package organisation
Recent changes to the TestVectorReader API introduced a dependency of the testVectors package on the database package (confL1Calo). This was felt to be undesirable.We agreed to modify the API (as described above) and the organisation of classes into packages to remove this dependency. A database-free version of DataGenRecipe and the as yet nameless object passed to the TestVectorReader::select() method will be moved into a new "infraL1Calo" package intended to contain common types and infrastructure classes. Both testVectors and confL1Calo will use these classes. The testVectors package will contain the TestVectorReader interface and its concrete subclasses. It will also have a factory class for creating appropriate reader objects according the specifications of the DataGenRecipe.
The majority of the simulation classes will then depend only on testVectors and infraL1Calo and not the database package. A new "dbSim" package will be required to bring together all the simulation packages together with the database. This will contain the DbSimulation class which will configure the entire simulation from the database. This class will be used by the run control. To preserve the independence from the database, the subset of the full set database settings for each module that the simulation needs will be copied to an xxxSimSettings object for each type of module.
CMT package management
We briefly reviewed our policy on how we manage our packages. Typically packages should be tagged before making changes to external interfaces or other changes which affect dependent packages. Developers should probably also tag before significant internal changes, though that is more a matter of personal taste.Changes to external interfaces should be advertised in advance for consultation, though the time for this should be short so it doesnt prevent work continuing. This will depend on the likely impact of the proposed changes.
CVS repository
After a recent minor accident, we now make our own private backups of our CVS repository. Meanwhile it was announced today that it is intended to set up a common CVS repository for the whole TDAQ project. We will be invited to join this at some point.Website, documentation and related issues
We didnt have time to discuss some suggestions for improving the website. However a few related issues were raised. Now that the HDMC CVS repository has moved to RAL, should the HDMC web pages also be moved? Murrough will ask Oliver.Steve has worked out how to use Doxygen tags to display links to classes from other packages properly. His linkSim package is a good example of how to do this. Alternatively he offered to update the Doxyfiles of our other packages if requested.
A large number of emails describing changes to packages
have been circulated on our mailing list. It would be good
if these were available as part of the package documentation.
Eg we could add a "Releases" file to the dox
directory somehow linked to the Doxygen documentation.
This would contain the history of changes in each tagged
version of the package.
An alternative (suggested after the meeting) could be to
have a "releaseNotes" directory containing a file for
each tagged version.
Next meeting(s)
To be arranged after the holiday season. In the mean time smaller working get togethers are encouraged.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 26-Jul-2002 by Murrough Landon