280 likes | 536 Views
Trigger & DAQ A. Boiano – A. Ordine FAZIA Days November 2008. DAQ Global schema. The acquisition mode is “free running”: the FEE cards continuously sample telescope signals the results are stored in a circular memory; The global synchronization
E N D
Trigger & DAQ A. Boiano – A. Ordine FAZIA Days November 2008
The acquisition mode is “free running”: the FEE cards continuously sample telescope signals the results are stored in a circular memory; The global synchronization the Main Trigger Board, inside the ATCA system, distributes the reference clock
Each FEE card - stores the digitized signals into the local circular memories • performs simple computation in order to send basic trigger information to the Block Card Block Card • collects data from its own FEE cards • forms trigger patterns • sends everything to the ATCA system.
according to the suggestion of A. Olmi (Florence meeting – September 2008): Basic trigger information for each telescope a 3D array [4, 4, 2] is defined a digital threshold is assigned to each detector of each telescope data from detectors are stored and compared to thresholds when a datum is over thresholds, the FEE computes the index [0-31] of the corresponding cell in the 3D array: Telescope Event Code (TEC)
In order to classify the events over the whole detector, an user defined code is introduced: the Event Class Code (ECC) Each telescope has a Look Up Table (TLUT) that associates to each TEC its own ECC. (for the sake of simplicity let us suppose that 8 bits are reserved for ECC) In setting up the trigger the TLUT has to be filled according to the association between the TEC and the corresponding ECC for each telescope TLUTs may be different from each other
Setup phase – TEC and EEC Just an example: Suppose, for the third telescope of the block n°10 we define 6 Event Class Code (moreover, at the same time, the ECC defined in all the system can be up to 256) We have to assign one of the 6 Event Class Code to each Telescope Event Code … …by filling the Telesope Look Up Table
Run Time … each FEE • measures the value of the TECs in its own telescopes in which the signals are over thresholds • extracts the corresponding ECCs from the TLUTs • sends them to the Block Card
Run Time … An example … we say : in the telescope n° 3 of the FEE n° 2 is occurred an event with TEC = 9 The FEE Card n° 2 extracts the corresponding Event Class Code from the Look Up Table of the telescope n° 3 of the FEE n° 2: The Event Class Code is “7”
Run Time … The Block Card: • calculates the multiplicity of each Event Class Code • builds the corresponding trigger sub-frame - builds a Block Trigger Frame chaining all the trigger sub-frames - sends it to the ATCA Regional Module. The transmission of frames between Regional Module and Block always happens into defined time slot. We set the length of a frame, i.e., to 40 ns. Note: of course, the number of trigger sub-frames sent, each time (40 ns), into the Block Trigger Frame by the Block, is not fixed. It depends upon the multiplicity & the number of ECC defined into the Block.
Note some figures By using a 3.5 Gbit/s optical transmission with the 8bit/10bit encoding and 40 ns frames each frame has 112 bit available The Block Trigger Sub-Frame needs 4 bits for multiplicity If we want a 8 bit Event Class Code (256 classes) there will be up to 9 trigger sub-frame in a frame
Run Time … Every Time Slot (40 ns) each Regional Card: performs the sum of multiplicities of the Event Class Codes, received, inside the Trigger Frames, from the Blocks ... builds a new Trigger Frame, the Regional Trigger Frame. (the Regional Trigger Frame has the same structure of the Block Trigger Frame) ... and sends it to the Main Trigger Board
Run Time … Every Time Slot the Main Trigger Board performs the Top Level sums of multiplicities of the Event Class occurred. Preview: Each Event Class Code occurred is used to address a Look Up Table inside the Trigger Board, in which there are the multiplicity thresholds above to which to accept the event and generate the Global Trigger. We took into account a Time Slot of 40 ns. But the real Trigger Time Window (the time spread in which correlated ECCs of the same event arrive) could be longer than only one Time Slot. We say, just to fix the idea, the Trigger Time Window is 10 Time Slots (400 ns). Then, the actual multiplicity of an Event Class is the sum of its multiplicity in the last 10 Time Slots.
Run Time … In the below simple sketch is shown how to do the multiplicity on the last 10 Time Slot, for, i.e., the Event Class “j” For Each Event Class there is a dedicated chain The actual multiplicity is compared with the one into the setup register: if it results higher than the multiplicity configured the “accept” signal is generated
Run Time … We can arrange in many way the elaboration for the generation of the Global Trigger In this example we have that 2 ECC are used to produce the Global Trigger. We say, the ECC-K is faster (it happens 80 ns before) than ECC-J and also happens more time in shorter time If we want use both for the trigger we have to respect the mutual time correlation Therefore we delay ECC-K and also shorten its Trigger Width with respect that one of ECC-J Furthermore, if the rate of ECC-K is too high we can set the Counter-K to downscale its occurrence Then, into the LOGIC UNIT, we can, for example, do the coincidence (AND) between ECC-J and ECC-K to have finally, our Global Trigger
Note about the trigger setup we have seen that to configure the trigger means to produce the 640 x 16 Telescope Look Up Tables ... x 10240 and, for each Event Class Code defined: set the Trigger Time Window DELAY and WIDTH, because each ECC, may be, has known but different delays between its generating, in the Blocks, and its arriving, to the end of chain, to produce the GLTR set the ECC Counter for the related downscale configure the LOGIC UNIT to perform the desidered logic operation
Run Time … Now we have the Global Trigger The Main Trigger Card packs the Global Trigger Frame: and sends it to all the Blocks now the contents of all circular memories, at defined depth, are copied into temporary buffers ... then the next step is the building of the event block into the buffer of the Block Card.
Data format … There is more than one type of words: data samples (ID=0), charge value (ID=1), Timing (ID=2) and also special words like the sub-detector Footer Words (ID=5), FEE Footer Words (ID=6) and End Of Event Word (ID=7). For each FEE we have 4 Telescopes = 12 sub-detector, we need of 4 bits to identify them Word Type Content For each FEE of the block we will have, into Event Block Buffer something like this ...
Data format … When all the data have been copied into the Event Block Buffer the Block Card Logic appends, to the end of the packet, the End Of Event Word in which also put the Event Counter sent into the Global Trigger Frame by Trigger Card The Block Units that have not valid data for this event put, into Event Block Buffer, only the End Of Event Word Now all the Block Units send the content of Event Block Buffer to the ATCA Regional Module The transmission of the event is done by fragmenting it in data frames
The Regional Board are equipped with one multi-event FIFO for each FEE Block. The Opt. Receiver & Control Logic Unit 1 extracts the data fragments from the data frame incoming from the Block and re-builds the Event Data Format For each event at least 1 word will arrived into each FIFO, the End Of Event Word The Control Logic 2 get the event words from each FIFO until it finds the End Of Event Word. If any FIFO is empty it waits for the arriving of End Of Event Word until a Time Out. If Time Out occurs the related FEE Block did not work correctly. When the End Of Event is found, for that event, in all FIFO, it check that all the Event Counters, in all the End Of Event Words have the same value (check for right alignment).
If is all right, the Control Logic 2 & CPUs complete each event data packet extracts from each single multi-event FIFO by writing, into the End Of Event Word the ID of the FEE Block related to the channel The data of all FEE Blocks are put into the Ethernet Buffer, encapsuled into a UDP/IP packet, with the IP destination number of one PC of the PC Farm The UDP packet is then sent to the switch. In the draft of the Regional Module are shown more than one Ethernet Buffer with its own Interface (4). We have to decide how many CPU + Ethernet Buffer + Ethernet Interface chains we need to make the Ethernet connection covers the bandwidth required.