TMS - Cycle Periods

Introduction
============
There are some issues with the current TMS when looping is employed within
the PUPE's FPGA TimingSwitchTable and in other similar cases. Also it would be good
to collate data (same CyclePeriod) across multiple state transitions (especially
EVENT_DELAYED) assuming the data format is the same (harmonic, bunch mask etc).

Current Implementation
======================
The PUPE has:

StateTable:		Software state table describing states.
DataTable:		Raw Simga,DeltaX,DeltaY data in DDR memory.
CycleTimingTable:	One entry per ms with the cycle time and DataTable's address.
TimingSwitchTable	State transition information and state information (16 entries)
CycleInformationTable	Entry for each timing event (16 entries)

The PUPE's TimingSwitchTable has 16 entries describing the state of the PUPE. The PUPE will move to a
new state when a suitable event occurs. The TimingSwitchTable provides information on which state to
move to on each of the events: CYCLE_STOP, CAL_START, CAL_STOP, INJECTION, HCHANGE and DELAYED. The
TimingSwitchTable moves to state 0 on CYCLE_START from the end state 15. (If two events occur
simultaneously, is there a priority as to which one gets used ?)

The software StateTable matches the TimingSwitchTable but has more information on each of the states,
including the harmonic number, bunch mask and which CyclePeriod the data belongs to.

On each TimingSwitchTable state transition an entry is added to the CycleInformationTable. This
records the event bit-mask that caused the change, the CycleTimingTable's address and the DataTable's
address. (Is an entry made on each event or on each event that causes a TimingSwitchTable transition ?)

The software uses the CycleInformationTable to break up the data into CyclePeriod's. The CyclePeriod is
an enum that can be CyclePeriodAll, CyclePeriodCalibration, CyclePeriodEvent[0-9]. The software uses
the event bit mask in the TimingSwitchTable to determine the CyclePeriod's type and sets the
CyclePeriod appropriately. In the case of INJECTION or HCHANGE events the software just increments the
CyclePeriod counter (from CyclePeriodEvent0). The CyclePeriod counter is used to match to the
StateTable to get information on the period.

It is this aspect that causes the problem as it does not catch looping and/or multiple INJECTION events
correctly.

New Implementation
==================
In the FPGA:
1. Make sure the CycleInformationTable only contains entries for each event that causes a state change.
   (not strictly necessary but would reduce the possibility of overrunning the CycleInformationTable)
2. Store in the upper 3 bits of the CycleInformationTable's 64bit entry, the TimingSwitchTable state
   number we are now in.

In the Software:
1. Change the CyclePeriod's to be: CyclePeriodAll, CyclePeriodCalibration, CyclePeriodInjection[0-9],
   CyclePeriodHChange[0-9].
2. For each CycleInformationTable entry, determine the event and state and create suitable CyclePeriods
   with appropriate information from the software StateTable (harmonic number, bunch masks etc).
   There can be multiple INJECTION periods and multiple HCHANGE periods. Loops can be catered for and
   delayed states.
3. Optionally in the software StateTable, we could add a flag to indicate that multiple INJECTION events
   should be combined into one CyclePeriod or other such options etc.
   
Adding the TimingSwitchTable state number to the CycleInformationTable will allow other software
strategies as well.