L1 Upgrade Summary

Original contributions are here

Simulation Code

General

• Need global switch (ptd/zpd/...) and utilities to manage modules/sequences in L1Sim.
  Simple switch for now, can be 'upgraded' to a more L3-style DB-driven sequence generation if the need arises.
• Switch information from TrigConfig (new info, coupled with GLT object def)
• Need lightweight L1SimApp for code testing and 'standalone' operation.
• Board latencies can either be applied at module level or at entry to GLT. Preference?
  Decided to code in possibility to apply module latencies, but set to zero (or disable) for now. Use common location (L1DLatencyConfig) to hold this info (hardcode for now).

TSF

• "As good as ready." Small updates need to be propogated from L1DczTest
• LUT mechanism works
• Calibration of new 6bit LUT needs work, can install in DB late

ZPD

• Work started in migrating code from L1DczTest
• Use L1DZpdConfig to hold parameters needed for simulation
  (hardcode for now, Config DB later)
• Other two LUTs (16bit/32bit) needed to hold configurable parameters (ConfigDB).
• Use 'baseline' DM for current simulation. DM may change late.

BLT

• Sim code should be straightforward "90% in one or two days"
• Conditions DB entry needed for algorithm changes (not high priority)
• Config DB entry needed for BLT mask
• Need proper output "digi" to feed GLT

PTD

• Significantly more complicated than BLT
• No DB config needed (as nothing has ever nor will ever change)
• Need proper output "digi" to feed GLT

GLT

• Five modules to handle Delay/Match/Combine, Object Count, Decision Module, Select trigger & T0 adjust.
• True time buffer input (simple EMT/IFR module needed)
• Object count will certainly have separate modules for old (pdt) and new (zpd).
  Use global switch info/utility to control this.
• Use online code to build object count LUT in simulation.
• Need configurable line map (or object order) in TrigConfig
• GLT algorithm may change after system is installed and studied.
• GLT object names must uniquely identify modules to be run. If new code is required then the trigger object must have a new name.

General Online/Offline

Online

• See Gerald's updated list

Digis

• TSF Digi 'upgrade' complete, persistent digi written, needs testing (skip to ROOT?)
• L3 needs only TC, no (real) dependence on TsfDigi
• ZPD Digi suite complete, persistent digis not done (wait and write ROOT version instead).
• PTD/BLT Digis unchanged (actually, there never was a SimDigi sending info to GLT, need to verify that existing Digi info is adequate.)
• GLT digi to change?
• No need to persist status digis

TC -> Digi -> TC

• TSF new Digi -> (post 2001) TC works, is all that is needed for L3.
• No problem reprocessing 99 data? (read old TsfDigiP, create new TsfDigi, convert to new TC for L3, L3 is happy, tracking is happy). Use run 9933 as a test of this.
• ZPD TC->Digi works, Digi->TC needs to be done.
• No need to put Status header back into TC.
• Use sector order in TC (TSF and ZPD + others?) to determine slot order.
  No need for slot-Dch sector map. TC must contain empty containers for every board, TC writer must know 'expected' number of boards.
• 'Slightly intelligent' TC comparator must be written

Configuration

• "Configuration flexibility" a virtue. tcl override, flat file reading, etc.
• General need for Conditions : Config : Fault proxy handling
• Need config Digi -> config TC convertors
  config TC should contain same info as config Digi, not derived/calculated quantities)
• Configuration parameter list

Tools

• Large scale commissioning in Nov03, deployment in Jan04?
• L1TNtuple primary tool for detailed checks (100k events)
• Online L1SimChecker very valuable
• Modular, 'unencumbered' simulation code highly desireable
• Online TSF digi comparator for fall
• Trigger event display
• L1TFmon needs updating, improvements
• L1TOprMon needs updating, improvements