Overview of SVT Software Tasks

• Board configuration data

• compact/computed vs memory image

• flat file / transient data structure / database

• used in simulation and in board initialization (should be common!)

• currently, for simplicity, we're typically using flat files of memory image data (possibly gzipped)

• Giovanni has done the most thinking about this task

• Board simulators

• goal is to emulate data flow between boards, bit by bit

• ANSI C -- must be portable/embeddable/lightweight

• needs to run in AC++ (trigsim), on crate CPUs, and standalone for board testing

• specifications for these are the first topic of the workshop

• have prototype simulators for HF, AMS/B, HB, TF, which have been used to test boards, but specifications are still evolving, and no attempt has been made yet at optimization

• HF simulator has now been (crudely) interfaced to AC++ Geant3 output--finds hits in single-muon events

• TF simulator is now much closer to meeting (last summer's) specifications than it was a few weeks ago

• Briefly, I think we (GP, AC, BA) mostly know what we want to do, but we need to sit down to do lots of work

• svtsim interface to AC++/trigsim

• essential for consumer-level monitoring of SVT output, offline trigger-rate studies

• should deliver XFT tracks + SVX-II raw data to svtsim

• should package svtsim output as StorableObject

• should interface to databases

• should allow configuration of svtsim from AC++

• possibly expose some internal svtsim data to AC++ analysis code

• We'll hear much more from Lorenzo today

• SVT initialization from Run_Control

• greatly reduced/simplified scope, thanks to Frank's presence at our last workshop

• prototype implementation exists for AMS+AMB+HB+SC; it was easy

• use flat files for now; no database

• plan to add HF, integrate into standard run start-up, once R_C experts are happy with SVX/FIB/VRB initialization

• more news later today (Bill/Xin)

• VME I/O libraries

• cdfvme code (with GUI) exists for all but HF,TF,XTF, thanks to Thomas

• "vmesvt" code (as well as various ad-hoc libraries) still in use for many boards

• so far, it has not been trivial to migrate code between workstation and crate

• very lowest level is identical, but middle-level libraries were independent

• Bill & Thomas have a straightforward plan to merge all of this code and to make it usable from both environments

• much of the work is already done; more news tomorrow

• Diagnostics (no beam)

• board-level tests need to be collected from experts and put in libraries

• most useful tests should be coded to be usable either from C or from cdfvme GUI

• system-level (multi-board) tests will evolve naturally from vertical slice test code in coming months

• maybe discuss tomorrow (Bill?)

• Spy buffer monitoring

• first line of defense for detecting and responding to unexpected board behavior during data taking

• need to have a clear specification of the job to be done

• may need to think about infrastructure/platform issues to optimize performance, minimize development time

• potentially a large and difficult task

• more news later today from Subir

• Beam position feedback

• TF crate CPU performs least-squares fit to track data from TF FIFOs

• report measurement every O(1-10) seconds, transmit to ACNET via workstation

• presumably uses same infrastructure as spy buffer monitoring, so little additional work is required

• details tomorrow (Luciano/Paul)