Proposed Event Builder System
From tigwiki
Contents |
[edit] Proposed System
In the proposed system, signals from different detector types will be collected by separate Vmics. This data will then be sent to the back end in an uncorrelated format. The back end will then write the uncorrelated data to disk. In addition, it will also send the uncorrelated data to an event builder. This event builder will then construct the correlated data stream which will then be sent to the analyzer system and also has the option to write the correlated data to disk. Also, the event builder will also be able to read uncorrelated data from disk and correlate it sending to either the analyzer or to a file.
[edit] Changes
- Currently, the channel header is encoded in a frame with the form 0xc0000spc where s is the slave number, p is the port number and c is the channel number. With this header, there is not enough channel numbers to encode all of the channels of a TIG64. In the new system the channel header will have the form 0xcvsppccc where v is the Vmic identifier, s is the slave identifier, pp is the port identifier and ccc is the channel identifier.
[edit] Current System
Currently, the data from all channels are collected in the TIGC cards and sent to a single Vmic card. This Vmic then correlates the data which is then sent to the back end where it is written to disk and sent to the online analyzer. The problem with this system is that a bottleneck occurs at the Vmic card since it is responsible for correlating the data. Also, due to the way that the card builds the events, it is possible that some of the data from an event may not be grouped into the event and could be discarded by the Vmic card.
[edit] Jeff's Interpretation of the Current Code
The system reads in data using the function read_tigcol_event. This function will check each collector to determine if it has event data to send. If so, the data will be read in by frame (a frame is a single 32-bit word of data). It determines how many frames the collector has and then continues to read frames from the buffer until one of the following has occurred:
- A trailer frame (0xENNNNNNN) has been found.
- A maximum number of frames has been read in EV_BUF_SIZE
- All the frames the collector has to report are read in
Only if a valid trailer frame is found in the buffer will the data be considered valid event data. If it is invalid event data, then the buffer is discarded. If the event data is valid, it is first checked by the function check_tigcol_event. This function will ensure that all of the necessary event information is contained within the buffer and that the event this data pertains to has not already been assembled. If either of these are true, the buffer is discarded. In addition, check_tigcol_event also adds the collector/slave number to the first channel header frame (0xc0000spc) it finds.
[edit] Issues To Be Dealt With In New System
- The fact that the slave number is only added to the first channel header is a problem since the rest of the channel headers will not have the slave number identified. (ie. the first header will be 0xc0000a80 and the rest be something like 0xc0000081) In the new code, this slave number will be added to each of the channel headers rather than the first one it sees.
- In the current system, the buffer is discarded if the event has already been written. The point at which an event is closed off is dependent on the buffer size of the event builder. This is a serious problem since important event information could easily be lost due to many new events being constructed in the buffer causing the buffer to fill before event information is written. In the new system this problem will be addressed.
[edit] Concept Definitions
The following is a list of concepts and words that pertain to the event builder system.
[edit] Frame
A frame is a single 32-bit word of data. Data from both the TIG10 and TIG64 cards will output their data in a series of frames. The data could be header/trailer information, channel headers, waveform data, etc.
[edit] Event
An event is simply an occurrence of interest. In our case, a radioactive decay. It occurs at a specific place and time.
[edit] Event Fragment
An event fragment is all of the data associated with a physics event that is given by a single channel. An event fragment will contain a header and trailer frame at the beginning and end of the fragment respectively, channel headers, waveform data, collected charge data, a timestamp, etc. The header and trailer frames will have a global event number encoded in them in order to determine the event that the fragment pertains to.
[edit] Assembled Event
An assembled event is considered to be all of the information from all channels pertaining to a single physics event. It is assembled from all event fragments that have the associated global event number encoded in their header/trailer frames.
[edit] Global Event Number
TO BE DEFINED
[edit] Raw Mode
If the DAQ is running in raw mode, frames from the collector cards will be read out in such a way that data written to a MIDAS bank will contain a full event fragment.
[edit] Super Raw Mode
In super raw mode, the DAQ will acquire frames from the collector cards as soon as they become available and write them to a MIDAS bank. In this mode, there is no guarantee that a bank will contain a full event fragment.
