Note – For those who prefer not to know anything of the details, or cannot find the time to read this, the important points are summarized in bold.

It is proposed that the software and Graphical User Interface (GUI) developed for Eurogam and Euroball be used for ExoGam. This is a highly modular software package, which can easily be extended to support the new VXI modules. With the present implementation addition of control software and the corresponding GUI for a new VXI module would take at most a week (possibly less) to implement an initial version. This can be done in parallel with the design of the electronics using the module specification and the GIR memory map.

Experience has shown that a number of factors cause small changes to be necessary to the software during the testing phase of the prototype module. These are caused by misunderstands of the specification (and errors in the specification and GIR memory map documentation) and corrections needed as the characteristics of the real hardware are determined. Once the first production module is commissioned final adjustments to the default settings and calibration information can be made.

It is planned to investigate the possibility of making the configuration of the software for new VXI modules more dynamic. This was the original aim for Eurogam I, but was not carried out because of concerns on the performance of doing the whole configuration dynamically. However the software used for CAMAC module configuration is totally dynamic and performance is fully acceptable. While CAMAC modules do tend to be a lot simpler than VXI modules adding a new CAMAC ADC module to the software system can take as little as an hour.

It has been proposed that all detectors which do not have dedicated VXI electronics should be interfaced via the GANIL xDC6414 VXI module which exists in a number of forms (ADC, qdc and tdc). A detailed specification for this module exists which can be used as the basis for implementation of the necessary control software. While the module was designed to be compatible with the Eurogam/Euroball VXI standard this needs to be proven. Also the data word format used is required to be compatible with the Eurogam/Euroball standard which does not at present seem to be the case.

The tests of the xDC6414 can be carried out at Daresbury immediately, where all the required hardware is available or at GANIL, if the necessary hardware is made available.

Software support for other data sources such as CAMAC and the Bordeaux FVI (Fera to VXI Interface) which may be used by specific ancillary detector systems is a standard option within the MIDAS package and will continue to be available.

For Eurogam/Euroball, and all other instances of the MIDAS software package to control VXI modules, the GUI communicates with software running within a Motorola MVME147 single board VME processor module located in the VXI crate Resource Manager and using VxWorks as the software kernel. While this configuration is perfectly satisfactory for the task the MVME147 module is now over 10 years old and perhaps now is the time to look for an update.

The Motorola PowerPC processor range would seem to be a good choice. For embedding within the Resource Manager the entry level board the MVME2301

(200 MHz PowerPC 603e and 16 Mbyte DRAM) would be appropriate. Other members of the same family would be suitable for all other VME based processor applications needed by ExoGam.

The MVME2300 family is supported by VxWorks and so it is an option that we continue to use that. However we would need a new architecture software license from Wind River for the PowerPC processor so from a cost viewpoint we should consider alternatives. LynxOS should be considered since much of the Eurogam VME software has already been ported to it. There is experience of LynxOS at GANIL (but not of VxWorks) and information is that Miniball would prefer LynxOS rather than VxWorks for the same reason.

If it is decided to switch to the MVME2301 then changes will be needed to the RM front panel. Daresbury should purchase as soon as possible an ExoGam RM and MVME2301 processor and agree the front panel changes with Struck. This should be done before any further ExoGam RMs are purchased unless it is accepted that the front panel may need replacing when the changes to accommodate the MVME2301 are known.

If it is decided to switch to LynxOS then Daresbury will port the VXI control software from VxWorks to LynxOS using the hardware purchased above. This should not be a major task but there are a couple of technical issues to be resolved. It is estimated that the job will not take more than 4 months. An interim version of the software could be made available before this time which would not contain restrictions of importance during the initial stages of testing.

The software porting required is only of the software which is loaded into the VXI RM. There should not be any requirements to make significant changes to the software which generates the GUI. Small changes may be needed to circumvent feature differences between VxWorks and LynxOS.

ExoGam will provide two types of singles histograms

1. The "pseudo" singles as produced for Eurogam and Euroball by hardware which spies on the DT32 bus readout. This histograms only data which is a part of a multi-parameter event. It is also a very valuable diagnostic tool since it is possible to histogram DT32 bus control data that can in certain cases detect very intermittent data errors. The histograms are held in RAM within a VME memory module which the Histogram control unit accesses for increment operations via a dedicated VSB backplane. VME bus is only used for access to the RAM in order to fetch counts for display purposed (and the histogram save function). The software required is exactly the same as for Eurogam/Euroball. There would be requirement to move the software to LynxOS if it has been decided to use this throughout ExoGam but some of this work has already been done and some is included in the port of the VXI software.
2. The "true" singles which is a new development for ExoGam. Patrick Coleman-Smith presented the proposals for the hardware for this during the meeting of 15^th Dec 1997. The required data to generate the histograms is passed from the VXI modules to DSPs on PMC daughter boards within a MVME2300 or similar processor. The histograms are held in RAM within the processor module and no access to the VME bus is required. Several such processor boards can be used to make a totally scalable system. A development of the Spectrum Access Server software used for the "pseudo" singles described above will be provided. This software in conjunction with the GUI provides a common access method to all histograms created by the Data Acquisition system.

