June 1996 Event Format
Format used to record for event data in the June 1995 level 1 trigger run
The data is written using the 32 bit EPIO package and is largely structured as 16-bit words. The overall structure, plus the CAMAC and CPM data formats are largely unchanged from last year's run, but there is some additional information in the header, which is the number of BCID and FADC words written.
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.
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 Word Event Header Length 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, which is always 15 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 Number of CAMAC words Word Number of BCID words Word Number of FADC words Word Time Word Date Word Day number
This indicates the current run, and is usually incremented for each new run although other steps are of course possible.
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.
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 CAMAC words
This is the number of CAMAC words which are in the record, if it contains an event record.
Number of BCID words
This is the number of BCID words in the record, if it contains an event record.
Number of FADC words
This is the number of FADC words which should be in the record, if it contains an event record. However, it is possible for problems reading out the FADC to reduce the actual number of words below this amount. This means that the FADC data length has to be determined from looking at the data itself. As the FADC data is followed by CFM data or the end of the logical record, just processing the record from the start of the FADC data as FADC Card data blocks until a block is found which does not start with 0xFADC is sufficient.
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 (... means that it is an array of 3 elements each of a word or whatever):
Word Number of slices to readout from CPM Word Offset of first slice to readout from CPM (negative value) Word Clock module register settings Word CPM threshold settings Then some data relating to the BCID cards... Longword Bitmask of BCID channels not to initialise Longword Bitmask of BCID channels not to readout Word Number of BCID slices wanted (same for all cards) Word First slice offset (same for all cards) Word Bitmask of BCID memory types to read char Xilinx configuration filename Word Flag - configuration of Xilinx enabled char Lookup table filename Word Flag - Load lookup table enabled Word Flag - Run BCID cards in test mode (i.e. use LUT as data source) Word Flag - Xilinx mode Then some data relating to the Flash ADC cards... Longword Bitmask of FADC channels not to initialise Longword Bitmask of FADC channels not to readout Word FADC slices wanted Word FADC first slice offset Word FADC playback enable Word FADC preload data Word FADC DAC values char FADC preloaded data filenames char Comment string 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 Word CPM threshold settings
Explanation of the BCID data
The BCID 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 BCID channels not to initialise
The system contains a maximum of three BCID cards, each of which contains 3 Xilinx FPGAs which each process 4 channels of data (making 12 channels per card). The first two entries are each pairs of 32 bit longwords relating to the overall control of the cards. They have the same format - each bit refers to a single channel and so all 32 of the bits in the first longword are used along with the first four bits in the second longword.
As the initialisation relates to the configuration of the card as a whole, the bits for the bitmask of BCID channels not to initialise are examined in groups of 12 - if any of the bits are NOT set then that card is initialised. The least significant 12 bits refer to the card numbered 0, and so on until the most significant 8 bits of the first longword and the 4 least significant bits of the second longword refer to card 2.
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 BCID channels not to readout
This is similar to the above, except that the memories on the BCID 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 BCID 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.
BCID first slice offset
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.
BCID 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 BCID memory types to read
The BCID boards have three memories per channel on them. This bitmask indicates which memories to readout. The following bits are used:
001 Input memory 010 Output memory 100 Lookup table memory
Thus, if the mask contains 3, then the BCID data portion of the event records should only contain input and output memory contents.
BCID 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 (which is why there are three filenames). If the suffix is not present, then .bit is assumed. The Xilinxes are only downloaded if initialisation of one or more channels to which they relate has been enabled (or rather, not disabled) and the following word in the record (BCID configure Xilinx from files flag) is set.
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.
BCID 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 only downloaded into the cards at initialisation (which occurs when the run is started) if the channels are selected to be initialised and the BCID load lookup table flag is set.
Flag - Run BCID cards in test mode (i.e. use LUT as data source)
This flag can be set to help debug the BCID cards. It indicates that the BCID 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.
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.
The flash ADC data is conceptually very similar to the BCID 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 BCID 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.
Holds an optional, null-terminated comment string. If there is no comment, then the first character is a null.
End of physical record
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.
These have the following format:
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
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.
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
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)
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.
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 word FIFO data And then word Energy sum
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