June 1996 Event Format

Format used to record event data in June 1996 level 1 trigger run

Norman Gee
Last updated 14 May 1996

The data is written using the 32 bit EPIO package and is largely structured as 16-bit words.

Physical records

The data is written as logical records, which this document discusses. These are encapsulated on the tape within physical records which have a standard EPIO format physical record header. The physical record header should be transparent if the tapes are read using EPIO. However, for reference, the physical record header consists of the following twelve 32 bit longwords:

Longword Physical record length in 16-bit words, always 16380
Longword Physical record header length in words, always 24
Longword Physical record number on tape
Longword Displacement of next logical record start
Longword Run number
Longword Physical record type, always 0
Longword Physical record identifier field = 522144444
Longword Physical record identifier field again = 522144444
Longword Number of empty physical record headers following this one
Longword Tape format version number = 8012
Longword Logical record word length, always 32
Longword Length of standard physical record header, always 24

The physical records always have the first longword set to indicate they are 16380 words long even when they are not. For example, the first physical record is empty apart from a physical record header followed by a longword -1 to indicate end data in this physical record.

The physical record number starts at zero and increases monotonically during the run.

For more information, you should get hold of a copy of the EPIO User's Guide; which is CERN program library long write-up I101.

User Header

All event records start with a common header, the first four words of which are the standard EPIO header, which has the following format:

Word Event Length
Word Event Type (1100,1001, etc)
Word Event Header Length (in words - currently 18 for events)
Word Event Sequence Number

An Event Length of -1 means that this is the last logical record in the current physical record on the tape, otherwise it is the real length of the logical event record. The Event Header Length is the length of the user header, in words, which is always 18 word for this run.

The Event Sequence Number rises monotonically for each logical record written during the run.

The only "interesting" entry in this is the Event Type, which indicates what type of event record this is.

After the standard EPIO header, there follows the following "user" data.

Word Run number
Word Event number
Word Interrupt register contents
Word Burst number
Word Event in burst
Word Time (bits 0:7 secs, 8:15 mins)
Word Time (bits 0:15 hours)
Word Date (bits 0:7 day , 8:15 month)
Word Date (bits 0:7 year)
Word Day number (bits 0:15 day number, 0=Sunday)
Word Number of words of fixed length (e.g. CAMAC)
Word Number of FADC words
Word Number of TXM words
Word Number of CPM words

Run number

This indicates the current run, and is usually incremented for each new run although other steps are of course possible.

Event number

This is the number of the event within the run. The first event is event 1.

Interrupt register contents

The least significant bit, bit 0 is set when there is an interrupt due to a physics event (and thus an event record is to be written) and bit 1 set when there is an End of Burst signal.

Thus, the user header interrupt register field should contain a 1 when it is part of a normal physics event record and 2 if it is part of an End of Burst record.

Burst number

This is beam spill number within the run. It is incremented at the end of the burst.

Event in burst

As the DAQ software is unable to discriminate between the sources of different triggers, and random triggers will be assumed to have come from the current burst.

Number of words of fixed-length data

This is the number of CAMAC words which are in the record, if it contains an event record.

Number of FADC words

This is the number of FADC words in the record, if it contains an event record.

Time, Date and Day number

This is a time stamp for when the record was written. It has the following format.

The least significant byte of the time is the number of seconds since midnight; the next is the number of minutes and the following one is the number of hours. For example if the time field contains 927755 decimal (=E280B hexadecimal), then this represents hour E hexadecimal, minute 28 hexadecimal, second B hexadecimal - i.e. the record was written at 14:40:11.

The date works in a similar fashion, with the day being represented by the least significant byte; the month by the next least significant byte and the year by the next two bytes. For example, 130745860 decimal = 7CB0604 hexadecimal, which can be interpreted as 4 June (i.e. month 6) 1995 (7CB hexadecimal).

The weekday is represented by the third byte of the weekday word, with 0 representing a Sunday. For example, 100 hexadecimal means it was a Monday.

The rest of the record depends upon the Event Type field in the header. It can take the following values:

ID EVENT = 1001    which means it is a physics event record
ID EOB   = 1002    which means it is an end of burst record
ID SOR   = 1100    which means it is a start of run record
ID EOR   = 1101    which means it is an end of run record

There are additional values for Start of Burst and comment records defined in Spider, but we do not currently use them (but see the note on End of Burst records below).

Start and End of run records

