Minutes 18/02/00 (Birmingham)

Present: A. Baird, J. Dowell (in part), Y. Fleming, S. Kolya, M. Landon, D. Mercer, P. Newman, D. Sankey, R. Staley

The text below is a general recollection of the discussions at the meeting, rather than formal minutes. Items are highlighted in red to indicate an important fact or number. There are lots of unanswered questions identified. Please let Dave know which of these questions you expect to be able to answer!


Time Schedules and Deadlines

The time schedule for the project is

June 2001: Full Prototype System Installed
December 2001: Full System Delivered

where the former date corresponds to the start-up of the experiment after the long shutdown (tbc).
It was felt that a detailed project plan is required in order to set deadlines on the way to these final target dates.
Dave S is asked to draw up this project plan, with consultation of all groups involved.


Future Meeting Plans

After some discussion about how best to communicate, it was agreed that ....

1) Regular contact is essential during the design phase. This could normally take place via a regular (fortnightly for around 2 hours?) video conference between RAL, Birmingham and Manchester.

2) At present, the implementation of the algorithm in hardware remains rather ill-defined. At least one more `face-to-face' meeting is needed in the near future to discuss this aspect. Various ideas also need to be evaluated as detailed below.

3) Mainly due to holidays, it will not be possible to have another meeting as soon as we would like. It is proposed to meet next on Tuesday 21st March, again in Birmingham.

4) We plan to have a complete block diagram of the data flow through the Front End Module well in time for that meeting. - The first attempts at drawing this block diagram will be posted on this page for comments. Adam was asked to make this drawing, in consultation with Dave S / everybody else.

5) Some interaction with Andre Schoening is going to be important here, as he knows the ideas behind the algorithm better than anyone. - We should invite him to our next meeting.

Overall System Layout

Thanks to Yves, for leading us through this part of the discussion with a couple of well chosen transparencies.

The full system comprises 450 CJC wires in 150 groups of 3.
In order to fit the full system into 2 crates, it is planned that .....
5 groups of 3 wires should fit into 1 Front End Module
(Total - 6 FEM's x 3 layers in CJC1 - 12 FEM's x 1 layer in CJC2 = 30 cards)
The most natural split then seems to be
1 crate (18 FEM's) for CJC1
1 crate (12 FEM's) for CJC2
which works well with the assumption that only CJC1 signals will be used for the L1 trigger. The trigger functionality would then only be needed for the service card in one of the crates and problems with passing signals between cards / crates would be minimised for the trigger.
We need to evaluate the physics losses associated with not including CJC2 in the L1 trigger.
If we decide that CJC2 is crucial to the trigger, an alternative plan would be to split the system into two crates according to azimuthal angle, though this gets more messy.

Initial estimates indicate that ....
1 large Altera (APEX 20K1000) will be enough to deal with 1 group of 3 wires,
(see notes below) which implies 5 FPGAs per FEM.
This question of capacity needs to be addressed further, but the above is our working hypothesis.

The working hypothesis is presently that the system is clocked at 80MHz (with ORing procedures such that the coarse-grained segment finding can be effectively at 20MHz.)
This choice arises from the fact that both frequencies are integer multiples of the HERA clock frequency (10MHz), but is not set in stone (e.g. 40MHz clocking would reduce the size / number of FPGAs needed).
Qu: Are there good reasons why the system should (not) be clocked at 80 MHz?

General Points on Algorithm Implementation

1) Combinations of wires between different (phi) cells is potentially made easier by the skewing of the wire planes relative to the radial direction.
Only correlations between i) the bottom wire of a group and the middle / top wires of its right neighbour (when looking in +z direction) and ii) the bottom and middle wires of a group and the top wire of its right neighbour are likely to be necessary.
Other possible correlations not expected to correspond to physical tracks with pt > 100 MeV
We should be careful to verify that this claim is really true (Paul and Yves?)

2) We are assuming that 1 microsecond is the maximum CJC drift time.
It was suggested that we contact CJC experts to check there is not likely to be a drastic change in gas mixture used.


FPGAs

1) What capacity is required for the CAMs?
This is defined by the size of the shift registers and the number of distinct possible (kappa phi) outputs (is it simply the product?).
For the L1 trigger, the final (kappa / phi) array is likely to be 64 (phi) x 16 (kappa), the shift register length being approximately 20 bins.
For the output to L2, the (80MHz) shift registers have around 80 register positions. The proposed granularity is 50 kappa x 500 phi (see PRC proposal).
Fortunately, the use of pivot elements reduces the effective number of register positions considerably!
We urgently need to estimate more precisely how many gates are required per CAM!
Also, how many gates are required for the Qt / anything else?
We budgeted for one 20K1000 per group of 3 wires?!?

2) The question arises of exactly what should be the format of the CAM outputs? The upshot of the meeting was
At the `20MHz' synchronisation frequency, we cannot resolve more than 1 track segment per wire group, so there is no need to worry about multiple track segments. However, due to the use of pivot element, the output information is complicated and usually valid for many bunch crossings. - Some means of encoding this information (and unencoding in the trigger module) is required. Can this be implicit in the pipelining? Is it problematic?
At the `80MHz' synchronisation frequency, the output information (for L2) can probably be unencoded. We may need to deal with the case where more than one valid track segment appears on the same group of 3 wires.
Work is needed here to provide better defined data formats!

Pivot Elements

The `pivot element' technique definitely makes the task of the CAMs easier. Here, the CAMs are only interrogated when there is a hit in a given register position in one of the 3 layers (probably the middle one). The number of possible masks is then more like the square than the cube of the number of register positions.
The price to pay is that a valid pattern including the pivot element could originate from more than one bunch crossing - each must be accounted for.
Also the same pattern corresponds to different (kappa/phi) at different clock cycles.
The resolution for the first level of search (20MHz / for L1 trigger) is probably something like 64 phi bins (half a cell) - such that this effect is irrelevant. - For the finer-grained search (80MHz / for L2 segments), it probably matters.
Qu: Where is the optimum position in the register for the pivot element?
Qu: Are we likely to need more resolution than just `cell number' for the L1 trigger?
Qu: Are there losses associated with patterns that are not picked up by the pivot element technique, or can things be arranged such that such patterns are unphysical?
Qu: For the case where a track crosses a cell boundary - What is the best way to deal with timing equalisation when passing information from FPGA chip to chip, from FEM card to card?


Tasklist

The tasks so far identified were laid out and discussed. Those listed below do not yet have names next to them.
Internal System Integration
Integration into H1 and Control
Monitoring Software

If Murraugh is able to join the project, we would be delighted if he could work in one of these areas!


Compiled by P. Newman, 21/2/00