[TEG.SPEC]TIMING_FUNC_SLC.TXT 20 Sept 1999 SLC Control System Timing Software 1. Overview. The main purpose of the SLC Control System timing software is fourfold: to drive or program all timing devices to produce the desired outputs, to maintain a database of current and default settings of all timing devices, to provide an interface with which an operator can adjust any timing value, and to provide an interface by which automatic feedback can do likewise. Since beam production and choice of target or dump are largely controlled pulse-by-pulse by timing devices, timing outputs must be controllable from a central scheduler. Any single timing channel is generally programmed to produce any one of a set of possible settings in response to a fairly concise command message broadcast to all micros at 360 Hz by this scheduler (known as MPG, master pattern generator). Driving or programming individual timing channels is done by the micros through camac. The typical timing channel (PDU channel) is capable of responding on each 360th of a second to an 8-bit code which selects timing value (in effect an offset relative to the accelerator's 360-Hz timing fiducial) from the channel's internal memory. Each PDU channel's internal memory is loaded or updated asynchronously through camac by the micro to which that PDU channel belongs. The database of timing settings is threefold: Each timing device is identified in the SLC operational database. An extension (known as TMATRIX) of the SLC operational database holds, for each individual timing channel, an array of timing values indexed by base beamcode. (Base beamcode is a 5-bit field in the MPG's 360-Hz output broadcast message.) A subset, known as timing configurations, of the configurations archived or reinstated by the SCP's configuration software contain timing values for sets of timing devices. The operator interface consists primarily of touchpanels, one or more per micro, on which are buttons for selecting any one of the given micro's timing devices, and, for a given base beamcode, adjusting the current value in the selected device. An individual timing value can be activated, set to a new value, deactivated, reactivated, or knobbed. Activation sets the channel's value to a reference value from the device's entry in the SLC operational database. Deactivation causes the channel's output to cease but remembers the present setting; reactivation reinstates the remembered setting. Timing touchpanels also have buttons for producing displays of timing settings, in three basic styles: for currently selected base beamcode, current settings for all timing channels in currently selected micro; for all base beamcodes, current states (activated, deactivated, never activated) of all timing channels in currently selected micro; for all beamcodes and for single currently selected timing channel, timing values and conditions under which those values apply. The operator interface also includes timing configuration touchpanels. The definition (known as template) of any timing configuration includes an explicit list of timing channels; single base beamcode is selected each time a given timing configuration is saved. It should also be noted that the timing software provides a few online hardware diagnostics (PDU, PNET, MBCD). 2. Time Criticality. The fiducial is the most time-critical thing, and consists of merely an edge. It has mainly three properties: its (approximate) period, its granularity, and its stability. Its stability (not its granularity) limits the accuracy of any timing channel's output. Its period is approximately 1/360 second = 2.77 milliseconds, and follows variations in the SLAC power source frequency, with further period variation of up to 103 microseconds as needed to facilitate bunch injection into HER or LER. The fiducial's granularity is 1/(476 MHz) = about 2.101 nanoseconds, though most timing channels outside of PEP2 are programmable with granularity 8.403 nanoseconds. In many places granularity is made finer by further delays programmable into VDU's or into other devices that use timing channel output. The fiducial's label is the next most time-critical thing. Just when between fiducials the label is received is less critical, but there must be exactly one between any two consecutive fiducials. The fiducial's label is most specifically the data output by camac function code F19, which the micro broadcasts usually to module 31, generally as soon as possible after the preceding fiducial. The micro derives the F19 data from the message broadcast at 360 Hz by the MPG. Next most time-critical thing is simultaneity of a timing adjustment done to more than one timing channel, say by multi-knob software, or to a VDU and its PDU channel. 3. Dependencies within Timing Database. Any timing value is generally the sum of several values, such that changing one value can cause a (small or large) group of values to change by the same amount. Examples: Moving one PDU:TREF value moves all timing values in the given PDU's crate. Moving one PDU:BPMT value moves all BPM-related timing values in the given PDU's crate. TNOMINAL is added to any timing value, and is indexed by base beamcode within micro. Moving one TRIG:PDUT value moves the reference value for just that one TRIG (single non-BPM-related timing channel). PDU:TREF and TRIG:PDUT can each be two-valued to distinguish between PEP2 HER and LER. Any timing value as retained by software (in the TMATRIX) includes several flag bits, one of which indicates deactivation. Three of these flag bits are for use in PEP2: one indicates whether the given timing channel on the given base beamcode is intended for use with HER as opposed to LER; another indicates ring fiducial as opposed to injection fiducial; another indicates ring turnaround rate (about 136 KHz) as opposed to max 360 Hz. 4. Further Conditions Imposable on Timing Channel Output. The SLC regional beamcode software allows specifying up to a dozen or so conditions for any individual timing channel on a given base beamcode, where any such condition is a logical expression in the bits in some subset of the PNET broadcast (extended fiducial label). The PNET broadcast message consists of both numerical values (e.g. beamcode, damping ring turn delay count, PSK parameter) and individually named bits (e.g. NO_GUN_PERM, DUMP_2_9, SBDARCN, SBDARCS, etc.). The bit subset used in a logical expression is arbitrary per individual timing channel, but is limited in number of bits referenced for any crate group. Logical expression is always tied to base beamcode. With any one logical expression is also associated a timing value sum expression, which may or may not refer to the timing channel's TMATRIX value for the given base beamcode, and may refer to zero or more TMVA's, each of which is an individually named timing variable that can be used to move (knob) the timings of an arbitrarily scattered set of timing channels as one. Timing value sum expression may simply specify deactivation under the given condition. Any SCP can edit conditional expressions belonging to a given timing channel, though downloading the result entails suspending the given micro's timing outputs for a few seconds while PDU and PAU memories are cleared and reloaded. 5. Timing Device Types Details of the timing timing software are largely dictated by the design of the timing hardware devices. The main timing device is the PDU (Programmable Delay Unit). The PDU has sixteen channels, each treatable as an independent device. Each channel produces as its output an edge whose timing is programmable relative to the machine's 360-Hz timing fiducial. Each channel has an internal memory 256 24-bit words long, which the timing software typically loads with values kept in the TMATRIX. Each channel has a mode register selecting which 8-bit fiducial label (out of at most 6 broadcast by camac function code F19) should be used by that channel as an index to select timing value from the PDU's memory on any 360th of a second; the timing software loads this mode register when the PDU's crate is brought online and otherwise leaves it unchanged. Three of these modes identify beamcode-driven triggers (known in the operational database as TRIG's and also used by PAU, KLYS, and other database primaries), allowing the programmed timing value to be relative to the fiducial just before beam crossing time, or the fiducial one 360th of a second earlier, or the fiducial two 360ths of a second earlier. Another mode is entirely beamcode-independent, utilizing a register in the PDU which counts from 0 to 35 at 360 Hz, indexing the first 36 locations in the memory of a channel (known in the operational database as TRBR) programmed in this mode. The timing software synchronizes this modulo-36 counter in all PDU's in all micros, using a reference broadcast by the MPG on PNET. One more of these modes, known as "YY-mode", identifies PDU channels that are reserved for use in capturing beam-synchronized data. Of each 16-bit word transmitted by F19, beamcode is the high-order 8 bits, and YY is the low-order 8 bits. The YY code's purpose is to coordinate measurements made by more than one micro in such a way that all can measure the same particle bunch as that bunch travels through the machine. The YY code is generally nonzero on only a subset of beam production pulses. The VDU (Vernier Delay Unit) is simply wired in series with a PDU channel's output, and is programmable in steps of about 0.1 nanosecond. The VDU does not see the 360-Hz F19 broadcast. The timing software's 360-Hz interrupt routine programs only those VDU's to whose PDU channels regional beamcode conditional expressions have been assigned; the micro reprograms other VDU's only when an operator makes a setting or adjustment to them. The PAU (Programmable Analog output Unit) is a single-channel analog output device whose output is controllable pulse-by-pulse. The PAU does receive and heed the 360-Hz F19 fiducial label. The PAU translates the 8-bit effective beamcode value into a 5-bit index, which in turn selects analog output value (having about 0.1% accuracy), presumably already programmed into the PAU's internal memory by the micro owning the PAU. In the SLC micros, the timing software is responsible for managing each PAU's beamcode translation table, while the magnet software is responsible for managing each PAU's internal memory of analog settings. 6. Timing for Beam-Synchronized Data Acquisition. In the existing SLC control micros, software that programs PDU channels owned by BPMP's (or by TORO's, GADC's, etc.) is part of the BPM software, and is quite separate from the software that programs PDU channels for general (non-BPM-related) timing purposes. At the beginning of any BPM data acquisition, the requesting SCP sends a "prep" message to all micros involved in that acquisition, causing the BPM software in each micro to allocate YY values (each of which indexes a location in any PDU channel's internal memory), and compute and write timing values into those locations. The requesting SCP gives the signal (to the MPG) to begin a measurement only after it knows that all timing setup has been completed for that measurement (without disturbing any already ongoing or pending measurements). The existing PEP2 RINQ BPMP is the most complicated BPMP, and is the only one containing its own programmable processor (DSP). The retrieved measurement may be an aggregate of individual measurements. The RINQ BPMP's gate input is from a PEP2 PPDU channel programmed to occur at ring turnaround rate. The RINQ BPMP terminates and cleans up any ongoing measurement upon having counted the expected number of ring turnarounds or upon detecting "gap" in its gate input or upon receiving a new F16A1 setup command (8 data bits), whichever occurs first. Absence of gate input for a dozen turns is plenty to signal this gap. The first gate input (beginning of 136 KHz pulse train) after both gap and F16A1 precisely marks the beginning of the next measurement. Granularity of programmability of PPDU output is made finer by a vernier delay programmed within the RINQ BPMP. Extraction by the micro of measurement data from RINQ BPMP's is interrupt-driven if the quantity of data is small, and otherwise occurs in a less time-controlled way; in both cases, the BPMP is generally unavailable until after all data for a given measurement has been extracted. The PAU, though primarily an output device, also contains an ADC (with resolution of max 12 bits) operating at 360 Hz and recording each reading into a location in internal memory indexed by 5-bit translation of effective beamcode. BPM data acquisition software can capture this ADC data, and can vary PAU analog output values, each in a beam-synchronized way during an acquisition.