Both types of singles histogramming system can be accommodated within a single VME crate.

The software (excluding DSP software generating the "real" singles) will be available in the same timescale as the VXI software above.

Readout of data from the various data sources within a VXI crate is via the VXI backplane and a Struck 8080 VXI module (VXI Readout Engine – VRE). This method has been used very successfully for Euroball. The software running in the onboard DSP within the VRE module will be unchanged from Euroball. Set-up, control and monitoring of the VRE module is covered by the VXI software mentioned above. The VRE module GUI in conjunction with features within the onboard firmware supports extensive test and diagnostic facilities, which allow, for example, display of the internal data buffers and generation of user defined test data.

There will be a number of VXI crates each containing a VRE module and linked by a DT32 bus readout chain to a DT32 bus master controller the D2VB (DT32 bus to VME bus). (DT32 bus is rather like a 32-bit version of FERA bus). The D2VB was used for Eurogam II and is used for readout in a number of smaller VXI systems. The D2VB is a VME module, which is in charge of the DT32 bus and delivers data blocks into its onboard 2Mbyte SRAM. The data RAM is divided by the control software into a number of buffers (for example 128 buffers each of size 16 Kbytes). The D2VB also contains a control store, which is a list of buffers within the data ram, which it can use. As the current buffer becomes full the D2VB firmware will switch within 1 microsec and at an event boundary to the next free buffer taken from the list within the control store. If there are no free buffers in the list then the D2VB stops data readout.

The data readout VME crate will contain a control processor, which could be the MVME2301 particularly if this is chosen for the VXI RMs (see above). A simple software task runs in the control processor to control the D2VB. As the data buffers are filled by the D2VB the control processor must handle (for example copy to a tape storage server) and return to the D2VB free buffer list. As long as the software can handle data buffers faster than they arrive the D2VB will never stop readout. The 2 Mbytes of internal data ram within the D2VB is adequate for most short-term (a few seconds) fluctuations in data rate.

The D2VB control GUI contains diagnostics to monitor and test the D2VB module and to display the contents of both the data ram and list ram. The data ram displays can be formatted to show the data as events and interpret each data word in terms of detector and ADC.

The end of the hardware readout path is the D2VB module, which resides within a VME crate and using a dual ported RAM makes blocks of raw data available via the VME bus. The Event Builder in the ExoGam case is not a builder of events at all since this is done within the VXI electronics and the DT32 bus. However it does have to perform the following tasks:

1. data readout
2. data checking
3. data formatting
4. data distribution

This has been mentioned previously. The existing D2VB control software can be used as a starting point.

The raw data blocks received via the D2VB are checked to ensure that they conform to the expected format. The raw data format generated within the VXI electronics modules and the VRE contains a number of fields which are intended specifically to allow checks to be made to ensure that the VXI electronics is functioning correctly. Typical of the checks, which can be made, is:

1. simple format consistency tests
2. checks that the contribution to the event from each VXI crate corresponds to the same event (same master trigger pulse).
3. checks that the data addresses within the event are valid and unique
4. checks that expected data is not missing and that there is no unexpected data

Statistics and rates of a number of event types including all abnormal events must be accumulated and made available for data quality monitoring.

This software does not exist for ExoGam and requires to be implemented.

Formatting data in this manner (rather than writing raw VXI data to tape) can if an efficient format is used reduce the data volume by a factor of 50%.

This software also does not exist for ExoGam and requires to be implemented.

The event builder passes both the formatted data blocks and optionally the raw data blocks (for further online diagnostic purposes when needed) to the data network. The data network should a broadcast network – which is data on the network can be read by all stations on the network. Such networks are FDDI and Ethernet. The data should be transmitted using a network protocol that is compatible with data broadcasting. This means that the UDP protocol should be used and not the TCP protocol. Thus as an example; using UDP protocol to send the data blocks over a FDDI network requires that the data be transmitted once regardless of the number of destinations.

There are two modes of data distribution:

a) controlled - This is the normal mode of data distribution

b) uncontrolled - Used only when there is no requirement for a)

