TDCB Status report Bruno Angelucci, Stefano Venditti NA62 meeting, 14/12/2011

Outline Delivery of 11 TDCBs (last meeting) Firmware improvements TDC windows: a non-problem solved First tests on rates and cross-talk Future plans

TDCBs delivery 11 TDCBs delivered to all groups who requested them Mounting problems on theTDCBs: 1. One board’s RAM mounted upside-down (back to the firm) 2.Glue on one board’s PP connector (scratched away) 3.Some components added (connectors, pins, resistances) Firmware tested step-by-step (TDC-TDCB-PP exchange tokens, words losses patched) and installed on each of the TDCBs TDCB manual updated: several points made clearer, many mistakes corrected VHDL/Tell1/TDCB startup session at CERN with at least one person from each interested group (18/10/2011)

Firmware improvements The first issue addressed after the last meeting was the long-time “recompiling” problem (unstable firmware after recompilation, loss of words and/or tokens). The problem has (probably) been traced back to some signals used in the TDCB logic, whose clock was that from the TDCs. Firmware recompiling was always successful since these corrections were introduced not a proof, but a strong hint! FIRMWARE CONVERSION TO MENTOR HDL DESIGNER TDCB firmware conversion from Quartus II to Mentor started by Marco several blocks made clearer/less cumbersome the conversion is almost completed, the “new” firmware will be tested in the next weeks

1 TDCB → 4 TDCs → 128 channels TDCs output: leading and trailing words (info on TDC index, channel number, time measurement at ~100 ps resolution) Words go into a 4 word-deep derandomizer, then in a 256 word deep L1 buffer (through a round-robin of the 8 ch. group) Events from the 4 L1 buffers are passed to the readout FIFO TDC & TDCB functioning TDCBs get words from TDCs end delivers them to PPs through a token exchange mechanism (no hand-shaking) A time-stamp (rollover ~107 s) and a word counter (# lead +# trail +time-stamp) are attached to the bunch received from one TDC following one trigger event time (19 bit) TDC channel(32)ld/tr. (0x4/5) TDC number & board (4x4)

TDC windows The second issue addressed is the optimal configuration for the TDC time windows (set through the TDC configuration string) TRIGGER OFFSET (TROFF): trigger latency for each incoming trigger REJECT OFFSET (REJOF): reject latency for each incoming trigger MATCHING WINDOW(MAWIN): time interval in which words are taken SEARCHING WINDOW(SEWIN):time interval in which words are searched time interval are in 25ns steps MAWIN= N = (N+1) x 25 ns REJOF at least 1 c.c. > TROFF SEWIN at least 8 c.c. > MAWIN When running in trigger mode the matching windows MUST cover all the acquisition time (and possibly avoid repetitions)

Anatomy of a non-error In order to look for possible data loss we set the acquisition system as follow: 12.8 µs cyclic pattern from pattern generator, 1 LVDS 25 ns signal/channel, 32 channels fired; Trigger to TELL1 sent by the pattern generator itself at the end of the pattern, using the TRIGOUT port PG TELL-1 TDCB LTU TDCB TRIGGER 32 CH. PATTERN The idea was to have a whole pattern from the PG in each TDCB trigger, making the search for possible data loss easier. TDC windows settings: TROFF: 0xE00 (-12.8µs) REJOF: 0xDF0 (-13,05µs) MAWIN: 0x1FF (12.775µs) SEWIN: 0x209 (13.025µs) ETHERNET

Anatomy of a non-error After collecting ~1M data, about 0.1 % events with 1 missing leading/trailing were observed. POSSIBLE EXPLANATION: a “blind space” between two contiguous windows If so, increasing the TROFF and/or MAWIN windows should lead to an inclusion of all words in the packet (and several repetitions, curable via software). A simple C++ program was written to eliminate repetitions in contiguous events, and several ~1M event packets were collected varying the windows (TROFF up to -13µs, MAWIN up to µs) However once the repetitions were eliminated the same percentage of missing leading/trailings came out Moreover the packets sent by the ethernet ports were not time-ordered: this caused mixing between different packets and further confusion. SOLUTION: only 1 ethernet used for the tests (SL register modified)

Anatomy of a non-error In the end the “non-problem” was spotted to be due to the slightly different duration of the PG pattern wrt the TDC matching window: 1 “loss” Right # events 12,8 µs 12,8+ε µs ONLY the number of total words compared to the number of triggers should be considered, disregarding the number of words in the single packet. Sending the TELL1 clock to the PG would allow for a pattern lasting exactly like the TDC window, but we didn’t manage to do this so far.

First rate tests After fixing all the problems, some first rate tests were performed: RATEELEMENTEVENTSLOSSES 80 KHz1 channel0,5 MNONE 625 KHz8 ch(L1 group)0,5 MNONE 1,25 MHz8 ch(L1 group)0,5 MNONE 2,5 MHz8 ch(L1 group)0,5 MNONE Data collected using an internal trigger for the TELL1 (rather than sending it from the PG) and sending a known number of events from the PG; At higher rates the use of 1 ethernet cable only limits the output MORE RATE TESTS SOON CROSS-TALK: one single channel was pulsed at 80 KHz and masked in the acquisition. No signals in the other TDC channels after ~2h datataking MORE CROSS-TALK TESTS SOON

Conclusions and outlook The acquisition system is ready to perform systematic tests of rates and cross-talk, to be presented during the next meeting Each group is invited to ask for specific tests in case of need The firmware transposition to HDL Designer will be finalized as soon as possible

Spare slide: PP & SL dataflow