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 delivery11 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)

01010100010111010101100100010101TDC number & board (4x4)

TDC windowsThe 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 takenSEARCHING 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-errorIn 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

PGTELL-1

TDCB

LTU

TDCB

TDCB

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-errorAfter 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 12.825µ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-errorIn 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 testsAfter fixing all the problems, some first rate tests were

performed:RATE ELEMENT EVENTS LOSSES

80 KHz 1 channel 0,5 M NONE

625 KHz 8 ch(L1 group) 0,5 M NONE

1,25 MHz 8 ch(L1 group) 0,5 M NONE

2,5 MHz 8 ch(L1 group) 0,5 M NONE

•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 SOONCROSS-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