This is the normal mode of data distribution for formatted data. The primary requirement is that the formatted data generated by the Event Builder is passed to the tape server to be written to tape. A simple but highly efficient dialogue between the event builder and the tape server controls the flow of data at a rate which is determined by the ability of the tape server to dispatch the data to the tape drives. If this dialogue takes into account the capabilities of the network interface hardware then loose of data and the need to retransmit should never occur. As in any controlled data flow there can be only one master and in our case it is the tape server. In addition to the tape server the broadcast data is available for capture by online data analysis programs and as required by online diagnostic programs in a manner similar to the Uncontrolled data distribution mode.

This is the normal mode of data distribution for raw data and can be used for formatted data when there is no requirement to write the data to tape. The data blocks are passed to the network interface, as they become available without regard to the result and capacity of the network. Since it is not important in this mode that 100% of the data is received by a specific destination there is no problem in doing this. The broadcast data is available for capture by online data analysis programs and as required by online diagnostic programs.

Software for the data distribution task exists from Eurogam using an Interphase FDDI VME controller. As with the data readout task this existing software could be used as a starting point for any new implementation.

Online data diagnostics functions use the capability of access to raw VXI data blocks broadcast on the data network. These diagnostics would be in addition to those provided by the data check functions built into the Event builder. Experience with Euroball has shown that understanding of very intermittent errors in the raw data stream can be very difficult using the event builder. The ability to write very specific code to detect very specific errors without effecting the standard Event Builder would be a valuable diagnostic tool. Such diagnostics can be run if necessary during normal experimental runs with minimal effect on the experiment and the data throughput available to it.

The data diagnostics would be run in hardware normally used for Online Data Analysis.

Online data analysis functions use the capability of slave access to the broadcast network to access the formatted data generated by the Event Builder. Since access is provided to the formatted data the analysis programs can be essentially the same as those used for offline analysis of data tapes. Any number of different analysis programs can in principle be run simultaneously the only limitation being the availability of processors with access to the data network. Library routines/procedures will be provided which give access to the data blocks equivalent to those typically required for access to data blocks from an event-by-event data tape.

A standard package will be provided which uses the MIDAS software for its GUI. This is currently widely used for the analysis of data from Euroball and several other sources. The current implementation is available for Sun Microsystems Solaris 2.5 for Sparc and Debian Linux.

Other packages already available at GANIL will also provided.

The tape server is the master system that controls the broadcast of data from the event builder when running in the "controlled data distribution" mode. When writing experimental event-by-event data to tape this will always be the mode used.

Experience has shown that the tape server should be a dedicated system and that it is highly undesirable for other functions to share the same system. Since the most unreliable part of the whole data acquisition system can be the tape drives (failure of mechanical components) immediate access to repair or replace is essential for the most efficient use of ExoGam.

The tape server and the tape drives are controlled and monitored from a number of windows in the MIDAS GUI. The communications protocols and a guide for implementation are available in the documents edoc304 and edoc305.

For the main operational phase of ExoGam a new implementation confirming to these documents should be made. As an interim measure until the final system is available the VME based tape server from Eurogam can be used taking advantage of existing hardware.

The tape server should be implemented as far as possible in a manner which is not system dependent and all system dependencies should be carefully encapsulated so that versions for various operating systems can be produced. Experience with a Unix based tape server shows that use of the standard Unix device driver /dev/rmt is totally inadequate and research is needed to find a suitable alternative.

The user interface to the ExoGam data acquisition system will be provided by the MIDAS GUI. This is used by a number of data acquisition systems including Euroball and also installed at a number of laboratories developing hardware to be used in conjunction with these data acquisition systems. It also provides the user interface to data analysis systems for use with Eurogam/Euroball and other data.

The core of the system; that is the data acquisition control and monitoring functions and the base data analysis functions; is now available for a number of platforms including:

Sun Microsystems Unix for Sparc – Solaris 2.5 or later

Microsoft Windows 95

Microsoft Windows NT 4.0

Linux – Debian, Red Hat and Caldera are known to work; probably others

Sun Microsystems Unix for x86 – Solaris 2.5/2.6

Windows98 and NT 5.0 will be supported as released.

A significant fraction of the MIDAS package is common to all installations and thus the continuing development of the package will be automatically available to ExoGam. There will be certain developments specific to ExoGam mainly for support of the new VXI modules as mentioned previously. As produced these will be supplied to GANIL and to the laboratories developing the new hardware both to enable testing of the software in parallel with testing of the hardware and also to aid checking of the hardware functionality itself.

The requirements for services in the experimental area are:

We have been warned that access to the racks holding the VXI crates and front-end data acquisition hardware will be restricted during experimental periods due to residual radiation levels. It is possible that a period in excess of 1 hour would be required between removal of beam from the area and access being possible. For this reason it is proposed that the VXI and VME crates are fitted with remote control facilities using CAMbus. Ian Lazarus has more details on the requirements. A GUI window will be provided within MIDAS which will allow remote restart of the VXI and VME crates if needed.