A Data Acquisition System for Euroball III

G.Maron, V.Pucknell

October 3 1995

1 Introduction

Euroball III is an European collaboration involving Denmark, France, Germany, Italy, Sweden and the UK.

The Euroball array 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 Strasbourg in late 1998.

The principal laboratories involved in the implementation of the Data Acquisition system for Euroball III include:

CCLRC Daresbury, CENBG (Bordeaux), CRN (Strasbourg), IPN (Grenoble), IPN (Lyon), INFN (Legnaro), INFN (Padova), IPN and CSNSM (Orsay), MPI Heidelberg, Liverpool University, FZ Rossendorf

2 Requirements

The data acquisition and electronics system for Euroball III will use the best components from the existing Eurogam II and GaSp systems but some areas, where appropiate, will use totally new solutions involving the lastest in technology and techniques.

2.1 Data Rate

An outline proposal paper of the Data Acquisiton system was submitted to the ECC meeting in February 1994 and the architecture described in the paper formally accepted. The ECC required that a system capable of handling a trigger event rate of 100 KHz and/or a total raw input data rate of 20 Mbytes/sec should be available for the first Euroball experiments with the possibility to increase the raw input data rate in the future.

2.2 Scalability

The system is designed to be modular both in its electronics and software. It is also designed to be scalable such that there is no fundamental limitation its performance. The only limitations at a point in time are those placed by current technologies and these are chosen to be areas of current development so that we can reasonably expect the desired improvements in the technologies to be available as the need arises.

2.3 Ancillary Detectors

Euroball will not be a pure gamma detector, but will frequently be used coupled with ancillary detectors of varying complexity. Therefore it is important that the front-end electronics, trigger system and data acquisition are easily and smoothly adaptable to accomodate these additional detectors. An important point in this sense is that different trigger systems and/or data streams must be available. Moreover one must consider the possibility of delayed trigger conditions associated with detectors running at different data collection rates. The system must allow collection of data from ancillary detectors using electronics and data readout by methods other than those used for the primary gamma ray detectors (VXI). Since most of the ancillary detector proposals are based on the FERA readout bus this option will be provided in the initial system. However other methods such as VME based ADCs should also be considered.

2.4 On-line data processing

The digitized and built events have to be fully processed on-line in order to generate formatted data for storage. Functions required include calibration, gain matching, different levels of filtering, event tagging and data sorting. Multiple output data streams will be available from the analysis in order to store data on different tapes according to user supplied selection criterion such as trigger type which is for example very useful for the ancillary detectors.

2.5 Development

The system will be built as far as possible from readily available commercial products. We have to follow the market where it can provide solutions for use and concentrate development efforts on only those areas where commercial solutions do not exist.

2.6 System Availability

Finally the Euroball system represents a major investment by the members of the partnership and demand to use the facility when operational will be very high. It is therefore of extreme importance that the maximum amount of useful data be collected from the available beam on target time. System availability should aim to be as close as possible to 100requires that the system be constructed to mimimise both the time to detect a fault and then the time to repair. The first of these two (time to detect a fault) is very important and online diagnostics and data quality checking will be provided to ensure that faults in the data being acquired from the electronics are immediately detected.

3 Detectors

Euroball III will use some detectors from the Eurogam II array combined with some totally new detectors. An array structure is being purpose designed and built to hold these detectors.

• 30 Coaxial Detectors: Ge detector + 10 element BGO shield from Eurogam I

• 26 Clover Detectors: 4 element Ge detector + 16 element BGO shield from Eurogam II

• 15 Cluster Detectors: 7 encapsulated Ge detectors + 18 element BGO shield

• ancillary detectors: will include a Silicon ball and Neutron array

4 Electronics

4.1 VXI Electronics

Euroball III uses the integrated electronics with full software control using the VXI (VMEbus eXtensions for Instrumentation) standard introduced for Eurogam I.

4.2 VXI Electronics

4.2.1 Introduction

VMEbus eXtensions for Instrumentation, Rev 1.3, July 1989

