SCT ROD Crate DAQ Status and Schedule

1
SCT ROD Crate DAQStatus and Schedule

• John Hill
• University of Cambridge

2
Summary of talk

• Short description of ROD Crate Controller (RCC)
  in context of ROD crate.
• Main requirements of RCC.
• Quick summary of interfaces.
• Status of DAQ software in RCC.
• Schedule.

3
SCT/Pixel ROD Crate - latest layout

• Mixed 6U/9U crate (RCC will be 6U).
• VME64x.
• Maximum 16 RODs/crate (not fully occupied in
  current planning).
• 8 ROD crates each for SCT and pixels.

4
ROD Crate Controller

• Hardware not yet defined - wait as long as
  possible
• to avoid specifying a processor that will be
  obsolete long before LHC starts running!
• to see what recommendations may come from T/DAQ
  group
• Prototype RCC using PCNI-VXI interface
• hardware already in use in a large number of SCT
  labs (and most importantly in the systemtest lab
  and the test beam)
• a lot of software support and experience already
  available (eg. LabWindows, SCTDAQ for existing
  readout hardware)
• Final RCC could be similar (Linux support for
  NI-VXI is now available), or a single board
  computer.

5
ROD Crate Controller - context

• See the diagram (courtesy Tom Meyer) for a
  possible context for the RCC.
• This is just a working proposal - the details of
  how the ROD Crate DAQ might appear are still
  being developed.
• for single-crate setups (eg. assembly sites, test
  beam), might have RCC at top level of ROD Crate
  DAQ
• for multi-crate setups (eg. final assembly,
  ATLAS), maybe a master RCC approach could be
  used
• However, it gives a good idea of how the RCC is
  likely to fit into the overall scheme.

6
(No Transcript)
7
ROD Crate Controller - requirements

• Not an exhaustive list - just describes the main
  requirements of the RCC
• operate both in global ATLAS and local mode
• communicate via the VME interface to the other
  modules in the crate
• BOC communication is indirect via the ROD
• ROD communication will be via the primitive
  mechanism
• TIM communication will be by direct access to the
  VME registers
• communicate over the LAN with central ATLAS
  services
• examples are Run Control, databases, Status
  Display
• initialise the modules in the ROD crate for
  data-taking
• might be as instructed by the ATLAS DAQ or local
  DAQ
• database information will be used to define the
  configuration

8
ROD Crate Controller - requirements

• RCC will be able to read events and/or histograms
  from RODs
• in ATLAS running event reading will be in spy
  mode (maximum rate 1kHz), with programmable
  selection criteria
• in local running this is the mechanism to get
  events from RODs
• histograms may be stored in a database for each
  run
• RCC must be able to reset, reconfigure or
  disable/enable a ROD
• to deal with a faulty ROD
• this may have to be dynamic if problems with 1
  of readout is not considered sufficient to pause
  ATLAS running
• during normal running, the RCC will continually
  monitor the RODs

9
ROD Crate Controller - interfaces

• Overlaps information presented elsewhere, so will
  skip over it quickly
• interface to ROD and TIM via VME
• initialisation, configuration, reading events,
  reading histograms, monitoring behaviour
• BOC interface is indirect via the ROD and the
  setup bus.
• synchronisation of the front end timing
• DCS, ATLAS DAQ interface via LAN
• will use whatever LAN technology is selected for
  ATLAS

10
ROD Crate DAQ - Status

• Existing readout of SCT modules uses SCTDAQ - see
  
• http//g.home.cern.ch/g/gmoor/public/sctdaq/sctdaq
  .html
• Developed by Gareth Moorhead, Peter Phillips and
  John Hill.
• Main purpose is for understanding of SCT front
  end modules.
• Current version uses MuSTARD, CLOAC, SLOG, SCTLV
  and BiLED for readout (see diagram and photo).
• Implementation is modular via a set of hardware
  libraries, and so including ROD/BOC/TIM should
  not be difficult.

