1 / 22

SCT ROD Crate DAQ Status and Schedule

SCT ROD Crate DAQ Status and Schedule. John Hill University of Cambridge. 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.

bianca
Download Presentation

SCT ROD Crate DAQ Status and Schedule

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCT ROD Crate DAQStatus and Schedule John Hill University of Cambridge ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  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 PC+NI-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. ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  6. ATLAS SCT and Pixel Off-Detector PDR

  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 ATLAS SCT and Pixel Off-Detector PDR

  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 ATLAS SCT and Pixel Off-Detector PDR

  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 ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  11. ATLAS SCT and Pixel Off-Detector PDR

  12. ATLAS SCT and Pixel Off-Detector PDR

  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”. ATLAS SCT and Pixel Off-Detector PDR

  14. ATLAS SCT and Pixel Off-Detector PDR

  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 Tom’s 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) ATLAS SCT and Pixel Off-Detector PDR

  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 ATLAS SCT and Pixel Off-Detector PDR

  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 - don’t 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) ATLAS SCT and Pixel Off-Detector PDR

  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). ATLAS SCT and Pixel Off-Detector PDR

  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). ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

  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. ATLAS SCT and Pixel Off-Detector PDR

More Related