Post on 22-Feb-2016
description
Ken Wyllie 1
LHCb Electronics Brainstorm
24th February 2009
Ken Wyllie 24th February 20092
Summary of ROUGH link estimate from sub-dets
Non zero-supp NZS Zero supp ZSSubdet # GBT @ 3.2 Gbit/s # GBT @ 3.2 Gbit/sVelo 8652 1176ST 31200 1200OT 6500 3500RICH 6292 1736Calo 1920 750Muon - -Total 54,564 8,362
Assuming “300 CHF per link”Cost CHF 16.5 MCHF 2.5 MCHF
Rough estimate for optical links in existing LHCb = 1.1 MCHF
Ken Wyllie 24th February 20093
Architecture with ZS
hardwaretrigger
Triggersuperviser
Data
HLT++
hardwaretrigger
Triggersuperviser
Data
HLT++
Ken Wyllie 24th February 20094
FE derandomising bufferAbsorb statistical fluctuations in dataNeeds careful monitoringNeeds careful simulation
BE input bufferLength = trigger latency+ margin for derandomiser
BE trigger bufferSmall, re-ordering?
BE output bufferDepends on output protocoleg MEP factor?
Buffering with ZSTriggering = BX correspondence
Ken Wyllie 24th February 20095
Data Structure from front-end
Define maximumlag between Bx andtransmission time.if exceeded, Þ start truncating
Ken Wyllie 24th February 20096
Modularity – something to think about . . . .Example:
Ken Wyllie 24th February 20097
Thoughts & Discussion
Clear cost saving in links by zero-suppressing in the front-ends-----------------------------------------------------------------------------------Need to implement front-end buffers after ZS
- carefully monitor event size and time lagEvent-sizes & statistical fluctuations have to be well understoodAdditional bandwidth overhead with ZS on front-end
- transmit BX (12 bits?)- transmit buffer status
Programmable devices would be very useful ! ! !-----------------------------------------------------------------------------------Interaction trigger/throttle decisions based on BX-ID tagsTELL40: buffer management + DAQ formatting-----------------------------------------------------------------------------------Existing Muon system is non-ZS: plan was to use this system
Fron
t-en
dBa
ck-
end