EDOC064

EUROGAM PROJECT

NSF DATA ACQUISITION SYSTEM Eurogam Hardware Event Format Usage

Edition 1.0 January 1991

Nuclear Structure Software Support Group Liverpool University Eurogam Hardware Event Format Usage

John Cresswell

Edition 1.0 January 1991

1 Introduction

This is an attempt to expand on the Eurogam defined event format ^{1} 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!].

2 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.

1Eurogam ROCO Data Formats, Stathis Kossionides

3 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.

4 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.

5 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 ^{2}. This is unavoidable and needs to be presented in a clear way to the experimenter.

2Event Builder Language User Manual, John Cresswell and Linda Pratt, - to be produced

6 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^{3}. Following is a list of the data words available in the trigger group together with allocated item numbers ...

item 0 : Trigger type

item 1 : Raw Ge sumbus ADC

item 2 : Suppressed Ge sumbus ADC

item 3 : BGO sumbus ADC

item 4 : External sumbus ADC

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.

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

item 0 : Ge Energy word ... low gain

item 1 : Ge Energy word ... high gain

item 2 : Ge TAC word

item 3 : Ge Ballistic Deficit TAC word

item 4 : BGO Energy word

item 5 : BGO TAC word

item 6 : BGO Hit Pattern word

3Trigger Specification (EDOC025) Ian Lazarus

8 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.

1) Start Event Token ...

Field size  2  6  8  16

11 3f ff

Event Number

2) Data Word ...

Field size  2  6  8  16
qq  i  g  Data

3) End Sub-Event Token ...

Field size  2  6  8  12  4
ee ROCO  ff  Word Count EN4

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.

[Exact allocation of the qualifier and error bits is awaited.]