LKr readout and trigger R. Fantechi 3/2/2010

The CARE structure

Readout FPGA functionalities

Readout scheme Readout strategies – Write continuously digitized data into the DDR2 memory Usage of a dual port buffer Actual memory size will not fit one burst Operation with 8KB buffers to write-to-DDR2 and read-to- DDR2 in an efficient way Possible pipelined processing of data to DDR2 – i.e. feature extraction – Flag samples using 8 spare bits – Transfer L0 flagged events to another buffer Sort of linear buffer or linked list Then use the DDR2 as a circular buffer with depth of seconds May be rearrange the sample order and add headers – Write out to GbE links events only when L1 (or L2) arrives Basic assumption is that L1 rate is O(20Khz)

Which rates we will have? Is it the assumption of O(20 Khz) for the L1 trigger right? – What can be done at L1 with the LKr trigger data? – Are there other detectors able to give a good rejection factor at L1? Or should we move LKr readout at L2? – Can L2 be efficient using only the LKr trigger data? – In this case, the internal transfer from circular to linear buffer could happen at L1 Less resources needed – L2 readout will imply an additional data merging after L2 processing

Zero suppression issues Up to now no zero suppression has been applied – Wish to have all the channels available for the analysis – Can this requirement/wish be dropped? Try to identify safe algorithms – There are places in the CARE module where to do some work – Some more could be done in the PC’s – First provocative proposal in few slides Some coherent simulation work should be started for both topics (rate and zero suppression) – NA62MC is available. Start to learn its features. Understand if something more should be added i.e. some signal processing (noise, shapes, etc)

Basic network scheme

The network Simple baseline implementation – At the assumed L1 rate, one can multiplex 16 GbE links into one GbE output link – LKr event building PCs have a 4-line ethernet card Up to now better than 10 GbE links – Fragments of one event (or of a bunch of events) are sent to one PC by all CARE links – Built events are sent out with links with the proper bandwidth Many improvements in this picture – The 16 to 1 switches could be one or more bigger ones with 10 GbE links to the upper switch – Need to define control paths to broadcast trigger packets to all CAREs – The upper switch could be a part of the NA62 big central switch to allow event transfer through the backplane

Trigger handling Actual baseline: a TELL1 + a control PC – TELL1: receives L0&clock, update global timestamps, prepares L0 readout requests, pass them to control PC – Control PC: receives L1 and L2 requests, packs O(40) of them in a packet sent to all CARE modules for readout using Jumbo frames, sends L0 packets to all CAREs, housekeeping, logging, handling of LKr calibration, CANbus interface for CPDAS parameter load Be aware – The TELL1 time stamp is updated by the TTC clock, while the address counters in the CAREs are updated with the “good quality” clock TTC clock will be derived from the other Enforce the check that the phase difference of the time stamps is fixed

Again about zero suppression

R. Fantechi From now on, linear scale on the left, log on the right From NA62MC

Possible zero suppression? NA62MC gives energy deposits/cell down to small energies – Less than the real noise of the readout – For a  +  0 event, few thousand cells different from zero Simple exercise – Keep only cells with a deposit larger than 10 MeV – The result is only O(few 100s) cells To be studied – Identification of pedestal channels inside the CARE FPGA – Keep only the average – Is it safe enough? R. Fantechi

Few numbers Assumptions – Conservatively, 16 bytes for one NZs channel and 4 bytes for channels below my threshold – Add 8 bytes header for each CARE output link (16 channels) NZS event – 224 CPD*64ch* *4*8 = bytes ZS event (N th = events above threshold) – (224*64 – N th )*4 + N th * *4*8 = (N th =500) – A factor 3 reduction Can be improved a little – But being safe has a price R. Fantechi

Conclusions There is a first baseline concept for the LKr readout – Based on CARE – Simplifies network structure reading events only at L1 with a rate of O(20 Khz) Many questions to the TDAQ community – L1 and L2 rates – Capability of local/global L1 to reduce the rate – Possibility/efficiency to do L2 with LKr trigger data – Zero suppression: a safe one is accepted? Could lead to i.e. a factor 3 reduction already at the output of the CARE module