Handling CAMAC Interrupts in Alpha OpenVMS/PCI
K.S. Lee, S.G. Kadantsev, E. Klassen, M.M. Mouat, P.W. Wilmshurst
Tri-University Meson Facility (TRIUMF)
4004 Wesbrook Mall, Vancouver BC V6T 2A3, Canada
Abstract
Software for Alpha/OpenVMS systems has beendeveloped to support CAMAC interrupts (LAMs) via PCI
bus. A number of devices in TRIUMF's Central Control
System generate interrupts that are delivered via CAMAC
systems. These interrupts arrive using previously existing
CAMAC executive crates and system crate interfaces.
Until this development, these interrupts were only being
serviced by VAX/OpenVMS computers using Qbus but thetendency to replace VAXes by Alphas has required that thisLAM handling software be developed.
The initialrequirements, hardware and software configuration, driver
structure, and performance are described.
1 Introduction
TRIUMF's Central Control System consists of a mixture
of VAXes and Alphas running OpenVMS. Thesecomputers are organized into two mixed OpenVMS
clusters, a production and a development cluster. Access tocyclotron devices occurs through a CAMAC executivecrate architecture. Each executive crate supports up toseven serial and/or parallel CAMAC branches and allows
multiple CPUs access via hardware arbitration. TRIUMF’ scontrols group supports 5 executive crates. Each nodein each cluster is capable of addressing two or more ofthese executive crates. The CAMAC operations in bothtypes of CPU are provided by a set of user-written systemservice routines in the form of an installed, privileged
shareable image. This method was chosen over using aformal CAMAC device driver for performance reasons, thereduced overhead involved in servicing the CAMAC
operations.
A variety of devices in TRIUMF's Central Control
System such as the main operator console, the remoteconsole panels and protect monitors, generate interrupts(LAMs) that are delivered via the CAMAC systems. The
CAMAC interrupts on the VAX/OpenVMS computers
arrived via the Qbus are handled using the VMS connectto-interrupt driver (CONINTERR.EXE). When theinterrupt occurs, the CONINTERR will cause an
asynchronous trap (AST) procedure to execute in processcontext. A nonprivileged process called LAM_HANDLER
in the VAX gets an IO channel for the CAMAC device
GEC0 and issues a queued IO system call ($QIO) with theIO$_CONINTREAD function code specifying an AST
procedure to execute and an event flag to be set when theinterrupt is generated. There is a tendency is to replace theexisting VAXes with Alpha machines due to the better
price/performance of the Alphas. Unfortunately theconnect-to-interrupt driver that is available under

VAX/OpenVMS is not available under Alpha/OpenVMS.
This meant that migrating LAM related applications fromthe VAXes to the Alphas was not immediately possible..
As a result, a formal CAMAC device driver was developedfor handling the interrupts delivered via the CAMACsystems.
2 Hardware configuration
Two Alphas, an AlphaServer 2000 5/250 and anAlphaStation 600 5/266, each with a PCI local bus, areconnected to the CAMAC system via the LogicalCompany BCI-2100 Q-bus adapter[1]. A pair of TRIUMF
designed executive crate interfaces (0782/0783 modules)
form the connection between the Q-bus and the GEC
executive crate (figure 1). This architecture allows multiple
Alphas to access multiple executive crates and is found tobe quite flexible.
The PCI Q-bus adapter consists of a BCI-2100 PCIcontroller, a CAQ-2101 Q-bus module, and a CAB-1104-8
interconnect cable. The PCI Q-bus adapter enables thecomputer to read and write to the Q-bus address space andto control Q-bus interrupt requests and DMA transfers.
Currently, CAMAC interrupts are only generated in one
executive crate (GEC0).
CAMAC
Executive Crate

Q-Bus
Expansion Chassis

DECAlpha

TRIUMF 0783
Branch Coupler
BCI-2100

TRIUMF 0782
CAMAC
Interrupt

