CH/Tech/93/08

Data Acquisition

Proposed Plan for Development

Author: V.F.E. Pucknell

Date: 16 November 1993

Proposed plan for the development of the Charissa Data Acquisition System

1 Current Status

The Data Acquisition system used for the batch of experiments just finished at ANU is essentially identical to that used for the last few years of running at the NSF. We were fortunate in being able to pick up developments allowing the GEC 4190 processors used at the NSF to be replaced by a single standard Motorola VME processor board using a 88010 CPU (88K) which could emulate exactly the instruction set of the 4190. This allowed a very compact data acquisition system to be produced with very little effort which could run all existing software and thus present to the experimentalist users a system which appeared identical to that used at Daresbury.

The only area which required any change and development was the CAMAC interface. The GEC 4190 interface had to be replaced by a VME interface from Hytec and the Camac software driver process was modified to exactly emulate the action of the 4190 interface and the DMA unit used for bulk data transfers. This latter task required that the 88K processor perform the actions previously carried out within the CAMAC DMA hardware.

The resultant system allowed the existing data acquisition software to run without modification unaware of the hardware changes. The rate at which data could be acquired was approximately the same as previously with the 4190s. However doing this meant that very little processing resources were left for online data sorting.

2 Short Term Developments

2.1 Event Controller

The most important task is to remove the requirement for the 88K processor to read the event data via the Camac interface under software control. Developments to the Event Controller are largely complete which will enable the event data to be transferred via a 16bit parallel bus into a VME memory module (CES HSM) under hardware control. The CAMAC interface will then only be used for setup and control of the hardware which is an undemanding task. Tests have shown that the 88K processor can acquire the data from the HSM via the VMEbus at a rate 20 times that possible via the CAMAC interface. This will mean that only a few percent of the processor resource will be needed to fetch the data into its local RAM.

At this time the data format generated by Event Controller will be identical to that currently used and so only minor software changes will be required within the data acquisition software to switch from reading the data via CAMAC to reading from the HSM module. No other software changes are required and apart from the side effects of freeing more of the 88K processor for online sorting the change would be invisible to the users.

The necessary work to complete this development should proceed as soon as possible with the intention of using it for the next round of running at ANU.

2.2 Online Sorting

Currently all online sorting is carried out within the data acquisition processor. This is the lowest priority task and the software just processes as much data as it can manage. All data acquired is written to tape. As mentioned earlier the amount of data which can be sorted is at present very low.

Offline sorting is carried out using the Sun workstations and it should be the aim to move the online sorting there as well. This is the solution which has been adopted for the next phase of Eurogam and has already been used for a recent experiment at ISOLDE. Development of the online sort to provide new features and change of the event data format on the long term would be much easier if the sort was implemented within a workstation.

The data acquisition processor would put the acquired data blocks onto a local area network (LAN) which can be either ethernet (adequate for Charissa purposes) or FDDI (for Eurogam) and any workstation wishing to process the data (and there can be as many as desired) just picks the blocks off the LAN. A private network is desirable (but not essential) so that the event data is the only data on the network and hence is not effected by other users and also cannot itself effect other users. The data is only transmitted once no matter now many workstations are wishing to process it and also they are totally passive spies on the data and cannot influence the data flow. As at present the priority is to ensure that all acquired data is written to tape.

It would be a simple task to modify the current Charissa SunSort program to work using live data. A software package exists which reads the data from the LAN and returns event data blocks exactly as would be seen if reading from tape. However an online sort task should allow the accumulating histograms to be viewed in realtime and also there are much better graphical interfaces available that UNIRAS.

Software developed initially for Eurogam can be used to quickly and easily generate a package with a state-of-the-art Graphical User Interface (GUI). In addition to an implementation of the Liverpool Sort Package this solution has also been adopted by the Edinburgh group who have a package for offline sorting giving realtime histogram displays.

