The full TMS system has been produced and installed at CERN and is
under test. Training on the use of the TMS system has been carried
out. Some minor issues are being resolved. The FPGA and software
source code have been handed to CERN.
The following work has been performed:
Added support for second System Controller on live system.
Fixed Cycle Parameter generation system to support multiple
The FPGA now loads the PLL_FREQUENCY on CYCLE_START as well
as after the PLL_FREQDELAY.
Added the ability to view the raw State/Phase table's
generated in the TmsControlGui program.
Added tmsBackup utility.
Fixed a few bugs in the state table generation system.
Changed the phase orientation in the phase tables so that a
+ve phase value generates a lag in the waveform.
Increased the bit width diagnostics Post Trigger delay
parameter to 32bits.
Fixed a bug where SDRAM data writes could get currupted when
a large amount of data was being read from the system.
The Cycle Parameter information has been updated with the
additional pllCycleStartFrequency field. This defines the PLL's
frequency which is loaded on CYCLE_START. This setting is entended
to set the initial PLL frequency for a calibration period.
The Cycle Parameter information has been updated with the
bunchMask field. This bitmap defines in which RF bucket's the
bunches to be captured lie. bit 0 of this bit mask defines bucket 1
The orientation of the bunchMask, Mean0Mask and Mean1Mask
have been reversed so that bucket 1 is bit 0.
The system can now handle multiple injection events. The
cycle periods are now named CyclePeriodEvent* rather than
CyclePeriodHarmonic to reflect this.
The system now has an improved BunchMean system. This
calculates the mean of up to 24 individual bunches during data
capture as well as the overal mean for all bunches. The additional
DataInfo function setting of DataFunctionMean returns data from this
system. The top 2MBytes of each channels SDRAM is used for the data
storage of the mean values.
The BunchMean system now calculates the time for each sample
and returns a standard DataValue object with a time field instread
of a DataValueMean object that had a numSamples field.
The TmsControlGui application has been modified to handle the
3.Meetings at CERN during full system
During the TMS system training visit a number of discussions and
meetings were had with various CERN staff. This resulted in a list of
minor problems, issues and possible improved features for the TMS
system. The list of these is given below:
Jeroen has started performing detailed tests of the ADC raw
performance. Generally all looks fine. There were some minor ADC
issues on three of the PUPE boards. The boards involved are: 104,
108 and 118. Jeroen will send a document covering his findings. The
faults are on some of each boards ADC channels and include: 25Mhz
noise, clock jitter and what looks like a stuck bit. Jeroen has sent
these boards back to Alpha Data and we have installed the three
spare boards in their place.
There is a slight system design problem in the FPGA
firmware/software. The CycleInformation table only stores the timing
of the events to nearest millisecond. We need to store the timing
more accurately, by storing the actual DataTable address at which
the event and associated state change occurred, in the
CycleInformation table, so that data read from a cycle period is
from just after the event and the data set in SDRAM has the right
harmonic number. The DataTable address stored should be that at the
start of the orbit, ie synchronised to the local FREF. Note that
this will only be possible for CALIBRATION, INJECTION and HCHANGE
events where the PLL is locked and the local FREF is valid. For
other events the existing ms Timing table system will be used. A
small change to the FPGA firmware and associated software is
required to fix this.
The software's getData() call should set returned parameters
to 0 in the event of an error being returned.
We will lower the communications timeout to around 200ms so
that major faults, like when a Module controller is not responding,
returns an appropriate error within a shorter time.
We will add the ability to set the TMS system into simulation
mode using a single API calls as well as the current system and also
provides some means of determining this state using the API. This
will help CERN develop the TMS client software while the PS machine
is shut down.
There may be SDRAM write issues with the current, version
1.2.1, of the FPGA software when setting the simulation test data.
We will perform more detailed testing of this.
We have seen a Module controller hang very occasionally
during or immediately after a FPGA bit file upload. We will
Currently the TMS system only allows data to be read once a
cycle is complete. CERN would like the ability, in the future, to
read the data for an individual Cycle Period as soon as it is
available. We will look into the issues of achieving this. This work
could be done in the future if required.
Although the TMS specification did not call for it, it would
be useful to have an ejection event. The hardware has three spare
digital input lines and one of these could be used for this. The
FPGA firmware and software would need modifications to make this
work and CERN would need to determine how to provide the ejection
signal. This work could be done in the future if required.
4.Work To do
Generally the full TMS system is in a functional state at CERN.
There are some small issues to be resolved. The Proton Synchrotron
will not be running again until March and so more testing with real
BEAM data will need to wait until then. However the client software
side can be tested by running the TMS system in simulation mode and
tests can be made using the PS's calibration system.
Jeroen will continue with ADC tests and connecting up all of the
digital timing and analogue wires and the CERN cleint side software
will be further developed.