Figure 1. Hardware Setup for handling CAMAC Interrupt
3 Software configuration
A formal CAMAC device driver, written in C, wasdeveloped with the sole purpose of handling the CAMAC
interrupts. The benefit of using C is that it is easier to write
and allows a certain level of portability. Also, for RISC
machines, a good optimizing C compiler generates
machine code usually more efficient than codes using theMACRO-64 language. The driver does not support anyother CAMAC operation such as read and write operations.

Those are supported by the existing user-written systemservice routines in the form of an installed, privileged
shareable image.
The CAMAC driver offers a SETMODE function whichrequests an attention AST be delivered to an AST routine
in process context. This driver code also contains aninterrupt service routine which acknowledges a CAMAC
interrupt has happened and delivers an attention AST.
The CAMAC device driver is loaded into system virtualaddress space with its associated data structure innonpaged pool using the system management utility(SYSMAN) IO CONNECT command:$ SYSMAN$SYSMAN>IO CONNECT CMC0 /driver = cmc_driver/vector = 20 /node = 64/ adapter = 2 /csr = 0A nonprivileged process called LAM_HANDLER gets a
IO channel for the CAMAC device CMA0 and issues a$QIO call with the IO$_SETMODE function code
specifying an attention AST procedure to execute after theinterrupt service routine has completed. The AST routine
performs the necessary CAMAC operation to fully service
the interrupt and sets an event flag to trigger the re-armingof the AST notification with another $QIO call (figure 2).
Open VMS
AXP Executive
CAMAC Interrupt
IO_INTERRUPT

CAMAC
Device Driver
ISRw Write QPRw Read QVRw Fire AST

LAM_HANDLING
Process
AST Delivered

AST Routinew Clear Branch Demand
w Set Event Flag to re-arm
SETMODE Request

Figure 2. Control Flow for Handling CAMAC Interrupts
4 Driver structure
A device driver has to interact with the operating system
to process the specified I/O request[2]. In this case, theCAMAC device driver has to process a SETMODE I/Orequest. The driver consists of a set of routines and data
structures in nonpaged pool. The following is a brief
description of the CAMAC driver routines.
4.1 Initialization routines
A set of initialization routines are executed when theCAMAC driver is first loaded. This includes the drivertable initialization routine, the structure initialization

routine, the structure reinitialization routine, thecsr_mapping routine and the unit initialization routine.
The driver table initialization routine initializes
the Driver Prologue Table (DPT), the Driver Dispatch
Table (DDT) and the Function Decision Table (FDT)
structures.
The structure initialization routine initializes the device
Interrupt Priority Level (IPL) to 21 and the fork lock index
to 8. It also specifies the CAMAC device characteristics.
The structure reinitialization routine sets up the Interrupt
Transfer Vector Block (VEC) of the Channel Request
Block (CRB) to point to the interrupt service routine. Itinitializes the pointers from the Device Data Block (DDB)
to the Driver Dispatch Table (DDT) and the Unit Control
Block (UCB).
The csr_mapping routine maps the PCI configuration
space, the PCI memory space and I/O space into theAlpha's virtual address space by calling the platform
independent I/O bus mapping routine IOC$MAP_IO.
The unit initialization routine enables interrupt bywriting appropriate values to the Q-bus Control and Status
Register (CSR) and the Q-bus Priority Register (QPR).
4.2 FDT routine
The CAMAC driver has only one FDT routine forhandling the set mode function. It enables attention ASTs
so any process issuing a $QIO call with this function will
have an attention AST delivered when the CAMAC device
interrupts. It calls the COM_STD$SETATTNAST to do thefollowing: it allocates an expanded access control block(ACB) from non-paged pool to hold the AST procedurevalue, AST argument, channel number and PID. It thenacquires the device lock, raising IPL to 21, to synchronize
access to the attention AST list[3]. After inserting the ACB
into the attention AST list it releases the device lock andrestores the previous IPL.
4.3 Interrupt service routineThis routine is executed when a CAMAC interrupt
happens. It executes at device IPL 21 and calls
COM_STD$DELATTNAST to delivers all queued
attention ASTs. It enables further processing of interrupts
by writing to the Q-bus Priority Register and reading theQ-bus Vector Register (figure 3). In an environment wheremultiple executive crates can deliver interrupts, the contentof Q-bus Vector Register can be examined to find out
which executive crate has generated the interrupt.
5 Performance
Timing results are shown in table 1. The interrupt
handling time is measured as the length of time that thebranch demand is present. The VAX 4100 has the slowest
CAMAC interrupt handling time followed by the VAX
4105. The Alphas are quite a bit faster. The interrupt
handling time continues to decrease as the CPUs get faster.
Handling time gradually increases with an increase insystem load. This
increased
XX1FFFFF

