L1Calo State Transitions

Introduction

Configure

Connect

Prepare for Run

Others

Murrough Landon

17 May 2006

L1Calo: Overview

Hardware

17 crates: 1 * TTC, 2 * ROD, 8 * Preprocessor, 4 * Cluster processor (CP), 2 * Jet/Energy processor

Use of transitions

Presently use both existing load and configure

Load: reset hardware/firmware and clocks

Configure: download parameters and check connections between crates

Could remap to new configure+connect

Or use old load+configure as internal substates of new configure transition and move connection check to new connect transition

Transition Actions: Load

Configure (part 1, “load”)

Load hardware description (presently OKS), parse crate setup and all connectivity (from COOL later?). Currently ~1s (small system), more with final system

At present allow IS flags for quick enable/disable of modules

DB access done in singleton once for all RCD modules

Reset modules, reset clocks, wait for internal synchronisation. Wait for firmware to load. Check on board firmware is correct version, if not download latest firmware (tens of seconds/module).

Resets and waits might benefit from multithreading?

If firmware stored in COOL could be >10Mbyte/crate

Presently 1-10s per module (without firmware download), but very likely this can be optimised.

Transition Actions: Configure

Configure (part 2, “configure”)

Load standard settings. These might be run type dependent.

At present we have several sets of simple run types all defined in OKS DB and read together

In future expect more complex descriptions in CORAL.

In test systems, run type change needs reload, but might not be required in stable final system

Load calibration data (now from OKS, but will be from COOL/CORAL). Worst case may be ~1MByte/crate. Typically ~50kByte/crate.

Downloading settings should be fast (<1s/module) so this phase probably dominated by DB access time

Transition Actions: Connect/Prepare

Connect

If we reorganise present load and configure, then:

Check connections successfully established between crates, reset error counters

No new DB access. Should be fast (<1s)?

Could use disconnect/connect to reset links

Though at present this needs another load transition

Prepare for Run

Might want to reload trigger thresholds (~1s)?

Possible reaccess of trigger menu DB

However it is envisaged that values of thresholds dont change during a fill, only prescales which is done at the CTP and doesnt affect L1Calo settings

Transition Actions: Others

Other transitions

StartTrigger: used to remove busy. Also to start set of calibration/test triggers

No use of checkpoint yet

Do use user broadcast commands for calibration/test (but no additional DB access)

Unload/unconfigure closes DBs: reload cycle will reread DBs completely, ie no update yet

During the run

At present no DB changes and no response to any other asynchronous changes

But envisage monitoring and response to hot cells

Murrough Landon

2006-01-28T11:35:15