L1 Calo Software meeting at RAL on 12 February 2001.
----------------------------------------------------

Present: Bill, Bruce, Eric, Gilles, Ian, Murrough, Norman, Steve.



Actions from previous meeting:
------------------------------

Norman:
- has been busy with the CMM and buying furniture and has not made
  progress with VME or data format documents; nor has he ordered
  new VME CPUs yet. To be continued...

Murrough:
- has checked the TTC commands used by the DSS: they do indeed
  conflict with the proposals in his document. The TTC addressing
  and command scheme will be discussed at the Birmingham meeting.
  
The other actions were all related to test plans discussed later.


Questions to Ian
----------------

Ian was present to discuss issues related to testing modules and
was asked a number of questions:
- programming of flash ROMs for loading FPGAs: it seems that the
  hardware (CPLD) solution being developed by Richard will be
  chosen for the CMM (and probably also JEM later) rather than
  using a software package as the latter would require memory
  mapping the whole RAM for which we dont have the VME space.
- initialisation sequence for LVDS, serialiser and backplane data
  transmission were discussed. The module setup does not require
  the LVDS to synchronise first; both serialiser and cp chips can
  have their previously calibrated delays set without needing the
  calibration process to be redone each time; separate control bits
  existing for serialiser and backplane calibrations; the system
  probably would need recalibration if the TTCrx clock was moved,
  but if this can be done in 1ns increments or less, the PLLs may
  catch up in about 1ms or so.


Module testing
--------------

Electronics division expects to make basic functional tests of single
modules in isolation. Though for some tests, a test module such as
the DSS or GTM may be used. The JTAG scanner can check that all static
connections are correct.

Detailed exploration of the phase space of a single module, tests of
more than one module or systems of modules should be done by "us".
Though we aim not to entrench an "us" or "them" mentality.

One aspect of the phase space, as evidenced by some problems with the
ROD, should include different electrical, VME etc environments.


Test plans: ROD
---------------

Bruce (with Bill) has been busy with actual tests of the ROD and has
not put much thought into documenting future tests or recording past
experience. The latter is important to feed back requests for changes
to firmware or documentation. Some software fixes have been needed to
workaround some misunderstandings in the implementation.

Future tests really require the automatic comparison of Slink packets
to be added to the DSS firmware. This is non-trivial and is still not
yet done.

As a broad summary, we will need to test all eight types of input data
to the ROD (only one done so far!) under different timing and trigger
regimes. We have to stress the module, eg with high rate and various
error conditions etc.

Given a proposed TDAQ week from 2-6 April, the previous week might be
good to schedule the ROD-ROIB tests. We arent sure we will be ready
though. We should aim to tell the Michigan people at the beginning of
March.


Test plans: CPM
---------------

Gilles presented a summary of the CPM. The available test points comprise
the serialiser playback memory (containing BCMuxed data) and the readout
memories of the slice data and the CP hits. Ian pointed out that the
serialiser playback and readout memories are implemented in the same RAM
and are not available simultaneously. We also have the proposed alternate
CPM chip code. This can be used to examine BCdemuxed data arriving from
the module and its neighbours.

Calculations at our last meeting were wrong. Five DSS modules are required
to fully populate all of one CPMs inputs.

[NB a numerology page to help remind us of these numbers now exists at
http://www.hep.ph.qmw.ac.uk/~landon/l1soft/numerology.html
which you should check for errors please!].

Other CPMs can be used in playback mode to provide dynamic data on the
backplane channels at the same time.

We briefly discussed, crates, module positions, VME extenders etc. Since
the crate will need a TCM, no access from the side to the CPM will be
possible.

Actions: continue thinking and produce a document (even if we know it
wont insulate us against surprises when the module arrives!).


Test plans: CMM
---------------

Norman outlined the test plan for the CMM (no document yet).
- the backplane connections from the CPMs can be checked at the memories
  on the board (without requiring the algorithm FPGAs). The source CPM
  will be laboriously moved from slot to slot to test all positions.
- the crate summing FPGA can be populated from playback memory to test
  the system summing operation.
- some tricks can be played with input and output cables (which have the
  same 64 pin format) to provide extra data and to check the output bits.
- the algorithm phase space can be tested by boundary scan
- we will require four CMMs (and control bits to defeat geographical
  addressing based autoconfiguration) to test the full system properly.
- alternatively (or in addition) it may be useful to provide some low
  speed 40MHz parallel DSS LVDS transmitter daughtcards.


Test plans: System
------------------

The RAL based group has been too busy (VHDL courses etc) to have any
brainstorming on this issues. Deferred to the joint meeting.


HDMC issues
-----------

We had a wide ranging discussion about HDMC.
- some complaints about having to use too many windows for the ROD tests.
  But are we using all its existing facilities well? Perhaps we should
  try to learn some tricks more experienced users...
- possibilities for more scripting
- the ever unresolved worries about its appropriateness in the DAQ
  context against the requirement not to reinvent another VME access
  and module description for the DAQ world as distinct from the interactive
  diagnostic world
- work will anyway be required to add support for the CPM (and CMM, etc).
- is what we presently have in HDMC enough for our single module test
  plans? (Multi module tests will be easier with DAQ type setup etc)

We need to know what the future support will be. Eg for integrating the
existing HDMC "database" (ie parts and configuration files) with the DAQ
configuration database


Run Controllers
---------------

Murrough reported on his continuing activities in the run control/setup
areas. Recent work has mainly been in learning about the DAQ configuration
database. He has tried implementing a first guess at an object model for
part of the trigger menu of immediate concern to us, ie thresholds etc.
More discussion will be required with the rest of level 1 and advice from
Igor Soloviev.


Use Cases
---------

In a recent phone call with Lorne Levinson, it emerged that the TGC muon
trigger community have developed an extensive and detailed set of their
"Use Cases". Although we have thought about and discussed many of these
issues, and some descriptions exists in various documents, we have not
brought them all together to check if we have covered everything. Lorne
is also interested if we can think of any cases they have missed.

Do we need to do this? It would be useful but would also take a lot of
time. We will mention this at Birmingham. In the mean time, Murrough will
try to extract Calibration use cases from previous documents and emails.
This will be useful as a basis for discussion with calorimeter software
colleagues at ATLAS week anyway.


Web and documents
-----------------

We dont have a single web site for the software project - its split into
a QMW part and other pages at RAL in the FrontPage empire which is at best
cumbersome to access from outside (and maybe now impossible due to the RAL
firewall). Storing the website on CVS would allow all of us to contribute.
The whole website could be extracted eg nightly and published at any one
of our sites. To be considered further perhaps...


AOB
---

None that I recall.


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

Apart from the software session at the Birmingham joint meeting, no future
dates were set. About three weeks after Birmingham seems about right.