130 likes | 267 Views
TEL62 status. Bruno Angelucci INFN & University of Pisa NA62 TDAQ WG meeting – CERN, 10/10/2012. Outline. Hardware status Firmware status Post dry run tests Towards the technical run. Hardware status boards location. 7 TEL62 at CERN ECN3 ( CEDAR, CHANTI, LAV1, LAV2, CHOD, MUV2, MUV3 )
E N D
TEL62 status Bruno Angelucci INFN & University of Pisa NA62 TDAQ WG meeting – CERN, 10/10/2012
Outline • Hardware status • Firmware status • Post dry run tests • Towards the technical run
Hardware statusboards location • 7 TEL62 at CERN ECN3 (CEDAR, CHANTI, LAV1, LAV2, CHOD, MUV2, MUV3) • 2 TEL62 prototypes in Pisa for firmware development • 1 TEL62 in Frascati (LAV3) • 1 TEL62 in Roma TV (LKR/L0) • 5 damaged TEL62 in Pisa (3 back from ARTEL, 2 from dry run)
Hardware statusbroken boards • 3 boards back from mounting firm after reflow: • TEL62-4: PP2 was not working, same situation after reflow • TEL62-6: PP0 was not working, some improvement after reflow (jtag ok), but not fully repaired • TEL62-12: PP1 and PP2 badly working (DDR and DC communication), worse situation after reflow (even jtag no more working) • Next possibility could be the reballing of the damaged FPGAs, will be tried during next weeks for one board.
Hardware statusbroken boards • 2 boards damaged during dry run: • TEL62-7: CCPC not working, discovered a broken line in an inner layer and repaired; DDR0 not working and RED led on PP0 broken (not understood) • TEL62-9: DDR0 not working (maybe same as before); PP3 badly working, with reduced functionality (maybe due to short circuit in specific part of the FPGA, to be better understood) • Franco and Elena are this week in Roma TV for the development of the boards testing tools, that will be firstly tried on one of this two boards (together with a good one) to find the real cause of these problems.
TEL62 firmware - PP small changes after dry run
TEL62 firmware – SL data small changes after dry run
TEL62 firmware – SL trig (new) new firmware blocks after dry run
TEL62 tests • Using a setup with LTU board in standalone mode we are able to reproduce the TTC inputs for the TEL62: • sent periodic “special” triggers (synchronization) with frequency up to 1MHz: seen limitations from the PC side at 250Mbit/s to be better understood (should be 1Gbit/s): next tests using MEP factor > 1 • tested the run/burst structure inside the firmware, with SOB/EOB signals and triggers … SOB EOB … …… Start RUN End RUN … EOB trigger SOB trigger
TEL62 tests • Using the pattern generator inputs to one TDC in a TDCB we can test physics triggers: • checked that data are correctly written in DDR2 (using ECS access) • measurement of offset between LTU and TEL62, taking latency into account • single packets (and then a fixed low number) correctly seen coming out from GBE, with a periodic frequency up to 1 MHz data from PG to TDC 1µs latency 100µs trigger form PG to LTU 1µs
TEL62 tests • Further tests of physics triggers, emulating a real situation: • sent a continuous flow of data (up to 1M triggers) • data are correctly received with frequency up to 200kHz (at 1 MHz an optimization of DDR2 write and read accesses is needed for the future) data from PG to TDC 1µs trigger form PG to LTU 1µs latency100µs
TEL62 tests • New tests at CERN using TALK-LTU-TEL62: • new firmware uploaded on all boards but CEDAR • synchronization ok between TALK and boards • synchro packets correctly sent to farm • simulated data correctly written into DDR2: seen firstly using ECS debug inside SL buffers physics packets correctly sent to farm • offset between pulses from TDCB and data arrival has been measured
Towards the technical run • Hardware: • reballing of the chip for one board • development of testing tool for complete check of boards • Firmware: • logic utilization: PP~50% (no SD specific part), SL~20% • “stretching” of logic used by monitoring inside the PP as with the SD part usage (80%) is more than recommended • complete corrections to data format (physics triggers) • complete the primitive sending part inside the SL • possible linking of choke and error signal inside firmware • Test: • complete pulser data sending to pc farm • do a continuous and stressing test with the TALK-LTU-TEL62, searching for other (minor) bugs in the firmware • interactions with run control