Eurogam uses D size cards. That is a triple height (9U) Eurocard module which includes a P3 connector in addition to P1 and P2 which are found in VME modules. The cards are 14 inches high and 13 inches in depth and are placed on 1.2 inch centers (VME cards are 0.8 in). The 1.2 inch module width allows feasible implementation of high density instrumentation modules while allowing enough space for shielding both sides of a module.

The P3 connector includes a 100 MHz clock and sync signal, additional power pins, more ECL trigger lines and 24 additional lines of daisy chain local bus. Also defined on P3 is a ”star” trigger system where precision ECL trigger signals are routed through Slot 0 acting as a cross point switch. This allows very precisely matched trigger timing between modules regardless of module position.

A standard VXI crate holds 12 ”user” modules plus the slot 0 (Resource Manager) module.

The Cluster card weights approximately 2Kg. Total power consumption of a full VXI crate may be as high as 3KW.

4.2.2 VXI Resource Manager

The VXIbus device protocols define how modules are granted non-conflicting portions of the VMEbus address space. Several devices may exist on a single module, and a single device may consist of multiple modules. 256 devices may exist in any one VXIbus system. A VXIbus system configuration space is defined in the upper 16K bytes of the A16 address space. Each device is granted a total of 64 bytes in this space. Devices requiring additional address space have their address requirements readable in a defined register in the A16 address space. The Resource Manager reads this value shortly after power-on and then assigns the requested memory space by writing the module’s new VMEbus address into the device offset register. The Resource Manager may assign space in the A24 and A32 address spaces by this means.

The Resource Managers are interlinked so that signals may be shared between all VXI crates (for example the trigger validation).

The Eurogam Resource Manager contains a standard VME processor module (Motorola MVME147) which provides

the communications path between the VXI modules and the control software.

4.3 Instrumentation Electronics

Euroball will use existing electronics from Eurogam I and Eurogam II for readout of the Eurogam detectors.

• Ge card - total of 6 VXI cards each having 6 channels (one is a spare).

• BGO card - total of 6 VXI cards each paired with a Ge card.

• Clover card - total of 26 cards. Each card has 4 Ge channels (+ one spare Ge channel) and 1 BGO channel.

Additionally new VXI electronics for the Cluster detectors (total of 15 sets) are being developed.

• Ge card - 7 channels plus 1 spare channel (2 energy + 1 timing parameters per channel)

• BGO card - 18 channels plus 1 spare channel (energy and timing parameters per channel) and 1 ”sum” channel (3 parameters)

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.

4.4 VXI Readout

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.

4.5 Other Electronics

A number of other VXI modules are required to control and readout data from the main instrumentation cards.

• Resource Manager (RM) VXI slot 0 card - one per crate

• Master Trigger

• ReadOut COntroller (Struck STR8080) - one per VXI crate

• Total of 9 VXI crates (core system)

Data from the VXI crates will be readout from the VXI crate ROCOs via the DT32 bus. A number of DT32 buses operating in parallel will be used in order to increase the maximum data rate which can be achieved by the system. In the initial (core) system 3 DT32 buses will be used but this number can be increased as required in order to scale up the total data rate from the system.

Other frontend electronics modules are

• Hardware Histogramming Unit with 8M channels per DT32 bus

• VME to CAMAC interface (Hytec VSD2992)

• Event Collector (VME Module) per DT32/FERA bus

4.5.1 Hardware Histogrammer

After all VXI crates the DT32 bus passes through a histogrammer unit which is a VME module acting as a spy onto the data. The unit is software programmable to select any specific parameters from any choosen detectors and build histograms via direct memory increment into global dual port memory.

The histograms can be examined using any of the workstations to check the quality of the data and monitor detector performance.

Additionally by histogramming the control tokens generated by the readout system (for example the start event token and end subevent tokens) the histogrammer can be used as a very powerful hardware diagnostic tool.

Currently there are 32 Mbytes of histogramming memory but this can be increased by adding more memory cards into the VME crate.

4.5.2 Ancillary Detectors - CAMAC

