\documentstyle[a4wide,11pt]{article}
\title{Eurogam Hardware Event Format Usage}
\author{John Cresswell}
\date{Edition 1.0\\January 1991}
 
\begin{document}
 
\begin{titlepage}
{
 
\hoffset=1truein
\hsize=5.25truein
\vsize=10.25truein
\font\small=cmssbx10 at 14.4truept
\font\medium=cmssbx10 at 17.28truept
\font\large=cmssbx10 at 20.74truept
\hrule height 0pt
\parindent=0pt
%\parskip=0pt
\hskip 3.9truein
\large
EDOC064\par
\vskip .5truein
\large
EUROGAM PROJECT\par
\vskip 1.5truein
\hrule height 2pt
\vskip 20pt
\large
NSF DATA ACQUISITION SYSTEM\par
\vskip .5truein
Eurogam Hardware Event Format Usage\par
\vskip 20pt
\hrule height 2pt
\vskip 1truein
\medium
Edition 1.0\par
\vskip 5pt
January 1991\par
\vfill
\medium
Nuclear Structure Software Support Group\par
\vskip 5pt
Liverpool University\par
\vskip .5truein
 
}
\end{titlepage}
 
\maketitle
 
\setlength{\parskip}{1ex}
\setlength{\parindent}{0em}
\section{Introduction}
 
This is an attempt to expand on the Eurogam defined event format
\footnote {Eurogam ROCO Data Formats, Stathis Kossionides}
from the viewpoint of
the Event Builder.
In this discussion the format of events received by the Event Builder
is assumed to be fixed and is included as an Appendix for reference.
The main aim is to simplify the setup for the user, and more
importantly to simplify software command structures etc.
 
The setup of the data acquisition hardware (VXI + others)
is directly involved with the input
format as seen by the Event Builder, in so far as parameter
addressing is concerned.
The sort setup is not directly involved with hardware setup
since the Event Builder provides a transformation from the
hardware definitions.
 
Eurogam (and indeed other data acquisition systems these days)
are tending to grow larger. This results in many more parameters per event
than has been normal previously.
However, it can be noted that there are typically many detectors of the same
type with the same small number of parameters for each detector.
For example, particle-orientated experiments may consist of
many telescopes, each producing the same set of parameters.
Eurogam has 70 Ge detectors , each of which may generate a maximum
of 7 parameters (including surrounding BGO).
In any particular experiment, the number of parameters per detector
may be less than 7 , but will be a fixed number [hopefully!].
 
\section{Hardware Mapping}
 
The ROCO event format definition defines a 14 bit address field
associated with each parameter data value.
As far as all the hardware specifications are defined so far, it will be
possible to individually assign the 14bit address values for
each parameter.
This feature allows us to allocate address values to each parameter during
hardware setup in any manner that we wish.
This could be useful in organising user presentation of the setup.
 
If the hardware does not allow us to define specific addresses for
each active parameter, then a lookup table mapping would be required
in the Event Builder. This would be relatively easy to arrange,
but might make the whole setup more obscure.
Hence it should be a standard policy that all future modules allow
the setup of parameter address fields.
 
\section{Parameter Groupings}
 
It has been noted that most modern detector systems consist of
many similar detectors with several related parameters repeated for each
detector.
This natural grouping of related parameters can be exploited
to make the user interface more understandable.
 
Specifying the set of active parameters as groups of Ge detectors
is very efficient for the Event Builder input file format.
Instead of 7 times 70 lines of adc information as in the simplest 
format, using the above suggested grouping this would reduce to 
one line ...  e.g.
 
GE [1..70] (E1,E2,T1,BD1,BGOE,BGOT,BGOHITS)
 
This line defines a group of 7 items (named in brackets)
which are repeated for detector numbers 1 to 70. Since each of the
70 groups of items are similar, they are given the same overall name (GE).
All names are arbitrary and are user-provided.
 
The other event parameters could also be described in terms of 
groups. Currently we can expect a trigger group and a RMS group.
 
The example above shows how economical groupings can be for naming purposes.
They can also be economical in programming terms. Each group
maps onto a software record or structure.
This makes it easy to process the information from a particular
detector.
With this scheme all parameters related to a particular detector
are kept together.
This allows access to individual parameters within a record, but
also allows whole records to be accessed
and moved around efficiently by using pointers.
 