could

2MB

explainedbyXX0FFFF4 - FF

Unused Locations

XX0FFFF0Q-Bus Test Point Register (TPR)

SIMM Memory

XX0FFFEC

Q-Bus MAP Register 4 (MR4)

Address Space

XX0FFFE8Q-Bus MAP Register 3 (MR3)

XX0FFFE4

Q-Bus MAP Register 2 (MR2)

XX100000
XX1000C0be

Q-Bus Control Registers 1MB

XX0FFFE0

Q-Bus MAP Register 1 (MR1)

XX0FFFDC

Interrupt Control Register (ICR)

XX0FFFD8

Q-Bus Address Register (QAR)

XX0FFFD4

Q-Bus Maintenance Register (QMR)

XX0FFFD0

Q-Bus Priority Register (QPR)

Q-Bus PIO

XX0FFFCC

Q-Bus Vector Register (QVR)

Address Space

XX0FFFC8

Q-Bus Data Register (QDR)

XX000000

theXX0FFFC4Write Status Register (WSR)

XX0FFFC0

Control/Status Register (CSR)

Figure 3. Q-bus Control Address SpaceSystem
AlphaStation 600 5/266
AlphaServer 2000 5/250
VAX 4105
VAX 4100

Length of branch demand
150 µsec
184 µsec
233 µsec
384 µsec

Table 1: Timespan of branch demand present when system
is 1-3% busy

System Business
Percentage~1%~ 10 %~ 20 %~ 30 %~ 50 %~ 80 %

AlphaStation 600
5/266
150 µsec
166 µsec
173 µsec
183 µsec
184 µsec
195 µsec

AlphaServer2000 5/250
184 µsec
202 µsec
211 µsec
212 µsec
227 µsec
230 µsec

As expected, there is also a dependency on the systemload. Table 2 shows that t he average CAMAC
interrupt
The nature of the system load also affects the timing. As
we see in table 3, when the Alpha is kept 100% busy doing
only CAMAC cycles, the increase in the CAMAC interrupt
handling time is very small. Whereas there is a greater
increase in time when the computer is doing various
activities such as updating X-terminal displays, accessing
disks, the network and other peripherals.
SystemAlphaStation 600 5/266
AlphaServer 2000 5/250

Length of branch demand
153 µsec
186 µsec

Table 3: Timespan of branch demand present with system
kept busy at 100% doing CAMAC cycles
The results indicate at least a one-third improvement inCAMAC interrupt handling time from a VAX 4105 to anAlphaStation 600.
6 Summary
To facilitate the migration of programs from VAXes toAlphas, a CAMAC device driver was developed in theAlphas for handling interrupts delivered via the CAMACsystems. The hardware and software structure of the device
driver is discussed and the interrupt handling timing results
are presented.
In general, the interrupt handling time in the Alphas isfaster than that in the VAXes. A dependency on the CPU
power and the system load is observed. The current driver
supports CAMAC interrupts generated in a single
executive crate (GEC0). However, it is possible to support
interrupts from multiple executive crates by examining theQ-bus Vector Register.
References

Table 2: Timespan of branch demand present with varying
system load
activities at IPL (interrupt priority level) above zero which
will lengthen the CAMAC interrupt handling time (whichhappens at IPL 23) as well as the attention AST deliverytime (which happens at IPL 2).

[1] BCI 2100 Q-bus Adapter for the PCI Local Bus
Owner's Manual (The Logical Company)[2] Writing OpenVMS Alpha Device Drivers in C bySherlock & Szubowics (Digital Press)[3] OpenVMS AXP Internals and Data Structures byGoldenberg & Saravanan (Digital Press)