The data acquisition can be easily exhanced to put all acquired data blocks both to tape and to a LAN interface using existing software. Once this is done a Sun-based online sort can be provided running initially in parallel with the existing 88K online sort but eventually replacing it. I would hope that we could at least reach the position of parallel running for the next batch of experiments at ANU and total replacement for the following batch.

3 Medium Term Developments

The data acquisition system is currently controlled from a Sun workstation running a package which emualates the displays generated by the Sension CAMAC graphics controllers and HP displays. (Only the older hands will actually recall the original hardware). For the Charissa data acquisition much of the graphics is associated with the online sort and it is hence not easy to do much until the online sort function is removed as proposed above.

The system actually running in the 88K is the result of combining tasks which ran in 3 GEC 4190 processors at Daresbury linked by a high speed network and communicating using a remote procedure call (RPC) style of operation. The 88K system still has these network links but they are now implemented internally.

Once the online sort function is removed then removal of the remaining graphical interface from the 88K to run native in the SUN using the Eurogam style of GUI and RPC communications is practical. The software techniques developed for Eurogam allow the GUIs to be generated very quickly and the communications software already exists for both ends. The tape control which is a significant part of the graphics which will have to be moved in fact already exists from Eurogam and provides many more features than that currently available.

If the online sort development allows a decision to totally remove the function from the 88K system after successful use during the next experiments at ANU then the new graphics can be available for the October 94 experiments.

4 Longer Term Developments

4.1 Hardware readout

As mentioned earlier the Event Controller has been developed so that the current event data readout via CAMAC is replaced by a parallel readout directly into a memory module with VME access. The Event Controller will continue to read its ADCs via Fera bus and then format the data into blocks following the NSF Event Manager format. This format was originally designed with a view to a compact format for up to 64 ADCs (the event managers in fact never had more than 32 ADCs) and was extended for Charissa use to 128 ADCs. The format however is only compact for systems with a small maximum number of ADCs or for events in which the typical number of ADCs in any event is significant compared with the maximum number of ADCs. Neither of these conditions is true for the current Charissa array (128 ADCs). Extension of Charissa to 256 ADCs (or beyond) would require a further extension of the existing event format and would become even less efficient. A change in event format is therefore required.

Additionally it is expected that in the future the Charissa array will be used with the Vivitron beam at Strasbourg possibly in conjunction with Eurogam. Hence when considering readout and data format changes to Charissa we should also consider compatibility with Eurogam readout which is also used for all Strasbourg data acquisition developments.

Eurogam defines a 32 bit parallel ECL bus (DT32 bus) very similar apart from width to the new Event Controller 16 bit readout bus. At present a VME module designed for Eurogam by Bordeaux/DL (ROHSI) is used to interface between the DT32 bus and a standard CES HSM memory module. Under design at Daresbury for Eurogam is a single VME module (D2VB) to be used as a direct replacement for the ROHSI and HSM. The specification for the DT32-bus is a Eurogam document (EDOC075; also available as CH/Tech/93/09) which also contains details for the data word format. Additional information concerning its use in Eurogam can be found in the Eurogam document EDOC064.

The Event Controller would require to be modified to comply with this 32 bit wide data format. Data would be acquired from a D2VB module (replacing the HSM) written to tape using the Eurogam data format and at the same time output to a network connection for sort in a workstation. Software changes would be required in the sort package to handle the change in data format for online use and both change in tape format and data format for offline use. Much of this software will already exist since it will also be in use for Eurogam experiments.

As a by-product it will be possible to use the histogrammer module used for Eurogam which is a passive spy on the data on the DT32 bus and can be setup to generate singles histograms of any type of data item observed on the DT32 bus.

The system could either be used ‘standard alone’ at Strasbourg or ANU or at Strasbourg combined with other instruments such as Eurogam. The hardware and software compatibility would be such as to be both a significant advantage and also allow sharing of resources and development effort.

V.F.E. Pucknell November 16 1993