Therefore, It is proposed we make maximum usage of the group format.
 
\section{Event Builder Usage}
 
Each data word has a unique 14bit address which is written
into the data acquisition hardware during the setup phase.
In order to make the processing of the data words easier,
it has been decided to logically divide the address into two parts
(an 8bit group number and a 6bit item).
This subdivision is somewhat arbitary, but allows the group number
to be extracted easily as a byte.
 
In any system there has to be some definition which fixes otherwise
variable quantities, in order to make simplifications.
For the Eurogam hardware it would be sensible to permanently fix the
14bit address allocated to a particular parameter.
This is not strictly necessary (since all address registers are
freely writable)
but will make hardware and software maintenance easier.
When system diagnostics becomes necessary due to some peculiar behaviour
it will make life easier if the mapping of address to parameter
is fixed (and hence rememberable).
 
The item numbers within a group are allocated consecutively starting
from zero upwards. 
This has to be so to define positions within a software record structure.
With fixed address allocations and mappings into groups the user
is no longer involved with knowing about the 14bit addresses.
Since the item field is in the most significant bits of the address,
then the resultant addresses will not be consecutive.
However, when viewed as a hexadecimal number the address is
trivially decoded into detector number and parameter offset.
 
The set of Ge and associated BGO detectors will be
considered as a group of parameters. For a single Ge detector the
associated group will have a maximum of 7 parameters. Each event will
consist of several such groups preceeded by a trigger or system
group.
Extra data acquisition devices (e.g. the Recoil Mass Separator,
FIFI, Inner balls ...)
will each provide a group of parameters.
 
We can define group numbers 1 to 70 to be Ge/BGO groups.
Group 255 is defined as the system or trigger group.
Others group numbers are freely available to be allocated as and when
necessary for ancillary acquisition sub-systems (RMS,FIFI,...).
 
This ordering of parameters into associated groups should
make event processing easier to accomplish. Several of the operations
to be applied to each event will be group oriented. For example,
the sum energy calculation will include the same words from each of
the Ge groups. Also, a typical operation may be to filter on all
Ge TDC words ... again the same operation performed on the same 
word from each group.
 
\section{Event Builder Transformations}
 
The set of parameters from each detector that are activated in a
particular experiment is defined whilst setting up the Event Builder for the
experiment.
Since not all possible parameters need be activated, then
some item numbers within a group will not be passed to the Event Builder
by the VXI hardware.
 
The Event Builder software will check all input parameters against the
list of valid ones and pack the activated
parameters received into a new group structure prior to output.
Hence there will most probably be two different group definitions
for the same detector on input and output from the Event Builder
\footnote {Event Builder Language User Manual, John Cresswell and Linda Pratt,
 {\em- to be produced}}.
This is unavoidable and needs to be presented in a clear way to the
experimenter.
 
\newpage
 
\section{Trigger Group Definitions}
 
The trigger group is the only fixed group to appear in every event.
The group number will always be 255.
The parameters available from the trigger module are more fully
described elsewhere\footnote{Trigger Specification (EDOC025) Ian Lazarus}.
Following is a list of the data words available in the trigger group
together with allocated item numbers ...
 
\begin{description}
\item {\bf item 0 :} Trigger type
\item {\bf item 1 :} Raw Ge sumbus ADC
\item {\bf item 2 :} Suppressed Ge sumbus ADC
\item {\bf item 3 :} BGO sumbus ADC
\item {\bf item 4 :} External sumbus ADC
\item
\end{description}
 
The trigger type parameter specifies which set of fast trigger acceptance
conditions were valid for the event.
This parameter can be passed through to the output trigger group
unaltered, or it may be changed in the Event Builder subject to 
software filtering conditions.
This provides a mechanism of tagging events for later separation
to different (tape) storage streams.
 
\section{Germanium/BGO Group Definitions}
 
The parameters associated with each Germanium detector and its
surrounding BGO shield can be
considered as a group.
The group numbers allocated will be in the range from 1 to 70
(or higher as necessary).
This group will have a maximum of 7 parameters.
Following is a list of the data words available in each Ge/BGO group
together with allocated item numbers ...
 
