1. 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?

2. 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

3. 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

4. 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.

5. 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

6. 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

7. 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

8. 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

9. 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, ...