1. NA 62 TTC partition timing T.Blažek, V.Černý, R.Lietava, M.Kovaľ, M.Krivda Bratislava, Birmingham We are developing procedures for timing parameter adjustment in TTC partitions (LTU & TTCex) However, it has some relation and consequences for other people’s work down the clock/trigger distribution chain, so this should be discussed as well We are preparing a full size document to be found on NA62 Twiki https://twiki.cern.ch/twiki/bin/view/NA62/LTUrelatedSoftware https://twiki.cern.ch/twiki/bin/view/NA62/LTUrelatedSoftware 1

2. Timing (delay) parameters categories: need adjustment (tuning) need measurement (calibration) need neither adjustment nor measurement All timing (delay) parameters are required to be stable and invariant to system restarts Digital equipment with synchronized information exchange 2

3. Timing (delay) parameters categories: need adjustment (tuning) need measurement (calibration) need neither adjustment nor measurement All timing (delay) parameters are required to be stable and invariant to system restarts Digital equipment with synchronized information exchange phase adjustment between L0 processor and LTU measurement of event signal delay between subdetectors delay of trigger bit propagation between the L0 processor and a subdetector Examples in NA62 3

4. Timing (delay) parameters categories: need adjustment (tuning) need measurement (calibration) need neither adjustment nor measurement All timing (delay) parameters are required to be stable and invariant to system restarts Digital equipment with synchronized information exchange phase adjustment between L0 processor and LTU 4

5. Phase adjustment - general A B incoming signal internal B clock resampled signal delay Δ adjusted to take sample in stable region of the input signal by delay of output in A by delay of clock in B 5

6. NA62 TTC 6

7. Phase adjustment points for synchronized communication 1 2 Adjust delay of LTU clock Adjust delay of LTU output No adjustment needed 7

8. Phase adjustment points for synchronized communication 1 2 Adjust delay of LTU clock Adjust delay of LTU output No adjustment needed 8

9. Phase adjustment points for synchronized communication 1 2 Adjust delay of LTU clock Adjust delay of LTU output No adjustment needed LTU firmware and software support ready To be tested during the dry run Needs cooperation of the L0 processor Details at NA62 Twiki https://twiki.cern.ch/twiki/bin/view/NA62/ LTUrelatedSoftware 9

10. Requirements L0P – LTU cooperation for phase adjustment L0 processor (L0P) feeds 12 LTU’s with signals relevant for synchronized transfer L0 L0DATA[0..5] Requirements L0 and L0DATA have to be in phase (same timing) distribution to 12 LTU’s either via fan-out board (to be constructed) or via daisy-chain LVDS (no need of synchronous arrival of the L0 signals at different LTU’s) L0P has to provide 20 MHz calibration signal to L0 and L0DATA connector for phase adjustment procedure. This calibration signal has to have the same phase (with respect to the L0P clock) as the live L0, L0DATA signals https://twiki.cern.ch/twiki/bin/view/NA62/LTUrelatedSoftware 10

11. Phase adjustment points for synchronized communication 1 2 Adjust delay of LTU clock Adjust delay of LTU output No adjustment needed 11

12. Why no phase adjustment needed Data come together with the clock superimposed (coded) onto the clock signal, therefore with well defined phase relation (locked) with the clock 12

13. Timing (delay) parameters categories: need adjustment (tuning) need measurement (calibration) need neither adjustment nor measurement All timing (delay) parameters are required to be stable and invariant to system restarts Digital equipment with synchronized information exchange measurement of event signal delay between subdetectors 13

14. beamAB event (TSAI,FTAI)event (TSBI,FTBI) Subdetector: time stamp TS (25 ns clock), fine time FT (100 ps clock) event: (TS,FT) or ID = TS*256 + FT Δ AB = (TSBI*256+FTBI) – (TSAI*256+FTAI) Δ AB is measured and announced to everybody in the chain Note: Δ AB includes effects of different optical fibre lengths to A and B! (it is not just physical time difference between event registrations in A and B) subdetector A is preferential defining the unique event identifier (TSref,FTref) ≡ (TSA, FTA) subdetector B can recalculate its event id (TSB,FTB) into unique event id TSref = ((TSB*256+FTB) - Δ AB )/256; FTref = = ((TSB*256+FTB) - Δ AB ) mod 256 14

