Muon Electronic Upgrade

1. Muon Electronic Upgrade Data Format

2. 32 bits nODE Architecture: remarks • Six 32 input channels nSYNC for each nODE • Three nSYNC per GBT • LLT implemented in the same AMC40 receiving Trigger data • Trigger Links mapping optimized for LLT algorithm • 2 GBT link for Hit data • These data are also used by LLT, they cannot be ZS • The frame will be always 96 bits wide, also if some bits will be meaningless • To write these data on disk we need a max bandwidth of about 85 Gbit/s from AMC40 to FARM • 2 GBT link for TDC data • These data are always ZS, but without the geographical address • To decode these data, we need to crosscheck with the Hit data, containing the geographical address • The frame will be always 96 bits wide, also if some bits will be meaningless • To write these data on disk we need a max bandwidth of about 85 Gbit/s from AMC40 to FARM • GBT frame = Wide bus: 112 bits, 16 for HEADER and 96 for DATA • Data framing: Fixed packing S. Cadeddu - INFN Cagliari

3. 32 bits nODE Architecture: mapping • Data framing: Fixed packaging, same scheme for both hits/TDC data link. nSYNC 3 nSYNC 2 nSYNC 1 SLOT 3 SLOT 2 SLOT 1 HEADER 32 bits 32 bits 32 bits 16 bits GBT Frame width = 112 bits S. Cadeddu - INFN Cagliari

4. 32 bits nODE Architecture • Data Format • Fixed packaging • Header 16 bits • GBT width : 112 bits • Error detection/recovery: no • NZS possible: The hit data are already NZS and they cannot be ZS (they are used for LLT). The TDC data are always ZS and cannot be NZS • Are data time-ordered by BXID? Yes • Data format compliant with he specs? Yes • Sync command integration and sync-frame definition: Yes • Header only command: No • What is the data latency? Fixed • Will the front-end transmit frames containing non-valid data that can be ignored by TELL40 ? No • What special running modes are required? To be studied/defined • Estimated bandwidth (how many AMC40 and inputs links by AMC40): • 16 AMC40 for Hit data, with number of links per AMC40 varying from 22 to 12, each link carrying 96 bits. • 16 AMC40 for TDC data, with number of links per AMC40 varying from 22 to 12 , each link carrying 96 bits. S. Cadeddu - INFN Cagliari

5. Alternative plans Following the review outcome, and considering the limitation of the present architecture, we are working on alternative design. • Leave the links as they are and include in the nODE a concentrator taking the data from the 3 nSYNC and interfacing with the GBT. • Leave the links as they are and add some info (like “sub-headers”) in the header and make some ZS in the TELL40 • Change the Architecture using a nSYNC chip with 48 input channel. • Each nSYNC interfaced with one GBT. • No more splitting the information in two different link, but each link contains hit+tdc related data • Frame length variable • Both ZS and NZS possible • If still necessary to send data to LLT, we could add an extra link each two nSYNC transmitting a fixed width frame with just hits info used only by LLT. In this case the frame will be “hardware” organized like in the previous case with three nSYNC, in this case with only two chip per link. This last alternative seems to be the most reasonable, we are studying it in more details S. Cadeddu - INFN Cagliari

6. 48 bits nODE Architecture • Data Format • Dynamic packaging • Header 16 bits • GBT width : 112 bits • Error detection/recovery: Possible • NZS possible: Yes • Are data time-ordered by BXID? Yes • Data format compliant with he specs? Yes • Sync command integration and sync-frame definition: Yes • Header only command: Yes • What is the data latency? Variable due to the dynamic packaging • Will the front-end transmit frames containing non-valid data that can be ignored by TELL40 ? No • What special running modes are required? To be studied/defined • Estimated bandwidth (how many AMC40 and inputs links by AMC40): • 16 AMC40, 17 links per AMC40, each link carrying 96 bits max (depending on ZS/Occupancy), max bandwidth of 65 Gbit/s. S. Cadeddu - INFN Cagliari