RCC-ROD Interface Requirements

Draft 0.5

25 January 2000

J.C.Hill (hill@hep.phy.cam.ac.uk)

This is a preliminary document - input welcome.

Introduction

This document refers mainly to the final RCC-ROD interface, so some of the requirements are not relevant or required for the prototypes.

I'm assuming in this document that the RODs are only directly (software) controllable from the RCC. Any instructions/responses from/to the central DAQ would go via the RCC (this assumption matches what the T/DAQ group expect).

Requirements

  1. RCC shall communicate with ROD via VME.

    VME64x seems to be the ROD standard in ATLAS, so it is unlikely to change.

  2. RCC will access BOC via ROD.

    BOC will have no VME functionality, just a 8-bit bus connection from ROD. Hence setup commands to BOC will have to feed via ROD.

  3. RCC must be able to do block transfers, programmed i/o and handle interrupts from ROD.

    This is directly from the "ROD99 Functional Requirements" document. It is likely that the initial use of the ROD will involve polling rather than interrupts.

  4. RCC loads configuration/calibration commands, including a broadcast mechanism. Includes run mode setup.

    Information about configuration and/or calibration taken from "databases" -ie. need access to SCT databases from RCC. This requirement assumes RCC handles communications with central services.

  5. RCC must be able to read error counters/flags in RODs.

    This information might be passed to the "Status Display" in global running, and only the RCC can communicate with the central services. It is also needed for the local monitoring of the behaviour of the RODs.

  6. RCC needs read/write access to histogram memory on ROD.

    RCC will copy histograms from RODs, either at end of run (as an example of an "automatic" operation), or on request. It also needs to be able to zero the histograms at any time. Also needed for calibrations.

  7. RCC needs read access to ROD event data (spy mode).

    RCC will pull sample events (or all the events in local mode) from RODs. RCC will send a command to the ROD to specify what sort of event should be sampled (eg. based on L1ID or minimum bias).

  8. RCC needs to respond to interrupts from ROD.

    Expansion of requirement 3. Also referred to in requirement 10. ROD might generate an interrupt when IT believes it is in trouble - RCC must evaluate situation and either try and correct and/or report to global DAQ.

  9. RCC needs to access BOC for synchronisation.

    Exact timing wrt FEs is not absolute - RCC needs to adjust settings on each ROD (and keep the information in a database). RCC also needs to access the BOC for thresholds and coarse timing.

  10. RCC can reset or turn off ROD.

    If a faulty ROD is causing problems (eg. high data rate) it must be possible to turn it off. RCC can do this either itself or on receipt of command from global DAQ. Ability to do this must be tightly controlled in software.

  11. RCC should monitor performance of ROD.

    Requirement overlaps various others, but RCC should be able to tell if a given ROD is misbehaving - not enough to cause major problems, but enough to impact on data taking efficiency and/or quality.

  12. RCC needs read and write access to ROD output memory.

    This is to enable testing of the connection from the ROD output via the SLINK to the ROB input (this requirement is not covered by any SLINK testing that might be possible, as one needs to see that the data gets from the ROD output memory to the SLINK).

  13. RCC needs read and write access to ROD input memory.

    This is to test that the ROD handles any data on the input stream correctly.

  14. In standalone mode, RODs have to indicate if their buffers are nearly full.

    To some extent an expansion of existing requirements. We may wish to run in a mode where we allow the ROD buffers to fill up before reading them out. It might be appropriate for the ROD to generate an interrupt if its buffer is nearly full, or alternatively to rely on polling a nearly-full flag in the ROD.

  15. RCC can issue single VME instructions to ROD to initiate slow commands.

    The ROD will have front end slow commands in memory. The RCC should be able to issue single VME commands to initiate a transfer to the front ends.

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