PHENIX MODE CONTROL - Version IIb

The PHENIX detector is a cyclic machine consisting of repeated patterns of beam events with interlaced functions such as calibration and FEE reset operations. Mode control of each detector subsystem has been assigned as a function performed using a number of mode control bits that are supplied to each FEM. Since many operations are cyclical in nature, there is a need to determine the most appropriate/efficient method of implementing this functions. Specifically, some decisions need to be made regarding the definition of a mode control command set and associated functions. The command set should be widely applicable to all PHENIX subsystems, though each subsystem may have some specific operations that will be handled by each subsystem-specific scheduler. Recent discussions regarding the use of optical links for the timing and control interface indicate that using an optical link will certainly expand the number of mode bits available. However, the preliminary definition given here doesn't require or consider the use of these extra bits.

II. Cycle Control Method

The cyclic nature of the detector allows for two primary methods of handling mode control of the FEM: FEM-defined and scheduler-defined approaches. It has been decided that the cycle be defined at the scheduler and implemented by low-level incremental commands via the mode control bits. This means that each cycle is defined using a low-level command set defined at the scheduler, and the FEM interprets and implements these single mode operations each beam clock. Resultantly, the scheduler has the overhead of putting the cycles together using single commands. This approach places more 'mode responsibility' on the scheduler since it has to generate complex cycle functions from low-level mode functions. One advantage of this method is complete control of the FEM by the scheduler, which would not be the case if each FEM were to implement cycle functions. If absolute control of the FEM by the scheduler is desired, mode commands must be output and executed each and every beam clock.

III. Timing & Control Interface

The hardware definition of the timing and control interface is given in Table 1. A total of 11 control bits are available for mode control, timing, and other functions (3 additional bits have been added to the initial specification). Under the new definition, 5 of the bits are reserved for mode control (MB4-0), 3 are used for providing timing signals (LVL-1, Beam Clock, and Beam ClockX4). The remaining 3 bits (MB7, MB6, and MB5) are available to each subsystem and can be used or ignored depending on the each subsystems control needs. The mode bits are output each beam clock cycle and are decoded to implement a specific command set. Each mode command will be sampled by the FEM on the rising edge of the Beam Clock and will be implemented on the following rising edge (or 1 Beam Clock period later). For a more complete timing definition of the timing and control interface refer to Sy Rankowitz's presentation given at the 1995 October Online at ORNL. One of the 3 extra mode bits may still act as a calibration pulse enable or other function as previously defined. For example, MB5 may act as the trigger to a pulser whose output is fed into the FEE of MVD for calibration. Complete flexibility exists with regard to MB5-MB7. These extra bits were added to the original specification because they already existed as part of the scheduler architecture, provide a means for each subsystem to handle special functions, and can be simply ignored (not routed anywhere) if not needed. Use of a GLink module for these bits allows complete transmission to each subsystem at no extra cost. Bits that are not used are simply not distributed past the optical receiver of the GLink.

IV. Command Summary

A set of common commands were agreed upon at the small group meetings held at Nevis during December, 1995. This set was determined to be sufficient for normal operations, diagnostics, monitoring, and calibration support. The common set is listed below.

Run

Run provides the means to start and continue acquisition. This pertains to all FEM functions including FEE control, AMU address list management, digitization, packet forming, and data transmission to the DCM, where applicable.

Halt

Halt is used to stop all FEM functions including FEE control, AMU address list management, digitization, packet forming, and data transmission to the DCM, where applicable. Halt provides a static state for serial operations associated with FEM configuration, monitoring, and diagnostics.

Initialization Reset (Init. Reset)

Init. Reset is used to place the FEM in an initialized state. All data, counters, etc. are reset but the configuration information is retained. ALM addresses are reset, LVL-1 qualified data and associated packets that have not been completely sent to the DCMs are lost. This reset will be used at powerup and for complete re-initialization of the FEM (in the event of a synchronization error, etc.).

Resync Reset

Resync Reset is used for the sole purpose of synchronously resetting the event counter in all FEM which will resynchronize all beam clock counters across the detector. The actual reset function will be performed on the next valid LVL-1 trigger to ensure this reset does not affect the processing of valid LVL-1 events by the FEM.

Special Reset

Special Reset provides a subsystem-customized reset operation. In some subsystems this function may require multiple beam clock cycles for execution. For example, MVD will require approximately 10 beam-clock cycles to execute an integrator reset command. For this and other commands requiring more than one beam clock cycle for execution, the scheduler should output the command the appropriate number of beam clock cycles. Some other subsystems may not need this command and can omit it from their command set altogether.

Next SL Command

One command code is reserved for implementing special operations that are configured using the serial port of the FEM (Next SL Command). Providing this capability allows for a large number of user-supplied, custom functions that may prove worthwhile especially during system development, testing, and diagnostics. When in normal use, PHENIX would most likely not use this control capability. One example SL Command is a diagnostic routine that generates a special event data packet composed of predetermined data values (AAh, 55h, etc.) As will be shown later, there are many unused command codes available which make the use of the SL function

All FEMs will powerup in the Halt All state. Careful design of the FEM is required so that all FEM functions start gracefully and predictably.

IV. Mode Bit Definitions

In defining the mode bit definitions several objectives were considered: standardization of the command set across all subsystem types where applicable, simplicity of commands, flexibility of commands for subsystem-specific functions, and developing a set that made the FEM operational state completely deterministic. A deterministic system for this application is defined as one whose functional state can be completely determined by observing the mode bits for any given beam clock (remember that the scheduler controls the FEM by issuing a mode control each beam clock). Use of a deterministic system allows one to determine the FEM operational state without knowledge of prior states. This will make both the scheduling, developing, and troubleshooting tasks more efficient.

The 5 mode bits have been split into 3 separate grouping, each defining a part of the operational state. MB4 is the Run/Halt Bit and defines the run status of the FEM (1=Run, 0=Halt). MB1 and MB0 are used to control the 'reset group' of commands (see Table 2). MB3 and MB2 provide another group of custom commands that are user defined (custom group). Tables 2 and 3 show the mode bits and associated commands that provide a simple, flexible, deterministic system.

Being deterministic allows a mode command structure where each command group can produce an operation regardless of what operation is specified in the other groups. This allows for multiple functions to be specified at once which can be both a benefit and a problem. For instance, a Run can be specified with both a Special Reset (integrator reset perhaps) and a Special Function 2 command. This makes the mode bits powerful but also allows for commands that may be incompatible if issued simultaneously. FEMs should be designed to handle invalid command sets by defaulting to a Run with no-ops for each of the other 2 command groups. It is safe to assume that error conditions (incompatible or undefined group commands) will be removed from the possible command list during system checkout and initial operation.