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
adjacent to the detector in the experimental cavern.
The number of G64s used by each detector partition is shown
in table 3.2.
G64 is a simple 64-line microprocessor bus developed by the Gespac company , 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 , designed by CERN ECP division initially for ALEPH, has also been used by DELPHI (figure 3.2).
The G64 system was designed with the 6800-series of 8-bit microprocessors in mind. The CPU card  used by DELPHI includes the Motorola 6809E  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 . 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 disk drive, ethernet card, and various input/output cards. Once the system is considered stable, the EPROMs are filled  with the application program and the floppy disk drive and controller are removed. This `production' system can run with or without a terminal connection.
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.
Most high voltages required by DELPHI are provided by the CAEN SY127 system  (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'.
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  allows the editing, compilation, and running of programs from disk.
Most application programs for the G64 have been written in Omegasoft Pascal . 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 . Calls between Pascal routines on different pages are made in a transparent fashion.
Communications between the VAX and G64 systems  use the OSI transport protocol over ethernet (IEEE ). The protocols are handled by the Marben Osiam product , running in the G64-ethernet card. An interface to this, CATS/TP4 , has been implemented on the G64-ethernet card, using the CATS (common access to transport service) calling standard developed at CERN . 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)  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.
Most G64 systems run a standard program, the G64 Skeleton , though a few use dedicated programs (marked 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 C.) This allows most systems to be run from a standard EPROM, while maintaining flexibility.
Tim Adye 2002-11-06