The array was operational at the NSF (Daresbury) between Sept 1992 and April 1993 (Phase I) and has been at the Vivitron (Strasbourg) since July 1994 (Phase II).
It is scheduled to continue at Strasbourg until autumn 1996 (or about 4 months before Euroball startup) when the detectors will move to Legnaro for Euroball.
Principle laboratories involved:
CCLRC Daresbury,
CENBG (Bordeaux),
CRN (Strasbourg),
Grenoble, Lyon,
IPN and CSNSM (Orsay),
Liverpool University,
Manchester University,
York University
Uses integrated electronics with full software control using the VXI (VMEbus eXtensions for Instrumentation) standard.
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.
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.
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.
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 the FDT32 module (Fera to DT32 convertor)
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.
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.
The user interface to the data acquisition system is via UNIX workstations while all VME cpus run the VxWorks real-time kernel.
The VxWorks kernel was choosen for the real time components because
Each VXI and VME crate contains a cpu (MVME 147) 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. The use of UNIX and VxWorks enables common network software to be used in all components of the system
All communications between applications specific to the Data Acquisition System 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.
The Eurogam data acquisition system has a small number of server programs which provide access to all the data acquisition resources
Access is via a RPC service 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.
Eurogam 2 uses single width VME modules each with 2 50MHz 88110 processors
Outputs formatted data via FDDI to the tape server using a multi bufferred RPC procedure
A general purpose communications core which can be customised for specific data acqusition control tasks.
What is a register?
A register is a named abstract object
Typically a register represents a group of one or more related control bits on an acquisition card.
A Register may however be purely a software invention (for example it could be a disc file containing a program to be loaded).
Register naming allows
Server recognises * ? [A-C] [23-36] [x,y,z]
Ge[1-12].CFD.*
Ge[?,??].PoleZero
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.
Hardware configuration for Eurogam II
Receives and controls data flow across FDDI from the Event Builder
Supports up to 4 data streams from the Event Builder
Each data stream may be output to any number of the Exabyte drives in either duplication mode, parallel mode or any combination of these.
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.
Implemented using TCL (Tool Command Language) by John Ousterhout, University of California, Berkeley.
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
Extensions provided within tcl-shell for
On-line sort using workstations connected to the FDDI network acting as spies on the formatted data passing between Event Builder and Tape Server.
Any existing off-line sort program may be easily converted to process live data.
One or two packages are provided as part of the system but users may bring their own favorite.
Any number of different sort packages may be run concurrently on the on-line data.
By World Wide Web (WWW)
Connect to http://nnsa.dl.ac.uk/Eurogam
For this talk connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc204/edoc204.html
For EG Session The Book connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc203/edoc203.ps
For Tool Command Language connect to http://nnsa.dl.ac.uk/Eurogam/documents/edoc202/edoc202.ps
For Netscape postscript viewer use ImageTool for these.
For some documents ImageTool fails and PageView may work better.