From tigwiki

[edit] Overview

When a module receives a global trigger, the TIG digitizer (TIG10 or 64) sends any data it has by LVDS to its collector card. These data are formatted as one fragment per channel and buffered. The collectors are interrogated by the front-end computer. If the collector has ONE OR MORE fragments, the data is read out by the front-end and passed as a bank to the MIDAS system, where it is treated as a "MIDAS event". An EventBuilder client can be used online to collect, identify, assemble, and delimit multiple fragments from multiple "MIDAS events" into real physically meaningful events.

[edit] WFDN banks

A Midas event contains one or more banks. WFDN banks contain the result of a readout of a collector. This bank contains one or more fragments which may come from one or more physical events.

The general form of the data is 32-bit words. The top 4 bits (the top nibble, or leftmost hex digit) is the "feature" nibble and identifies what kind of data is carried in the rest of the word. 0x8NNNNNNNN is the "feature" identifying the start of a fragment from sequential trigger number NNNNNNN. 0xENNNNNNN identifies the end of a fragment. A well-formed event has, as a minimum, these two words.

As such, he data fragments produced by the digitisers look like the following ...

  0x8NNNNNNN 0xc0000xxx 0xa0xxxxxx 0xa1xxxxxx [0xa2xxxxxx ... 0xa8xxxxxx]
  0x0xxxxxxx     ...    0x04xxxxxx 0x05xxxxxx 0xENNNNNNN

where NNNNNNN is the event number in this run, and appears in both the header 0x8.. and trailer 0xe... The rest of the features are described below.

WFDN banks contain one or more fragments from one or more events.

[edit] TIG0 banks

The EventBuilder client generates TIG0 format data. TIG0 events are assembled; all fragments that were identified from a given event are written to a single TIG10 event. The following description is from Chris Pearson's definition of assembled events.

• Each TIG0 bank contains 32-bit long-word data for a single physics event.
• The first datum is the common assembled event number for all fragments in the event.
• All subsequent data are parts of the fragments.
  • Each fragment starts with a header datum. Other than this, there is no guarantee of order or content of each fragment.
  • There is no end-of-fragment identification.
• Any one datum can be identified by the leading nibbles.
  • 0xc0000spc: Header datum.
    • The port number is encoded 0-5 for ports 0-5, and 8-13 for ports 6-11. Don't ask why there's a gap of 2 in the middle.
  • Subsequent data are the fragment read read from collector (i.e., slave) s, port p, channel c.
  • 0xb00ppppp: 19-bit trigger pattern. The lower 12 bits are the ports requesting triggers. The next 7 bits are the pretriggers satisfied/not-satisfied (one bit for each of the 7 pretriggers). This pattern will be the same for each fragment coming from the same collector - I may get rid of the redundant data and only include this element in the first fragment from each collector.
  • 0x0wwwwwww: Two 14-bit samples.
    • 14-bit two's complement. When decoding, make sure to extend sign bit, or do other appropriate math.
    • First sample is in Bits 0-13, second sample is in Bits 14-27. (zero in LSB) As such, the two samples span the middle nibble of wwwwwww.
  • 0x4ttttttt: CFD time
    • Units of 1/16th of a clock cycle, i.e, 0.625 ns.
    • According to Chris, only the last nibble is "new" information. It gives the time within a sample of the CFD time. The upper 6 digits should be identical to the lower six digits of the time stamp, datum type 0xa0.
      • However, this does not seem to be true. There is a fairly consistent difference between these two numbers. Update: The cfdtime is the time of the pulse, the timestamp is the time the trigger accept is received back from the master (These times used to be the same with the single-collector-simple-trigger system where the wait for a trigger accept was very low. The 3-level, complex trigger now adds quite a large delay to the timestamp). The timing of the waveform is related to the timestamp (not the cfdtime), and so the position of the pulse in the waveform samples has some significant variation. It should be possible to align the pulses to a fixed position using both times (not tested yet).
  • 0x5eeeeeee: evaluated energy.
    • Units are based on ADC units, the K (window width) parameter, and A (attenuation factor).
    • If x is the pulse height in ADC units, then e = x * K / A.
  • 0xajTTTTTT: 48-bit time stamp from beginning of run; 10 ns clock ticks.
    • j=0: lower 24 bits encoded in this datum. See notes on CFD time (type 0x4) above.
    • j=1: upper 24 bits
  • 0xa2llllll: Live time. This counts 100Mhz clock ticks while NOT Processing a pulse, the value is read out every 2^24 ticks (~1.6Hz) and will be zero if 100% dead, or 2^24-1(ffffff) if 0% dead.
    • This does not give the correct deadtime, as the main contribution to deadtime is the blocking of triggers due to frontend buffers being full (Not the individual channels pulse processing) - I may change this to be more useful.
  • 0xa4nnnnnn: Requested triggers
  • 0xa8nnnnnn: Accepted triggers

[edit] MIDAS

The data with format as described above is stored by the midas data acquisition system, which adds its own headers etc. around the data. The additional midas headers/trailers are described in the following pages.

• midas data format (Cern page)
• midas data format (Triumf page)