1 / 14

10 December 2013

Integrating Timepix (3) Szymon Kulis , Mathieu Benoit, Bas van der Heijden , Frans Schreuder , Henk Boterenbrood , MvB and the Timepix3 designers Xavi Llopart , Tuomas Poikela , Vladimir Gromov , Francesco Zappon Massimiliano de Gaspari and others. 10 December 2013.

muniya
Download Presentation

10 December 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Integrating Timepix(3)SzymonKulis, Mathieu Benoit, Bas van der Heijden, FransSchreuder, HenkBoterenbrood, MvBand the Timepix3 designersXaviLlopart, TuomasPoikela, Vladimir Gromov, Francesco ZapponMassimiliano de Gaspariand others 10 December 2013

  2. Timepix versus Timepix3 Martin van Beuzekom

  3. Timepix integration in common DAQ • Detailed talk given by Mathieu Benoit in WP9.3 meeting on Nov. 21 • Lots of info in that talk, will not repeat it here. Please look at https://indico.desy.de/conferenceDisplay.py?confId=8849 • Main bottle-neck: Timepix is either in acquisition mode, or in readout mode • Readout time of 8 (or more) ms per frame -> long dead time • Operation of FitPix and Relaxd is similar Martin van Beuzekom

  4. Our (Nikhef/LHCb) focus is on Timepix3 • In view of the LHCbVeloPix developments (ASIC submission aimed for Q3 2014) • VeloPix which has to cope with 600 Mhits/s • But we also have a complete and working Timepix/Relaxd telescope Martin van Beuzekom

  5. SPIDR Speedy PIxelDetector Readout Readout system for Timepix3 and MPX3.1/RX over 10 Gb or 1 Gb Ethernet Martin van Beuzekom

  6. SPIDR • Firmware properties: • Vendor independent and highly configurable • 1 Timepix3 at full (80 Mhits/s) speed, or multiple Timepix3 chips at lower speed • LFSR lookup tables in FPGA • Pixel data over UDP/IP, slow control over TCP/IP • Currently running on a development system (Xilinx VC707) • Multiple setups running at Nikhef and CERN • Development of Compact SPIDR ongoing (but at a slower pace) +/- 400V Bias supply I2C FMC SFP+ cage 1G/10G PHY FGPA USB DC/DC 1V2 DC/DC 1V5 DC/DC 2V5 12V Trigger/busy Ext bias Expansion header Martin van Beuzekom

  7. Multiple TPX3 hardware configurations (Thanks to Jerome Alozy) Nikhef Chipboard Nikhef Chipboard Nikhef Chipboard CernChipboard CernChipboard FMC extender cable 50cm FMC extender cable 50cm FMC extender cable 50cm FMC 2 VHDCI Xilinx VC707 development board Nikhef Compact readout Nikhef Compact readout FitPix Martin van Beuzekom

  8. Data acquisition • To run at high speed, each SPIDR needs its own DAQ PC • A single timepix3 at max. speed produces 5.12 Gbits/s • Including the extended time-stamp and overhead this fills ~70% of a 10 GbE link • Data is streamed to disk, without looking at the data • Not possible to evaluate each packet at maximum speed • Separate monitoring stream which samples (copies) the main data stream • DAQ Format: header of several kBytes (settings etc. ) followed by a stream of pixel packets, 8 bytes each • Header format not yet frozen • No trigger/event number or alike • Pixels packets are unique by their time-stamp • Synchronisation and checking of different SPIDR data streams is important Martin van Beuzekom

  9. Data acquisition II • However 26 seconds is too short for a normal run • Timepix3 has an internal 48 bit counter, which is reset with the T0-sync • resolution 25 ns, range 81.44 days • This timer can be read on request, and has unique packet header • -> timer data will end up in the data-stream • Hence to cover a larger time range, the (Leon) processor in the SPIDR FPGA will request readout of this timer every second. 15 0 19 16 20 43 44 29 30 60 63 59 hdr 4b PixAddr 16b ToA 14b ToT 10b FTOA 4b SPIDR time 16b time stamp 30 bits, 25ns resolution + 4 bits, 1.56 ns resolution range: 26.844 sec 33 17 18 0 4 3 SPIDR time 16b FTOA 4b ToA 14b Martin van Beuzekom

  10. Running with multiple SPIDRs • Required TLU functionality can be very basic • Provide clock, shutter, T0-sync and combine busy signals (OR) • Somewhat more advanced functionality required for high speed monitoring (next slides) repeater repeater SPIDR SPIDR SPIDR busy TLU clock, T0-sync, shutter Martin van Beuzekom

  11. Interface to TLU, sync time-stamp • Synchronising time-stamps • Disable shutter • Send T0-sync, min. 25 ns • Enable shutter shutter (ext) tpx3-reset (int, optional) 25 ns (or more) T0-sync (ext) > 1.6 us > 25 ns time-stamp n 0 1 2 7 8 n-1 n-2 3 6 5 4 data-out w.o reset no data packets data-out with reset no data packets Martin van Beuzekom

  12. TLU interface, Busy • Data flow is controlled/halted via shutter/busy mechanism • Busy is tied to ‘almost full flag’ of SPIDR ethernet buffer • DAQ PC signals busy/overflow by sending pause-frames to SPIDR • -> SPIDR buffers fill up, leading to the SPIDR pulling the busy • In addition DAQ PC can send a ‘halt’ command to Leon processor • This will pull also pull the busy line • Will be implemented soon shutter (ext-in) busy-0 (out) busy-1 (out) no data packets data-out0 no data packets data-out1 Martin van Beuzekom

  13. Monitoring of data streams • Monitoring of data streams by copying a fraction of the data • Send data to a dedicated monitoring/slow control PC • Two sampling methods • Software sampling • Each DAQ PC takes a snapshot at a given time (CPU timer triggered, or via run control?) • However DAQ streams are not synchronised • -> need a large snapshot to guarantee overlap between streams • Hardware sampling • Dedicated ethernet packets (different destination IP address, and/or port number) are generated by SPIDR • Copies data from a range of timestamps to this dedicated monitoring packet • Start of monitoring sample could be controlled by TLU • Length of monitoring sample defined by SPIDR setting • This is foreseen, but not yet implemented Martin van Beuzekom

  14. Summary & Plans • Development of Timepix3 readout is actively ongoing (Nikhef + CERN) • But building a high speed readout is not trivial (so we have to be patient) • We (LHCb) are building a high speed Timepix3 telescope • Timepix3 is good exercise for VeloPix which produces 8x more hits/tracks • VeloPix has to be submitted Q3 next year • Integrating Timepix3 into an AIDA telescope seems simpler than integrating Timepix • Matching of data from different SPIDR streams using time-stamps • Checking of synchronicity is key • Separate monitoring data stream Martin van Beuzekom

More Related