PT module design and readout Work in Progress The concept does not have to be fully accurate but a concrete picture is needed to expose the major issues and allows to propose solutions which can be evaluated quantitatively Geoff Hall Overall layout [Mark P] Assume stacked layer at R 25 cm Tilted to minimise cluster size large clusters from grazing incidence need to simulate low p T tracks efficiency bias for oppositely charged low p T tracks? relevant if full readout for tracking is used? Feb 2009G Hall2 R = 25cm thickness = 285m R [cm]p T _graze [MeV/c] Occupancy estimates Scenarios for sLHC and vLHC W Scandale & F Zimmerman Nuclear Physics B (Proc. Suppl.) 177178 (2008) 207211 40MHz, peak luminosity 1.55x10 35 PYTHIA & total inelastic (pp) = 79mb -> Then geometry dependent R = 25cm | |=2.5, untilted sensors, 100um x 2.5mm pixels average occupancy over layer is 0.45% 17%[3 Poisson variation], cross section uncertainty = 30%[Tomalin], low pt track uncertainty = 12%[Tomalin], cluster width uncertainty = 50%[simulation] => (0.45 0.3)% occupancy. Other factors include fluctuations in jets being studied Feb 2009G Hall3 PT layer pixel size Should reduce need to compare many nearby columns independent of , but offset in z between layers increases with R- compare to assembly precision ~ 100m Feb 2009G Hall4 d R Luminous region L R = 25cm, L =28cm d = 2mm 2 mm d R L = dL/R LHC luminous region L 28cm (3 ) may be larger or smaller at SLHC Schematic PT module Feb 2009G Hall5 Inexpensive prototyping, using wire bonding, might be possible - experimental demonstration will be important 2 x 2.5mm 12.8mm 104 x 2 Data out 128 x100m x 2x2.5mm Correlator data R = 25cm Occupancy ~ 0.5% at 40MHz & This is believed to be worst case PT layer readout Bring data for comparison with second layer, using minimum power high speed shift register? 128/25ns = 5.12Gb/s try to exploit low occupancy? address hit channels? 128 = 7 bits and should handle some multiple hits high PT candidates should be narrow clusters ignore clusters of 3 or more strips likely to be only one candidate group per 128 channel even in congested environment Feb 2009G Hall6 column of 128 pixels Possible schematic divide column into 32 x 4 channel groups eg logic sets 9 address lines: 5 bit group + 4 bit pattern +1 bit spare provide more information than single channel address ignore combinations consistent with wide clusters a moderate number of address lines could be sufficient still plenty of space for power, clock, I2C, probably share some in 256 channel chip Nearest neighbour logic to avoid group boundaries including (upper) chip edge Feb 2009G Hall7 column of 128 pixels Some details Valid 4 bit patterns = double cluster Invalid Although infrequent, there will be adjacent groups nearest neighbour logic to merge eg is an invalid cluster Could also increase address lines to cope eg 110 groups of 8 channel groups => 12 bits cf 32 groups of 4 channels => 10 bits Optimise design using MC eg 256 elements, longer groups, and to avoid bias Feb 2009G Hall8 column of 128 pixels More details At central boundary need data from ROC-L & ROC-R extra level of bonding? Feb 2009G Hall9 ROC-LROC-R ROC-LROC-R Simplest solution: If a valid pattern with hit in [pixel:127] pass all data from last pixel, even if match not found use spare bit as indicator that no matching comparison extra data volume, for rejection factor 20 ( *0.05)/(128*0.05) 1.15 [pixel:127][pixel:0] Data rate for PT module Feb 2009G Hall10 2 x 2.5mm 12.8mm 104 x 2 Data out 128 x100m x 2x2.5mm Correlator data Module 25.6mm x 80mm 256 x 32 sub-units = 8192 channels Occupancy ~ 0.5% => 40 hit channels PT reduction 20 [Mark P] => 2 hit channels/BX 32 bits, with column address ROC Feb 2009G Hall11 ROC-1: 128 chan ROC-2: 128 chan Height:128 x 100m = 12.8mm + Width:2 x 1.5mm= 3mm + Space for bond pads, etc. Dense bonds on module : 8192 channels Optimised pitch size? Max chip size in 130nm: 19.5mm x 21mm Functions: amplifier, threshold adjustment, comparator, latch, neighbour logic, connect to bus, internal test? Questions could assembly be done using inexpensive bump bonding? eg C4 layout with 200m spacing should be possible Power transmission over long, narrow chip? Module - plan view of section Feb 2009G Hall12 assembler 10 bits from column above transmits column to each neighbour receives 10 inputs from each neighbour and stores receives 10 inputs from module below compares pattern from module below with three (10 bit) stored patterns x10 column 128 channels interconnect chip lower layer store + (memory buffer for full readout) 10 bit bus upper layer 10 bit bus x10 assembler multi-via column 128 channels x10 Module - section view in r- plane Feb 2009G Hall13 Interconnect chip mass produced, cheap coarse pitch ~250m ~2.5mm x 2.5mm Maybe an easier method? sensor ROC assembler store PCB ROC 2mm Sensor & ROC ~ 200m thick Very small component, with regular spacing - Possible connectors Feb 2009G Hall14 Fine Stack.40 mm Pitch Plug & Receptacle Number of Positions = 80 (also 20,24,46,50,60) Overall length = 18.4mm Board-Board Stack Height = 1.0mm (X) In-Line Contact Layout X O Zorba Fine Stack socket Feb 2009G Hall15 More speculative Elastomeric connectors Feb 2009G Hall16 Lifetime, aging, precision, reliability? become more cost-effective at board separations of about 0.200 (5 mm) or less and pad pitches below 0.050 (1.27 mm). Module - section view in r- plane Feb 2009G Hall17 sensor ROC assembler store PCB ROC 2mm Sensor & ROC ~ 200m thick lateral connections via PCB layers and wire bonds 2.2mm Questions: what is achievable precision? could all connections be made simultaneously? what accuracy vertical spacing is required? thermal stress Adapt module for bump bonding - r- plane Feb 2009G Hall18 sensor An alternative variant with one layer inverted allows to avoid connectors but at the price of having doubled sided modules and possible assembly and handling questions. How difficult will it be to align? For all designs, what is the best cooling method? Pipes at module edge may be sufficient NB expect to remove material from picture frame under sensor ROCassembler PCB 2mm ROCstore PCB wire bonding should be sufficient but could use silicon interconnect bridge to connect ROCs laterally ROC (2) Feb 2009 G Hall19 ROC-1: 128 chan ROC-2: 128 chan Height:128 x 100m = 12.8mm + Width:2 x 1.5mm= 3mm + Space for bond pads, etc. Dense bonds on module : 8192 channels Optimised pitch & pixel size? Max chip size in 130nm: 19.5mm x 21mm Would be natural to make assembler part of ROC and, if possible, aim for identical chip for top and bottom layer Height = 5mm ? => 18 mm x 6mm Assembler Logic 3 x 10 bit storage 1 x 10 bit from paired layer * Comparison logic with compensation for r- offset (switch off for lower layer) * Time stamp & pattern buffer for 256 latency (if needed) > 50% empty for O 0.5% * Output 10 bit column to/from paired layer (switch off for lower layer) * Output pattern & address if coincidence * Need to receive/transmit clock Dimensions from pad layout Assembler Identical chip for top and bottom layer possible? Feb 2009G Hall20 10 x 200m 10 x 10(?) m 10 x 100m 10 x 10m staggered 1.5mm 5mm staggered Module sensor above Feb 2009G Hall21 Is it feasible to assemble modules in this orientation? (Connectors are below board in top layer) interconnect bridges ( if bump bonds needed) 25.6mm data out control in concentrator 80mm Module sensor below Feb 2009G Hall22 Modularity: 10 bit bus = 320 lines, 4 x 80 way connectors 4 x 80 way =>4 x 18.4mm = 73.6mm interconnect bridges 80mm 25.6mm data out control in concentrator Module at large schematic plan view Feb 2009G Hall23 eg 10mm If accurate alignment possible, simply offset connectors, and add routing Comparison logic Feb 2009G Hall24 p = IP Modules are flat, not arcs Compensate for Lorentz drift Orientation of module => position dependent logic [Anders/Mark P] R- view Luminous region z view z offset dependent search window to allow for luminous region and quantization => 3 pixels (if not tiny) ~200m ~12mm = 2.5 NB position dependent logic could contribute to alignment at expense of complexity Data transport Feb 2009G Hall25 From 32 ROC + Assemblers & 0.5% occupancy 10 data bits + 5 address bits to transmit (differential?) ~2 hits/module to transfer/BX after PT match 1 hit/32 ROC 8 data bit bus + 1 busy 80Mb/s ? Power - two arguments: CMOS logic [Mark] or energy per bit [Sandro] (i) 2W/MHz/cm x 80MHz x 8cm x 8 / 4096 = 2.5 W/channel (ii) 10pJ/bit x 16bit /25ns /4096 1.6 W/channel Clock distribution? Store data on assembler while awaiting readout Concentrator to GBT Control, PLL, Trigger Data volumes and link requirements Feb 2009G Hall26 for 40M channels in stacked layer Channels/chip128 Occupancy0.005 PT data reduction0.050 Channels above PT cut/BX/layer5,000 Bits/channel16 No 3.2Gbps [new]1000 Power/link [W]2.0 Link Power [kW]2.0 Power/chan [W]50 Assume 16 bits/chip to transfer and trigger data from one layer Options following trigger (1)no further readout (2) read out unmatched patterns saved in Assembler (choose top or bottom layer) more power: logic & to send data more links and traffic management extra data volume for rejection factor 20 (40MHz/ kHz)/(40MHz/20) = 1.05 (3) read out all data requires 6.4s storage on each FE pixel memory in ROC FE significant extra power penalty & complexity Power estimate Budget for PT layer: 112W/channel Option (3): for full readout => ?? Feb 2009G Hall27 * Ancillary chips in present tracker typically required 50mW => 20mW in 130nm Assume one PLL per side => 20mW/(32*128) = 5W Approximate dimensions R [cm ] L [m] A [m 2 ] N face N chan N ROC N module N links P [kw] M150k M293k Feb 2009G Hall28 For stacked layer (doublet) Pixel size100m x 2.5mm ROC2 x 128 channels /pixel120W | MAX | 2.5 NB no allowance for overlaps in R- or Simulations use 0.5-1mm overlap in -> +8% [Mark P] number of APV25s produced and tested for present Tracker Conclusions The crucial issue is the assembly & interconnect problem do layers need to be precisely aligned ie sub-100m? is it feasible to use connectors? Density of lines on module and connections to sensors suggest bump bonding will be required but inexpensive C4 looks feasible Power consumption for layer is still dominated by data transmission off the detector this is very sensitive to occupancy and rejection factor it probably will be remote from module Feb 2009G Hall29