1 / 9

FELIX: Strips Requirements

FELIX: Strips Requirements. Matt Warren (Bruce Gallop, Peter Phillips, Marcel Stanitzki, Tony Weidberg) 9 Sept 2014. Introduction. FELIX connects multiple Staves and Petals to counting room systems over GBT links We expect about 16 FE GBT links per FELIX

danford
Download Presentation

FELIX: Strips Requirements

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. FELIX: Strips Requirements Matt Warren (Bruce Gallop, Peter Phillips, Marcel Stanitzki, Tony Weidberg) 9 Sept 2014

  2. 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 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/

  3. FELIX Requirements 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

  4. FELIX Requirements 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 • 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 • Local signal generate, with synchronised sending • Loaded into FELIX, and then issued on next ECR, L1, command etc.

  5. FELIX Requirements 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?

  6. FELIX Requirements FELIX Packet Formats (from FELIX docs)

  7. 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: FELIX Requirements

  8. FELIX Requirements Uplink Options With 250b Packets • We need a robust way send our data • Reliable packet detection and recovery from errors Options (non exhaustive): • 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 • Long header/trailer with predictable format – 8% increase BW • “1101” header, 16 zero trailer + outlaw 16 zeros inside packet = 20b overhead • Fits with 320Mb/s hybrid links on stave • Scrambling of link may be required

  9. FELIX Requirements Conclusion/Discussion points • Use header/trailer instead of 8B/10B • 8B/10B 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

More Related