Will initially be sited at INFN Legnaro where it is hoped to start operation early in 1997 for a period of 15-18 months.
It is then scheduled to continue at CNRS Strasbourg in late 1998.
Uses integrated electronics with full software control using the VXI (VMEbus eXtensions for Instrumentation) standard.
Existing electronics from Eurogam I and Eurogam II
VXI electronics for the Cluster detectors (total of 15 sets)
A PPADC channel is under development which could be used in the future to replace the ADCs on the Ge card. This would be a third card per detector.
The Neutron detectors are planned to have VXI cards (50 channels with 8 channels/card) and the Si ball (at least 42 channels) may use VXI.
Eurogam I and Eurogam II used "Common Dead-Time" mode VXI readout. This means that all the electronics remained disabled while an event was being digitized by the adcs and the data read from each card active in the event by the crate ROCO. Apart from being simple this mode also ensured that there was no other activity in the crate during the analogue processing stages within the VXI cards. At the time the Eurogam I VXI cards were being designed this was a sensible precaution.
Euroball will use a "parallel" mode in which only the VXI cards (detector channels) active in an event will be disabled and then only until the data is in a FIFO ready for VXI readout. All other cards will be reenabled as soon as it is determined that they have no part in the current event.
The Eurogam I cards cannot be made to operate in this parallel mode and so 2 pairs of cards only will be installed in a VXI crate (total 3 crates) and the crate be treated as a unit in parallel readout mode. For later phases of Euroball the Eurogam I cards will be redesigned.
All new cards will use a General Interface and Readout (GIR) unit for the VXI/VME interface and readout. This enables the VXI cards to be more modular and removes the need for each card design to reproduce the VXI/VME interface.
The Euroball Data Acquisition system is required to be able to collect the data generated by event rates up to 50 - 100 kHz in order to be suitable for a wide range of experimental situations. The corresponding raw data rate will depend on the particular experiment but data rates up to 20 Mbyte/sec are required to be handled by the initial system. Additionally the system design has to be scalable so that higher data rates can be handled in the future simply by the addition of further hardware within the existing structure.
Euroball will often be used coupled with ancillary detectors of varying complexity. In some cases these will have their own VXI electronics and thus will couple into the core system without problem. However, others will use CAMAC ADCs with FERA readout and possibly VME ADCs. It is therefore important that the ReadOut system be able to handle these other type of data source in addition to DT32 bus for data from the VXI crates.
The Eurogam ROCO can output data onto the DT32 bus at 330 nsecs/word (12 Mbytes/sec) which is less than the required data rate from Euroball.
In its core configuration Euroball will consist of 9 VXI crates which could expand to 12 or more when PPADCs and ancillary detector electronics are added.
Thus Euroball will use multiple DT32 bus readout chains. It is expected that 3 buses each with 3 or 4 VXI crates will be adequate for all uses. Also the Eurogam ROCO will be replaced by the Struck STR8080 which was developed for the Heidelberg Crystal Ball. The STR8080 contains a DSP (Motorola 96002) which can be programmed to generate the control tokens needed for secure operation within a multi-bus readout system. It can output data onto the DT32 bus at 100 - 125 nsecs/word (dependent on DSP program) which is 32 - 40 Mbyte/sec and thus greater than our requirements for Euroball.
The Event Collectors act as a bridge between the data readout bus and the event builder processors. They each collect event fragments for a given number of events (at high rates this would be typically 10K events) to generate a "Super-Event" fragment buffer. The "Super-Event" fragment buffer in all Event Collectors must contain only data from the same Master Trigger events. These buffers will be generated at a rate of not more than 10 per second which will allow all subsequent buffer handling to be performed at non real-time rates and thus allow the use of standard UNIX operating systems.
The Event Collector contains a DSP (Texas TMS 32000) which is mainly used for control of the data readout and counting of events to determine when a "Super-Event" fragment buffer is complete. It can also be used for some data integrity testing.
One of the most critical parts of the system is the event builder and thus the event distribution from the Event Collectors to the processor farm which performs the task of combining event fragments into complete events.
The event distribution for Euroball will be performed using a switching network to the Fibre Channel Standard (FCS). A 16*16 node switch will be used with individual interface ports at 255 Mbits/sec. Switched networks such as FCS and ATM have total throughputs measured currently at several Gbits/sec (the data rate on the switch backplane). This is a significant advantage over broadcast networks such as ethernet and fddi in which the total throughput is limited by the individual port data rates (100 Mbits/sec in the case of fddi).
Fibre Channel is being developed by manufacturers such as IBM and HP to connect disc farms to processor farms. Also see the SCSI-3 proposals.
Super-Event fragment buffers of the same events collected in the Readout Units are sent in parallel via the FCS switch to the same destination processor to be analysed. The fragments are tagged with the event number within the ROCOs.
The event builder function includes tasks such as:-
All data sources (ROCOs and FERA masters) are required to generate an event fragment even if it contains no data. This is important for the event construction since it is possible to detect a missing event fragment or malfunctioning data source which would not be the case if empty fragments were not required.
The Event Building and Online data analysis functions take place within the Processor Farm. This is composed of standard commercially available workstations which are connected to the FCS switch. The data buffering within the Event Collectors both allows for efficient use of the Fibre Channel and reduces the interrupt rate of individual processors within the farm to a few Hz. This allows the use of a standard UNIX system within the farm processors. The use of UNIX allows for a much better software development environment and thus more secure software than is normally possible if a dedicated real-time operating system is used.
Control communication between the elements of the Processor Farm and the Event Collectors is performed using ethernet which is possible at the low interrupt rate being used.
The processors within the farm are controlled using the Common Object Request Broker Architecture (CORBA).
Online analysis is defined as all the data processing that is performed by the processor farm during the acquisition of the raw data. The processor farm can be partitioned to allow two modes of operation:-
If required all processors in the farm can be used for this mode of operation in which case Type 2 will not be available.
In this mode of operation a predetermined percentage of events is sent to the processors or more likely all output data and the processors just handle as much as is possible.
A complete development tool called the Neo++ Development Center is available to users to aid the programming of the processor farm in both Types of operation. The tool allows the user to create programs (following the Neo++ rules), to compile it, load it into the farm and execute it. A full source debugger is also available. The appropiate interface procedures will be available to users who which to run their own analysis codes on the processor farm.
Neo++ is an extension of the C++ language providing the statements to program the processor farm. In particular it provides the grammar needed to describe the raw data format of the expected input events, the data processing required, the output data streams, the building of histograms and gates and dynamically setable variables to allow run-time interaction with the analysis code.
The same access method as used for the hardware histogrammer will be used thus enabling the histogram viewer and analysis codes to freely mix online hardware and software histograms with offline histograms.
Hardware configuration for Euroball III
Supports up to 4 data streams
Each data stream may be output to any number of the drives in either duplication mode, parallel mode or any combination of these.
Currently DLT4000 available (20 Gbyte/tape and 1.4 Mbyte/sec). By Summer 1996 it is expected that 5 Mbyte/sec (raw) will be available.
The Exabyte 8500 drive can write up to 5Gbyte of data onto a 8mm video cassette at a continuous rate of up to 0.5 Mbyte/sec.
Experiment control and monitoring will be based on the Eurogam system.
The Eurogam Register Server will be used for control functions with an interface developed to communicate with the CORBA system.
The Tool Command Language (as used by Eurogam) will be used to generate the Graphical User Interface.
Will use existing Eurogam LeCroy mainframes with new CAEN mainframes.
Software control system based on the Eurogam system.
Will use the hardware controller from GaSP with a largely standalone system based on UNIX and LabView.
connect to http://nnsa.dl.ac.uk/Eurogam and http://nnsa.dl.ac.uk/Euroball
For this talk connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc303/edoc303.html
For the talk on Eurogam connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc204/edoc204.html