1. 2010-04-21E. Hazen - Detector Systems1 HCAL Initialization Cooling it Down!

2. 2010-04-21E. Hazen - Detector Systems2 Required Functionality ● What happens now? ● DCC: init() and coldInit() – Lots of C++ constructors and memory allocation – Reset everything via VME: Counters, EvN, Slink etc ● What is desired? ● DCC: warmInit() – Same thing, but without any memory leaks!? ● Just re-load all the DCC registers from existing configuration? ● Are config DB changes allowed? ● What about EvN, OrN? Is ok to reset them? ● Is it possible to have a stop() before warmInit()?

3. 2010-04-21E. Hazen - Detector Systems3 Existing Code Review hcalDCCManager.cc hcalHTRManager.cc Reload LUTS Reload ZS thresholds Reset link error counters (only) Does not change EvN, OrN, counters of # L1A etc? Resets everything All registers, EvN, OrN, etc Calls prepareForRun() Calls startRun()

4. 2010-04-21E. Hazen - Detector Systems4 Existing DCC Firmware Functionality ● VME Functions: ● 1. Reset all registers including EvN, OrN etc ● 2. Reset TTCrx ● 3. Reset SLink ● TTC broadcast functions: ● OcR, BC0 -- reset OrN, BcN ● Resync -- reset EvN, flush data (or not, config option)

5. 2010-04-21E. Hazen - Detector Systems5 What must be changed for DCC? ● Provided it is OK to start with EvN=1 after warmInit(), only some software (not very difficult) ● Implications for monitoring: ● If an error condition occurs and we do warmInit(), the information on what cause the error could be lost ● Jeremy sez monitoring force-flushes when: – run number changes – partition changes into Active, Ready or Paused ● Does this mean the hardware registers are read before the state change?