Level 1 Calo Software Meeting at RAL on Friday 19 April 1999.
-------------------------------------------------------------

Present: Murrough, Kithsiri, Norman, Tara, Bill, Eric, Scott, Reg.


The agenda was:

(1) Diagnostic Software....................Kithsiri
(2) DAQ Software...........................Bill
(3) Summary of recent discussions..........Norman/Murrough
(4) Hardware Platforms.....................Murrough
(5) Thoughts on Calibration................Reg
(6) Progress with software tools...........Tara
(7) Experience with Heidelberg Software....Murrough
(8) Future software workplan...............Discussion
(9) AOB & Next Meeting


Diagnostics
-----------

Kithsiri and Murrough reported on the status of the diagnostic software
for the DSS. The software was tested using a VIC as a VME memory and most
of the standard functions worked as expected. The Verify command was not
working properly. After looking at the code it appears that the software
expects the hardware and model to be in sync before a Verify is done.
This has not been checked with hardware.

Murrough has added an extra Tcl command to speed up the initialisation of
large memory widgets so the DSS memory windows now open much faster.

Before the meeting, Murrough and Kithsiri made a few cleanups of the code
removing a few superfluous items from the windows.

Kithsiri has added an Autotest window for quick Verify tests of all the
registers and memories on the DSS module. This has not been tested yet.


DAQ Software
------------

Bill and Scott outlined the status of the DAQ software. Bill has now
completed a version of the event readout. At the moment the event format
is variable, only channels with errors are read out. The daqctl menus
allow a variety of runs to be started with multiple DSS modules connected
in a number of ways.

Scott has included the DSS in the event dump program and is now working
on adding histograms for the DSS in the analyser program.

Unfortunately a hard to trace bug in the producer program prevented a
demonstration of the DAQ system before the meeting.

Attempts to help understand this were hindered as the Birmingham LynxOS
system is sitting behind their firewall. Birmingham should investigate
safe ways to allow limited external access to their LynxOS system.

The DAQ version at Birmingham needs to be merged with the existing
versions at RAL. The recent work at Birmingham started from their local
version using the Bit3 VME connections instead of VICs and may not include
changes made in the last version at RAL.


Summary of recent discussions
-----------------------------

Norman and Murrough have had two day long discussions covering a number
of topics, mostly related to the ROD and readout issues.

For the ROD, a scheme has been agreed for connecting and using the DSP.
This sits on a PCI Mezzanine card and has (almost) no control over the
rest of the ROD module. Communication between the DSP and its host ROD
passes through a memory which is divided into a multievent buffer and
an area for the DSP to report its results. Complete events destined for
the Slink are copied into the multievent buffer and a flag is set for each
full slot in this buffer. The DSP quickly examines each event header and
copies interesting events into its own memory for further analysis and
clears the flag. From time to time (eg at the end of a run or during
calibrations?) the DSP places the results of its analyses into the results
section of the memory.

Normally, if the ROD finds that all slots in the multievent buffer are full,
it will only send a new event to the Slink. However there is provision for
the DSP to request all events which may be useful for calibrations.

The readout of the serialising Asics on the CPMs has also been discussed.
Normally we only want to read out a single time slice, but because the inputs
are Bunch Crossing multiplexed, we actually need to read two slices to be
confident we can reconstruct the data for the L1Accept slice. The choice
to which two slices depends on whether, for each channel, the L1A slice is
the first or second of the two BCMuxed slices.

However for some sample of events we may want to read out up to five slices.
For the above reasons, this actually means we need six slices. Ideally the
choice of whether to read one or five slices would be made on the basis of
the trigger type word. But this arrives via the TTC system long after the
slice data has to be read out into the derandomiser buffer.

After toying with ideas such as requesting a prompt trigger type from the
CTP via a separate cable, it has been proposed instead that we always read
the maximum number of slices from the serialising Asic (and the CP Asic
results). The ROD, which does get the trigger type in time, can then decide
how much to include in the data stream. The Glink bandwidth into the RODs
is quite adequate for this.

We should also expect the same strategy for the Jet system readout.

This is still just a proposal as its not clear that the ROD will actually
be capable of the multitude of tasks we are assigning it.

To gauge this, Norman has started writing (in C++) a model of the dataflow
through the readout buffers in the system.


Hardware Platforms
------------------

Murrough reported that Cornelius has followed up our discussions at the
Birmingham joint meeting and has been investigating possibilities for
new hardware platforms (for VME access) at Heidelberg. Following this
Murrough asked the DAQ group for the status of their support and plans.

To upgrade their CES RIO2 system to LynxOS 2.5 and to add another 32M
memory would cost 5kDM. However the DAQ group use systems with just 32M
so the memory upgrade might not be required.

One alternative is for a PC based VME processor board. Examples from
Concurrent or Dynatem cost about 10kDM. Apparently Mainz already have
a slower cheaper one which they are quite happy with. This is Cornelius
favoured solution (running Linux). The DAQ group (Louis Tremblet) has
used a VMIC-78xx - unknown cost.

Another alternative is a desktop PC with a PCI to VME bridge or adapter.
The SBS Bit3-617 (which the DAQ group have also used) costs 4-8kDM
(depending on quality, features?).

QMW and some other Silicon Tracker sites in Atlas have PCI-VME interfaces
from National Instruments (MXI-2) for use with LabView. It is not clear
if these support DMA functions which we might want. Eric will check.

On the operating systems, it is clear that the DAQ group are moving towards
Linux and away from NT.


Thoughts on Calibration
-----------------------

As his introduction to working on Atlas, Reg has been starting to think
about our calibration issues. He begun by presenting all the calibration
systems used by both LAr and TileCal calorimeters.

Having gleaned all available information from their TDRs, it is clear that
we still dont have enough information about the granularity with which we
might be able to use either the LAr electronic calibration or the TileCal
laser calibration. Also how we would actually gain access to their systems.

Reg will continue to chase up the information via subsequent technical notes
(if available) and through our contacts (if not).

In other discussions, Reg has agreed to make a list of all our requirements
in the calibration area: from integrity of cabling, energy calibrations to
the timing setup.


Progress with Software Tools
----------------------------

Tara has not restarted work on this after his Indian holiday. Murrough
reported some problems with CVS hanging when accessed from QMW over AFS
(whereas CVS network access from Heidelberg worked fine!). Tara will check
if this is a known problem, eg at DESY?


Experience with Heidelberg Software
-----------------------------------

After some initial problems on OSF and with the (too?) clever Makefile
on Linux, Murrough has linked the Heidelberg test software. It proved
easy to make windows for various DSS registers. However attempts to
connect memories to histogram windows only produced crashes. Cornelius
does not see this on his system.

At present the Heidelberg software is designed to be extremely flexible
and configured by text files. Its not obvious how to implement test suites
or DAQ type code which would ideally reference registers as specific C++
objects rather than generic, dynamically configured ones.

The C++ part of the UK diagnostics does have considerable flexibility,
but this is not accessible via the Tcl/Tk GUI. However the existence of
the model code throughout doesnt make it very suitable for the DAQ area.

In the Heidelberg setup, test suites would presumably have to use test
vectors or code which knew the expected results, rather than the completely
general approach of Dave Rees model software.

Some suitable way forward must be found. Murrough and Cornelius should
have more discussions.....


Future software workplan
------------------------

Norman and Murrough should discuss this and produce something for review
and comment.


Next meeting
------------

Wednesday 19 May at RAL.