CERN Trajectory Measurement System

Project Meeting at CERN

1.References

• IT-3384/AB: Technical Specification for a new trajectory measurement system for the CERN Proton Synchrotron.

• Alpha Data’s CERN Trajectory Measurement System technical specification “IT-3384/AB”

• Alpha Data’s CERN Trajectory Measurement System “systemDesign 0.5” document.

• Alpha Data’s CERN Trajectory Measurement System “pupeBoradDesign 1.0.1” document.

• Alpha Data’s CERN Trajectory Measurement System “pupeFpgaDesign 0.3” document.

• Alpha Data’s CERN Trajectory Measurement System “softwareDesign 0.10” document.

2.Introduction

Staff from CERN, Alpha Data and Beam Ltd had a meeting on the 16^th of November 2006, at CERN, to discuss the CERN Trajectory Measurement System design. The meeting covered all aspects of the system design with reference to the design documents produced by Alpha Data and Beam and the original tender specification.

During the day we went through each of the design documents discussing each and proposing changes.

3.System Design

CERN were happy with the overall system design and rack system with system controller approach.

• CERN would like to use positive logic for all of the digital timing input and test output signals.

• CERN would like to know the the maximum ADC input voltage. Their current analogue front end amplifiers could produce +-3 volts.

• A general discussion on synchronisation was had. Apart from the CYCLE_START and 10MHz system clock signals it would be possible to internally generate the other TMS timing signals from information on the Proton Synchrotron’s processing cycle. Unfortunately it does not appear to be possible to get this information from CERN’s systems at the moment. In the future it may be possible for CERN’s systems to give the TMS system more information on the processing cycles in order to do this. This would eliminate many of the digital timing inputs to the system.

4.PUPE Board Design

CERN were happy with the PUPE cPCI board, based on ADM-XRC-4FX based FPGA, design. Some points discussed were:

• CERN would prefer to have LEMO type connectors, as per the design presented, rather than SMA’s as they feel it would make it easier to connect leads considering the close spacing of the connectors.

• CERN showed us some double height LEMO connectors. If space is tight on the front panel we could use these connectors although the spacing between the connectors is small.

• CERN were happy with using the front panel based timing bus.

• We discussed what the propagation delay along the timing bus would be. We will ask Derek and Bill for their ideas on this.

• If the timing buses propagation delay is long, we may need a extra, 125MHz capable, digital input to the board for the INJECTION signal to allow for more accurate synchronisation. (Perhaps using the double height LEMO with 10MHz and INJECTION inputs ?)

• CERN would like to investigate the possibility of using faster ADC’s with lower bit resolution. They were not sure if this approach would actually be better for them. They are going to investigate this. Andrew was reasonably sure that the FPGA signal processing could operate at this higher speed. We could not remember the exact issues with using faster ADC's from the previous meeting we had but cited the possibility of not obtaining the 10.5 ENOB figure and that there might not be sufficient I/O lines available on the FPGA. We decided that it would be best for Derek and Jeroen to discuss this further.

• CERN would like to use positive logic for all of the digital timing input and test output signals. This will reduce power dissipation in their TTL drive circuitry.

• CERN stated that there will not be an issue with high common mode transient voltages into the systems inputs as the timing signals come from nearby racks, but stated that the ADC inputs may exceed the +-1Volt specified. They stated that this could easily be +-3v. We need to check and inform them of the maximum ADC input voltage.

5.PUPE FPGA Design

CERN were happy with the overall FPGA design and register/memory level API.

• CERN proposed a modification to the synchronisation scheme that becomes possible with the 3 PU channel per FPGA design approach. The proposal is to use a single PLL synchronisation unit per 3 PU channels. The PU channels would be connected to physical PU’s dispersed around the ring and would lock to the combination of Sigma signals from the three pick-ups. This would improve the PLL’s ability to lock onto the beam’s signal and reduce the PLL jitter. Testing of the system may be harder though. It was decided that this should be relatively easy to implement within the existing design and we would look into adding this feature.

• CERN mentioned some missing information in the diagnostics capture system. We stated that this was not complete and needed items such as the orbit frequency. We stated that this design detail was not complete and the information would be present in the final system. We could possibly increase the diagnostics signal table to 64bits and/or use some signal selection bits in the DIAG_CTRL register.

• The calculating of mean values for the Sigma/DeltaX/DeltaY values, in the FPGA, using a digital filter approach was discussed. This could be done on the fly for two bunches or could be done on data output using the data pattern engine. Both methods have pro’s and con’s and depends on when and what data users request. We will look further into implementing this as the design develops.

• CERN has been developing and testing VHDL/FPGA implementations of the synchronisation system and other FPGA VHDL components and have has some success with this. This input will help in implementing the system.

6.Software Design

CERN were generally happy with the overall software design. Some points discussed were:

• Some changes were made to the API’s to take into account Cycle types in a machines super cycle.

• The numBunches parameter in the PuCycleParam object should be an array, one entry for each corresponding phase table.

• CERN would like ‘C’ as well as ‘C++’ API implementations.

• CERN have asked some other internal staff to look at the software design and give any comments. None have been forthcoming so far.

7.Conclusions

CERN were generally happy with the TMS design and happy with the current level of design detail as a basis for agreeing to on-going TMS development. We will jointly discuss the ADC speed issue and update the current design documents with feedback from this meeting. We intend to make the updated design documents available to CERN on 24/11/2006 so that a formal agreement to the design can be made. A relatively quick decision on the ADC sampling rate is needed to achieve this.

It was noted that the development of the CERN TMS has a research and development side. As such the full detailed design cannot be set in stone at this stage. The design will be refined as development and feedback from actual tests with the PS machine are conducted.

A quick decision on the FPGA board design design is needed in order to allow us to progress on this, time critical part of the contract, especially with the Christmas holiday period approaching.