RCC Essential Model

Draft 0.2

16 July 1999

John Hill (hill@hep.phy.cam.ac.uk)

This is a preliminary attempt to describe the essential model of the ROD Crate Controller. While it is certainly not complete, I hope the information in this document is correct. Comments/corrections/omissions will be gratefully received.

Introduction

A ROD Crate Controller (RCC) is a processor which is housed in the ROD crate. There will be one processor per ROD crate. Its basic task is to control the RODs in the crate, but it will also interact with the Back of Crate cards (BOC) (indirectly via the RODs), TTC Interface Module (TIM) and also the global Trigger/DAQ. The details of the implementation are not well defined, but the choice will be influenced by the recommendations of the Trigger/DAQ group.

Context

See the diagram at http://www.hep.phy.cam.ac.uk/atlas/hill/rcc_essential.ps or .gif - this shows the context in which the RCC works. In particular:

The RCC responds to Run Control commands from central DAQ.
The RCC will read the appropriate database information from the central databases when necessary.
The RCC issues commands to the RODs (including BOCs) and the TIM as necessary.
The RCC can read register information from the RODs (including BOCs) and the TIM over the VME backplane.
The RCC can read event data, histograms and error counters/flags from the RODs over the VME backplane.
The RCC will send summary histograms, error counters/flags and database updates to the central DAQ.

Notes

The RCC may be a VME-based single board computer, or an interface module plus a PC. The choice will depend on recommendations from the Trigger/DAQ group. For planning purposes the choice has no bearing on the Essential Model.
The RCC must be capable of the following VME functions: block transfers, programmed i/o, broadcasts and interrupt handling.
The interface to the global Trigger/DAQ is likely to be ethernet or similar - the RCC must support whatever choice is made.
The RCC must be able to operate in standalone and global mode. It is likely that a standardised (or close) Local DAQ will run in the RCC and that this will cater for both modes of operation.
The RCC must be able to handle event data from the RODs over VME at up to 1kHz. It must be able to either analyze the data, or write it to local storage.
The RCC must be able to read histogram data from the RODs over VME. It must be able to process these data and generate a summary, which will then be sent to the central DAQ.
The RCC must be able to read and write the registers in the RODs and the TIM.
The RCC must initialise the RODs as appropriate. In global mode, the ROD-ROB link must be enabled, the Front Ends to be enabled are read from the configuration database and the RCC will spy a sample of events over the VME backplane. In standalone mode, the ROD-ROB link must be disabled and it is likely that the information about enabling Front Ends will come from information held locally. All events will be read over VME.
Similar considerations apply to the initialisation of the TIM - it must be set up correctly for either standalone or global mode of running.
The RCC must handle Run Control commands from the central DAQ and issue the relevant instructions to the RODs and/or the TIM. It must issue a Run Control acknowledgement or an error to the central DAQ on successful completion or failure as appropriate.
The RCC must be able to initiate a calibration of the Front Ends. The TIM will be signalled to issue the appropriate command to the RODs. The RCC must read the data back from the RODs and handle it in the correct way.
The RCC must be able to read from and write to the central databases. The exact details of which databases will be accessed are not yet worked out.
The RCC must monitor the event counters and flags on the RODs, and transmit them (or a summary) to the central DAQ.

This file is http://www.hep.phy.cam.ac.uk/atlas/hill/rcc_essential.html