3.3 Front-end Systems (G64)

The lowest level of computer functionality (excepting intelligent devices such as the CAEN high voltage units described in section 3.3.1) is vested in the G64 systems. These are located in the electronics counting rooms adjacent to the detector in the experimental cavern. The number of G64s used by each detector partition is shown in table 3.2.

Table 3.2: A summary of the G64 crates and Elementary Processes used by each detector partition. The numbers of Slow Controls detector-monitoring (SC) and gas-system G64s are given, as well as the numbers of Elementary Processes for high voltages (HV), low voltage electronics (LV), temperature monitoring (temp), fastbus power supply monitoring (FB), and others.
$ ^{m)}$
indicates that the G64 Skeletons or VAX Elementary Processes (EP) have been modified (often only slightly) for functions specific to a particular detector partition.
$ ^{p)}$
indicates that partition-specific programs, not based on the G64 Skeleton or standard Elementary Process, are used.

Note that the gas-system G64s run a different program from the detector-monitoring G64s. The functions of the individual G64s and Elementary Processes enumerated here are detailed in table C.1.
\begin{abox*}
% latex2html id marker 5766
{\textwidth}%
{%
\begin{tabular}{\vert...
... & % other EPs
\multicolumn{1}{l}{} \\ \cline{1-8}
\end{tabular}%
}%
\end{abox*}


A full list of G64s and Elementary Processes and a summary of their functions is given in table C.1. In total 88 G64 crates are used: 50 for the detector monitoring and control, 34 for the gas systems,3.3and 4 for the magnet.


3.3.1 G64 Hardware

G64 is a simple 64-line microprocessor bus developed by the Gespac company [98], though the term is often used to designate the entire computer system. Its simplicity has led to the production of a number of cheap input/output cards, and is thus well suited to an experiment, such as DELPHI, with a requirement to monitor and control a very large number of channels, without particular emphasis on speed.

The MAC-G64 chassis [99], designed by CERN ECP division initially for ALEPH, has also been used by DELPHI (figure 3.2).

Figure 3.2: The MAC-G64 and CAEN crates. The MAC-G64 crate (on top) consists of a G64 bus below a MAC bus. The G64 bus contains, from left to right, a double-card CAEN interface, two digital input/output cards, a G64-ethernet interface connected to thinwire ethernet, a CPU card with two RS232-C connectors, and a disk controller and drive. The MAC bus contains a double-card CAEN interface, two digital input/output adapters, and the power supplies on the right. Below the MAC-G64 crate is a CAEN high voltage crate, connected to the G64 by CAENnet.
\includegraphics[height=.5\textheight]{g64-caen-colour}
It contains two card frames; the lower has a G64 bus, whilst the upper is used to hold the MAC (monitoring and control) cards [100] which are tailored to specific input or output functions (such as multiplexing analog signals). These cards are read out using a small selection of G64 cards (typically analog-to-digital converter (ADC) and digital input/output cards) in the lower cardframe. This separation enables a small number of cards to be used for a variety of functions, simplifying the software and the maintenance of the hardware. In addition, the electrical separation of the MAC and G64 buses reduces noise problems by allowing the MAC cards to be separately grounded.


3.3.1.1 G64 cards

The G64 system was designed with the 6800-series of 8-bit microprocessors in mind. The CPU card [101] used by DELPHI includes the Motorola 6809E [102] microprocessor, 256 kilobytes of RAM, 32 kilobytes of ROM, two serial (RS232-C) interfaces, and a real-time clock. Peripherals on the G64 bus are memory-mapped, normally into a 1-kilobyte region, the Valid Peripheral Address space, which is decoded on the CPU card.

Since the 6809 has a 16-bit address bus, it can only directly address a maximum of 64 kilobytes. Additional memory (either RAM on the CPU card or RAM/EPROM on other G64 cards) can be addressed by using a paging facility on the CPU card, which allows, in our case, different 32-kilobyte sections of memory to be brought into use under program control.

Communication with the VAX systems is effected using a G64-ethernet interface [103]. This contains a 68000 processor, onboard RAM and EPROM, and the LANCE ethernet chip. The G64 CPU has access to a window of the 68000's RAM, and the 68000 can access all of the 6809's address space, allowing DMA transfers.

Two broad configurations of G64 cards have been used by DELPHI. `Development' systems contain a CPU card, EPROM card containing parts of the operating system, floppy disk controller card and $ 3\ensuremathbox{\frac{1}{2}}''$ disk drive, ethernet card, and various input/output cards. Once the system is considered stable, the EPROMs are filled [104] with the application program and the floppy disk drive and controller are removed. This `production' system can run with or without a terminal connection.


3.3.1.2 Input/Output cards

The main input/output G64 cards used are a Parallel Input Adapter (PIA) card for reading digital statuses, analog-to-digital converter (ADC) cards (10- and 12-bit resolution) for reading analog voltage levels, and an Output Register card to control digital states. The output register card is preferred to the PIA card for control, as all its outputs go to the same (off) state when the G64 crate is switched on or reset. Each ADC card has 16 channels; the digital input/output cards have 32.

Many of the required ranges accepted by the G64 input cards, or voltages produced by the output cards, are not suitable for direct connection to the detector. The conversion and electrical isolation is performed by the MAC cards: input adapters, relay cards, platinum resistance thermometer (PT100) temperature adapter cards, etc. Multiplexer cards, coupled with a PIA card, allow a single ADC channel to monitor 32 input voltages, albeit more slowly. The type of each MAC card can be read out by a special G64 card, allowing a crosscheck between program configuration and the actual hardware installed.


3.3.1.3 CAEN High Voltage Unit

Most high voltages required by DELPHI are provided by the CAEN SY127 system [80] (figure 3.2). Each crate can control up to 40 channels, divided into modules of 4 channels each. Different modules can be fitted for different channel characteristics, such as maximum voltage or current resolution.

The CAEN crates can be accessed by a front-panel keypad and LED display, by terminal (using a menu-driven system), or from the G64. Normal operation in DELPHI relies on the link to the G64, which is effected via a G64-CAEN interface and then CAENnet to the CAEN crate. CAENnet allows up to 100 crates to be daisy-chained together, allowing a total of 4000 channels to be controlled and monitored from a single G64-CAEN interface.

CAEN channels are normally maintained at a constant voltage (V0) unless the current drawn exceeds a preset limit (I0). In this case, the CAEN can be set either to trip (switch off) that channel immediately, or to enter a constant-current mode for a prespecified time before tripping (unless the load is reduced in the meantime). When voltages are changed, they ramp up or down at a preprogrammed rate. After the command to start ramping has been given, the CAEN is free to accept other commands for the same or different channels. All these parameters can be individually set or read (for each channel) from the G64. The channel statuses (i.e. whether on, off, tripped, etc.) and actual voltages (VMON) and currents (IMON) can also be read from the G64.

In the event of a computer failure, the operator can initiate a hardwired central ramp-down of all CAEN high voltages; this ramps the CAEN to an alternate set of voltages (preset to zero in the CAEN), and subsequently triggers a `kill'.


3.3.2 G64 Software


3.3.2.1 System Software

The G64 `operating system' is extremely primitive, and contains no facilities for multitasking.

The 4 kilobyte monitor program in EPROM handles the initialization, and provides basic routines for terminal and disk input and output. When the system is switched on or reset, the monitor either bootstraps the operating system from disk (in the development systems) or loads the application program from EPROM.

The FLEX disk operating system [105] allows the editing, compilation, and running of programs from disk.

Most application programs for the G64 have been written in Omegasoft Pascal [106]. As well as standard Pascal features, this compiler allows the program to be split into separate modules, and allows direct addressing of memory-mapped peripherals.

The size of the DELPHI standard application program is considerably larger than the 64-kilobyte address space can hold. A mechanism has been developed to allow different modules of a program to be placed on different pages in memory, overcoming this problem [107]. Calls between Pascal routines on different pages are made in a transparent fashion.


3.3.2.2 Communications

Communications between the VAX and G64 systems [108] use the OSI transport protocol over ethernet (IEEE $ 802.3$). The protocols are handled by the Marben Osiam product [109], running in the G64-ethernet card. An interface to this, CATS/TP4 [110], has been implemented on the G64-ethernet card, using the CATS (common access to transport service) calling standard developed at CERN [111]. CATS attempts to standardize calling sequences to different transport protocols and implementations. A simple protocol allows CATS calls on the G64 to be executed by CATS/TP4 on the G64-ethernet card, using the shared-memory window.

Remote Procedure Calls (RPC) [112] are used both on VAX and G64 to communicate commands and data. RPC is based on a client-server model, and allows network calls (i.e. calls to CATS) to be hidden from the application. The client application calls an application-defined routine, which is implemented on the server. The RPC system takes care of transmitting the request, along with the input parameters of the call, to the server. The server RPC system then calls the requested routine with the parameters decoded from the received message, and, upon its completion, sends back the return parameters to the client RPC system, which returns them as output parameters to the client application. RPC also handles the translation between different number representations, such as the different floating point representations used by the VAX and Omegasoft Pascal on the G64.


3.3.2.3 Application Program (G64 Skeleton)

Most G64 systems run a standard program, the G64 Skeleton [113], though a few use dedicated programs (marked $ ^{p)}$ in the SC G64 column of table 3.2).

