TRIGGER CALIBRATION QUESTIONNAIRE February 13, 1997 Version 0.2 4/11/97 Dear Dave and Gregory, CC: Walt and Paul This calibration questionnaire form was not filled out via the Web GUI. It was made from an empty version of the ascii skeleton that is mailed to Gregory and David - please refer to the Web form to see what the questions were: http://www.cithep.caltech.edu/~gpdf/calibration/questionnaire.html. realname ...... Fred Kral username ...... jfkral@lbl.gov formVersion ...... 2.0.0 detSystem ...... TRG detSystemOther ...... responseBlessing ...... Advisory DISCLAIMER: Almost none of the below information has been specified or designed. Most of the information has not been discussed with anyone else in the trigger group. It is really too early for us to commit. In 4 months, we should be in a much better situation for delivering reliable information. (Filling out this form was a lot of work. I hope it makes up for the absence of Trigger folks at the February 14 meeting.) responseType ...... New (Next 4 responses are in the opposite order of the questions.) readoutMapping ...... The trigger system is really three partitions in five front-end crates: DC - Drift chamber trigger 1 DAQ crate, 2* or 3 ROMs, 3 front-end crates EM - Calorimeter trigger 1 DAQ crate, 1 ROM, 1 front-end crate GL - Global trigger 1 DAQ crate, 1 ROM, 1 front-end crate 3 DC front end crates of two types: 2 TSF - track segment finder crates 1 BLT - binary link tracker and PT discriminator crate (NOTE: both BLT+PTD) 1 EM front end crate: 1 TPB - trigger processor board crate 1 GL front end crate: 1 GLT - trigger processor board crate The below enumerates the types of front-end elements in each crate. There are 6 different types of front-end elements: (1+2) TSF X-type and Y-type - recivers of the X and Y-type drift chamber endplate GLINK super, (3) BLT, (4) PTD, (5) TPB and (6) GLT. TSF crate 1: 8 TSFX Modules 4 TSFY Modules [option: 16 TSFX Modules]* TSF crate 2: 8 TSFX Modules 4 TSFY Modules [option: 8 TSFY Modules]* BLT crate : 1 BLT Module and 8 PTD Modules TPB crate : 10 TPBs GLT crate : 1 GLT Module Each front-end crate above sends data to one ROM. All three DC ROMs are in the same DAQ crate. *TSF Options: TSF crates may be sorted by X and Y types rather than having 12 TSFM's/crate. TSF crates may be served by 1 ROM rather than 2 ROMs, since ROMs have the capability to have two DLINKs per ROM. Different readout sections contributing different-length data: For simplicity, if a ROM receives both X and Y type data, the Y type data transmission will probably be padded out with blanks to make it the same lenght as the X data transmission. Likewise for the BLT and PTD that share one ROM. channelsPerSection ...... The number of channels per section is somewhat arbitrarily defined, below there is an indication of the number of bits per channel, intended to better explain the data (see also definitions below). There are four sets of data available to the DLINK: 1) DAQ data (listed in the below table). The below information is almost enough to calculate the size of a complete event: every "channel" has a certain sampling frequency (4 MHz or 8 MHz) and time window per event (1 us or 5us). Thus an 8MHz channel would transmit 8 times the below data per event. Headers are not included below. 2) Input Record Memory data. Every DC and GL Module has a input recording memory that may be read out during calibration or diagnostic runs. These can only be accessed through a non-runtime read command. They will not be read out during normal data taking. Sizes are under discussion, but they should be able to trap at least 24us of running. Estimate ~4KBytes for now. Each type module will have a different length memory. See below for EM trigger. 3) Output Record Memory data. Every DC and GL Module has one or more output recording memory that may be read out during calibration, diagnostic or test runs. See remarks under Input Record Memory data (estimate ~4KBytes for now). For this purpose, EM trigger board Spy FIFOs, located at various points in the algorithm logic flow, are read out via IOCs (I/O Controller CPUs) in the front-end crates. These communicate with EPICS and other detector controls systems. How is that information merged with DAQ stream data? 4) DAQ latency buffer data. It will probably be possible to read out the full 12us latency buffer data with a non-runtime CLINK command. Likewise for the four derandomizing buffers. DAQ data (item 1 above), accessible via L1 Accept CLINK commands: Name Number Chans/ Tot Bits/ Bytes/ Freq Window Number Section Sect Chan Chan (MHz) (us) Samples TSFX 16 75 1200 18 3 4 1 4 TSFY 8 72 576 18 3 4 1 4 BLT 1 1 1 64 8 8 1 8 PTD 8 4 32 15 2 8 1 8 TPB 10 4 40 5120 640 4/8 1+ 4+/8+ GLT 1 2 N 1 64 8 8 1 8 L 1 30 4 8 5 40 _____________________________________________________________________________ 1851 The GLT has two different types of channels: N - Multiplicity channels (object counts) L - Line channels (trigger lines) +The plus signs indicate that the calorimeter trigger TPBs use safety factors beyond the required 1us. These range from 25% to 100%. channelDefinition ...... All channels are composed of digital data. There are seven different types of channels. Note two types of channels in the global trigger. TSF - 16-bit segment address, 2-bit time stamp (best segment encoding mode) - in "raw segment encoding mode": 4 16-bit segment addresses BLT - 2 32-bit phi(A) and phi(B) track maps PTD - 15 bits with a lot of different meanings TPB - up to 5120 bits with a lot of different meanings GLT N - 16 4-bit object multiplicities L - 30 1-bit trigger line decisions channelCount ...... Total channel count is 1851. quantitiesWhich ...... At this point, the use of the "calibration" runs in TRG needs to be defined. Trigger does not have any pulsed analog inputs, unlike other systems. So what is given in this survey is information relating to an expanded view of what "calibration" means. Types of non-normal-running runs envisioned for TRG system: 1) Calibration run Parasitically using pulsed patterns from the DCH and/or EMC front-end systems. Some patterns would of course be requested as useful to the TRG group, and thus be in addition to the DCH and EMC planned patterns. Trigger cards will be reading out DAQ data via either true of fake L1Accept signals, or both. In DC and GL TRG, a calibration run may have Input and Output Record Memories enabled, for readout at the end of the calibration sequence, if deemed to be needed. In the EM, the separate IOC (I/O Controller CPU) readout stream from Spy FIFOs is performed, if needed. 2) Test run Using digitally downloaded digital playback patterns. These don't require a calibration strobe. They involve any permutation of TRG modules/crates being active. Each card has an Input Playback Memory that is switched in as an alternative to true realtime input data. DC and GL trigger modules have their Output Record memories enabled during such a test run. Playback FIFOs in the EM trigger are controlled via the IOC in the front-end crates; Spy FIFOs record the data at intermediate points in the board. Short basic test runs will precede every BaBar physics data taking run. 3) Diagnostic run This run is much like normal data taking. In the DC and GL trigger modules, both the Input and Output Record memories are enabled. These runs are only expected to be used to diagnose problems. It is hard to answer the actual question. I imagine most operational verification will happen in the online farm, not in the ROMs or ROCs. If problems are found, they will be used to debug the system. Very little information FROM a calibration will make its way back into the BaBar configuration database. I.e., the result of a TRG calibration, test or diagnostic run is mostly "Trigger OK or Trigger not OK" (1 bit). Based on reading questions below, you are also interested in learning about how we fill any configuration database entries used in the trigger. There are three types of configuration data: 1) "mask" data - dead/hot channels 2) algorithm "LUT" data - pattern/algorithm lookup tables 3) trigger "condition" data - programmable operation of algorithms Here is a partial list of places that need these data: TSF - hot channel mask, segment weight LUT, segment phi/time LUT, X/Y condition BLT - dead supercell mask, delay phi maps condition PTD - PT engine LUT, number of layers required condition TPB - FIR filter weights LUT, various data for trigger condition GLT - Lots of different data relating to trigger condition 1) Mask data will probably too come from offline (see below). 2) All of the LUT data will be derived from offline studies. For example, the segment finder look-up phi/time lookup tables will be derived from single-track events (probably 100,000 di-muons). Real data with beam backgrounds will be used to tune the weights for the calorimeter TPB finite impulse response filter weights LUT. 3) Configuration data will come from the online data base (in some cases, like the global trigger condition, from run control somehow). quantitiesWhereUsed ...... Main goal of TRG calibration, test and diagnostic runs is to verify the digital algorithmic operation of the TRG. In general, configurable TRG data are digital data derived from offline analysis with real data. All analog adjustments are done by the drift chamber and calorimeter front end systems (not in trigger). Places where a calibration run may potentially (hypothetically?) feed back into the TRG configurable data are in the TRG "front-ends": TSF - Drift chamber hot channel mask BLT - Drift chamber dead supercell mask quantitiesAccuracy ...... All digital results have to be exactly identical to expectations. quantitiesChanges ...... For the trigger internal operation: very rare :-) For dead/hot DCH and EMC inputs to trigger: see those systems. quantitiesRepresentation ...... All quantities are digital. All information needs to be looked at. calibsDataSources ...... Masks may come from calibration runs. All other data will come from normal physics data taking. calibsNormalData ...... We used 25,000 single muons (pt from 0 to 1 GeV/c) to calibrate the TSF phi/time LUTs in the Monte Carlo during our design studies. We'd need occasional 100,000 di-muon data sets to do this job with real data. From the data, we would need well-tracked lower-momentum tracks, so probably radiative Bhabhas. These tables would need to be re-done whenever the DCH time to distance relationship changes in a VERY significant way (changes at the 70ns level for a given drift distance - probably need a different gas or different HV to produce such shifts). calibsStimuli ...... Calibration runs: see DCH and EMC electronics calibration methods. (Is there also be an EMC personality-module pattern playback that originates from the EMC front-end system?) Test runs: Input Playback memories located on trigger modules. stimuliSources ...... Test runs: one Input Playback memory per module (in DC and GL trigger) and one Playback FIFO per board (in EM trigger). Configurable at begin-run time, then played. All digital. stimuliControl ...... Controlled through front-end CLINK protocol. calibsDetectorConditions ...... Calibration runs: same conditions as DCH and EMC require for electronics calibration. Test runs: no interference from other systems possible. calibsPEPIIConditions ...... Calibration runs: same conditions as DCH and EMC require for electronics calibration (probably means beam off). Test runs: no requirement, no limitations. calibsIntraSystemPartitioning ...... Need complete flexibility for the trigger crates and modules. calibsInterferedBy ...... Test runs: no problems from other systems. Calibration runs: need to cooperate with DCH and/or EMC systems, as required, when we need calibration pulses from those systems. calibsInterferesOn ...... None. calibsCombinedRequired ...... It is under discussion whether we need DCH *and* EMC at the same time for a calibration run. Cannot be excluded at this time. It is clear that we will need DCH with the DC (and GL) triggers and that we will need EMC with the EM (and GL) triggers. calibsFitSchedModel ........ (this button was not emailed to me) No. calibsFitSchedComments ...... No: Short test runs - we would like a basic TRG test run at every physics begin run. Such begin run tests need a time budget; the good news is that they can be done in parallel with anything else. Yes: Extended test runs fit into the 1/day category. Calibration runs probably fit into the ~1/week category. Diagnostic runs are "as needed" to debug real problems. calibsFitModel ........ (this button was not emailed to me) Yes. calibsDontFitModel ...... We don't have any stringent requirements. pulseType...... Only relevant for DCH and/or EMC calibration run for TRG. See their writeups. pulseMinDelayOK ........ (this button was not emailed to me) Yes. pulseMinDelayExplain ...... No problem. pulseDelayChanges ...... CalStrobe-to-L1Accept delay values larger than 2.2us will be required by TRG. Values of the order of 12us will be needed. The delay does not have to be varied during a single calibration in the TRG system. pulseDataProcessing ...... Data processing needed is comparing read out digital values with an answer-sheet - a set of values that have the expected outcome. Thus, we need to make word compares (A = B) for each read out word. minorCyclePulses ...... No accumulation of statistics via minor cycles is foreseen. TRG either works or doesn't. minorCycleDeadtime ...... minorCycleRateLimits ...... minorCycleDataCollected ...... minorCycleDataVolume ...... minorCycleCalculations ...... minorCycleResult ...... minorCycleResultLongevity ...... majorCycleMinorCount ...... Need 0 minor cycles per major cycle. majorCycleStimulusChanges ...... Changes between major cycles: this is only relevant for DCH and/or EMC calibration with TRG. DCH calibration: many different on/off patterns from the DCH front-ends will be needed to be tested. A guesstimate here asks for 10,000 different patterns to verify DCH to TRG connectivity and timing. EMC calibration: may need fewer patterns than DCH to verify connectivity and basic timing since rather than one bit per EMC channel, EMC can use 16 bits per channel. majorCycleStimulusSetupTime ...... See DCH and EMC systems. majorCycleStimulusControl ...... Probably ROMs or ROCs can cycle through the changes. (See DCH and EMC systems.) majorCycleCalculations ...... Compare actual with expected digital quantities. majorCycleResult ...... Not much to record - probably yes/no per major piece of data. Worst case would be 1 bit per channel. majorCycleResultLongevity ...... These data do not need to be archived. metaCycleWhich ...... Types of meta cycles: Calibration runs: DCH only test DCH to TSF connectivity and timing EMC only test EMC to TPB connectivity and timing DCH+EMC test overall timing synchronization Test runs: TSF playback test DC trigger TPB playback test EM trigger TSF+TPB playback test overall trigger metaCycleSetupChanges ...... I don't understand this question. How is it different from "majorCycleStimulusChanges"? metaCycleProcessing ...... Each meta cycle gives rise to a yes/no answer. metaCyclePipelining ...... Anything can be piplelined. validationMethods ...... TRG calibrations and tests are ONLY used as a validation. Again, just comparing measured digital words against template expected words. End result is just one big yes/no for the whole system. validationLeapfrog ...... Leap frog is not acceptable. For example, each "begin run" short test run needs to have a functioning trigger before the run is begun. On the other hand, there should not be much processing to do and there are no resulting constants going back down to the front ends as a result. minorCycleRateRequest ...... We won't use minor cycles. No large repetition rates are needed.