These have the same format and contain the same data. The only difference is the different Event Type values. One is written at the start of a run and the other at the end. They are always the last logical record in a physical record.

They have the following format (...[3] means that it is an array of 3 elements each of a word or whatever):

Data relating to the TXM modules ...
Word Bitmask of TXM Modules not wanted
Word Bitmask of TXM modules not used.
Word Number of TXM slices wanted (same for all cards)
Word First slice offset (same for all cards)
Word Bitmask of TXM memory types to read
char Xilinx configuration filenames[12][9]
Word Flag - configuration of Xilinx enabled
char Lookup table filenames[12][9]
Word Flag - Load lookup table enabled
Word Flag - Run TXM modules in test mode (i.e. use LUT as data source)
Word Flag - Xilinx mode

Data relating to the Flash ADC cards...
Longword Bitmask of FADC modules used[2]
Word FADC slices wanted
Word FADC first slice offset
Word FADC playback enable
Word FADC preload data
Word FADC DAC values[9]
char FADC preloaded data filenames[12][9]

Data relating to the CFM modules ...
Word Number of slices to readout from CFM
Word Offset of first slice to readout from CFM (negative value)
Word CFM threshold settings[36]

char Comment string[80]
Word End of physical record marker (= -1) See description!

Explanation of the first part of the header

Number of slices to readout from CPM

This value is set to between 0 and 248, and represents the number of sets of memories RAM and FIFO to read out. Each memory is written 25 ns after the previous one, hence the concept of successive time slices.

Offset of first slice to readout from CPM

Word Clock module register settings[12] Word CPM threshold settings[36]

Explanation of the TXM data

The TXM data is taken from parameters set before the start of the run in a shared memory section. This memory area is used for communication between the user interface and the DAQ producer process.

Bitmask of TXM modules not wanted

The system contains a maximum of 9 TXM cards, each with a Xilinx FPGA processing 4 channels of data. The first two entries are words relating to the overall control of the cards. They have the same format - each bit refers to a single module

As the initialisation relates to the configuration of the card as a whole, each bit relates to a group of 4 channels.

Note that the normal state is to initialise everything, so these longwords should usually be all zero if everything was working when data was written.

Bitmask of TXM channels not to readout

This is similar to the above, except that the memories on the TXM card are paired up in the following fashion. As the card is accessed as 16 bit data, a read to its memory access register will return data from a pair of channels, such as channels 0 and 1. Thus, pairs of bits are examined and if either is ZERO then that channel pair is read out.

Number of TXM slices wanted

This is the number of successive memory addresses to read from the BCID card. Each one represents the data at a successive 25 ns interval.

TXM first slice offset

This is the number of successive memory addresses to read from the TXM card. Each one represents the data at a successive 25 ns interval.

TXM first slice offset

When the system is stopped for readout to start, it commences at the memory location corresponding to a certain interval before the current time. This is done by starting to access the memory at an address which is offset from the one which was written immediately before the system was halted. This offset represents the interval, in units of 25 ns.

Bitmask of TXM memory types to read

The TXM boards have two memories per channel, excluding look-up tables. This bitmask indicates which memories to read out. The following bits are used:

001     Input memory
010     Output memory

Thus, if the mask contains 3, then the TXM data portion of the event records will contain input and output memory contents.

TXM Xilinx configuration filename

As part of the initialisation, each Xilinx FPGA can be downloaded with a configuration program. This field contains the null terminated filenames to be used for each card. If the suffix is not present, then .bit is assumed. The Xilinxes are only downloaded if the corresponding modules is present and required in the readout.

As the DAQ code is largely written in C, all of the strings follow the C string convention of being null terminated with any unused characters following the null containing arbitrary junk.

TXM lookup table filename

This null-terminated string contains the name of the file which contains the lookup table values. The file contains all of the tables for all channels of all cards in a simple, but tedious, ASCII format. It is downloaded only into the cards present and wanted, when the run is started.

Flag - Run TXM cards in test mode (i.e. use LUT as data source)

This flag can be set to help debug the TXM cards. It indicates that the TXM cards are being run in test mode, in which the lookup table memory is used as a source of fake data which is clocked through the Xilinxes instead of real data being used. This allows the Xilinxes to be tested without the need for an external data source.

Xilinx mode

This is used to set the Xilinx operation mode. There are two signals into the Xilinx chips which control the mode - the Peak Finder Override (PFO) and the FIF Filter Enable (FFE) signals. The mode can take the following values:

