FELIX: Strips Requirements Matt Warren (Bruce Gallop, Peter Phillips,

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

Introduction FELIX connects multiple Staves and Petals to counting room systems - We expect about 16 FE GBT links per FELIX FELIX is essentially a media converter and data router: - Converts GBT e-links into Ethernet 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 L1Track some data can be forwarded using repurposed GBT links Good technical talk from Lorne here: https://indico.cern.ch/event/289737/session/25/contribution/115/material/slides/ 9/09/2014 FELIX Requirements 2

Requirements (Uplink) – L1Track/DCS L1Track: FELIX needs to transfer FE data direct to L1Track fast - Dedicated links on FELIX For L0 rate readout: - (a copy of) ALL data ends up in L1Track For R3/L1: - only R3-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 - Using a separate physical port? Or over the readout network 9/09/2014 FELIX Requirements 3

Requirements (Downlink) – TTC The FELIX needs to forward and encode signals for the FE - These travel on 80Mb e-links via GBT - 2 40Mb signal lines are time-multiplexed onto an 80Mb e-link L0/Command and L1/R3 - L0 is broadcast, synchronous - needs deterministic latency - L1 is broadcast, asynchronous - COM can be broadcast or for a given GBT, asynchronous - R3 is unique to each link FELIX will receive TTC signals various sources: - upstream TTC, probably via a single GBT possibly local inputs Internal generators configured using the FELIX control network Sometimes signals will need to be loaded into FELIX, and then issued synchronous on e.g. the next BCR, ECR, L1 or an internal command 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 8B/10B, 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 64b packets this adds enormous overhead, and not efficient - 64b with 8b/10b 80b, add SOP and EOP 100b 50% higher BW It followed we need a special ITk custom decoder - Not the FELIX way BUT now Strips we have a new proposal for a much longer packet (see Session 5 this morning) – does this fit better? 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 12b strip address 3b adj-hit-map 15b 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 9/09/2014 Description Header/Trailer Type L0ID BCID Cluster count (len) Parity/ECC Clusters (15b x 13) TOTAL (Barrel) End-Caps FELIX Requirements 7

Uplink Options With 250b Packets We need a robust way send our data - Sufficiently robust packet detection and recovery from errors 8B/10B – 25% increase in BW - Could help (locked/synchronised link) - But we still need to recover from corrupted SOP 64B/67B? – 57% increase BW(!) - Syncing large frames wasteful (34b/packet!) - Could work async of frame boundary, but then no SOP [Note this uses scrambling, which we might use anyway, regardless of format] Long header/trailer with separators – 8% increase BW - “1101” header, 16 zero trailer outlaw 16 zeros inside packet 20b overhead 9/09/2014 FELIX Requirements 8

Discussion points 9/09/2014 FELIX Requirements 9