Level 1 Calo Software Meeting at Birmingham on Thursday 4 March 1999.
---------------------------------------------------------------------

Present: Murrough, Scott, Kithsiri, Norman, Tara, Ian, Cornelius,
         Uli, Ralf, Juergen, Bill, Scott, Eric.


The agenda was:

 (1) Software for UK Modules (DSS and ROD)
     (a) Diagnostic Software....................Kithsiri
     (b) Remote VME access from Diagnostics.....Murrough
     (c) DAQ Software...........................Scott
 (2) Software for Heidelberg Test System........Cornelius
 (3) Progress with Software Tools...............Tara
 (4) Progress with DAQ prototype -1 code........Murrough
 (5) Consideration of Level 2 DAQ Software......Norman
 (6) Future Hardware Infrastructure.............Norman/HD/Stk/Mainz?
 (7) Requirements document......................Murrough
 (8) Discussion on Future Directions............All
 (9) Overlap with Offline Software..............All
(10) AOB & Next Meeting.........................All



(1) Software for UK Modules (DSS and ROD)
-----------------------------------------

(a) Diagnostic Software
-----------------------

Kithsiri described his progress in implementing the DSS module into the
existing diagnostic software. So far he has created the C++ class with
the registers and memories described in draft 4 of the specification.
However, since then the number of registers has grown from 8 to 56!
On the Tcl side he has implemented a window for the original registers
and one window to display four of the eight memory buffers. Another
window will be required for the other memories and it is clear that
other registers windows will be required for the new registers.


(b) Remote VME access from Diagnostics
--------------------------------------

Murrough described recently completed work on providing access to VME
via the network. This consists of two ends. On the LynxOS end there is
a network daemon, vmed, which responds to requests for VME operations
sent by a client running on another system. The diagnostic software
has been modified by extending the VMEAccess class to implement several
VME access modes, including a network mode which acts a as client to
the vmed server.


(c) DAQ Software
-----------------

Scott and Bill have made a start on modifying the existing DAQ software
to add the DSS module. So far most of the time has been spend on finding
their way around the code. Bill has started the work to add configuration
menus, but it is clear that a lot more work is required on quite a short
timescale. Bill and Scott should ask for more help if they need it.


(2) Software for Heidelberg Test System
---------------------------------------

Cornelius gave a detailed presentation on the test software he has
developed for the new Heidelberg test system. The motivation was to
provide a very flexible system providing functions from low level bit
accesses to higher level histogramming of data flows all presented
with a user friendly graphical interface. The aim was to be as portable
and platform independent as possible and to use appropriate tools such
as CVS, Qt, etc to increase productivity.

Cornelius presented many beautiful diagrams showing the class hierarchy.
The base class for most components is the Part which has many subclasses
such as Register, FPGA, Module, IoFrame. Parts can be dynamically added
and configured under the control of a PartManager. The configuration can
be read from text files which are also used to generate the Verilog code
for synthesis.

The IoFrame part provides the functions of data source and sink and can
be used to make histograms of data in memories for example. The IoFrames
have input and output port and trigger inputs and can be connected together
in arbitrary sequences, eg to provide a filter chain.

The GUI is separate from the hardware classes, though the classes which
can be represented in the GUI know what kind of GUI component is needed
to display them. At the moment, the GUI windows show detailed views of
registers down to invididual bits and up to histograms of memories. However
a graphical overview of the system is still missing.

Cornelius has used the Doxygen (free) product to provide HTML documentation
of all the code. This uses specially formatted comments to extract text
from the source code. Keeping the documentation together with the code
increases the likelihood that the documentation will be up to date.
See here.

He has also provided web access to the CVS repository so that the code
can be viewed from a web browser. This also seems like a very useful feature
that could be added to the UK CVS repository.
See here.



(3) Progress with Software Tools
--------------------------------

Tara gave a report on his work on various software tools: CVS, SRT and StP.

As has been advertised already, Tara has incorporated (almost) all our
existing code into a CVS repository which is mounted on an AFS filesystem
at RAL. After some initial problems with access control lists were fixed,
this now seems to be working satisfactorily. AFS access could be extended
to non-UK people on demand.
For more details, see here.

