\documentstyle[a4wide]{article}
\title{A Data Acquisition System for Euroball III}
\author{G.Maron, V.Pucknell}
\date{October 3 1995}



\begin{document}

\maketitle

\section{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

\section{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.

\subsection{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.
 
\subsection{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.

\subsection{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.

\subsection{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.

\subsection{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.

\subsection{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 100%. This
requires 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. 



\section{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.
  
\begin{itemize}
\item 30 Coaxial Detectors: Ge detector + 10 element BGO shield from Eurogam I
\item 26 Clover Detectors: 4 element Ge detector + 16 element BGO shield from
Eurogam II
\item 15 Cluster Detectors: 7 encapsulated Ge detectors + 18 element BGO shield 
\item ancillary detectors: will include a Silicon ball and Neutron array
\end{itemize}





\section{Electronics}

\subsection{VXI Electronics}


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


\subsection{VXI Electronics}

\subsubsection{Introduction}
\scriptsize

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.
\normalsize 

\subsubsection{VXI Resource Manager}
\scriptsize

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.
\normalsize

\subsection{Instrumentation Electronics}


Euroball will use existing electronics from Eurogam I and Eurogam II for
readout of the Eurogam detectors.
 
\begin{itemize}
\item Ge card - total of 6 VXI cards each having 6 channels (one is a spare).
\item BGO card - total of 6 VXI cards each paired with a Ge card.
\item Clover card - total of 26 cards. Each card has 4 Ge channels (+ one spare 
Ge channel) and 1 BGO channel.
\end{itemize}

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

\begin{itemize}
\item Ge card - 7 channels plus 1 spare channel (2 energy + 1 timing parameters
 per channel)
\item BGO card - 18 channels plus 1 spare channel (energy and timing parameters
per channel) and 1 "sum" channel (3 parameters)
\end{itemize}


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.




\subsection{VXI Readout}
\footnotesize

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.
\normalsize


\subsection{Other Electronics}

A number of other VXI modules are required to control and readout 
data from the main instrumentation cards.
  
\begin{itemize}
\item Resource Manager (RM) VXI slot 0 card - one per crate
\item Master Trigger
\item ReadOut COntroller (Struck STR8080) - one per VXI crate
\item Total of 9 VXI crates (core system)
\end{itemize}

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
\begin{itemize}
\item Hardware Histogramming Unit with 8M channels per DT32 bus
\item VME to CAMAC interface (Hytec VSD2992)
\item Event Collector (VME Module) per DT32/FERA bus
\end{itemize}



\subsubsection{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.


\subsubsection{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 

\begin{itemize}
\item  manages interaction with the Eurogam Trigger
\item  performs readout of the adcs via FERA bus
\item  tags the data to enable subsequent merging with data from the VXI modules
\item  passes the data to the Event Builder in the same manner as the
VXI/DT32 Event Collector
\end{itemize}

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.


\subsection{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.
 
\subsubsection{Autofill}
 Euroball will use the hardware controller from GaSp with a largely 
standalone system based on UNIX and LabView.

\subsubsection{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.



\section{Euroball III Data Acquisition}


\subsection{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.
  
\begin{itemize}
\item Event Collector (VME Module) per DT32/FERA bus
\item High Speed Switching Network - Fibre Channel
\item Event Distribution
\item Event Builder
\item The Processor Farm and on-line analysis
\item NEO++
\item Histogram Server
\item Tape Server
\item Experiment Control and Monitoring
\end{itemize}






\subsection{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.

 






\subsection{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.





\subsection{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:-
\begin{itemize}
\item Basic consistency checks on the event fragments. The raw data format 
contains redundant information for security and this can be checked for
self consistency to detect possible hardware errors during data readout.
\item 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.
\end{itemize}

\begin{itemize}
\item  The fragment tokens are removed at this stage and the 
formatted complete event is now in a more compact format than the raw data.
\item 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.
\end{itemize}

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.





\subsection{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.





\subsection{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:-

\begin{itemize}
\item 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.
\end{itemize}
If required all processors in the farm can be used for this mode of operation
in which case Type 2 will not be available.


\begin{itemize}
\item 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.
\end{itemize}

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.

\subsection{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.


\subsection{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

\begin{itemize}

\item register server
\item histogram server/spectrum server
\item tape server
\item message/error logger

\end{itemize}
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.

\subsection{Register Server}

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

\begin{itemize}

\item VXI crate setup and control application
\item CAMAC crate setup and control application
\item VME crate setup and control application
\item Histogrammer setup and control application
\item Detector High Voltage control system

\end{itemize}


\subsubsection{Register Server Introduction}
\footnotesize


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.
\normalsize


\subsection{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.



\subsubsection{Spectrum Access}


\begin{itemize}

\item Provides a common application interface independent of
location of the data
\item Spectrum name determines remote server location
\item Online (in histogrammer) and offline (on disc) spectra 
are interchangeable
\item Workstation based client-end software merges spectra from multiple
servers to appear as a single source
\item RPC/CORBA program optimised for efficient network access.
Supports various high level primitives to allow data to be accessed while
minimizing network traffic.

\end{itemize}




\subsection{Tape Server}

Hardware configuration for Euroball III

\begin{itemize}

\item 6 Digital Linear Tapes (DLT) 
\item 8 Exabyte 8500 tape drives fitted with robot changers (from Eurogam)
\item Several independent SCSI or direct Fibre Channel connections 

\end{itemize}

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.





\section{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.

\begin{itemize}

\item Implemented within a distributed computing environment
\item All items to be controlled or monitoring are accessed via 
an ethernet LAN.
\item Uses Internet Protocols (UDP/IP for RPC and TCP/IP for CORBA)
\item 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
\item Graphical User Interface using UNIX workstations
\item No master workstation or Central DataBase which improves overal system
resilience.

\end{itemize}

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.


\subsection{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.

\subsubsection*{VxWorks}
The VxWorks kernel was choosen for the real time
components because
\begin{itemize}
\item it is designed specifically for real-time 
control  and data acquisition functions within a 
multi-tasking environment;
\item it gives very fast handling of interrupts, task 
scheduling, etc.;
\item it is UNIX source compatible. All software generation
and compilation is performed using UNIX workstations;
\item it has full support for BSD networking allowing 
complete integration into a UNIX workstation 
environment;
\item source level debugging is available from UNIX
workstations using DBX.
\end{itemize}

\subsubsection{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.

\subsection{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.

\subsubsection{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

\begin{itemize}
\item graphical interface ---  (spectrum widget)
\item Eurogram interface --- eg
\item CORBA/ORBIX interface
\end{itemize}






\section{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 Acquisition 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.

\end{document}
