SVT Initialization

• Goals

• At start of run, R_C causes all SVT boards to be configured for data taking

• Particular choices for patterns, maps, various control registers are taken from databases by R_C

• Do this in such a way that we write as little code as possible

• Progress

• Have R_C "daqmsg" message-passing mechanism working to configure AMS, AMB, HB, SC

• On the R_C end, I read an ASCII file to fill in the configuration message contents for each board

• This is the standard "partition from file" feature of R_C

• On the crate, I use the configuration message to fill one C structure per board, which is passed to an initialization function

• Result is that R_C "cold start" accomplishes same thing that was done by Alex's initialize_boards.c in last summer's slice test

• No event data in or out yet, but even in real life, SVT boards are just a pipeline, no DAQ readout

• Can then (in a separate program) drive data from HF OSPY, through other boards, and check spy buffer contents against expectation

• Not sure this was essential, but I made the C code capable of reading gzipped memory image files, to save space/traffic

• Future work

• Add Hit Finder; get SVT slice processing FIB data

• Move from "partition from text files" to database entries (which initially will probably just contain names of text files that contain memory images)

• Once SVX DAQ hardware is routinely included in test runs, we should start to include SVT

• Start some kind of monitoring task automatically on crate CPU

• Add Track Fitter

• Refine definition of each board's coldstart function and data

• Once Giovanni's plan for representing board memories is ready, we should use it to initialize the boards

• Eventually, define real database formats (probably not before summer)

• Need a plan for warm start as well as cold start

• Can we evaluate a checksum on various memory contents, and if it fails, request a coldstart download?