Monitoring the TABs and GAB using the Event Data Memories

updated: 25-May-05

Index

  1. Description of the Event Data Memories
  2. Offline Test Mode Running
  3. Online Test Mode Running
  4. Online Monitoring

Offline Test Mode Running

This mode of running is foreseen to be used when the TAB/GAB system is not connected to the DØ SCL timing, but uses VME/SCL board local timing signals instead. It is used primarily for standalone tests of the Nevis hardware/algorithms.

Requirements on the Pulse Signal:

  1. The system should be initialized (i.e. before init is sent to the TABs and GAB) to generate the pulse starting each time the BC and TURN numbers reach values specified by the control software.
    It is the responsibility of the user to read the desired memories before the next occurence of the trigger BC/TURN.
  2. The width of the pulse (in BCs) should be setable through the control software at initialization. Values from 1 to the maximum allowed by the event memory depths in the TAB chips 0-9 should be allowed.
  3. If it is not too difficult to implement, the BC/TURN and width parameters should be changeable through the control software while the system is running. When made these changes should happen at the next triggering BC/TURN combination.

Requirements on the Accept Signal:

  1. The timing of this signal should be specified at initialization as an offset from the pulse signal. (This is the way it's done now, right?)

Online Test Mode Running

In this mode the TAB/GAB system gets its timing from the DØ SCL signals but we still want to store data for specific BC/TURN combinations. This could be used for:

  1. Tests involving data from the ADFs. For example, cable connectivity tests.
  2. Local tests using special BC/TURN-based triggers (if such things exist?)

Requirements on the Pulse Signal:

  1. The same as for Offline Test Mode, plus
  2. Need to be able to freeze the event data memories (prevent further writing) until they are read out or come up with some other strategy to prevent reading from the memories while they are being written and to ensure that a well-defined event is read.

Requirements on the Accept Signal:

  1. This signal will come from the DØ framework over the SCL.
  2. Do we need the ability to generate it locally at the VME/SCL card, through a VME command as well ???

Online Monitoring

In this mode, we need to collect monitoring information when the DØ framework sends out a collect status bit on the SCL (approximately every 5 seconds). Memories that should be read out for monitoring (under the control of EPICS ?) are:

  1. TAB: input TTs
  2. GAB: ???

Requirements on the Pulse Signal:

  1. This should be derived from the collect status SCL bit at the VME/SCL board.
  2. The width of the pulse should be downloadable at system initialization. It may be useful to allow widths > 1 BC here.
  3. The ability to freeze event data memories is probably not critical here because the only source of pulses during online running will be from collect status. Readout of all monitoring data has to be completed before the arrival of the next request though.

Requirements on the Accept Signal:

  1. This signal will come from the DØ framework over the SCL since this is normal running mode.