Software phone conference on 11 May 2004

Progress with software for new modules

PPM

Florian reported on PPM software progress. Working with Murrough in London he created a ppmTests package for a standalone "kicker" type test program, added infrastructure for generating and loading test vectors, and provided access through the configuration database to XML trees containing PPM settings to be used by module services.

Since then the VME map has been (almost) finalised and expanded with further changes for the RemFPGA. In particular A32 is now required if we use more than two PPMs. Florian should discuss with Bruce about implementing an A32 VMEBus part for HDMC. We also need to check that the TCM (and TTCvi which may be in the same crate for standalone tests) either ignore or respond appropriately to A32 cycles.

We also discussed access to the TTCrx. Kambiz said the PPM may need a different implementation of TTCrx access from the other modules. It was hoped the interface could be similar.

Steve has now updated the ppmSim to provide a simulation of the full 64 channel PPM real time path. The Glink readout stream needs to be added. Also integration with the database is needed. This needs further discussion with Florian and Murrough.

Initial tests will have to use the neutral ROD Slink format though it is hoped the proper Slink format would be available for analysis and monitoring software. Bruce hoped the PPM would be available for a slice test integration blitz at the end of June.

Later in meeting Kambiz asked about run modes. He was considering two modes: a normal mode where change of ASIC parameters affecting readout would be prevented by the RemFPGA and a test mode which permitted changes. It was felt that this was not necessary. The software should handle this kind of access control. The RemFPGA should also always enable the readout as the ROD expects that the Glinks will be running all the time and that it will receive data after an L1A.

JEM1

Stefan reported that he can configure the new JEM1 via HDMC. Now this needs to be done with the online software as well.

For reading the spy memories, which are implemented as FIFOs accessed via a single register he needs a new HDMC part. A long term aim is to map these memories directly into VME space. It was suggested Stefan discusses again with Uli if this can be done sooner.

Stefan also raised this issue of the behaviour of the "regbuild" generated classes. To write a bit field of a read/write register the class does a read, modify, write operation. Given the death of JEM 0.2, Stefan is worried this could give problems if initial read access returned invalid data (eg due to some problem on the VME bus). This could lead to bad values being loaded back to the register and causing a problem - especially if the register was one controller FPGA loading.

He suggested the regbuild class should maintain internally a model of the register value. Murrough was worried that an API change might affect other modules. The suggestion needs more consideration.

So far Stefan has not committed his changes which are not compatible with JEM0. Should these go into a separate package or should they replace the existing JEM0 based package? A separate package would need some renaming either of the new or old classes, or else putting one into a separate namespace. There would also need to be a separate database object to distinguish the two versions.

However freezing jemServices for the latest JEM0 software and updating it with JEM1 software carries the risk of us having to use JEM0 later and having to port outdated software. It also prevents us using both modules at the same time. The two options need some further thought.

9U ROD

Bruce expects to develop this software (in a separate package) using the existing CPROD as a basis. The old and new RODs may be needed at the same time.

Norman remarked that Slink formats are still being discussed by himself, Bruce and Tony.

LSM

Status of discussions and work on monitoring

Adrian reported on the status of monitoring. He has had a discussion with Stefan Tapprogge, but they are still waiting for relevant documents to be forwarded to them.

Meanwhile Adrian has made good progress with his monitoring framework application and histogram display, after some struggle with problems due to the thread model internal to ROOT. He hopes to be able to finish this and publish his work as (one or more?) CMT packages in the l1calo repository by the end of this week.

In the absence of the final documented ROD Slink formats there has not been any progress on byte stream converters and thus not on analysis code.

Kambiz asked what was monitored and in particular how did the local PPM monitoring (rates histograms) fit into this scheme. Such monitoring needs to be handled via the run controller (may be easy with ROD crate DAQ?) then as long as the data is published in the IS it can be accessed and displayed by the standard tools.

Database evolution and migration to ROD crate DAQ

We are being encouraged (and may be required) to move to ROD crate DAQ for the test beam. Apart from anything else we may want to be able to give feedback for the "installation release" of the dataflow software.

We are also starting to want to write calibration and conditions data for long term studies, so moving from the present OKS based files for calibration data is desirable.

However we need further discussion on the detailed implications of these moves on our existing software. We should perhaps involve outside help for this, eg the ROD crate DAQ support from CERN.

Testbeam integration and move to online/dataflow software

Bruce has tried the latest online/dataflow software, which will be used at the testbeam, on the system at RAL. After some database work due to schema changes, he successfully read data from a CPM into a ROS. However the latest dataflow expects us to be using version 2.4 of the event format. The ROD needs a firmware update for this. When this is available and tested we can all move to the testbeam versions.

We need to find out what else we are required (or encouraged) to do in order to complete our integration for the test beam. The first integration session is scheduled for the week starting 5 July. Norman agreed to circulate the checklist.

Software still needed for slice test and test beam

Bruce mentioned a few items, such as:

• electronic logbook
• test vector generators for BCMUX
  - however Steve said that such a generator already existed
• generalisation of the kicker programs

Change of paradigm for the test beam

Bruce suggested we should consider the differences between our working model for the slice tests and operation in the test beam. For example, we will not be running the simulation.

Our existing tests use many of our own private "run types". For the test beam we probably just have one set of physics settings. However - if the infrastructure allows - we are likely to want to run our standard test setup with various run types and simulation to be able to run system checks. What are the implications for setting up the database? Is this something we can check during or before the first test beam DAQ integration week?

Next meeting(s)

Another phone conference was tentatively arranged for Thursday 27 May at 14:00 UK time (15:00 german time). The usual number +44 (0)1235 44 5420 and arrangements will apply.