11
(No Transcript)
12
(No Transcript)
13
ROD Crate DAQ - Status

• Above the individual libraries, st provides the
  glue that makes them work together
• root is used for display and control (see
  picture).
• SCTDAQ has been used in the systemtest lab (B186
  at CERN) and the 2000 SCT test beam, as well as
  in a large number of institute labs.
• Since the ROD User Evaluation has to mesh in
  with work on front end modules (which are much
  scarcer than had been hoped, and hence not
  available for dedicated ROD evaluation), it is
  natural to consider the use of SCTDAQ as the
  framework for initial ROD evaluation in the
  field.

14
(No Transcript)
15
ROD Crate DAQ - status

• However - clearly SCTDAQ is not suitable for the
  ROD crate DAQ to be used in ATLAS, so we need to
  start to develop this final DAQ in parallel with
  the evaluation of the prototype RODs.
• This will be an iterative and incremental process
  (see Toms slide)
• Use Cases are the primary mechanism in defining
  what we need.
• work on this has already begun
• not critical to get all the Use Cases enumerated
  initially
• implementation issues are not addressed (so we
  avoid technical nitty-gritty until it is
  necessary)

16
Methodology

• Analysis (Define the problem)
• Design (Elaborate the problem)
• Implementation (Design the solution)
• Testing (Test the solution)
• Release (Let users beat up the solution)

The key point Iteration
17
ROD Crate DAQ - status

• Basic tool for the design phase will be UML
  (Unified Modeling Language) - seems to be fairly
  universally accepted
• Important to get the design right - dont rush
  into implementation
• this was graphically demonstrated by the
  successful way the ROD DSP software was developed
  (we seemed to spend a long time in the design
  phase, but the implementation went quickly and
  painlessly)

18
ROD Crate DAQ - status

• Can we use existing software? We should certainly
  avoid reinventing the wheel if possible.
• The ATLAS DAQ-1 Backend software (see URL
  provides many of the services we need
• Run Control
• Database tools
• Message Reporting
• Process Management
• etc.
• Also it would allow us to integrate in a natural
  way with the ATLAS DAQ (ie. we would minimise
  incompatibility issues).

19
ROD Crate DAQ - status

• Can we use existing software? We should certainly
  avoid reinventing the wheel if possible.
• The ATLAS DAQ-1 Backend software (see URL
  http//atddoc.cern.ch/Atlas/DaqSoft/Welcome.html
  ) provides many of the services we need
• Run Control
• Database tools
• Message Reporting
• Process Management
• etc.
• Also it would allow us to integrate in a natural
  way with the ATLAS DAQ (ie. we would minimise
  incompatibility issues).

20
ROD Crate DAQ - status

• The Backend software is available as a bi-monthly
  release (including sources) on CD - we can take
  the package away and evaluate it.
• The ATLAS T/DAQ group view DAQ-1 as the most
  appropriate starting place for DAQ in ROD crates
  (and in Spring 2000 it was used by the TileCal
  group in their test beam) - hopefully this means
  some assistance because...
• Though we are starting the evaluation process,
  progress is constrained by limited manpower.

21
ROD Crate DAQ - Schedule

• Taking software from the test stand and
  integrating in the existing SCTDAQ is envisaged
  by end-September 2000.
• Up to March 2001 is the User Evaluation period
  - main non-expert location will be the SCT
  systemtest. Software will be developed during
  this period in the light of experience.
• In parallel with the above two activities,
  continue the specification and design of the
  final RODDAQ.
• Spring/Summer 2001 - the ROD may be used in the
  ATLAS SCT test beam, either with SCTDAQ or with a
  first version of the final DAQ.

22
ROD Crate DAQ - Schedule

• In any case, a version of the final DAQ will be
  needed soon after summer 2001, as construction of
  the first SCT barrel is scheduled to start at
  that time, which needs 1 full crate of RODs to
  be completely read out.