For ancillary detectors which do not have purpose designed VXI electronics CAMAC adcs (such as the Silena 4418V and LeCroy 4300b) may be used.

These have FERA readout and a FERA version of the Event Collector

• manages interaction with the Eurogam Trigger

• performs readout of the adcs via FERA bus

• tags the data to enable subsequent merging with data from the VXI modules • passes the data to the Event Builder in the same manner as the VXI/DT32 Event Collector

The VME to CAMAC interface is used only for control, monitoring and diagnostic purposes. Software enables the CAMAC modules to be accessed in a way very similar to that used to access VXI modules and so includes CAMAC adcs into the system in a seamless manner.

4.6 Other Components

In addition to the detectors and the VXI modules used to acquire data from them other systems provide and control the services needed for the detectors to operate.

4.6.1 Autofill

Euroball will use the hardware controller from GaSp with a largely standalone system based on UNIX and LabView.

4.6.2 High Voltage control

The High Voltage control system will use existing Eurogam LeCroy high voltage units interfaced via a VME module to provide the necessary bias to the GE detectors and BGO crystals. For new detectors CAEN high voltage units also interfaced via VME will be used. The software control system currently used by Eurogam will be enhanced to handle the two types of HV hardware in a transparent manner.

5 Euroball III Data Acquisition

5.1 Introduction

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 Data Acquisition system can be divided into a number of components which will be considered in turn.

• Event Collector (VME Module) per DT32/FERA bus • High Speed Switching Network - Fibre Channel

• Event Distribution

• Event Builder

• The Processor Farm and on-line analysis

• NEO++

• Histogram Server

• Tape Server

• Experiment Control and Monitoring

5.2 Event Collector

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.

The Event Collector is constructed as a purpose designed processing & control module (which contains the DSP) which connects (via the IP standard interface) to a commercial single slot VME processor module (currently the Motorola MVME162FX). Each Event Collector has a separate interface module which contains the interfacing to the data source. Two versions of this interface module have been developed; one for DT32 bus and one for FERA bus. Others could be developed as required to accomodate different types of data bus.

5.3 Event distribution - Fibre Channel Network

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 266 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.

5.4 Event Builder

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:- • Basic consistency checks on the event fragments. The raw data format contains redund-

ant information for security and this can be checked for self consistency to detect possible hardware errors during data readout.

• Using the event number within each fragment complete events are constructed. Further checks can be performed on the complete event to ensure correct functioning of the frontend electronics and readout mechanism. For example the data received can be checked against the hardware setup to detect readout errors.

• The fragment tokens are removed at this stage and the formatted complete event is now in a more compact format than the raw data.

• Statistical information is produced so that a constant check can be kept on the quality of the raw data and alarms produced if the error rate exceeds reasonable levels.

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.

5.5 Processor Farm

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 analysis software within the farm is controlled using the Common Object Request Broker Architecture (CORBA). The farm processors will be managed using one of the commercial products available such as LSF (Load Sharing Facility) by the Platform Computing Corporation.

5.6 Online Analysis

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:-

• Type 1. Full Online Data Processing. This has to process all the raw data events before sending them to tape. In addition to the basic functions of event building, data checking and event formatting it can also include functions such as calibration, filtering and event sorting. In this case it is necessary to consider the impact of such processing on the final data rate. Also any errors introduced may seriously effect the correct output of data to tape.

If required all processors in the farm can be used for this mode of operation in which case Type 2 will not be available.

• Type 2. On request (spy) online analysis. This would always run in conjunction with a basic Type 1 program which would just perform the event building, data checking and event formatting steps and output the data to tape. The data output from stage 1 would be available to the Type 2 program for calibration and event sorting. However in this mode of operation the correct or otherwise operation of the software can have no effect on the output of data to tape and is thus a more secure mode of operation.

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.

5.7 NEO++

Nuclear Event Orientation

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 evolution of the Neo language currently used in the GaSp experiments. 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.

