Level-2 Framework in
Run 1

Jan Hoftun

What was the Framework?

Hardware Interface

• Data was "wrapped" with ZEBRA headers as soon as it arrived in Multiport Memory.
• Set up transfer and signaled driver to send data up to the host via HSOC.

Software Interface

• Received run information from COOR via Supervisor.
• Sent status information to Supervisor and Surveyor.
• Sent special monitoring information (timing etc.) to host programs (L2_GRAPHICS).
• Handed off events to the actual filter code.
  

Successes

Framework flexibility

• Use of address table for setting up scripts without knowing calling order of tools.

COOR interface

• Was set up as an "object" early on. subroutine header used as documentation and COOR just linked against L2CONTROL library which was also used to test routines in the SUPCON program.

Use of "Servers"

• Begin run cycle was sped up a lot when the nodes read the run parameter file from the Supervisor memory instead of a host disk.
  

Problems?

Memory use

• Programmers had to learn to use memory in a more "economical" way since program had to fit in the available physical memory

Releases

• Long time to implement fixes to framework/monitoring parts which had no direct physics impact.
• Persistent bugs were left in too long. Problem both for framework (needed workarounds etc.) and DAQ-experts.

Monitoring

• Not enough ideas and planning early for gathering monitoring and timing information.
  

Important Lessons for
Run-2

Need for test facility

• Must have a place for filter code developers to test their code in an environment which is as close to the real Level-3 as possible.
• This may mean "revival" of the "playback"-mode.

Separate frame functions and filter functions as much as possible

• Several separate "EXEs" is the ideal way to handle this.

Plan for future changes

• Must be able to respond quickly to changes in requirements