Notes from brainstorming held on 20th September 2000 and 4th October

Present: Michel Jonker, Quentin King, Jean-Jacques Gras, Alan Burns, Gary Beetham, Mike Lamont, Jean-Jacques Savioz, Philippe Baudrenghein.

After a brief review of the requirements, Michel Jonker presented his thoughts on LHC slow timing implementation. This essentially drove the meeting. Slides here.

Implementation - four options

1. Classical, dedicated a la LEP
2. BST (TTC) based TTC home page TTC Intro
3. Based on absolute time
4. Replace by RT system

1. Classical A realiable solution. We know what we dealing with, main problem is distribution into tunnel.

2. BST Main stumbling block is the fact that the BST unit of time is turn number. Need to re-synchronise to ms plus nonrandom jitter and an intrinsic granularity of 89 microseconds. Quentin not happy with this. General feeling seemed to be that it's better to keep the two system apart.

A lot more discussion on this in the second meeting, and although the 40 MHz TTC is somewhat over specified to deliver 1 ms events (comparisons with a sledgehammer) it was felt that a solution was possible:

• Jean-Jacques Savioz sketched out a possible implementation. By using one of the free FIFOs for a milli-second tick synched with absolute time a technical solution appeared feasible. The issue of responsibility would need to be addressed.
• Quentin expressed his discomfort at the possibility of both a TTC receiver and GPS in the gateways, but sketched a possible solution which used just the TTC. There would be an acceptable biased jitter.

• The question of whether we can we abandon absolute time and use turn number was raised. Although the turn clock is an ideal reference for the RF system, there are many systems wherein this is not true. The fact that the revolution time varies (particularly with heavy ions) and the need to lock to, say, the injection revolution frequency when there was no beam were raised as objections. Clearly a translation between absolute time and turn number would be required.

3. Absolute time. Looks like a lot of work, but it looks as if we will have GPS in the gateways.

4. Real time. Could be nice. Vision of real-time manager sending commands out to equipment. Noted that ethernet won't guarantee 1 ms latency. Do we need a real-time system anyway? To be followed up.

All four choices appear capable of providing the required functionality. The final choice will need to made based on criteria such as: cost, ease of use, reliability, responsibility.

Reliability

Clearly an issue:

• Do we need handshaking? i.e. confirmation of receipt of events. System such as that used in LEP seems a good compromise, enable hardware and check response, if OK send event and assume it gets through.
• TTC based system was thought to be inherently very reliable.
• TG3 like system has a simple output and is easily programmable - an important consideration (PB).

Other ideas

Michel suggested a "function generator" which could be used generate events locally (for, say, the RF). The generator would accept, say, the energy ramp and could generate events as a function of this. More in his slides (see above).