It is intended to provide a GUI (Graphical User Interface) which for most experiments will allow users to generate the NEO++ code just by selecting options from the graphics screen. Some of this will be automatic and the user will just have to accept the system generated setup. For example it is intended that the input statements will as far as possible be constructed from the known state of the hardware setup. Thus it will not be necessary for users to learn the NEO++ or C++ languages in order to run an experiment but they may if they wish.

5.8 Software Components - The Servers

The Euroball data acquisition system has a small number of server programs which provide access to all the data acquisition resources

• register server

• histogram server/spectrum server

• tape server

• message/error logger

New design has been required for histogram and tape servers according to the CORBA approach and to the new SMP workstations architectures. Much of the design and code of the other servers has been adopted from the Eurogam system. Access protocol for all the servers are fully compatible with most of the Eurogam and GaSp clients.

Access is both via CORBA and RPC services from client workstations

For each server a RPC program protocol is defined which is designed to provide access to the server facilities and to conform with the RPC methodology.

However the developing CORBA (Common Object Request Broker Architecture) standard is being used for new developments. The CORBA concepts are a development of the older RPC method and are very close to the ideas and structure of the Register Server concept developed for Eurogam. Transparent bridges will be provided between the existing RPC based implementations and the CORBA implementations which will allow for example the existing Eurogam VXI crate control software to run in the Resource Manager processors.

5.9 Register Server

The Register Server is a general purpose communications core which can be customised for specific data acquisition control tasks.

• VXI crate setup and control application • CAMAC crate setup and control application

• VME crate setup and control application

• Histogrammer setup and control application

• Detector High Voltage control system

5.9.1 Register Server Introduction

Initially each server has a number of application specific procedures which are loaded when the system is booted. Registers are then defined dynamically by the clients using the server protocol and specifying the local procedures in the server to be invoked when the register is subsequently accessed.

The register server allows named items of arbitrary data to be passed between the user interface programs and the server applications. The register name and the server command primitive select the local procedure to be called.

The data can be a single bit to be written to a VXI or CAMAC register or may be up to 1 Kbyte. Larger amounts of data (for example trigger or event builder programs) are handled by passing a filename to a suitable register class.

The register attributes provide additional information as needed by the application procedures to execute the read, write and initialise primitives. For example, a simple case would be a VXI register and the register attributes would include the VME address offset used to access the register on the VXI card. For a CAMAC register the register attributes would include the CAMAC cnaf data.

The server allows many registers to be accessed by a single RPC request by the use of wild-card techniques applied to the names. The available register names can be obtained by clients from the server thus allowing a number of user interfaces in workstations to access the server with all coordination provided by the server.

5.10 Histogram Server

The Histogram Server is based on a set of workstations connected to the FCS switch. It receives output from the processor farm and constructs histograms as requested by the analysis program running on the farm. Histograms are initially cached in RAM and then from time to time dumped to disk. The histograms can be retrieved at any time for viewing.

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.

5.10.1 Spectrum Access

• Provides a common application interface independent of location of the data

• Spectrum name determines remote server location

• Online (in histogrammer) and offline (on disc) spectra are interchangeable

• Workstation based client-end software merges spectra from multiple servers to appear as a single source

• RPC/CORBA program optimised for efficient network access. Supports various high level primitives to allow data to be accessed while minimizing network traffic.

5.11 Tape Server

Hardware configuration for Euroball III

• 6 Digital Linear Tapes (DLT)

• 8 Exabyte 8500 tape drives fitted with robot changers (from Eurogam)

• Several independent SCSI or direct Fibre Channel connections 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.

6 Control & Monitoring

The Euroball control & monitoring software will be based on the exiting Eurogam system ungraded as necessary. A major aspect of the upgrade of the software will be to ensure that the cause of faults can be quickly located and corrected.

• Implemented within a distributed computing environment

• All items to be controlled or monitoring are accessed via an ethernet LAN.

• Uses Internet Protocols (UDP/IP for RPC and TCP/IP for CORBA)

• The client-server model which is used to build a network of workstations is followed and the data acquisition modules become additional resources on that network

• Graphical User Interface using UNIX workstations