Cornelius asked if network (rather than AFS) access could be provided as
this would be more useful for the LynxOS systems (and a few other systems
at Heidelberg and probably elsewhere) which dont have direct AFS access.
Using an NFS mounted disk from an AFS client is not very satisfactory.
We should investigate this.

The SRT tool is now standard at CERN (at least by ATLAS) and is used for
building binary releases of software on multiple platforms. We will
probably have to use it eventually.

After some delays in getting the necessary access (CERN account, etc)
Tara has made a start investigating Software through Pictures with the
help of Steve Fisher at RAL who is the ATLAS StP expert. The program
provides graphical editors for all the diagrams used by standard OO
design methodologies. It also has a reverse engineering tool. Unfortunately
this was not as wonderful as one might have hoped. You have to do some
extra work to create nice diagrams from the information it reads from your
source code, but it could still be helpful.

Within the offline community, StP is mostly used for documentation rather
than as the place where code is really designed.


(4) Progress with DAQ prototype -1 code
----------------------------------------

Murrough briefly summarised his investigations before Christmas of the DAQ-1
database component OKS. After some problems with finding a suitable platform
to run the software, he successfully created some OKS classes describing
components of our configuration such as Crates, Modules etc and populated
a very small configuration database. However the GUI tools of OKS are a bit
cumbersome to use - the DAQ group use StP instead!

Murrough intends to continue looking at OKS and also to make some tests of
the MRS, IS and Run Control components. We have also been invited to make
and evaluation of the recently released first version of the Test Manager.


(5) Consideration of Level 2 DAQ Software
-----------------------------------------

Norman covered a broader topic that just the alternative Level 2 DAQ
software in his talk. He outlined the probable future deveopment of our
software as a semi-random evolutionary walk amidst continual short term
demands rather than a beautiful complete design with two free years of
stress free contemplation.

He remarked that due to lack of cooperation from the DAQ group, Level 2
has felt it necessary to embark on a DAQ software effort of their own
which clearly is a duplication of effort overall. This would be more
freely available to us that the DAQ groups code, but is unfortuntely not
really ready for us to start using right now.

We could continue to develop our own code using a host of available bits
developed by other groups, eg OPAL, but this still leaves us having to
make a transition to DAQ group code later.

I think the feeling of the meeting was that we try to continue prising
software out of the DAQ group if possible.


(6) Future Hardware Infrastructure
----------------------------------

The UK groups all have rather old 68K based VME processors for running
LynxOS. These are not supported by the DAQ group (who are reluctant to
let us try supporting their code on them ourselves). They have limited
memory which is now really sufficient for running X based applications
and they are slow. Heidelberg and Stockholm have faster PPC based systems
which are supported by the DAQ group, but these also are not over supplied
with memory.

For the future we need to consider upgrading our hardware platforms. One
option being considered by the DAQ group is PCs (running NT or Linux)
with PCI to VME interfaces. These might be interesting for us, though
we need to consider how we evolve to the architecture of the final system.


(7) Requirements document
-------------------------

Little progress has been made with this. Once again we remind ourselves
not to forget the longer term amid short term needs.....


(8) Discussion on Future Directions
-----------------------------------

Can we converge on one set of software for test and diagnostics and to
use as a base for hardware access by other components? The existing UK
diagnostics has many drawbacks for future development. The new Heidelberg
code doesnt incorporate ideas such as the model which was found useful
in creating flexible tests.


(9) Overlap with Offline Software
----------------------------------

This was only briefly discussed at the meeting. Norman and Murrough will
get together to draft a reply to Traudl.


(10) AOB & Next Meeting
-----------------------

If we are to make good progress towards having a prototype of our final
software ready within two years, we will probably need to have meetings
more often than the three or four monthly joint meetings. We need to try
video conferencing. We gave an action to Norman to arrange a trial video
conference between RAL and Heidelberg. At the moment, neither QMW nor
Mainz have suitable facilities but both are within (uncomfortable) range
of RAL and Heidelberg respectively.