\begin{description}
\item {\bf item 0 :} Ge Energy word ... low gain
\item {\bf item 1 :} Ge Energy word ... high gain
\item {\bf item 2 :} Ge TAC word
\item {\bf item 3 :} Ge Ballistic Deficit TAC word
\item {\bf item 4 :} BGO Energy word
\item {\bf item 5 :} BGO TAC word
\item {\bf item 6 :} BGO Hit Pattern word
\item
\end{description}
 
 
\newpage
 
 
\section{Appendix ... ROCO Event Format Summary}
 
There are three basic format words. For each event there is a unique separator
word called the Start Event token. This is followed by the sub-event words
for each ROCO unit in sequence. Each sub-event is composed of Data words
followed by an End Sub Event token.
All numeric values are given in hexadecimal.
\vspace{0.5in}
 
1) Start Event Token ...
 
\begin{center}
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.4cm}Field size}
\makebox[0.2in]{\rule[-0.2cm]{0cm}{0.4cm}2}
\makebox[0.6in]{\rule[-0.2cm]{0cm}{0.4cm}6}
\makebox[0.8in]{\rule[-0.2cm]{0cm}{0.4cm}8}
\makebox[1.6in]{\rule[-0.2cm]{0cm}{0.4cm}16}
 
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.6cm}}
\framebox[0.2in]{\rule[-0.2cm]{0cm}{0.6cm}11}
\framebox[0.6in]{\rule[-0.2cm]{0cm}{0.6cm}3f}
\framebox[0.8in]{\rule[-0.2cm]{0cm}{0.6cm}ff}
\framebox[1.6in]{\rule[-0.2cm]{0cm}{0.6cm}Event Number}
 
\end{center}
\vspace{0.25in}
2) Data Word ...
 
\begin{center}
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.4cm}Field size}
\makebox[0.2in]{\rule[-0.2cm]{0cm}{0.4cm}2}
\makebox[0.6in]{\rule[-0.2cm]{0cm}{0.4cm}6}
\makebox[0.8in]{\rule[-0.2cm]{0cm}{0.4cm}8}
\makebox[1.6in]{\rule[-0.2cm]{0cm}{0.4cm}16}
 
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.6cm}}
\framebox[0.2in]{\rule[-0.2cm]{0cm}{0.6cm}qq}
\framebox[0.6in]{\rule[-0.2cm]{0cm}{0.6cm}i}
\framebox[0.8in]{\rule[-0.2cm]{0cm}{0.6cm}g}
\framebox[1.6in]{\rule[-0.2cm]{0cm}{0.6cm}Data}
 
\end{center}
\vspace{0.25in}
3) End Sub-Event Token  ...
 
\begin{center}
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.4cm}Field size}
\makebox[0.2in]{\rule[-0.2cm]{0cm}{0.4cm}2}
\makebox[0.6in]{\rule[-0.2cm]{0cm}{0.4cm}6}
\makebox[0.8in]{\rule[-0.2cm]{0cm}{0.4cm}8}
\makebox[1.2in]{\rule[-0.2cm]{0cm}{0.4cm}12}
\makebox[0.4in]{\rule[-0.2cm]{0cm}{0.4cm}4}
 
\makebox[1.5in]{\rule[-0.2cm]{0cm}{0.6cm}}
\framebox[0.2in]{\rule[-0.2cm]{0cm}{0.6cm}ee}
\framebox[0.6in]{\rule[-0.2cm]{0cm}{0.6cm}ROCO}
\framebox[0.8in]{\rule[-0.2cm]{0cm}{0.6cm}ff}
\framebox[1.2in]{\rule[-0.2cm]{0cm}{0.6cm}Word Count}
\framebox[0.4in]{\rule[-0.2cm]{0cm}{0.6cm}EN4}
 
\end{center}
\vspace{0.25in}
 
\begin{verbatim}
where ...
 
q       =   qualifier bit
i       =   item number
g       =   group number
e       =   error indication bit
EN4     =   lowest 4 bits of Event Number
ROCO    =   number assigned to the ROCO 
 
Data words from the master trigger module appear immediately after the Start
Event token, and have g=ff and i=30 to 3e.
 
ROCO numbers take the values 00 to 2f, with 2f always assigned to the last
unit on the DT32 bus.
 
\end{verbatim}
{\em [Exact allocation of the qualifier and error bits is awaited.]}
 
 
\end{document}