• No master workstation or Central DataBase which improves overal system resilience.

All aspects of the system from setup and monitoring of the VXI/VME/CAMAC hardware, through control of the event collectors to control of the processor farm will be managed by a fully intergrated Run Control System. The user will interact with the Run Control System via a common Graphical User Interface (GUI) thus ensuring that all parts of the system can be controlled and monitored in a consistent manner.

6.1 System Software

The user interface to the data acquisition system is via UNIX workstations. The frontend data collection systems are based on VXI and VME which contain cpus running the VxWorks real-time kernel. The data processing systems, the software histogramming server and the tape server are based on UNIX workstations.

VxWorks

The VxWorks kernel was choosen for the real time components because

• it is designed specifically for real-time control and data acquisition functions within a multitasking environment;

• it gives very fast handling of interrupts, task scheduling, etc.;

• it is UNIX source compatible. All software generation and compilation is performed using UNIX workstations;

• it has full support for BSD networking allowing complete integration into a UNIX workstation environment;

• source level debugging is available from UNIX workstations using DBX.

6.1.1 Network Communication

Each VXI and VME crate contains a cpu (MVME 147/MVME167/MVME162FX) having an ethernet interface which is a node on the local area network and which also acts as a gateway for other CPU cards in the same crate. All UNIX workstations by default contain an ethernet interface in addition to any other network interface they may contain. The use of UNIX and VxWorks enables common network software to be used in all components of the system and thus allows a totally consistent approach to control of the system.

All communications between applications specific to the Data Acquisition System running under the VxWorks Kernel are based on the Client/Server model using Remote Procedure Calls. Using the network software RPC requests can be made between clients and servers across the ethernet, between VME cpus within a crate across the VME backplane, and within a single CPU or workstation.

This allows the software components to communication in a way which is independant of their location.

Fixed UDP/IP ports are used by the servers in order to avoid the delays which the use of dynamic ports and the Portmapper would involve.

Those servers and resources based on UNIX workstations will use the newer CORBA based software which also follows the basic Client/Server model.

An transparent interface will be developed between the RPC and CORBA based systems for each of the server protocols thus allowing free communication between the two methods and ensuring that our aim of a totally unified Run Control System is achieved.

6.2 Graphical User Interface - GUI

Implemented using TCL/TK (Tool Command Language) by John Ousterhout, University of California, Berkeley.

This is similar to the TCL system used for the implementation of the Eurogam GUI. However the Eurogam software is currently being converted from using a home produced graphical interface to the Sun specific XView package to the TK software now available in the TCL/TK package which is Motif compiliant.

This development will allow more graphical features to be used by the software and most importantly remove the dependence on Sun hardware.

6.2.1 Command Language Interpreter – tcl-shell

User Interface generated as TCL scripts which are interpreted.

No compilation - Just edit script source file and execute or simply type or paste commands into the tcl shell window.

Development is VERY FAST and easily extended by a group of individuals.

Extensions provided within tcl-shell for

• graphical interface — (spectrum widget)

• Eurogram interface — eg

• CORBA/ORBIX interface

7 Further Information

By World Wide Web (WWW)

connect to http://nnsa.dl.ac.uk/Eurogam and http://nnsa.dl.ac.uk/Euroball

For a talk on Euroball connect to

http://nnsa.dl.ac.uk/Eurogam/documents/edoc303/edoc303.html

For a talk on Eurogam connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc204/edoc204.html or connect to http://axplnl.lnl.infn.it/www/annre94/annual report 1994.html For a description of the 1994 daq activities looks to the following papers Euroball Data Ac-

quisition System Simulating the Euroball DAQ Architecture Switching network tests The Euroball DSP-Driven Front-End Dual Port Memory Euroball: a software prototype for the Event Builder Simulation Euroball Data Analysis These are ps files, but soon converted to HTML.

or connect to http://mvxpd3.pd.infn.it/Euroball.htm For a description of the autofill system This paper will be made available in HTML in the near future to replace the above or provide

HMTL links as appropiate and extended as the project implementation proceeds.