Design of DCH output tagged containers

Last modified: 18 May 1998 by E.W. Varnes
Byte-stream diagram added: 29 March 2001 by M. Kelsey

What is an output tagged container?

Digitized hit times and pulse heights from the DCH front-end electronics are sent to a Read-Out Module (ROM), of which there will be either two or four for the drift chamber. In order to reduce the amount of data traveling downstream of the ROM, the important "features" of the raw data will be extracted by code running in the ROM, and only the information about these features will be propagated through the rest of the system. (In the course of feature extraction, the online calibration constants will be used to convert FADC and TDC counts into time and charge.) The output tagged container is the object that carries this data.

Therefore, there are four basic ground rules for the definition of the output tagged container:

• It must be as compact as possible.
• It must contain all of the information needed to construct a DCH digi.
• Since the object must be robust when transported across platforms (from VxWorks to unix), pointers are not allowed.

Necessary information

This is my understanding of the information that is essential to the construction of a digi:

• Number of hits
• Hit time(s)
• Integrated charge
• Wire/layer number

The first two of these are quantities that must be calculated by the feature extraction routine, while the latter will be obtained via a lookup table from the "detector tag" associated to the tagged container.

In addition to these quantities, there is other information that may be useful. This includes:

• Flags for problems in feature extraction (pedestal not reliable, waveform not shaped nicely, etc.)
• Width of waveform (number of samples integrated to provide charge)
• Any other suggestions?

Strawman format

So, given all of the above, here is what the data members of the output tagged containers may look like:

Channel level:

twoBytes status;        // feature extraction status word, with bits:
                        // [0:3]   Number of TDC hits
            // [4:8]   Number of samples summed to give charge
            // [9]     1 if waveform poorly defined
            // [10]    1 if pedestal calculation unreliable
            // [11]    1 if waveform clipped at FADC limit
            // [12]    1 if raw waveform is appended at end of 
                         features (for diagnostic purposes)
            // [13:15] To be defined...
twoBytes charge         // integrated charge.  Each charge sample is 6 bits 
                        // from the FADC, with an additional bit due to the 
            // bilinear FADC response.  The total charge, summed
            // over several samples, has a precision of 8-9 bits.
            // The additional 7-8 bits of space allow one to 
            // perform pedestal subtraction and apply calibration 
            // constants at the ROM level.  
twoSignedBytes time[maxTimes];   
                        // list of hit times, again corrected using calibration
                        // constant.  The time measurement has 11 bits of
            // precision.  The additional bits allow one to do T0
            // subtraction at the ROM level.

For the simplest case where there is only one TDC hit, this structure will use 6 bytes, meaning we reduce the channel data by x5 in feature extraction.

Chip level

The raw ELEFANT header word contains four bytes, of which we'll need to retain at least two in order to know the chip/channel addresses:

Byte address;           // ELEFANT address
Byte hitMask;           // Mask of hit channels

We may also want to send up the other two bytes (trigger tag and ELEFANT counter). Alternatively, we could just check that these values are reasonable during feature extraction, and flag any errors.

Element level

This structure is designed to be similar to the raw data, and consists of a longword header followed by the data from the element.

fourBytes header;    // Most-significant word is element data size in bytes
                     // Least-significant word is element address

Slot level

As the elements are self-labelled, there is no data needed at slot level.

Diagram of byte stream

Here is an example of the byte stream for a "typical" DCH feature-extracted XTC, the kind of data which is shipped out of the ROMs to OEP. The XTC header data is suppressed -- this is just the payload.

|  size   | address |addr|hitM| status  | charge  | time[0] | time[1] |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+ ...
0                   4         |         8                   12        |
DchElementFeature -->         |                                       |
                    DchChipFeature -->                                |
                              DchChanFeature -->                   <--|

| status  | charge  | time[0] |addr|hitM| status  | charge  | time[0] |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+ ...
|         16                  20                  24                  28
|                             |         |
|                          <--DchChipFeature -->
DchChanFeature -->         <--|         DchChanFeature --> 

| time[1] | time[2] | time[3] |addr|hitM| status  | charge  | time[0] |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+ ...
28                  32        |         36                  40        |
|                             |         |                          <--|
|                          <--DchChipFeature -->                   <--|
DchChanFeature -->         <--|         DchChanFeature -->         <--|

|  size   | address |addr|hitM| status  | charge  | time[0] | time[1] |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+ ...
|         44        |         48        |         52                  56
DchElementFeature -->         |
                    DchChipFeature -->
                              DchChanFeature -->

What is drawn is the first complete FEE (class DchElementFeature), which contains three chips (class DchChipFeature).

• The first chip has two channels, one with two times, and one with just one.
• The second chip has just one channel, but that channel has four times.
• The third chip also has only one channel, with a single time.

Notice that some of the objects are aligned on four-byte boundaries, but most (at every level of structure!) are not. In particular, for this example, the second DchElementFeature object itself starts in the middle of a word. This means that the DCH data stream can be two-byte (short) aligned, but cannot be stored or accessed using longword alignment.

Back to BaBar detector home page Back to SLAC home page

For comments/questions about anything in the above, contact varnes@slac.stanford.edu