Software phone meeting on 15 December 2005

Present: Bruce, Florian, Gilles, Kambiz, Murrough, Norman, Paolo, Richard, Stefan, Steve, Victor.

Status reports

CERN: cable test software, databases

Murrough reported that the scripts for running cable tests have had only a little development, but do now run two crates simultaneously. Meanwhile some problems of robustness of the software, eg in sensitivity to IS variable naming, have been fixed. Florian is also improving the robustness and error reporting in the C++ parts of the cable test software.

On the subject of databases, the most recent Online DB meeting had a talk by Beniamino di Girolamo about DB work for TRT, making minimal use of COOL and more use of real tables via RAL or CORAL). This might be interesting for us.

RAL: databases, VP315s

Norman has done a little work on the connectivity DB, mainly bringing it up to date with the latest changes to the cabling document and updating his documentation. There is now a new (non-CMT) package in CVS called connectivity which is intended to store scripts, data and eventually software related to connectivity.

Richard now has a stable way of taking data from CMMs and has been working on verification of the resulting calibration so the data could be ready to be used by the run controller.

Bruce has tested the new VP315 CPU with most of our modules. He has found and reported a problem with the ROS filar driver that has now been fixed by Markus Joos.

Bruce is also preparing changes to the SimpleBuffer API to make it look like the std::vector API and would allow a future implementation using std:vector. He will write a more detailed note about the proposed changes.

Heidelberg: monitoring, databases

Kambiz said that Victor is now starting work on PPM monitoring (see more discussion below). He also reported on work in the offlie work related to using large datasets via references in COOL tables. He will circulate what he has learnt about this.

Mainz: tdaq release, production testing

Stefan reported that the latest TDAQ release is now installed at Mainz, though not yet tested. Now the JEM PRR is over, Rainer will look at production testing software for the JEM and will need to know our intended direction regarding multistep runs vs the old "kicker" style. See below for the beginning of a discussion about multistep runs.

Run states discussion

The TDAQ controls group is proposing some changes to the run state model, mainly to improve the shutdown sequence, but also with some renaming of startup steps to encourage detectors to all put their time consuming actions into the first step to be renamed "Configure" (previously "Load"). The old "Configure" step will be renamed "Connect".

We did not react to this proposal when it was first announced so if we want to object we need to be fast.

We had a lively discussion as to how this proposal might affect us and what we thought about it, without really achieving a consensus.

Although there was general agreement that the aim of encouraging all subdetectors to do their time consuming actions during the first step was reasonable, some people were upset that the model was changing again after we have evolved a way of using the existing states.

Our discussions didnt come up with any immediately obvious showstoppers to prevent us combining most of what we presently do in "load" and "configure" into a single transition. However we may end up taking more time in total if we have to wait for FPGA resets to be "done" during the single new "configure" transition, instead of only inspecting the "done" flags at the start of the next transition (if thats what we actually do at the moment?).

Murrough was asked to email Giovanna with our concerns.

Byte swapping and VME bus types

So far we have be using software byte swapping in our software rather than use the hardware byte swapping capabilities of the Concurrent CPUs - except at the test beam. As hardware byte swapping is the ATLAS standard (and is faster) we should probably change to that. It would require a change in an HDMC class and in the vmetab file used to configure our CPUs.

Bruce will try doing this at RAL. However there would be a problem with the homebrew CPU which does not support hardware byte swapping.

On a related subject, we also discussed whether and how to use memory mapped IO to VME as well as the programmed IO we are now using. This would need different HDMC bus type classes for A24 and A32 accesses.

Bruce will think these issues and circulate a proposal.

Multistep runs, workshop at end of January

It was clear from a brief discussion that we need to have a more detailed session on and do more work on multistep runs. It was suggested that we have a two day workshop towards the end of January, allowing some time next year for development before the workshop. Murrough will try and find some suitable dates at CERN.

PPM monitoring

Victor has started working on aspects of PPM monitoring. We agreed that he should be using the objects (RDOs) from our bytestream decoder, and for VME readout, that he should write the converter to create the RDOs from the VME readout buffer.

Next meetings

The dates of phone meetings in 2006 are still to be fixed. There was a preference for having the meetings one hour earlier than the hardware meetings, ie 11:00 CET (10:00 GMT).