Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 August 2000ATLAS SCT and Pixel Off-Detector PDR 1 SCT ROD Crate DAQ Status and Schedule John Hill University of Cambridge.

Similar presentations


Presentation on theme: "1 August 2000ATLAS SCT and Pixel Off-Detector PDR 1 SCT ROD Crate DAQ Status and Schedule John Hill University of Cambridge."— Presentation transcript:

1 1 August 2000ATLAS SCT and Pixel Off-Detector PDR 1 SCT ROD Crate DAQ Status and Schedule John Hill University of Cambridge

2 1 August 2000ATLAS 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.

3 1 August 2000ATLAS 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.

4 1 August 2000ATLAS 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.

5 1 August 2000ATLAS 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.

6 1 August 2000ATLAS SCT and Pixel Off-Detector PDR 6

7 1 August 2000ATLAS 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

8 1 August 2000ATLAS 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

9 1 August 2000ATLAS 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

10 1 August 2000ATLAS 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.

11 1 August 2000ATLAS SCT and Pixel Off-Detector PDR 11

12 1 August 2000ATLAS SCT and Pixel Off-Detector PDR 12

13 1 August 2000ATLAS 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”.

14 1 August 2000ATLAS SCT and Pixel Off-Detector PDR 14

15 1 August 2000ATLAS 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)

16 1 August 2000ATLAS 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

17 1 August 2000ATLAS 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)

18 1 August 2000ATLAS 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).

19 1 August 2000ATLAS 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).

20 1 August 2000ATLAS 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.

21 1 August 2000ATLAS 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.

22 1 August 2000ATLAS 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.


Download ppt "1 August 2000ATLAS SCT and Pixel Off-Detector PDR 1 SCT ROD Crate DAQ Status and Schedule John Hill University of Cambridge."

Similar presentations


Ads by Google