KLIPA DrvrSpec Dec83

This document, the "TOPS-20 KLIPA Driver Functional Specification," describes PHYKLP.MAC, the TOPS-20 port driver for the IPA-20 (KLIPA) device. Published in December 1983, it serves as the lowest level of software support for the CI-20 (likely a CI Bus).

Key Responsibilities and Interactions:

1. Architectural Position: PHYKLP.MAC is a passive service, primarily responding to requests from the higher-level SCAMPI.MAC protocol module. It's responsible for maintaining port-to-port virtual circuits between the local and remote systems on the CI, and providing an interface to CI services for these higher-level protocols.
2. KLIPA Microcode Interface: The driver communicates with the KLIPA port using a queued protocol, relying on seven doubly-linked queues (command, response, and free queues) managed via a Port Control Block (PCB) in the KL's memory. PHYKLP performs essential initialization steps like creating and initializing the PCB, loading the KLIPA microcode, and starting the device. Error information is reported via CSR bits, the response queue, and PCB error words.
3. PHYSIO Interface: As a standard TOPS-20 device driver, PHYKLP handles channel initialization (KLPINI), once-a-second device polling (KLPCHK) to detect new on-line nodes and establish virtual circuits using a three-way handshake, and interrupt service (KLPINT).
4. SCAMPI Interface: This is a major interface. PHYKLP provides services for SCAMPI to implement the Systems Communications Architecture (SCA) protocol, supporting three types of data transmissions: messages (guaranteed delivery), datagrams (delivery not guaranteed), and named buffers. PHYKLP maintains port-to-port virtual circuits, manages buffer transfers, and informs SCAMPI of critical events (e.g., nodes coming/going online, virtual circuit status changes, transfer completions, errors) via callbacks. SCAMPI is responsible for providing necessary buffers.
5. Data Structures: The driver uses Channel Data Blocks (CDBs), Port Control Blocks (PCBs), and System Blocks (SBs) to manage device and node-specific information, queue states, and communication parameters.
6. Error Processing: The system detects errors by monitoring CSR bits, examining PCB error words, and checking status fields in response queue entries. PHYKLP generates system error entries and console messages, and can trigger the reloading of KLIPA microcode if necessary.
7. Key Algorithms: The document details the specific procedures for KLIPA Initialization, the Once-a-Second Poller (for device health checks and network discovery), and KLIPA Interrupt Service (for handling incoming data and various error conditions).
8. Testing: PHYKLP is validated through Design Validation Testing (DVT) (fault insertion), the SCSTST test system (for SCAMPI and driver features), and the PAGES program (for continuous disk I/O verification).