The G64 Skeleton, being at a low level and running on a comparatively slow computer, was designed for greatest simplicity. Essentially it tries to hide from the VAX the details of accessing the hardware, providing little `intelligent' control, while at the same time minimizing the amount of communications necessary with the VAX.

Control and inquiry functions are implemented as remote procedures callable from the VAX (i.e. RPC with VAX as client, G64 as server). For efficiency, a single remote procedure call can read or set a number of channels if desired.

The G64 Skeleton executes a continuous program loop, monitoring all input channels. Any status change is flagged by calling a reporting routine on the VAX via RPC (i.e. G64 as client, VAX as server). Again, for the sake of efficiency, if the G64 detects several status changes within one monitoring loop, up to 10 of these are buffered into a single call.

The RPC/ CATS/OSI connections are initiated from the VAX and repeatedly checked with application-watchdog messages from both sides.

A simple model of the hardware is presented to the VAX: channels are classified either as digital input, digital output, analog input, analog output, or CAEN. Except for CAEN channels, all values are represented as integers at this level: 0 or 1 for digital channels, or ADC counts (e.g. 0 to 1023 for a 10-bit ADC) for analog channels. Since the CAEN communicates voltages and currents in units of the resolution of the relevant module (whose type need not be known to the VAX), the G64 Skeleton program applies appropriate scale factors so that the VAX can use volts and microamperes for all CAEN channels, regardless of their type.

Digital and analog input channels are monitored continuously. The error status of analog channels is determined using a desired value and two error limits. If the monitored value differs from the desired value by more than the first error limit, then the channel goes into error. In order for the error to be cancelled, the value must return to within the (narrower) second error limit. This hysteresis prevents frequent state changes when the value hovers around the limit. State changes in either direction (going into, or out of, error) cause a notification to be sent to the VAX.

CAEN channel statuses are monitored continuously, and any changes are reported to the VAX. While the actual voltages and currents are readable by command from the VAX, these are not continuously monitored by the G64, since any faults here will be signalled by the CAEN with a status change.

Digital setting, analog setting, and CAEN channel settings are only accessed by explicit initialization or changes requested from the VAX.

The channels to be monitored and their desired ranges are defined by RPC commands from the VAX. In addition, the G64 Skeleton program can be cleanly tailored for the few systems with special needs, such as those with special hardware or with a requirement for fast or particularly reliable intervention at the G64 level. (For example the Forward RICH stops TMAE flow immediately if the temperature drops below 25 $ \ensuremathbox{^\circ}$C.) This allows most systems to be run from a standard EPROM, while maintaining flexibility.

Tim Adye 2002-11-06