Some basic ideas (not a solution) Towards a trigger chip Why we should start now Some basic ideas (not a solution) How to advance this?

Introduction Time to develop chips is long: start sooner rather than later Need to have a solution or solutions now, so people can believe it is possible and so they know roughly what the performance will be Even if it is not the final solution: of course, we will continually improve and alter when we come to implement it on a chip design There are many ways to cook an egg ...and even more ways to set up an on-chip trigger scheme The sooner we brainstorm and get ideas out, the sooner we can see what the performance criteria are and start to narrow down the list This talk: Not a solution... just want to stimulate a start to the process and give some basic ideas to think about

Environment Geant4 one year will give us the details, meanwhile some *very* rough numbers: The track rate at the outside of the solenoid is a few MHz/cm2 (depends on what lower threshold you start counting at) O(100) hits per track O(20) bits per hit (tdc, address) A chip is about 2 cm2, maybe bigger O(10 Gbit/s) (very rough) Conclude: must use parallel processing, limit transport of hit data --> Some per-pixel logic needed with local communication to neighbours Probably parallel processors at end-of-columns

Technologies Now: 130 nm single plane Soon: 90, 65 nm... Later: 3D interconnect with many layers Chips: FE-I4: per-pixel memory, ATLAS read-out rates (100 kHz) Timepix: Per-pixel memory with tdc; Timepix II in the pipeline Propose we look at all possibilities, but concentrate in the short term on finding a 2D (single plane) solution based on Timepix-II and assume some sort of marriage with FE-I4 type read- out Then add on top of this a trigger scheme.

Consideration for T0/BC without a trigger FE chip records the arrival time of a hit We want the drift-time, which needs the T0 For us, that means the BC producing the track needs to be identified For most applications, e.g. MDT, it is produced by another detector (e.g. RPC, TGC) We have to determine this in the FE chip. Presumably we "try all possibilities", i.e. at 40 MHz we look for a signature of a complete track, probably limiting the possibilities already to reasonably high pT (E.g. 1 GeV/c or a fraction of it) Many ways to do this: Anatoli and Harry will present their ideas next. I will present one idea too. Then maybe a fast pT cut based on cluster width in the r-phi direction Then use full information for a sharp pT cut at high pT With quality and direction selection Involves arithmetic processors In any case, we probably need to implement many levels in the scheme

One idea for T0 When assumed T0 is too early, only first hits are present and are placed far away When T0 is correct, you get the full track. Hits exist in first and last BC bins. Only when T0 is correct do you get hits in first and last BC When assumed T0 is too late, most hits have disappeared (gone out of range) and the far hits are placed too close to the chip

So look for a coincidence... Look for a coincidence between hits in the most recent BC and hits in the BC corresponding to the maximum drift time Reduce coincidentals mixing two track stubs, and limit pT, by doing this in f regions E.g. 32 regions of 8 columns of 55 mm Avoid edge-of-region effects by looking for a coincidence between most-recent-BC in this f region and max DT hit in this or immediate neighbour regions You have reduced the rate from 40 MHz LHC clock to O(few 100 kHz) track candidates per f region Use this coincidenc to start a "cluster width search" in the phi direction equivalent to a rough pT cut further reduces rate

Precision step We want good quality trigger: Sharp pT Low fake rate Point to interaction region? Supply trigger with x, y, q, f and c2 of track Can we put arithmetic processors at the end of each column to use full information? Do linear regression: Readout all hits in the columns involved in the coincidence Calculate S1, Sx, Sx2, Sy, Sy2, St, St2 (Use integers i.e. drift velocity = 1, pixel size = 1 unit etc.) Use these to get x, y, q, f and c2 (add multiply and divide operations) Apply cuts on f (= pT) Can also apply cuts on q (point to interaction region) and c2 & number of hits (quality) If a track meets all these criteria, issue a trigger and send x, y, q, f and c2 of track to ITkL1 ITkL1 converts to global coordinate system and sends to Topo trigger

Final Remarks I have no idea how big pixels have to grow to make the coincidences... but they can grow in the z-direction without significant loss of performance I have no idea how much the end-of-column logic has to grow for the arithmetic processors - maybe it is impossible There are many ways to cook an egg but they all involve heat There are many ways to make a trigger but they all involve finding T0 quickly get rid of low pT tracks (the bulk) use as high precision for pT cut as possible and minimise power, chip space, false triggers, ...