Proposed Status Word Format for the Lvl1 / Lvl2 Data format
( 23th, july, 1999 )
General remarks:
It has been decided that the standard ATLAS event format (ATL-DAQ-98-129)
will be adopted to implement the data format between Lvl1 and Lvl2. According
to a short discussion with D. Francis (17/06/99)
-
the only condition for the status word is that if the first status word
is non-zero, this indicates a corrupted/unusable/suspicious data block
of the data fragment.
-
the field "Data event type" (this is the last field of the header before
the data or status block starts) can be freely used to label the event
type.
Therefore we propose to use the Data event type-field to label and distinguish
-
Physics events
-
test events (generated artificially)
-
Events which have monitored throughout the ROD system with help of a special
flag (this is currently being implemented in the MUCTPI system )
-
cosmic runs
-
calibration runs
Currently there is no convention/rule how to use this bitfield. It should
be discussed with the "developers" of the data format if some standardization
is wanted and how it could look like.
Status words:
Two kinds of status information have to be transfered to LVL2:
-
Error information which indicate that the data transmitted in the corresponding
data fragment is corrupted, incorrect or in any sense unreliable
-
Status information useful or necessary to interpret the content of the
data block
For each kind of information a 32 bit word is proposed. The first one contains
the error information. For non-corrupted events it is 0. Both words are
split into two bitfields of 16 bits each labled "common "and "private".
The bits in the common field have the same meaning for every subdetector
involved. The private section contains bits which have meanings specific
to the subdetectors. They can be used to give more detailed information
on error or status information. The proposed format
is based on the following information and assumptions:
Error-Bits (1st status word)
The following table lists the error bits which of the common field of the
first status word. For every error type a bit is reservered. If no error
has been detected the data is most probably ok and the first status word
is 0x00000000.
Error Bits contained in the Common Field
|
Error Type
|
Abbrev
|
Description
|
| BCID mismatch |
BCMM
|
Fatal error : a reset might be necessary |
| EVID mismatch |
EVMM
|
Fatal error : a reset might be necessary |
| Internal Data Transport Error |
IDTE
|
Can be further explained in private section. Data may be incorrect. |
| Data Overflow |
DOFL
|
An overfow in one of the internal buffers has occured. Absolutely FATAL.
(Should not occur if throtteling works correctly). Data is not expected
to be usefull anymore. |
| Time Out |
TOUT
|
A time out in one of the modules has occured. The data block may be
incomplete. |
The specific Error Bits for the Calorimeter Trigger are shown below.
All types of errors also correspond to a common Error Bit which is set
at the same time. That Bit is indicated in the column "Common Type".
Calorimeter Trigger specific Error Bits
|
Name
|
Abbrev
|
Common Type
|
Description
|
| PPr Link error |
PLERR |
IDTE
|
Protocol or Parity Error on link from preprocecssor into towers |
| ROD Link error |
RLERR |
IDTE
|
Protocol or Parity Error on link from ROI processor to ROD |
The following table shows the error bits specific to the muon
trigger:
Muon Trigger specific Error Bits
|
Name
|
Abbrev
|
Common Type
|
Description
|
| MibakBusError |
MBERR |
IDTE
|
The error line on the internal MIBAK bus had been activated. |
| MibakProtocolError |
MBPER |
IDTE
|
Protocol error on the MIBAK bus |
Status-Bits (2nd status word)
The second status word contains bits which give general status information
on the data of the data-block. They are to be seen as additional information
concerning the whole event. If set it does not mean that the data in the
data block is corrupted. Situations indicated by these bits are actually
foreseen during normal data taking. Again the word is divided into common
and private field.
Status Bits contained in the Common Field
|
Error Type
|
Abbrev
|
Description
|
| Internal Data Inconsistency |
IDI
|
Occurs during internal processing. Is further explained in the private
bitfield of the word |
| Limited Roi Set |
LRS
|
The number of ROIs sent to LVL2 has been limited in order to reduce
the total data volume. The limit is Detector dependent. It can be further
explained in the private field. |
The table shows status information sent by the calorimeter in addidtion
to the common status information above.
(HIGHLY PRELIMINARY: WILL BE CHECKED BY NORMAN)
Calorimeter Trigger specific status Bits
|
Name
|
Abbrev
|
Common Type
|
Description
|
| ???Input Data Saturation |
IDS |
? IDI ?
|
At least one FADC out of dynamic range |
| ???Algorithm Overflow |
AOF |
IDI
|
Overflow during internal calculations |
The private bitfield of the MUCTPI specifies further the case where
a limited ROI set is sent to LVL2:
Muon Trigger specific status bits
|
Name
|
Abbrev
|
Common Type
|
Description
|
| Suppress First |
SUP1 |
LRS
|
At least one "first" muon candidate has been suppressed because
it did not reach its threshold |
| Suppress Second |
SUP2 |
LRS
|
At least one "second" muon candidate has been suppressed because it
did not read its threshold |
| Candidate Overflow |
COFL |
LRS
|
In the MUCTPI a maximal number of candidates to be transfered to LVL2
can be programmed (between 1 and 16). The flag is set if an event contained
more candidates than given by this limit. Only the programmed maximal number
of candidates have been transfered to LVL2. |
| Sorter Overflow |
SOFL |
LRS
|
The unit in the MUCTPI which sorts the muon candidates according to
their pt can only hold a limited number of candidates of the same pt (currently
10). If more candidates of one pt are present in the event, only the last
10 candidates of that pt are transfered to Lvl2. This limitation is independent
of the one above. |
Proposal for Status Word in LVL1/LVL2 interface
Status information foreseen for CTP
So far there is no status information foreseen to be sent to LVL2 by the
CTP. The logic of the CTP consists of Lookup-Tables and logic "hard-wired"
in programmable logic devices. Nothing can "go wrong" in this logic which
could indicate a special status. Moreover no checks of which a result could
be communicated in the status word are performed. If internal Buffers before
the links to the DAQ or LVL2 run full, the BUSY and the module does not
send Triggers anymore. Therefore a data-loss (for a triggered event) is
impossible.
(Nick and Philippe investigate possible if there is possible information
for a status word in this module)
|
The ATLAS Level-1 Calorimeter Trigger