FELIX Strips Requirements Matt Warren Bruce Gallop Peter

FELIX: Strips Requirements Matt Warren (Bruce Gallop, Peter Phillips, Marcel Stanitzki, Tony Weidberg) 9 Sept 2014 9/09/2014 FELIX Requirements

Introduction • FELIX connects multiple Staves and Petals to counting room systems over GBT links – We expect about 16 FE GBT links per FELIX • FELIX is essentially a media converter and data router: – Converts GBT e-links into Ethernet (or Infiniband) packets – Directs data of different types to different destinations • In the opposite direction (downlink, to FE), it is more of a fanout – Receives TTC, fans-out and forwards to the FE • For L 1 Track some data can be forwarded using repurposed GBT links 9/09/2014 FELIX Requirements 2

Requirements (Uplink) – L 1 Track/DCS L 1 Track: • FELIX needs to transfer FE data direct to L 1 Track fast – Dedicated links on FELIX • For L 0 rate readout: – (a copy of) ALL data ends up in L 1 Track • For R 3/L 1: – only R 3 -data needs to get to the track-finder – Needs fast extraction, or maybe ALL data is sent anyway • Data needs to be moved with low latency – But not fixed-latency – Can be aggregated onto faster links DCS: • Monitoring data needs to be separated and sent to DCS FELIX Requirements 9/09/2014 3

Requirements (Downlink) – TTC • The FELIX needs to forward and encode signals for the FE – These travel on 80 Mb e-links via GBT – 2 40 Mb signal lines are time-multiplexed onto an 80 Mb e-link L 0/Command L 1/R 3: • L 0 is broadcast, synchronous - needs deterministic latency • L 1 is broadcast, asynchronous • COM can be broadcast or for a given GBT, asynchronous • R 3 is unique to each link – Need complete manual control of these signals from local DAQ • Stand-alone, “desktop” operation • FELIX will receive TTC signals from various sources: – upstream TTC, probably via a single GBT – possibly local inputs – Internal generators configured using the FELIX control network 9/09/2014 FELIX Requirements 4

FELIX Uplink Data Handling • GBT links are expanded into component e-links • Data on each e-link is deserialised and packets detected • Ideally the e-link is encoded using 8 B/10 B, and start-of -packet (SOP) and end-of-packet (EOP) symbols are used. • The packet type (aka destination) is encoded after the SOP symbol to allow for routing while receiving • With our 64 b packets this adds enormous overhead, and not efficient – 64 b with 8 b/10 b = 80 b, add SOP and EOP = 100 b = 50% higher BW • It followed we need a special ITk custom decoder 9/09/2014 FELIX Requirements 5

FELIX Packet Formats (from FELIX docs) 9/09/2014 FELIX Requirements 6

Strips Updated Data Format • For inner barrel hybrid: 12. 5 clusters per event = 13 - Where cluster = Strip number + bitmap of 3 adjacent strips • Each cluster is 12 b strip address + 3 b adj-hit-map = 15 b • Note: Wide spread of number of clusters per event - Fixed length packets not efficient • HCC packet data: Bits 3 5 8 8 6 8 195 233 ~263 Description Header/Trailer Type L 0 ID BCID Cluster count (len) Parity/ECC Clusters (15 b x 13) TOTAL (Barrel) End-Caps 9/09/2014 FELIX Requirements 7

Uplink Options With 250 b Packets • We need a robust way send our data – Reliable packet detection and recovery from errors Options (non exhaustive): • 8 B/10 B – 25% increase in BW – Could help (locked/synchronised link) – But we still need to recover from corrupted SOP • 64 B/67 B – 57% increase BW(!) – Syncing large frames wasteful (34 b/packet!) – Could work async of frame boundary, but then no SOP • Long header/trailer with predictable format – 8% increase BW – “ 1101” header, 16 zero trailer + outlaw 16 zeros inside packet = 20 b overhead FELIX Requirements 9/09/2014 8

Conclusion/Discussion points • Use header/trailer instead of 8 B/10 B – 8 B/10 B does not increase reliability, but consumes BW • Can we do calibrations with FELIX – We think yes, using bursts of 40 -80 triggers • A copy of the draft requiments document is attached to the agenda FELIX Requirements 9/09/2014 9