L1Calo Software Meeting at RAL on 2 October 2001

Actions from previous meetings

• Murrough has prepared a web page on installing the Online software.
• Other actions are carried over...

Norman: Readout for the slice test

There are a number of issues still to be resolved.

• How (whether?) to read the extra CMM outputs that we cant send to the CTPD (which is limited to 32 bits). Sending them to a DSS would require extra development to read the DSS and presumably generate extra Slink packets to the ROS. Another suggestion might be to put the appropriate daughter card onto a ROD. Either way, firmware effort is required.
• How to trigger only on errored events flagged by the DSS? Some interface to the ROS components (eg TRG or LVL2 modules) is required. Its still not clear how to do this. One suggestion involves implementing the automatic checking on the ROD (instead of the DSS) which could more easily correlate bad events with the L1 event ID required by the ROS. Good and bad events could be flagged in the ROD in a FIFO read by the local CPU or perhaps flagged at the end of the output Slink packets? Again all likely solutions will probably involve firmware changes.
• Some data rates cant be calculated precisely yet because the Slink data formats are not defined. Norman should chase people to fill the gaps in his data formats document.

We discussed what we might do if we cant solve these problems - at least by the start of the slice tests. To some extent we would have to rely on separate tests in isolation, ie rigourously verify part of the system and then assume it works correctly in the whole system

If we cant trigger only on bad events, we would have to rely on statistical sampling of all events. While running at 100 kHz we can probably check at least 1 kHz of events. Significantly longer test runs would be required to see the same level of occasional errors.

Bruce: CPUs, RODs, ROS

Apart from forware problems, Bruce is worried that his tests can be disturbed by other activity in the crate CPU, eg another ssh login etc. In principle his tests are not critical real time applications and should not suffer if extra delays occur.

Bruce has used the Slink receiver program from the ROS software to read and check events from the ROS - ie repeat of the ROS integration part of the April tests. He has implemented the necessary system modifications required by the ROS software (bigphysarea kernel patch, capabilities support) as described by DAQ note 136. He has looked at the ROS code on the CERN AFS but has not yet run the full ROS setup.

The two workstations in the lab at RAL have also been updated with various packages to support the Online software. This is now running successfully on atlun01 (RedHat 6.2 machine). We intend to standardise on RedHat 7.1 when the next version of the Online software is released later this month. We now have a web page listing the required RPMs. However it is not clear if the additional patches required for the full ROS software are yet available for the Linux 2.4 kernel which is now the default.

Steve: Simulation and Testing

We discussed some issues relating to test vectors. We will need a way to collect, organise and identify test vectors for the whole system. Sometimes we will want to generate them on the fly, sometimes we will want prepared files. Comprehensive tests of the trigger consist not only of input data, but also the parameters loaded into the system, eg trigger thresholds in CPM and JEM, lookup tables in PPM, etc. Steve should collate the requirements and make some suggestions (in a little document?)

Murrough: Run control and Module services

• Where to describe the crate configuration? The Online database can describe crates and modules. The present prototype run control package uses this to create run time module subclasses. These could read their subcomponents from parts files or create their subcomponents by constructor. However it would also be desirable to initialise the run control configuration in the same way as when using HDMC which suggests using a single parts file for the whole crate and thus not using the Online database.
• How to handle run types? Different run types will require different actions inside module (and even submodule) class. It seems best to encapsulate the choices appropriate to a given run type in a run type object, perhaps a tree of such classes. Given that, there are two possible philosophies. Either implement the run type as a set of options which the module objects can interrogate, or else give control to the run type object which becomes responsible for calling methods of the module classes.

Progress on the first issue requires more discussion with Oliver about changes to HDMC. Regarding run types, we need to think more about what run types we expect to have and what they imply for detailed control of the internal module actions.

Testing the CMM and CPM

Software Organisation

One omission from the the present document concerns tools. Should we try to agree on a set of tools that we all use? We have already agreed to use Doxygen for source code documentation, and some of us have experience of the Together tool for producing UML diagrams. Do we want to propose a code development environment? Eg KDevelop or CodeWarrior or something else? Also what about checking tools, eg SNIFF++, Insure++, Purify, etc.

Online software demo

Actions

• Oliver: circulate thoughts on software process
• 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

Next meeting

Particular items to be discussed: HDMC changes, readout strategy. Also a general run through of the whole system.

During the week, we should also ask the DAQ group about support for multiple ROBins in a PC ROS with many PCI slots, and about the bigphysarea patch for the Linux 2.4 kernel.

The next meeting after that will be the joint meeting which will be preceded by a couple of days set aside for software working sessions (which may be a mix of discussions and activities at terminals implementing previous decisions).