0 FFE=1 PFO=0
1 FFE=0 PFO=1  ("transparent mode" - Data passed unchanged)
2 FFE=0 PFO=0
3 FFE=1 PFO=1

indicates that the Peak Finder Override and FIR Filter Enable bits on the FPGA control registers should be set so that the Xilinxes passed the input data through themselves without modifying it. Again, this function is only used for debugging and testing of the software and hardware and should not be enabled during a "normal" run.

FADC data

The flash ADC data is conceptually very similar to the TXM data. Each card handles 4 channels, and each channel has only one 256 byte memory instead of three. The bitmask and slice settings are similar in function to the TXM cards and need no further description only to say that the initialisation of a card occurs if any of the four channels on it are enabled.

FADC playback enable

For diagnostic purposes, the memories on the cards can be preloaded with fake data and the cards will play it back through the digital outputs. The normal operation is for the analogue inputs to be digitised to be recorded in the memories and sent out on the digital outputs.

This flag having a non-zero value indicates that the playback mode was selected for this run.

FADC preload data

This flag indicates that data was preloaded into those cards which were initialised. The filename is in the "FADC preloaded data filenames" field. The file contains the preload data which can be used for all cards.

FADC DAC values

This is an array of 12 words which contains the D/A converter bias offsets which were loaded into each card that was initialised. Note that these are byte values, although recorded in words.

Comment string

Holds an optional, null-terminated comment string. If there is no comment, then the first character is a null.

End of physical record

Always -1.

Note On 7 June we slightly changed the format of run start and end records so that this word was not counted as part of the record length in the header. This is because we were having problems reading the tapes with EPIO and now believe that this word is considered by EPIO to be the start of the next logical record on the tape. A value of -1 for the record length has a special meaning - it means that there is no more data in the physical record.

End of Burst records

The End of Burst record is written at the end of the spill. It just contains a "user" header with the interrupt register field set to 2, and the burst number incremented.

Important note: During running, we discovered that the End of Burst signal was plugged into the Start of Burst port on the interrupt register. This means that when there is an End of Burst signal, the computer considers it to be a Start of Burst. The only difference is that the computer writes a Start of Burst data type field instead of an End of Burst and increments the Burst Number field. For End of Burst it does not increment the Burst Number.

So, rather than increasing the number of different tape formats for this run, we just revised this document so that the Start of Burst data type gets renamed to End of Burst! In the running program, the source code still thinks it is writing Start of Burst records. The only complication is that the Burst Number gets incremented at the end of the burst.

Event records

These have the following format:

• Header
• CAMAC data
• BCID (new bunch crossing identification cards) data
• FADC (Heidelberg flash ADC cards) data
• CPM (Cluster Processing Module) data

CAMAC data

Ten words of CAMAC data, which is:

Word Interrupt register
Word Microscaler channel 1
Word Microscaler channel 2
Word Microscaler channel 3
Word Pattern unit
Word TDC channel 0
Word TDC channel 1
Word TDC channel 2
Word TDC channel 3
Word Switch register

Interrupt register

The CAMAC crate has an EC218 Interrupt Register unit in it which is used to generate interrupts to the computer to indicate that it a physics event has occurred and that it is therefore to readout the various modules; or to write and end of burst record.

The least significant bit, bit 0 is set when there is an interrupt due to a physics event (and thus an event record is to be written) and bit 1 set when there is an end of burst signal. Thus, the user header interrupt register field should contain a 1 when it is part of a normal physics event record and two if it is part of a start of burst record.

Microscaler channel 1

The microscaler card is just a CAMAC module with a set of registers which are incremented each time that a pulse is detected on a corresponding input port. The registers can also be zeroed by the computer. The first channel records the number of S3.S4 and random triggers seen since the start of the run.

Microscaler channel 2

This records the number of S3.S4 and randoms gated seen since the start of the run.

Microscaler channel 3

This records the number of "event" acknowledgements that the computer has issued since the start of the run. The function of these signals is to reset everything after an event has been processed and make the system ready to receive the next trigger. One acknowledgement is issued when the run starts and then one each time that the computer has finished processing an event. Thus, this number should be equal to the number of events so far processed + 1. This information was not recorded in this word last year.

TDC channels

