350 likes | 522 Views
Strips trigger rate Issues & Can the strips achieve the following proposed trigger parameters (proposed following Stanford AUW)?. L0 accept rate: 500 kHz L0 latency: ~ 5-6 m s L1 accept rate: 200 kHz L1 latency: 20 m s. L1 trigger rate capability will depend crucially on expected pileup.
E N D
Strips trigger rate Issues & Can the strips achieve the following proposed trigger parameters (proposed following Stanford AUW)? L0 accept rate: 500 kHz L0 latency: ~ 5-6 ms L1 accept rate: 200 kHz L1 latency: 20 ms
L1 trigger rate capability will depend crucially on expected pileup In fact system design in terms of front-end data formatting depends critically upon this number. What is inelastic cross-section at sqrt(s) = 14 TeV? Is design luminosity = 7 x 1034 cm-2 s-1 ? Also bunch crossing at 25 ns or 50 ns plays a role What are machine parameters to be used for LOI ? Need these numbers in the LOI parameters document For this preliminary trigger analysis we will use between 150-200 pileup events at 25 ns bunch crossing.
Array of Pileup Numbers • Simulation used for trigger calculations is for 200 events/bunch crossing • We have occupancies for 200 events • We connect L1 trigger rates to occupancies • But need to understand this table to connect trigger rates to luminosity
Upgrade Architecture for Short Stave Proposed Readout GBT Sensor Module 5120 Strips Hybrid 10 ABCN130, 1 HCC Hybrid 10 ABCN130, 1 HCC • HCC is the “Hybrid Controller Chip” • Serves as interface for TTC/Data between ABC130 ASICs and Service Bus • 12 Modules (Utopia layout) are shown in drawing. May be 13 modules in Cartigny layout • Each HCC maps readouts out 10 ABC130 in two parallel streams. Thus HCC readouts out 2560 strips
Upgrade Architecture for Short Stave • Important points to note are: • A short strip cartigny stave needs 26 readout lines (maps poorly to GBT). • The data rates on each data line are only available at three discrete values. • The HCC in the strips detector (petals & barrels) with the most average hit data to read out will determine readout and thus trigger rates. Note: Each data line is associated with an “e-link” in GBT terminology
ABC130 Buffers and Implications for Trigger Parameters • L0 accept rate = 500 kHz ? • Yes, L0 Accept rate my be higher. Simply determined by tradoff between L0 accept rate and L1 Latency • L0 Latency ~ 5-6 ms? • Determined simply by L0 Pipeline Depth/25 MHz = 256/ 40MHz = 6.4 ms • L1 Accept rate 200 kHz? • This will require more detailed calculation in subsequent slides • L1 Latency : 20 ms? • L1 latency = Depth of L1/R3 buffer/L0 accept rate = 256/500 kHz = 512 ms ! More than sufficient latency. Can trade off latency for higher L0 accept rate if desired. 3 out of 4 trigger parameters trivially satisfied due to ABC130 dual 2 x 256 dual buffer architecture
ABC130 Data Format 59 bits per data packet. For L1 Accept calculation we require that only L0_1BC Packet and R3 Packet data be sent. L0_3BC Packet send data for 3 consecutive bunch crossings; there is not sufficient bandwidth for this. 4 clusters central hit position Event ID 3 clusters geom. patterns
ABC130 Data Format • To get a reasonable L1 rate, we must use L0_1BC data format where data from adjacent bunch crossings is not used. • What does the current ABCD chip use for physics data taking? • Is there any reason during physics data taking why adjacent bunch crossing will be desired? Presumably adjacent bunch crossings are useful for initial calibrations and timing setup.
Strip Occupancy 200 Pileup Events Utopia Layout L1 accept rate “appears” to be determined by this region of innermost short strip layer. Note simulation was for 10 cm long strips. Occupancy is halfed for 5 cm strips
Strip Occupancy Summary Inner Short Strip Barrel Divide by 2 for 5 cm strips
Disk Cluster Widths There is a strong radial cluster width dependence
Barrel Cluster Widths Cluster width values and z dependence very similar all layers
Comments on Simulation • Simulation data provide by Karoline Selbach and Nick Styles. Andre Schaelicke provide information below on simulation and interaction cross section • 200 event pileup sample • Sample represents 5 x 1034 cm-2 s-1 at 50 ns corresponding to 80 mb cross section • Sample is an ND + SD + DD Pythia 8 mix with some pt cut (A. Schaelicke)
Hit vs Strip Occupancy • Occupancy previously shown was strip occupancy, not hit (or cluster) occupancy. • What is relevant for the readout rate is hit occupancy due to ABC130 data packet formatting (it reads out clusters) • Need to correct “strip occupancy” plots with average width per cluster to get “hit occupancy” plots. • Hit occupancy = (Number of hits/detector-event)/(Number strips/detector )= number of hits/strip-event
Hit Occupancy Approximated from Previous Plots (and long strips now ~ 5 cm long) • Occupancy is now relatively independent of z position • Long Strips (layers 3 and 4) occupancy very low now (≤ 0.5%) • Inner short strip detector only needs to be considered to calculate trigger rates • However, ends of short strips have slightly wider clusters and should still determine the overall trigger rate. Will use max 0.9% hit occupancy Hit Occupancy for Barrel Layers
L1/R3 Trigger Rate Calculation • Key numbers to calculation for L1 are the mean number of bits per event per HCC are needed for the HCC in the detector system with the maximum average data • Similar number is needed for R3 • Additionally, we need to know what event rate is needed for R3. If we assume we want to generate a R3 trigger for every event in L0, and that at most the ROI will point back to geometrically no more than 5% of the detector, than R3 rate = 5% x L0 rate. • Important question is do we expect ROI will be uniformly distributed? • Then, • L1 elink rate = 200 kHz x N bits/HCC-event • R3 elink rate = 500 kHz x 5% x M bits/HCC-event • Total elink rate = L1 elink rate + R3 elink rate • Note: for barrel 1 HCC corresponds to one hybrid or 10 ABC130 chips
Calculation of L1 Nbits/HCC-event and R3 Mbits/HCC-event • These numbers are best generated from proper simulation. They must take into account the ABC130 hit formatting for both types of data • Here I present an approximate calculation derived from occupancy and cluster widths plots supplied by K. Selbach Use hit occupancy to generate poisson distributed hit distribution (A) Use cluster width distribution (B) for that hybrid (HCC) to generate cluster size probability distribution. Split clusters with width > 4 into two clusters (A) (B) (C)
Calculation of L1 Nbits/HCC-event and R3 Mbits/HCC-event Group clusters according ABC130 data format to determine average number of bits/event-HCC (69.9 bits/event-HCC) corresponds to 1.18 L1 packets)
L1 Readout Rates Use different hit occupancies to generate N bits/event-HCC (if want to see rates at different luminosities) Use similar approach (but different algorithm) for R3 rates. Close to M. Warren’s more sophisticated calculation (154 Mb/s)
GBT Issues Current GBT has three different data packet or “frame formats”. Most robust (uses Forward Error Code Detection) is “GBT” frame format. Has lowest data bandwidth (detector to daq) Least robust (i.e. no error code detection) is “wide frame mode”. Has highest data bandwidth (via extra available inputs)
GBT Issues • At 160 Mbps, there are only 20 inputs available in GBT mode. This is ok for long strips (13 inputs needed), but not for short strips (26 inputs needed) • Potentially outer short strip could be run at 80 Mbps and there are then 40 inputs available (needs closer examination). • Inner short strip needs either • A. Two GBTs running at 160 Mbps, or • B. One GBT running in wide frame mode at 160 Mbps(28 inputs) • C. An Atlas specific GBT with a few more inputs. However, this GBT would need an increase in the overall serial bandwidth that is currently specified at 4.8 Gb/s
Conclusions • The HCC with the highest average occupancy determines maximum L1 Accept Rate. • Appears we are close to being able to satisfy L1 +R3 rates for barrel. Need to pin down actual pileup vs luminosity. • GBT • Wide frame mode needs consideration. • Data bits • May be able to save some bandwidth by using only 51 bits for L01_1BC ABC130 packet data (M. Newcomer) • Petals • Need to apply calculations to petals. But first three backup slides show much higher hit occupancies (up to 3.5%) without a corresponding reduction in the number of chips/HCC. This would seem to imply that the petals as geometrically laid out will significantly limit bandwidth
News from DESY • Meshingproblemssolved • Failureat 3D-Model surface • Change meshelementandsize • Now in progress • Drawingsfor: • DESY PETAL • Gluingjigs • Supports • Gluingstand in preparation • Tool forcoolingpipebending • In a fewmonths: workshopforcompositematerialsstartup
News from NIKHEF Main change is that we re-routed the cooling pipes to come out at the top of the petal, see drawing. Previously they exited at the ears. Now (invisible in the picture) they make a loop out to theears and back in. x Main reason is to make the petal prototype fit in our cold box; also in the endcap when the pipescome out sideways they make insertion of the petal difficult and risky y z
Ring Number Utopia in Athena (simulation) Relative placement Nstrips Utopia Nstrips 1024 768 1024 768 896 768 896 768
Inner ring endcap bits/asic-event as function of occupancy Previous slide and this would seem to imply that due to saturation we will often miss the hits of interest for the ROI (unless precision on the level of the width of a chip are sufficient
Comparison Barrel and Endcap Short Strip Barrel Ring 0 (3% occupancy, 6 chips/hcc)
Proposed Upgrade Readout Timeline ~50uS latest R3 ~500uS latest L1 2-6uS fixed Latency Simple Rules for Maximal Flexibility • L0 Delay Fixed at Initial Setup • R3 Must precede L1 • R3 readout highest priority • L1 initiates Off Detector Readout Event Time SyncronousL0 AsyncronousR3 AsyncronousL1 Non Sequential Readout Requires Self describing Data Blocks
Hi All, I just wanted to conclude the present trigger discussion with one final note concerning the endcaps. I did the bandwidth calculation for one of worst endcap rings with an occupancy of 3%. It needs an elink bandwidth of approximately 216 Mb/s at 200 pileup events. A summary of this and compared to the barrel is shown on slide 29. Maybe this isn't so bad for the moment. But I wanted to comment on something that may be more important. Slide 27 shows the hit distribution for 3% occupancy. Most of these hits (90-95%) have width <3 so are not thrown out by the R3 algorithm. The mean number of hits is thus around 7. Since only up to four hits are sent per chip, doesn't this mean that a large percentage of the time we will be losing the ROI hits that we want? Regards, Dave
End of Stave (GBT controlled) Signals Bussed Outputs Stave_BC(40 MHz Data Clock) Elink TX1 TX Elink TX2 L0_ CMD @80Mbps Elink TX3 R3_L1 @80Mbps Point to point Data Lines - one per Hybrid Only possible with 80Mbps for present GBT technology. Optical Link Tosa Rosa GBT Versatile Link Elink RX1 Hybrid 1 Hybrid 2 Elink RX2 … … … RX Elink RX24 Hybrid 24 ? ??? current GBT design provides only 20 @160Mbps Note that for a longer stave we would be forced to go to 2 GBT’s per Stave.
ABC130 Data Flow Readout L1 latency (up to 256us) L0 latency (6.4us) DCL L1 Local FiFO 53 256 Pipeline (SRAM) 256 256 L1 buffer (SRAM) WA RA WA RA Local FiFO DCL R3 L0ID 53 BC WAgen RAgen At BC : WA=WA+1 At L0: RA=WA-L0Lat R Event Address R Event Address R3 L1 CLK RR RR Data Flow Control Command Decoder W W L0-COM R3L0ID L1L0ID R3-L1 BC