\documentstyle[a4,psfig,12pt]{article}
%\setlength{\textwidth}{6.375 true in}
%\magnification=\magstep 1
\setlength{\textwidth}{6.000 true in}
\setlength{\textheight}{655 pt}
\pagestyle{empty}
\renewcommand{\thefootnote}{\fnsymbol{footnote}}
\newcommand{\cc }{$^{12}$C}
\newcommand{\oo }{$^{16}$O}
\newcommand{\mg }{$^{24}$Mg}
\newcommand{\be }{$^{8}$Be}
\newcommand{\neon }{$^{20}$Ne}
\newcommand{\he }{$^{4}$He}
\newcommand{\al }{$\alpha $}
\newcommand{\degree }{$^\circ $}
\newcommand{\micron }{$\mu $m}
%\newcommand{\above }{\above 0pt}
\begin{document}

\setlength{\unitlength}{1cm}
\noindent
\begin{picture}(0,0)
\put(0,1.7){\makebox(0,0)[l]{CH/Tech/93/08}}   %% Reference number of document
\end{picture}

\noindent
\begin{minipage}[t]{10cm}
\fbox{
\parbox[t]{6.5cm}{
{\large {\bf Data Acquisition}}\\[2mm]
Proposed Plan for Development
}}\\[7mm]
\makebox[2.5cm][l]{Author:} V.F.E. Pucknell\\[2mm]
\makebox[2.5cm][l]{Date:} 16 November 1993\\[2mm]
\end{minipage}
\hfill \raisebox{-2.5cm}{
\psfig{figure=char-encap.ps,height=3cm}}\\[2mm]

\begin{center} \begin{tabular}{l@{\hspace*{14cm}}l} \hline
~\\[-6mm]
\end{tabular}
\end{center}


\begin{center}
{\Large Proposed plan for the development\\
 of the Charissa Data Acquisition System}
\end{center}

 
\section{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. 
 
\section{Short Term Developments}
\subsection{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.
 
\subsection{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.
 
\section{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.
 
\section{Longer Term Developments}
\subsection{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.
 
 
 \vfill
\noindent V.F.E. Pucknell \hfill November 16 1993
\vfill



\end {document}