There are four words of TDC (=Time to Digital Converter) timing data. Only the first TDC channel (Channel 0) is used, so the last three contain meaningless values. The TDC is the time between a trigger being received and the next 40 MHz clock tick, so always falls in a 25 nanosecond range. The start of this range is not defined but can be determined statistically by looking through a large number of events (i.e. there is a propagation delay through the NIM logic so the lowest TDC value seen is not zero but some initial offset. The TDC card has its range is set to 0.25 nanoseconds per unit.

Switch register settings

There is a manually set switch register which is usually changed to mark when some change is done during a run, or at the start of a run. The current value in this register is recorded in the last CAMAC word written

BCID data

The BCID readout appears on the tape after the CAMAC readout, and has the following format:

BCID channel data
BCID channel data

... (for as many channels as selected for readout)

BCID card status data
BCID card status data
... (for as many BCID cards as selected for readout - max 3)

The format of a BCID channel data block is as follows:

Word 0xBC10 OR'ed with the memory type (range 1-3)
Word card number (range 0-2)
Word channel pair (range 0-5)
Word slices wanted (i.e. how many slices are being read out)
Word first slice offset (negative number)
Word Slices for this pair of channels[slices wanted]

memory type is 1 for input memory, 2 for output memory and 3 for LUT memory The channels are read out in ascending card number. Within that, they are read by ascending channel pair and within that by ascending memory type. e.g.

card 0, channel pair 0 (i.e. channels 0 and 1), input memory
card 0, channel pair 0 (i.e. channels 0 and 1), output memory
card 0, channel pair 0 (i.e. channels 0 and 1), LUT memory
card 0, channel pair 1 (i.e. channels 2 and 3), input memory
card 0, channel pair 1 (i.e. channels 2 and 3), output memory
card 0, channel pair 1 (i.e. channels 2 and 3), LUT memory
...
card 2, channel pair 0 (i.e. channels 0 and 1), input memory
card 2, channel pair 0 (i.e. channels 0 and 1), output memory
card 2, channel pair 0 (i.e. channels 0 and 1), LUT memory

The format of a BCID card status data block is as follows. If there is more than one of them, then they are ordered in ascending card number. These blocks always come after the last BCID channel data blocks. Any card which is read out will contribute one of these. The registers are read when the event is read out.

Word 0xBC20
Word Card number (0-2) which the block refers to
Word Module ID register
Word Control and status register
Word FPGA control register

The FPGA control register is laid out as follows:

Bit 0 Peak Finder Override select flag
Bit 1 FIR Filter Enable select flag
Bit 2-3 Unused (read as zero)
Bit 4-5 FPGA number selected for current operation (range 0-2)
Bit 6-7 Unused (read as zero)
Bit 8 (Not) Clear Program (1 = good)
Bit 9 Trigger readback of selected FPGA reading back (read as zero)
Bit 10 RAM Clock Trigger (read as zero)
Bit 11 RAM Clock status (0 = good)
Bit 12 Not Initialised (0 = good)
Bit 13 All FPGAs on card Loaded (1 = good)
Bit 14 Readback In Progress (0 = good)
Bit 15 Loaded - selected FPGA is loaded (1 = good)

FADC data

The FADC readout appears on the tape after the BCID data, and has the following format:

FADC card data
FADC card data
...
 (for as many cards as selected for readout)

In ascending FADC card number

The FADC card data has the following format:

Word 0xFADC
Word card number [0-8]
Word Control and Status Register
Word Counter at start of readout
Word Slices wanted (i.e. how many slices were read out)
Word First slice offset (negative number)
Word pairs FADC data (packed as bytes - first Word = 
		channels 0 & 1, second = 2 & 3)

If any channel on a card is selected for readout, then all of the channels on the card are actually read out.

If there is a VME, clock absent or similar error when reading out a card, then only 6 words are written in the event record for that card - but the second three words (Slices wanted onwards) will be zero. It should be possible to determine the reason for the error by looking at the CSR word.

The FADC data is read out as 32-bit longwords, with each byte representing one channel of FADC data.

CPM data

Apart from the CF00 check word and the number of slices, it has the same format as for last year. The current format is:

wordCF00 hexadecimal
word Number of slices requested
Then, for each slice in turn:
    word RAM data[20]
    word FIFO data[9]
And then
word Energy sum[9]

The number of slices is easily found from the header.

For the latest version

This document is available via http://hepwww.rl.ac.uk/atlas/l1/home.html  

This page was last updated on 16 December, 2013
Comments and requests for clarification may be sent to
E-mail:
Telephone: