] > Information (now somewhat refactored) on the whiteboard after morning meeting of Aug. 8. File contains a list of operating modes, followed by a list of <delegates> (in the MOOT sense; see e.g. http://www.slac.stanford.edu/exp/glast/ground/notes/moot/moot21july05.shtml) and a list of <FSWinputs>. A <delegate> may have arbitrary collections of <parm> and <parmGroup> children; a <parmGroup> may also have <parm> and <parmGroup> children, so the hierarchy under a <delegate> may be to arbitrary depth. The smallest possible number of <parm>s should be used, subject to the following conditions: 1) information belonging to a single <parm> must all be destined for the same FSW input and 2) validity lifetime of all information encompassed in a single <parm> should be approximately the same 3) all information belonging to a single <parm> should come from "the same place". Configuration parameters for LAT housekeeping Configuration for charge injection calibrations. May also be enhanced to handle timing scans. This is the only delegate which allows registers to be set dynamically and repeatedly under program control. Other delegates concerned with registers ask to set them once. Can concatenate descriptions of multiple scans in a single calibration, but there is no easy way to express that here. If calibrations are typically done by running several scans in sequence, it may be a lost cause to try to specify it all here. Would be better to just let CAL_calib take a single value, which is a reference to a file containing all the details. Same would go for ACD and TKR calibrations. Thermal control parameters. Since input values all go into the same FSW file and probably tend to have the same lifetime, just need one <parm> element There isn't much here and it should hardly change. Not sure this belongs here; may belong under PIG Output for this one will be scattered among different LATC output files. tkr_trgseq, tack_delay field TCC tcc_trg_align register, both fields (shape_time, primitive_align cal_trgseq, tack_delay field delay_1, delay_2, delay_3 in CRC all fields within CCC trg_alignment register Doesn't seem to be anything here Is the one AEM register all that's needed? AEM trgseq register Various timeout and delay registers are set by PIG since they should only need to be set once after everything is powered up and network is established. AEM timeout register, various ARC registers (see lrd_aem.xml), TEM configuration register, CCC event_timeouts register, TCC event_timeouts tkr_trgseq and cal_trgseq tack_delay fields (TEM). tcc_trg_align register (TCC). delay_1, delay_2, delay_3 (CRC). ccc_trg_alignemnt (CCC). Could this just be one parm? Or will these things routinely change independently? All registers in ROI component of GEM; names are of form r_ijk_pqr or just r_ijk this one was questionable (paranthesized) Registers in WIN component of GEM: window_width and window_open_mask Configuration for each of the 16 engines includes at least TAM and mappings. TAM determines prescale, form of CAL readout, use/non-use of calstrobe, etc. Registers in the TAM component of GEM, named engine_i, 0<= i < f (oxf, that is); all fields. Also perhaps the mapping in SCH ("scheduler registers") of conditions to engines is what's meant. I'm making this one up, based on lrd and GEM document - seems not to be included elsewhere TIE in lrd-speak, or registers described in section 2.9, "Input enable registers", of GEM document. Output must be handled by CDM. How many pieces are there? Most likely will be moving cal gains and peds to CAL delegate; acd gains and peds to ACD delegate. n instances of the parms below. However, we might want to combine the whole thing in a single <parm> if all this stuff tends to change - or not change - on the same time scale; that is, in that case it might as well all be specified in a single file Output for this one will be split among different LATC files plus a little PIG. All broadcast (default) values have been gathered together in a single <parm>, the assumption being that none of them are likely to change very frequently. Has to be consistent with specifications in Power delegate PIG_acd_on(off) command. Also PIG (I believe) controls power state of free boards by means of AEM power_up and power_down registers. Exceptional only. No bcast version since there is only one AEM. However, if LATC AEM output is lumped together with DFT, might consider moving this to the "ACD default" parm data_mask field in aem_configuration reg. of AEM pha enable and veto enable register exceptional values Maybe should combine this parameter with the next one Veto DAC register and veto vernier register? Is HLD the right register for this? AFE HLD threshold registers PHA threshold registers AFE bias DAC registers ARC SSA and hvbs registers Seems to correspond to Max PHA enable register pha enable and veto enable registers (ARC), pha thresholds (ARC), veto DAC register and veto vernier register (AFE) HLD threshold register (AFE) Operating bias voltage (AFE) Max PHA enable register (ARC) Output for this one will be split among different LATC files + a little PIG. All LATC defaults go in a single parameter. TEM on/off state will be controlled within Power delegate. But there is a separate Calorimeter on/off field in the TIC power supply register which is handled by PIG and might logically be specified here. calorimeter field in TIC power supply register; PIG_calorimeter_on(off) command Will need to change over time. Exceptional values, if any. TEM data masking register. Exceptional values, if any. TEM GTIC cal input mask register (enable/disable a layer). Exceptional values, if any, layer masking, output of cable controllers. CCC layer mask registers, controller output enable field of configuration register CFE config 1 le_trigger_enable, he_trigger_enable. config 0 le_rng_enable, he_rng_enable fields. Other config 0 fields, such as OVERWRITE, FIRST_RNG, USE_FRST_RNG, having to do with range selection. CCC configuration register, data_fifo,error_fifo and diag_sum_fifo fields CFE registers FLE_DAC, FHE_DAC, LOG_ACPT, RNG_ULD_DAC (range select threshold?) TIC cal bias dac Includes defaults for all categories above: masks, FIFO depths, thresholds, bias voltages. TEM data masking register and the layer mask registers. Note both data masking and trigger masking may be specified here. Data masking register (TEM); cal input mask register (enable/disable a layer) (GTIC); layer mask registers (CCC); controller output enable field of config. register (CCC); config 1 le_trigger_enable, he_trigger_enable fields (CFE); config 0 le_rng_enable, he_rng_enable fields (CFE); Other config 0 fields, such as OVERWRITE, FIRST_RNG, USE_FRST_RNG, having to do with range selection (CFE); fifo fields in config. register (CCC); threshold registers (CFE); cal bias dac (TIC) Output for this one will be split among different LATC files. Put all defaults in a single parameter, in hopes that they all are extremely stable. TEM on/off state will be controlled within Power delegate. But there is a separate Tracker on/off field in the TIC power supply register which is handled by PIG and might logically be specified here. Tracker field in TIC power supply register; PIG_tracker_on(off) command Will need to change over time. Is there anything from TRC which goes here? GTIC layer enables and output masks TEM data masking register Input mask register, configuration register (output_enable field; maybe also cable_length field) data_mask, trg_enable Will need to change over time low, high registers Config register, fifo fields for summary/diag and TOT, error and data tfe_dac, threshold field tkr_bias_dac register regList is a guess csr fields size_write_en and size (TRC) This is maybe already covered under masks/trigger masks layer enables, output mask (GTIC) tkr_bias_dac register (TIC). data masking (TEM). input mask register, configuration register (TCC). csr fields for RC trimming (TRC). Config register, fifo fields for summary/diag and TOT, error and data (TCC). tfe_dac, threshold field (TDC). low, high registers (SPT). This delegate is different from the others in that it is not handled by FMX; hence there is no associated <FSWinput>. MOOT might not be involved in establishing a particular state, but it might be involved in tracking the state. May want to lump all this stuff together in one parameter. For several objects a choice must be made whether to use the primary or redundant unit (or neither or both, if it makes sense). List below is not exhaustive. Which ones are on? How to keep consistency with what's specified in CAL and TKR delegates? Same comments as for TEMSpower: keep track of which are on. May want separate parameter for each EPU. An <FSWinput> represents one of the kinds of files to be input to a FSW service. These should almost map 1-1 to files output by FSW. LATC outputs 15 different kinds of files, by last count. LCI outputs one kind, and CDM will ultimately transform all other kinds of input (housekeeping, event filter parameters,...) Single output for LAT Housekeeping parameters For ACD readout controller registers For ACD front-end registers For Trigger Interface Control registers For Calorimeter Cable Controller registers For Calorimeter Readout Controller registers For Calorimeter Front-End registers For Tracker Cable Controller registers For Tracker Readout Controller registers Guessing this is for Tracker splits For Tracker Front-End registers For Tracker Digital Converter registers FSW output binary contains values for one each of the register classes (GEM, AEB, ARC, AFE,...) CAL charge injection config. TKR charge injection config. ACD charge injection config. Single output for Thermal Control parameters Need to check that there really is such a thing as an output file dedicated to EBM