SVT Cold Start / Database Issues (WJA, 2001-02-05)

• Pros/cons of what we did in the commissioning run

• :) It was simple

• :) It was fast (both to implement and to run)

• :) It was flexible

• :) It worked

• :( Memory image files were big and cumbersome

• :( No easy way to reconstruct what we did as a function of time

• .

• Merging svtramgen into cold start code

• Eliminates need to store memory image files; generate them instead dynamically on the crate CPU

• The high-level files needed as input are, in any case, what the simulation code prefers as its input (SS map, patterns, etc.)

• Alex Barchiesi and Lucia Zanello have made great progress on this in the past 1.5 weeks

• Gathered code, data needed to reproduce Nov '00 configuration

• Made it run on VxWorks

• Next, make it write to boards (not files)

• Then seek minimal set of code/data/memory/clutter to do the job

• Database issues

• Hardware database (already) specifies, via metaKey, what role in SVT the board in a given crate/slot fulfills (e.g. "hb_w03", "sc_w00_w01", "tf_w00")

• This is (already) used by cold start code, e.g. to construct name of register file

• Trigger database will tell us which set of constants to use for a given run

• I imagine there will be only a few (fewer than ten) sets actively in use at any time, but we may make many revisions at the outset

• E.g. "nominal_wide_fakeXFT", "302_real_bfix" (output of previous talk)

• Easiest solution is to use this "name tag" ("SvtConfiguration"?) as the name of a subdirectory in which one finds the files needed for download

• This is seamlessly compatible with what we did for the commissioning run; allows adiabatic transition to new configuration scheme

• Perhaps (if we have the resources) we'll eventually use this "SvtConfiguration" string as a key into some other database, which replaces the flat files, if DBs prove easier to export than files

• Spoke with Stephen Miller a couple of weeks ago; told him my plan; sent e-mail yesterday to see how to make it happen

• Follow up with Stephen at TWG this Thurs?

• Calibration database

• In case we make small changes to config constants, which are not serious enough to warrant a new trigger table (e.g. we mask off a single troublesome pattern), store "version number" in calib DB

• Rick St. Denis tells me it is no problem to use run number + a string (we call it "SvtConfiguration", calib DB calls it "algorithm") as a DB key

• Probably separate versions for (a) patt, (b) gcon, (c) everything else, to avoid replicating big things for e.g. a one-register change

• Read SVX pedestal data from calib DB, apply a simple algorithm of our choosing to the data to tell HFs which strips to disable

• No need to maintain our own strip-by-strip data (yuck!)

• Petar and Igor assure me that this will be adequate

• Parametrize algorithm by version number and a few integers (TBD), read from calib DB

• Store a small amount of information per board (e.g. a few 32-bit words) in run conditions database, for paranoia

• Combined checksum of all large memories' contents

• Checksum of control register settings

• Some kind of firmware version / board ID information?

• Perhaps also store the (tiny) information (i.e. the magical directory name string) that was actually extracted from the trigger/calib DBs and sent to the crates

• Advantage is that run conditions DB is (if I understand correctly) only written at start of run, whereas calib DB may be updated afterward

• Do we also want an "SVT expert override" in the R_C GUI, to supersede what the DB chooses, for special test runs?

• Write code to initialize offline svtsim from same DB constants, reproduce boards' behavior