15. beamAB event (TSAI,FTAI)event (TSBI,FTBI) Subdetector: time stamp TS (25 ns clock), fine time FT (100 ps clock) event: (TS,FT) or ID = TS*256 + FT delay Δ AB Δ AB = (TSBI*256+FTBI) – (TSAI*256+FTAI) Δ AB is measured and announced to everybody in the chain subdetector A is preferential defining the unique event identifier (TSref,FTref) ≡ (TSA, FTA) subdetector B can recalculate its event id (TSB,FTB) into unique event id TSref = ((TSB*256+FTB) - Δ AB )/256; FTref = = ((TSB*256+FTB) - Δ AB ) mod 256 Δ AB has to be stable invariant to system restart 15

16. Δ AB has to be stable invariant to system restart Standardized clock counter resetting procedure L0 processor decides to reset the TS clock counter resets its TS clock counter to 0 in the very same time sends trigger bit via A channel with accompanying B-channel message “reset TS counter" the A-bit arrives to a subdetector after some (UNKNOWN) delay in the very same time when the A-bit arrives the subdetector resets its TS clock counter to 0 as well as FT counter to 0 From then on, each time some A-bit arrives to the subdetector when its clock reading is TS the subdetector knows that the L0 processor decided to send this A-bit in the time when the L0 processor’s clock counter reading was the same value TS 16

17. Timing (delay) parameters categories: need adjustment (tuning) need measurement (calibration) need neither adjustment nor measurement All timing (delay) parameters are required to be stable and invariant to system restarts Digital equipment with synchronized information exchange delay of trigger bit propagation between the L0 processor and a subdetector So now we understand why 17

18. How the L0 processor operates gathers trigger primitives from subdetectors each labeled by unique event id (TSref, FTref) makes the decision to accept the event (TSref, FTref) calculates the value T0send = TSref + Toffset where Toffset is arbitrary chosen but fixed value (and known to everybody) puts a corresponding B-message to output buffer in the very moment when the L0 processor clock reading is equal to T0send it sends in parallel the A-bit as (L0 signal) and B-message (as L0DATA[0..5] signal) to LTU’s which transfer it to TTCex and via optical fibres to subdetectors How subdetectors operate when the A-bit arrives when the subdetector’s clock reading is TS, it knows that the bit was sent by L0P when its clock has shown the same value T0send = TS the subdetector calculates the event time stamp as TSref = TS - Toffset 18

19. Requirements L0P – LTU cooperation for phase adjustment L0 processor (L0P) feeds 12 LTU’s with signals relevant for synchronized transfer L0 L0DATA[0..5] Requirements L0 and L0DATA have to be in phase (same timing) distribution to 12 LTU’s either via fan-out board (to be constructed) or via daisy-chain LVDS (no need of synchronous arrival of the L0 signals at different LTU’s) L0P has to provide 20 MHz calibration signal to L0 and L0DATA connector for phase adjustment procedure. This calibration signal has to have the same phase (with respect to the L0P clock) as the live L0, L0DATA signals signals to be sent wait in the output registers waiting for chosen sending time T0send and at that very moment are sent without any further processing to LTU 19

20. We have grossly sketched a possible scheme of synchronous communication protocol just to have something specific in mind when preparing the software/firmware for TTC partition. It, however, does not mean that this is the specification of the protocol. There are, for sure, technical subtleties which we are even not aware of. We would appreciate, to have a detailed specification (at least the first iteration of a document) of the protocol for synchronous TTC communication in order not to be surprised during the dry/technical run for need of firmware/software support for something we did not think about. There is one particular topics we did not touch: the delay parameters in the rx chip. As far as we understand it, these parameters concern the interface between the rx chip and the electronics in the front-end, not the trigger/clock distribution down the optical fibre. The rx-chip initialization can be fully done locally via i2c but partly (including the delay parameters) also through long B-messages via TTC optical line, that is from LTU in the Standalone mode. If this needs to be supported, we should know about that! Other comments 20

21. Dry run tests detector operation in Standalone mode L0P – LTU synchronization (we expect some test to be done even before the dry run in the lab) event ID tests (in Global mode) - sending resets from L0P to FE - sending random triggers from L0P to FE - detector reading of B-messages - checking consistency of (TS,FT) event identification 21

22. 22

23. 23

24. 24