[Overview
| CDFVME] [Overview
| CDFVME]
|
The Run II Data Acquisition System (DAQ) being built for the upgraded CDF detector is based on a distributed CPU architecture. The system is comprised of roughly 120 VME crates scattered around the detector, the collision hall and the counting rooms. The crates mounted on the detector or in the collision hall are difficult to access, requiring a shutdown of the experiment. The crates in the counting rooms upstairs from the detector can be located up to 80m distant from the experiment. These VME crates contain about 1,000 VME modules, all of which need to be operating properly during data taking. As such, they require calibration, monitoring and attention at regular intervals. To facilitate the management of such a large system, each VME crate contains a local CPU, typically a 68040 or PPC on a VME board (Motorola MVME 162 or MVME 2301) running a real-time Unix variant known as VxWorks. In order for the system to operate efficiently and avoid network bottlenecks, each crate CPU is required to perform as much of the low-level initialization, monitoring and calibration of the local VME boards as possible. A Run Control program sends out high-level commands to each crate which interpret them into a series of low-level commands. This Run Control program, running on a Unix workstation or PC, communicates with the crate CPUs via ethernet. CDF is using Java, a popular new object-oriented language to write the User Interface to Run Control, and also for the core of Run Control itself. We then need a means of communicating with the various crate CPUs. Several standard methods are available -- we have chosen to use a product based on the CORBA (Common Object Remote Broker Architecture) specification. CORBA is a standard, implemented by various software packages, which allows for Remote Object Invocation. It allows one to request that functions be run in a crate CPU and provides a mechanism for passing down arguments and returning data. Designing, bulding, testing, running and maintaining such a large system of high-speed electronics is a difficult task. In parallel with the electronics design, software must be written for each task. In particular, code is required for the following stages:
Each of these steps can, and very often does, end up with its own unique software, which results in enormous duplication of effort. Further, each subsystem of the DAQ which requires integrating a series of VME modules spread over multiple VME crates faces the same problem of writing code to handle multi-board/multi-crate operation. In order to speed up the development time of the CDF DAQ system, and to reduce the amount of duplicated code, a set of software was designed which allows the exact same software to be used at all stages. The code packages are CDFVME_COMMON, CDFVME_TEMPLATE and CDFVME_TESTSTAND. The architecture is scalable from a system of a single VME board to dozens of crates and hundreds of boards. The basic structure is a client/server system, with a main client program (TestStand) written in Java running on a unix workstation or PC running Linux or NT. CDFVME_TESTSTAND, downloadable via upd or by ftp from here, is a template of a TestStand, a Graphical User Interface which allows the user to combine code from individual VME board support packages into a working system. CDFVME_TEMPLATE is a template VME board package, which users fill in so that all of their VME board functionality can be accessed through Java or C routines. Finally, CDFVME_COMMON is the core code which drives all of this, as well as providing other useful features such as a structure for running arbitrary user tests in a batch mode, useful for testing large quantities of boards. More information about these packages can be found on the CDF Online pages, which contain copies of talks, a userguide and instructions on setting up and running on NT.
|