Level 1 Calo Software Meeting at Mainz on Thursday 30 March 2000.
-----------------------------------------------------------------

The agenda was:

- CTP configuration                        Ralf
- Calo trigger configuration databases     Murrough
- Status of HDMC                           Cornelius
- Bit field access with HDMC               Murrough
- HDMC discussion
- Status of DAQ work                       Norman/Bruce/Tara
- Use of ROOT IO for Event class?          Tara
- DAQ discussion
- Hardware platforms
- Software organisation/process            Murrough
  (DAQ -1 open source and all that)
- DAQ -1 tutorial/workshop
- Schedule for forthcoming hardware tests


CTP Configuration [Ralf]
------------------------

Ralf summarised his recent note (ATL-DA-EP-0001) on the CTP configuration.
His slides are here.

He has categorised the configuration data into hardware or software
and dynamic or static. In his note he gives a detailed list.

The CTP will depend on receiving some of its configuration data from
other systems and those in turn will require some of the CTP information.
In particular, the level 1 calorimeter trigger will need to know some
of the overall trigger menu settings, and the CTP needs to know how
the trigger information arrives on our cables.

Ralf hopes that we can work together in future to produce a combined
data model for the whole of the level 1 trigger and then also provide
the software to support it.


Calo trigger configuration data [Murrough]
------------------------------------------

Murrough presented the current thoughts on configuration data for the
calorimeter trigger and first drafts at a data model.
The slides are here.

The main input is Erics list of our configuration data.
This can be found here.
We should turn this into a proper document.

Other inputs include the existing DAQ -1 configuration database
and the HDMC class model.

It seems likely that our hardware configuration (modules, crates)
can be fitted into the DAQ -1 scheme. We will have to do some
more work on our other data, eg calibrations, connections, etc.

Some extremely preliminary class diagrams sketches include:
- DAQ -1 hardware schema
- L1 Modules
- Eta/phi connections
- FPGA programs
- Calibration
- Inventory
These were created with a very flaky Mac tools called ObjectPlant.
Together seems a somewhat better bet for the future.


Status of the Heidelberg C++ software [Cornelius]
-------------------------------------------------

Cornelius summarised the recent improvements to the HDMC software.
His slides should appear via here.

Recent improvments include:
- handling of VME bus errors via a new general scheme using C++ exceptions
- most of the code now assumes modern compiler support (STL, templates, etc)
  but the bus server (running on LynxOS) is now free of STL and Qt dependency
  and does not use exceptions
- the Part class now handles a list of its dependent Parts
- this allowed a framework for recursive Part verification to be established
- constructors added to accept natural arguments (as opposed to GUI created
  structures) to allow easier use directly from other C++ code
- support for various scripting languages (Python, Perl, Tcl) has been
  added using the SWIG package
- various other miscellaneous improvements to MVME167 and dummy bus,
  histogramming, saving/restoring Part and GUI state, etc
- work has started on providing "Part Hierarchy" views, such as all
  the Registers/Memories in a Module, or Modules in a Crate etc.
- version 0.2 will be released shortly after the meeting


Bit Field Access in HDMC [Murrough]
-----------------------------------

The slides for this talk are here.

HDMC allows detailed interactive access to the bit fields of complex
registers. For DAQ work, a scheme to allow clear and simple access to
bitfields from C++ is desirable.

Murrough presented a proposed syntax. The necessary class header files
could be created by a suitable compiler from the HDMC configuration files.
A similar scheme could be used to create Module classes which had named
data members containing their registers, memories and other subcomponents
as a short cut to continually locating them via the PartManager.


Overview of DAQ work [Norman]
-----------------------------

Norman gave a brief introduction to work on the DAQ system which has
been done recently at RAL. The general idea has been to evolve the
existing system gradually towards the DAQ -1 environment.

For the ROD, the first stage should include:
- control via DAQ -1 GUI and run controllers
- cut down version of the old daqprod, using HDMC services
- new daqana creating histograms with ROOT
- use of ROOT to display histograms, ditching the old presenter
- still using the old buffer manager and old "database"


Ideas for new DAQ Producer [Bruce]
----------------------------------

Bruce showed some new ideas for the DAQ producer program, daqprod.
His slides are here.

It must be started via the DAQ -1 run control and use the DAQ -1
message reporting. Use of DAQ -1 services will require the program to be
multithreaded. For the moment, it will use the old database.

As described in an earlier talk, a desirable feature would be C++
access to bit fields within registers. Also perhaps the concept
of the "register group", ie set of registers with contiguous
VME addresses, would be useful.

Bruce presented some ideas on how the buffer manager might be seen
by the producer: either ROOT stream, or some kind of smart memory or bus.

Finally he showed a "primordial" object diagram, created by the rather
flaky Together tool. He would like to map "hardware" versions of crates,
modules etc to software (ie readout) duals of them. The exact mechanism
is not yet clear though.


Use of ROOT IO for Event class [Tara]
-------------------------------------

Tara gave an introduction to the ROOT IO classes. ROOT is a large
framework designed with HEP in mind. We have already decided to use
ROOT, at least initially, for providing histogramming within the DAQ.

ROOT also provides IO classes which allow definitions of trees of
objects that can trivially be stored in files and/or piped through
streams.

These might provide a convenient model for our Event class and allow
events to be stored and retrieved from the buffer manager.


Hardware platforms; Software organisation; DAQ -1 tutorial
----------------------------------------------------------

Murrough briefly covered each of these topics.
The slides are here.

All six groups appear to have enough processors, used with network VME
access, to cope with their foreseen needs for the prototype program
(except perhaps Stockholm?).
Though there may still be a case for investigating our future architecture.
Processors from Concurrent seem to be considerably cheaper than those
from VMIC which the CERN group selected. (NB the dollar signs in the slides
should be pounds).

The reorganisation of the trigger/DAQ project including the formation
of an online software group may lead to pressure on us to participate
in a more formal software process similar to that used within the
present backend DAQ group.

Norman, Bruce and Ralf (but no one from Heidelberg) will be attending
the forthcoming tutorial on the backend software.