Level 1 Calo Software Meeting at RAL on Wednesday 19 May 1999.
--------------------------------------------------------------

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


The agenda was:

(1) Diagnostic Software for DSS............Kithsiri
(2) DAQ Software for DSS Tests.............Bill
(3) Progress on Calibration Issues.........Reg
(4) Experience with StP....................Tara
(5) Choice of New Hardware Platform?.......Eric
(6) Computing/Readout Architecture.........Discussion
(7) Plan for Use of DAQ Software...........Murrough/Discussion
(8) Timescales and Workplan................Discussion
(9) AOB & Next Meeting


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

Kithsiri reported that the Verify commands for the DSS registers and
memories has been checked (on a VIC memory). There are some further
changes to the programming model which still need to be incorporated.
[After the meeting the latest version was installed at Birmingham as
an aid to development of the DAQ system there].

Norman reported that the DSS was finally submitted to the RAL drawing
office for layout. There have been some problems which are being dealt
with. It will be at least another month before we have a module to test...

It was requested that a short guide to starting and using the diagnostics
be provided. Kithsiri will do this.

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

Bill reported that he, Scott and Norman had tested the DAQ system at
Birmingham the previous day. There is an unresolved problem, thought to
be a race condition, which prevents the normal startup of the DAQ system.
But if the producer program is started under the debugger, the system
works happily, accepting event interrupts, reading (fake) memory and
producing events. The event dump appears to decode the events successfully.
The analyser still has to be tested. This should be the highest priority
as Scott is shortly due to go out to CERN for a short trip.

It would also be desirable to generate some more realistic fake events in
the VIC memory for the system to read. The diagnostics might be useful here.

Worries were expressed about the DAQ infrastructure at Birmingham. The
VME display may be faulty. Both RAL and Birmingham need a PC with a decent
screen for X displays.


Calibration Issues
------------------

Reg showed us the electronics chain for the TileCal and discussed their
various calibration systems. The TileCal group have provided a document
specifically intended for level 1 with more information than appears
in their TDR. It is claimed that any tower configuration can be set up
with the laser calibration. Tara and Reg have contacted Rupert Leitner to
ask some of our outstanding questions.

We still need to know how level 1 might access their calibration system.
Also whether and how they might want access to the receiver stations. Their
PM numbering scheme is only not completely specified (L/R ambiguity?).

There is also more documentation availalble from the LAr community, but
as yet Tara and Reg have not yet contacted them for more details.


Progress with StP
-----------------

Tara has done some more work investigating StP. He has now tried more
of its features which cover the whole software lifecycle.

The reverse engineering is sophisticated, but doesnt produce good diagrams.
However the feeling is that it would be useful for bringing existing
diagrams up to date with modified code.

The HP version at RAL accesses the CERN SYBASE server which is a little slow.
There is also a problem with the licences as most of our licences are for the
OMT version as opposed to the newer UML standard. This will be fixed soon.

However the NT version is much nicer to use. It stores its data in a local
SYBASE repository so is also much faster. Though it is then unclear how
multiple users would share their work.

Steve Fisher is still evaluating other tools:Together/C++, Together/J
and a free product called aros(?) for possible use by the offline group.

Both Norman and Murrough were interested in trying the NT version on existing
code. Tara will check up on the licencing situation.


New Hardware Platforms: Connecting PCs to VME
---------------------------------------------

Eric has been investigating new hardware platforms in some more detail.
He has also been in contact with Louis Tremblet (from the ATLAS DAQ group)
about the software support.

He presented four solutions, one VME based CPU and three options for
connecting desktop PCs to VME:
(a) VMIC-7587: a pentium based VME single board computer.
    The DAQ group support this: they have a Linux driver and low level
    libraries. The LDAQ is expected to be working this summer.
    However like our existing LynxOS systems it may be expensive to
    upgrade.
(b) CES PVIC-7225: PCI-VME connection.
    A Linux driver exists and the system can handle multi crate connections.
    However it is not supported by the DAQ group.
(c) National Instruments PCI80xx: PCI to VME interface.
    Multi crate links possible, but not clear if a Linux driver exists.
    Also not supported by the DAQ group. (But similar devices are in use
    within the ATLAS SCT community, accessed from Windows NT & LabView).
(d) SBS-Bit3 617: one of a family of PCI-VME connections.
    The DAQ group have a Linux driver and low level libraries for direct
    access to VME (drivers for many other platforms exist too). The LDAQ
    should be working by the end of the year.
    It is cheaper than either (b) or (c) options.

A heated discussion ensued! Among the issues raised were:
- worries that our future software should be runnable at all six sites
  (who may not all be able to purchase new hardware in the near future)
- whether it was viable/sensible to access VME over the network to our
  existing LynxOS systems

What was agreed was that both RAL and Birmingham will buy PCs capable
of running Linux (possible in addition to NT at RAL) and that we may
buy one SBS-Bit3 interface for evaluation.

At a nuts and bolts level, there were questions:
- are the PCI-VME interfaces memory mapped, as is seen on LynxOS?
- what about big/little-endian differences on PC vs 68K/PPC platforms?

[From later perusal of the Bit3 data sheet, it appears the the VME address
space can be mapped into PCI address space; also the Bit3 can be set up
to return big or little endian values].


Evolution of DAQ Software
-------------------------

In the brief time remaining before lunch, Murrough gave an overview of
the work required on the DAQ system.

We will probably have the ROD within six months and we should aim to have
a prototype of our final software (DAQ, calibration, monitoring etc) in
about 18 months, when most of the other prototype modules will appear.

For the immediate future, we could try to evolve the existing DAQ system
by replacing parts such as EMU, the run parameters and the daqctl program
by equivalents from the DAQ-1 software, ie the MRS/IS package, the OKS
database and the Run Control package.

We would also have to provide new classes to implement the ROD, DSS and
other modules. These should at least share low level code with software
developed for tests and diagnostics. [Which still requires more detailed
disussions with Cornelius].


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

To be decided...