Computer_Interconnect_Specification_198111
Subj: Remember it's a prelim. spec. The phys. channel has yet to be added.
Title: Computer Interconnect Specification
File: HYDRA::WRKD$1:[THOMPSON.CISPEC2]CISPEC.MEM
Date: 15-NOV-81
Authors: D. Thompson
J. Buzynski
J. Hutchison
Contributors:
R. Casabona
R. Giggi
R. Stewart
W. Strecker
Abstract: This document describes and specifies the implementation
independent functional characteristics of the Computer
Interconnect (CI) and its system interfaces.
Revision History:
Rev # Description Authors Date
1 Draft Thompson, 1-MAY-81
Buzynski,
Hutchison
2 Add priority queued Thompson, 15-NOV-81
model, misc. changes. Hutchison
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 2
1.0 SCOPE . . . . . . . . . . . . . . . . . . . . . . . 5
2.0 NOTATIONAL CONVENTIONS . . . . . . . . . . . . . . . 5
3.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 6
4.0 GLOSSARY OF TERMS . . . . . . . . . . . . . . . . . 8
5.0 REFERENCE DOCUMENTS . . . . . . . . . . . . . . . . 9
5.1 CI Design Memoranda . . . . . . . . . . . . . . . 9
5.2 Port Architecture And Implementation
Specifications . . . . . . . . . . . . . . . . . . 9
5.3 Higher Level Protocols . . . . . . . . . . . . . . 9
5.4 CI Diagnostics . . . . . . . . . . . . . . . . . 10
5.4.1 CI Node Tester . . . . . . . . . . . . . . . . 10
5.4.2 CI Network Exerciser . . . . . . . . . . . . . 10
6.0 OVERVIEW OF THE CI . . . . . . . . . . . . . . . . 11
7.0 ARCHITECTURAL LAYERS . . . . . . . . . . . . . . . 15
7.1 Port Layer . . . . . . . . . . . . . . . . . . . 16
7.2 Data Link Layer . . . . . . . . . . . . . . . . 18
7.3 Physical Channel Layer . . . . . . . . . . . . . 19
8.0 PORT SPECIFICATION . . . . . . . . . . . . . . . . 22
8.1 Path Selection . . . . . . . . . . . . . . . . . 26
8.2 Sequentiality And Priority . . . . . . . . . . . 28
8.3 Datagrams . . . . . . . . . . . . . . . . . . . 29
8.4 Virtual Circuits . . . . . . . . . . . . . . . . 30
8.5 Datagrams (General-purpose) . . . . . . . . . . 32
8.6 Messages . . . . . . . . . . . . . . . . . . . . 33
8.7 Data Transfers . . . . . . . . . . . . . . . . . 34
8.7.1 Writing Data . . . . . . . . . . . . . . . . . 36
8.7.2 Reading Data . . . . . . . . . . . . . . . . . 39
8.8 Configuration . . . . . . . . . . . . . . . . . 44
8.9 Diagnostic And Booting (Maintenance) Operations 48
8.9.1 Loopback . . . . . . . . . . . . . . . . . . . 48
8.9.2 Resetting Remote Systems . . . . . . . . . . . 50
8.9.3 Writing Remote System Memories . . . . . . . . 52
8.9.4 Reading Remote System Memories . . . . . . . . 55
8.9.5 Starting Remote Systems . . . . . . . . . . . 59
8.10 Maintenance/Configuration Datagram Service . . . 61
8.11 Unrecognized Packets . . . . . . . . . . . . . . 62
8.12 Port Performance Counters . . . . . . . . . . . 62
9.0 CI INTERFACE AND SYSTEM STATE . . . . . . . . . . 63
10.0 DATA LINK SPECIFICATION . . . . . . . . . . . . . 70
10.1 Packetization . . . . . . . . . . . . . . . . . 70
10.1.1 Framing . . . . . . . . . . . . . . . . . . . 71
10.1.1.1 Character Sync . . . . . . . . . . . . . . . 71
10.1.1.2 Packet Length/Type . . . . . . . . . . . . . 72
10.1.2 Addressing . . . . . . . . . . . . . . . . . . 73
10.1.3 Packet Integrity . . . . . . . . . . . . . . . 74
10.2 Channel Control . . . . . . . . . . . . . . . . 75
10.2.1 Arbitration . . . . . . . . . . . . . . . . . 75
10.2.2 Acknowledgement And Retransmission . . . . . . 77
10.2.3 Data Link Performance Counters . . . . . . . . 79
10.3 Data Link Structured Specification . . . . . . . 80
10.3.1 Global Definitions . . . . . . . . . . . . . . 80
10.3.2 Transmitter . . . . . . . . . . . . . . . . . 82
10.3.3 Receiver . . . . . . . . . . . . . . . . . . . 86
11.0 PHYSICAL CHANNEL SPECIFICATION . . . . . . . . . . 88
11.1 Channel Character . . . . . . . . . . . . . . . 88
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 3
11.2 Isolation Scheme . . . . . . . . . . . . . . . . 88
11.3 Bit Transmission And Reception . . . . . . . . . 89
11.3.1 Encoding And Decoding . . . . . . . . . . . . 89
11.3.2 Packet Format . . . . . . . . . . . . . . . . 90
11.3.3 Bit Synchronization . . . . . . . . . . . . . 90
11.3.4 Trailer . . . . . . . . . . . . . . . . . . . 91
11.4 Carrier Detection . . . . . . . . . . . . . . . 91
11.5 Media -- Cables And Couplers . . . . . . . . . . 91
11.6 Input/Output Signal Level Specification . . . . 91
11.6.1 Driver Power Output Specification . . . . . . 91
11.6.2 Receiver Input Power Specification . . . . . . 92
11.7 Input/Output Signal Timing Specification . . . . 92
11.7.1 Driver Output Signal Timing . . . . . . . . . 93
11.7.2 Receiver Input Signal Timing . . . . . . . . . 93
12.0 CONFIGURATIONS . . . . . . . . . . . . . . . . . . 95
12.1 Physical Topologies . . . . . . . . . . . . . . 95
12.2 Installation Rules . . . . . . . . . . . . . . . 95
12.2.1 Installation Rules For Signal Cables And
Couplers . . . . . . . . . . . . . . . . . . . 95
12.2.2 Power, Grounding And Site Preparation For
Installation . . . . . . . . . . . . . . . . . 96
12.2.2.2 Primary Power Distribution: . . . . . . . . 97
12.3 Addressing . . . . . . . . . . . . . . . . . . . 97
12.4 Installation Of A New Node Onto An Operational
Cluster . . . . . . . . . . . . . . . . . . . . 98
12.5 Bus Maintenance And Temporary Configurations. . 98
12.5.1 On-Line Maintenance Procedures . . . . . . . . 98
12.5.2 Use Of Extender Cards . . . . . . . . . . . . 99
12.6 Allowed Configuration Exceptions . . . . . . . . 99
12.7 Mechanical Considerations . . . . . . . . . . . 100
13.0 DIAGNOSTIC AND MAINTAINABILITY REQUIREMENTS . . . 101
APPENDIX A CI OPCODE SUMMARY
APPENDIX B EXAMPLE OF NODE BOOTING VIA CI
B.0.1 Locally-Loaded System . . . . . . . . . . . . . B-1
B.0.2 Remotely-Loaded System . . . . . . . . . . . . . B-2
B.0.3 A Booting Example -- 11/780 . . . . . . . . . . B-4
APPENDIX C MINIMAL IMPLEMENTATION OF DUAL PATH INTERFACE
APPENDIX D IMPLEMENTATION FUNCTIONALITY
D.0.1 Implementation Functionality Field . . . . . . . D-1
D.0.2 Implementation Functionality Summary . . . . . . D-2
APPENDIX E ACTIVE EXCHANGE HUB SPECIFICATION
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 4
APPENDIX F L0100 LINK SPECIFICATION
F.1 TABLE OF CONTENTS . . . . . . . . . . . . . . . . F-2
F.2 REFERENCE DOCUMENTS . . . . . . . . . . . . . . . F-4
F.3 GENERAL . . . . . . . . . . . . . . . . . . . . . F-5
F.4 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . F-6
F.5 LINK INTERFACE . . . . . . . . . . . . . . . . . F-18
F.6 MECHANICAL . . . . . . . . . . . . . . . . . . . F-41
F.7 APPENDIX A . . . . . . . . . . . . . . . . . . . F-42
F.8 APPENDIX B . . . . . . . . . . . . . . . . . . . F-43
F.9 APPENDIX C . . . . . . . . . . . . . . . . . . . F-44
APPENDIX G CHANGE HISTORY
G.0.1 Revision 1 To 2 . . . . . . . . . . . . . . . . G-1
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 5
1.0 SCOPE
This document comprises the functional specification of the
Computer Interconnect (CI). Included are the system-independent
electrical and mechanical characteristics and the specifications
of the data link and controller protocols.
The higher level protocols for system intercommunication used
with the CI are not specified since many such protocols may be
accommodated on a single CI connected system.
Also not specified are the implementation-specific details of
the various interface (port) architecture and option
specifications.
2.0 NOTATIONAL CONVENTIONS
All numbers are decimal unless otherwise specified.
Hexadecimal numbers are noted by a suffix of "(hex)", for example,
1A(hex). All packets (sometimes called "frames") are shown as
composed of 8-bit bytes (sometimes called "octets"). Least
significant bytes are shown at the top of the diagram (numbered
lowest). Bits of a byte are numbered from right to left (bit 0 on
right), with the rightmost bit the least significant.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 6
3.0 INTRODUCTION
The Computer Interconnect (CI) is an interconnect for
intercomputer communication. A computer is defined (minimally) as
a memory-processor pair where the processor may be a central or
I/O processor. The need for an efficient, cross-product
compatible, general-purpose intercomputer communication link comes
from several sources:
1. "Intelligent" I/O systems with significant computing
capability used for diagnostics, error correction,
transfer control, etc.
2. High availability systems structured as a network of
closely coupled computers, each with their own independent
memory and operating systems.
3. Load sharing systems, where a number of closely coupled
computers share, say, a common file system.
An example of a CI coupled cluster is shown below in Fig. 3-1:
_______________________________________________
| | |
| | |
+-----+ +-----+ +-----+
| Ici | | Ici | | Ici |
+-----+ +-----+ +-----+
+-----+ | +-----+ | +-----+ |
| | | | | | | | |
| Pio |----------- | Pc |------------ | Pc |-----------
+-----+ | | +-----+ | +-----+ |
| | | |
+----------+ +-----+ +------+ +------+
| | | | | | | |
| M(buffer)| | Ms | | Mp | | Mp |
+----------+ +-----+ +------+ +------+
Ici --> CI Interface (Port)
Pc --> Central Processor (e.g. VAX-11, PDP-10/20, PDP-11)
Pio --> I/O Processor (e.g. HSC50)
Mp --> Primary memory
M(buffer) --> I/O system buffer memory
Ms --> Mass storage
Fig. 3-1: Typical CI-Coupled Cluster
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 7
The primary characteristics of the CI are as follows:
o Data Bandwidth: 70 Megabits/second raw bus bit rate (per
path)
o Topology: Logically multi-dropped, Physically radial
o Maximum number of nodes: 16 with "passive hub", 224 with
"active exchange"
o Maximum distance between nodes: 90 meters, all nodes
maximum of 45 meters from central point.
o Medium: 2 coaxial cables (per each of two channels),
serial data transmission.
o Channel Access Control: Carrier-Sense, Multi-access,
Round-robin slotted arbitration. Reserved immediate
acknowledgement.
o Data Format: Packets, 7 to 4100 bytes (excluding bit
synch, header and trailer).
o High-Availability: Dual-Path access with no
single-component failure of both paths.
o Intercabinet Isolation: Transformer coupling (high DC
isolation).
o Communication mechanisms: Variable length buffer to
buffer transfers, messages, datagrams.
Some of the primary non-characteristics of the CI are:
o Security: There is no protection against malicious users
in the areas covered by this specification.
This specification consists primarily of the
implementation-independent architectural and electrical
characteristics of the CI. However, implementation is described
where it is deemed to be the most appropriate manner of
specification. Additionally, implementation examples are given in
some sections to increase clarity and ease of understanding.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 8
4.0 GLOSSARY OF TERMS
1. Port Address - 8-bit addressing number on the CI. Each port
address is unique on a CI. May be part of higher level
addresses. A system may have multiple ports and therefore
multiple port addresses.
2. Path - Logical and Physical connection of Data Links over
which packets may be transmitted and received.
3. Port - Interface of a system or node to a CI. May be a single
or a dual path interface.
4. Host Computer - A computer system, nominally a processor and
memory, with or without other components. In this context,
systems are the "host" system connected to the CI via a port.
5. System - A host computer and its port(s).
6. Node - Same as a system (used interchangeably).
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 9
5.0 REFERENCE DOCUMENTS
The following is a list of CI related documents:
5.1 CI Design Memoranda
1. Strecker, W., "ICCS Arbitration", Internal DEC Memorandum,
(November, 1979).
2. Casabona, R. and Thompson, D., "ICCS Architecture
Specification", DEC Specification, AUG 79 (Original CI
Specification).
3. Thompson, D., "Preliminary Results of ICCS Arbitration Study",
Internal DEC Memorandum, FEB 80.
5.2 Port Architecture And Implementation Specifications
1. Strecker, W. and Thompson, D., "VAX-11 CI Port Architecture
Specification", DEC Specification, MAR 80.
2. Carrafiello, M., "CI 780 Functional Specification", DEC
Specification, FEB 81.
3. Dossa, Don, "LCG CI Port/Port Interface Specification", DEC
Specification, AUG 81.
4. Documentation on HSC 50 CI architecture and interface (to be
supplied), target date unknown.
5.3 Higher Level Protocols
1. Strecker, W., "Systems Communication Architecture", DEC
Specification, JAN 81.
2. Kronenberg, Nancy, "VMS Systems Communication Services
Specification", DEC Specification, AUG 81.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 10
5.4 CI Diagnostics
1. Sarni, John. "CI Diagnostic Strategy", DEC Memorandum, JAN 82
(target date).
5.4.1 CI Node Tester -
1. Heller, Liz and Giggi, Bob. "CI Node Tester Functional
Specification", DEC Specification, 4 MAR 81.
2. Hennesey, Rich. "CINT Control Software Design Specification",
DEC Specification, AUG 81.
3. Klumpp, Jim. "CINT Responder Software Functional
Specification", DEC Specificaton, MAR 82 (target date).
5.4.2 CI Network Exerciser -
1. McMillen, Dave. "CI Network Test Protocol Specification". 1
MAY 81 (target date).
2. Roemer, Fred. "CI Exerciser Design Specification", DEC
Specification, SEP 81.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 11
6.0 OVERVIEW OF THE CI
The CI is a logically multi-dropped "computer room"
interconnect for building "closely-coupled" multicomputer
clusters, where computers may be central processors or dedicated
I/O or special purpose sytems.
CI nodes usually have dual paths for high availability.
However, both paths are regarded as parts of a single CI. All
dual-path interfaces, or "ports", must be designed such that a
"very low" probability exists that a failure will incapacitate
both paths with respect to communication between other pairs of
nodes. Rather than specify the actual probability, it has been
defined that low probability means that the failure of any single
component of the node (at any level) may not simultaneously
preclude cluster communication on both paths. Such a failure
within a node may, however, preclude it from communicating with
any other node.
Single path CI nodes are required to be connected to path 0.
This ensures that all nodes on a CI may communicate at least on
path 0 (under error-free conditions).
A logical diagram of a CI cluster is shown below in Figure
6-1.
CI PATH 1
<----+----------+---------------------------------------+----->
| | CI PATH 0 |
<----------+---------+---------+-------------------+---------->
| | | | | | |
| | | | | | |
+---------+ +--------+ +--------+ +---------+
| Port 0 | | Port 1 | | Port 2 | | Port 3 |
|---------| |--------| |--------| |---------|
| | | | | | | |
|Computer | |Computer| |Computer| |Computer |
+---------+ +--------+ +--------+ +---------+
Fig. 6-1: Single and Dual Path Ports
The physical implementation of the CI is a radial
configuration, with a central hub coupler. The hub coupler is
used for increased electrical reliability. Additionally, the
"star" type configuration is efficient with respect to cable
lengths in a "computer room" environment.
The type of hub determines the maximum number of nodes. For
up to 16 nodes, a "passive" transformer-coupled hub is used. For
extended distance connection of only two nodes, a special coupler
may be provided in the future. It will also be possible to use an
active "exchange" hub for up to 224 nodes to increase the
available cluster bandwidth (by allowing multiple, simultaneous
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 12
transfers between node pairs). Special restrictions are likely to
be imposed in such configurations.
An example of a configuration using the 16-node coupler is
shown below in Fig. 6-2. More information in this area can be
found in the Configuration section.
The bus is multi-access with no single node performing a bus
master function. As a result, the removal of any node from the
bus does not preclude continued communication between the other
nodes. Such removal can be accomplished on-line, that is, while
the other nodes of the cluster continue to communicate.
Three major types of communication mechanisms are supported.
Datagrams, the simplest, provide "best-effort" delivery of single
data blocks from one node to the next. Messages provide a more
reliable transfer of similar data blocks using "virtual circuits".
Virtual-circuit controlled delivery is sequential, non-duplicated,
and error-free.
The block data transfer service (DMA) is used to move large
blocks of buffer data. Large blocks are divided into multiple
sub-blocks and non-atomically transferred. The data service also
uses virtual circuits and is therefore guaranteed sequential and
error-free.
The CI is packet-oriented. Packets are integral numbers of
bytes from 8 to 4100 bytes in length (excluding bit synch, header
and trailer). Transmission is Manchester-encoded serial at 70
Megabits/second.
The physical interconnect consists of two coaxial cables per
path (one for transmit, one for receive). The cable connections
are transformer coupled on the interface card for high
inter-cabinet isolation. The central hub is an impedance-matching
coupler for reducing reflections and increasing immunity between
individual node connections. Dual-path clusters have two separate
hubs with each system connected to each hub by two cables (one
transmit, one receive per hub).
Addressing is on a per node basis, with each node having one
address that is unique on the particular CI.
Packets are framed by a special start character and a byte
count carried in the packet header. A 32-bit CRC character is
attached at the end of the packet for detection of transmission
errors.
The bus is multi-access with equal priority for all nodes
(time averaged). The arbitration method is distributed and uses a
slotted, dual-priority, round-robin algorithm with carrier
detection. Any collisions are detected by the packet integrity
check.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 13
+-----------+
| |-----------------+
| SYSTEM 0 | |
| | |
| | |
| |----------------------------+
+-----------+ | |
| |
+-----+ |
+-----------+ | HUB | |
| |---------------| 0 | |
| SYSTEM 1 | | | |
| | +-----+ +-----+
| | | | | |
| |-------------------------| HUB |
+-----------+ | | | 1 |
| | +-----+
| | |
+-----------+ | | |
| | | | |
| SYSTEM 2 | | | |
| |-----------------+ | |
| | | |
| | | |
+-----------+ | |
| |
| |
+-----------+ | |
| |-------------------+ |
| SYSTEM 3 | |
| | |
| | |
| |----------------------------+
+-----------+
Figure 6-2: Dual-path, Hub-coupled (passive)
CI Cluster (16 nodes maximum)
Acknowledgement of packets is immediate, that is, bus time is
reserved immediately after each packet for the receiver to send
back an acknowledgement. The type of acknowledgement returned
depends on the result of the transmission. If any error in the
packet was detected, no acknowledgement is sent and the
transmitter detects the problem via timeout. If the packet was
correctly received and buffered (at least in the interface), a
positive acknowledgement (in the form of a special packet) is sent
to the original packet source node. If the packet is correct but
the interface is unable to buffer it, a negative acknowledgement
is returned. Retransmission occurs in any case except positive
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 14
acknowledgement, following a defined algorithm. The limits on the
algorithm are designed such that if failure is detected at the
limits, it is very likely that a "hard" failure has occurred.
Note that that certain transient "errors" can occur in correctly
operating clusters due to congestion. These errors are
effectively handled by the retry mechanisms.
A CI interface, generally referred to as a Port, is
conceptualized as an intelligent controller designed to reduce the
load on the host processor for intercomputer communication. The
functionality of the interface is defined with respect to the CI
by this specification and on the host side by the implementation
port architecture and hardware specifications.
The Port consists of three functional components. These are
the Port Processor, Packet Buffer, and Link/Front End as shown in
Fig. 6-3. The Port Processor interfaces to the host memory and
controls the Link and Packet buffers. The Port Processor is
responsible for data mapping, address translation, buffer loading,
packet interpretation, and control of the host interconnect and
Link. The Packet Buffer is a temporary storage interface between
the Link and the Port Processor. It is not imperative that the
buffer actually exist. Rather, it is a "virtual buffer". The
concept of buffer "fullness" is represented by the temporary
inability of the interface to accept the data from the bus at the
bus rate. For example, the buffer might actually be a small FIFO.
If an implementation does not fully buffer packets, it must be
highly likely that the data can be accepted for the entire packet
at the bus rate. Cluster bandwidth could be greatly reduced by
ports that lost a high percentage of packets due to buffer
overflow.
The Link is responsible for the implementation of most of the
data link protocol and moving the data between the CI and the
Packet Buffer. The Front End performs the bit level operations of
bit encoding/decoding and carrier detection.
+--------------+ +-----------+ +-----------+ CI
| | | | | |
H --| PORT | | PACKET | | LINK/ |-- PATH 0
O | PROCESSOR |---| BUFFERS |---| FRONT END |
S | |---| |---| |
T --| | | | | |-- PATH 1
| | | | | |
+--------------+ +-----------+ +-----------+
Fig. 6-3: CI INTERFACE FUNCTIONAL COMPONENTS
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 15
7.0 ARCHITECTURAL LAYERS
The CI is architecturally specified as three layers. The
bottom layer, the Physical Channel, describes the transmission
medium, bit encoding/decoding and carrier detection functions.
The middle layer, the Data Link, encompasses the functions of data
packetization and channel control. The top layer, the Port,
describes the protocols used between ports to provide the highest
level communication mechanisms. The interface of the Port to the
next highest layer is implementation dependent and beyond the
scope of this document. This necessitates overlap of this
specification with the various port architecture specifications,
which do, in fact, specify this interface.
It is intended that the specification of the internal
function of each layer be independent of the other layers such
that implementation changes within a layer are effectively
isolated. In practice, however, it is recognized that
hardware/firmware/software tradeoffs may not dictate such a
separation. Ideally, information used in one layer is ignored and
untouched by all the lower layers through which it is passed.
Information used by a layer is "peeled" off before passing to a
higher layer. The exceptions to this are in addressing and
framing. Framing at the Port level is implicit in the Data Link
framing. Addressing information is also used by both the Data
Link and Port levels.
These three layers correspond to a portion of the
four-layered System Communication Architecture (SCA). The
Physical Interconnect layer of the SCA is implemented in the
Physical Channel and Data Link layers of the CI. The Port layer
of the CI corresponds to the Port portion of the Port/Port Driver
(PPD) layer of the SCA. Note that the implementation dependent
interface between the Port and Port Driver is shown with a broken
line, since it is not included in this specification. Fig. 7-1
shows the correspondence of the architectural layers.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 16
SCA CI
|
|
3. I/O Applications (SYSAP) |
|
--------------------------------+
|
2. System Communications |
Services (SCS) |
|
--------------------------------+
|
|
1. Port/Port Driver (PPD) +- - - - - - - - - - - - - - - -
| 1a. Port
|
--------------------------------+-------------------------------
| 0b. Data Link
|
0. Physical Interconnect (PI) +-------------------------------
| 0a. Physical Channel
|
--------------------------------+-------------------------------
Fig. 7-1: SCA and CI Architectural Layers
7.1 Port Layer
The Port layer provides three main communication services
over the CI: Datagram, Message and DMA.
The Datagram service provides delivery of a single packet to
a single remote destination on a best-effort basis. The packet
may be variable size up to 4089 bytes (text length). The actual
maximum size may be limited by prior agreement between nodes to
less than that. However, all nodes must accept datagrams of a
minimum of 58 bytes in length (text).
A datagram will be discarded if buffering for it is
unavailable in the receiving node. No provision is made for
notifying the sender of the loss. However, provisions do exist
for counting discards at the receiver. Higher-level protocols
using the datagram service must accomodate its characteristics.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 17
The Message service provides a sequential, error-free,
delivery service via node-to-node independent virtual circuits.
The virtual circuit state is maintained in each node on a per-port
basis for all active ports. The circuit state consists of one bit
indicating that the circuit is open (on) or closed (off) and two
single-bit sequence numbers, one for transmitting message packets
and one for receiving message packets. Before a message can be
successfully sent from one node to another, the corresponding
sending and receiving sequence numbers must be equal and the
circuits opened. This is accomplished via higher-level protocols,
an example of which is the System Communication Services of the
System Communication Architecture. The specification of such a
protocol is beyond the scope of this document.
The Message mechanism is only to be used for "trustworthy" or
highly predictable communications since errors of any type result
in circuit closure (requiring reinitialization).
The Block Data transfer mechanism provides a reliable,
multiple-packet transfer service for moving blocks of data from a
buffer in one node to a buffer in another node. This mechanism
uses the same port-to-port virtual circuits used for Messages.
This guarantees sequential, non-duplicated transfers. Data
transfers can be accomplished in both directions, namely a "read"
or "write" with respect to one of the nodes. The buffers are
named and the name must be passed in prior agreement via a
higher-level protocol. Such a protocol is beyond the scope of
this document. Note that any errors in the Data transfers close
the virtual circuit, disabling both data and message
communications.
Maintenance and Configuration services are also provided for
establishing system configuration/state, booting and aiding in
diagnosis of ailing nodes. These mechanisms provide datagram
class service.
Path selection is necessary in dual-path clusters. This
function is seen as a port layer function primarily because it is
legitimate for data link transfers to simultaneously occur on both
paths (with certain restrictions). The port layer has the duty of
multiplexing packets between paths. The path is normally selected
on a random, equal-priority basis to balance the load. However,
nodes may elect to use a particular path for reasons of path
verification or communication with single-path nodes.
A node does not necessarily have to support the ability to
simultaneously use both paths (for transmission or reception). An
example of a minimal implementation of a dual-path interface using
a considerable amount of shared hardware is discussed in the
Minimal Implementation appendix.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 18
7.2 Data Link Layer
The Data Link layer provides the port with reliable delivery
of single packets across the Physical Channel. It performs
packetization of blocks of data and channel access/control.
Packetization includes framing, addressing, and integrity
checking. Framing is accomplished by marking the beginning of the
packet with a special "start-of-header" character, called the
character sync. The end of the packet is determined by a packet
length, which is included in the packet and immediately follows
the character sync.
Addressing is accomplished by following the packet length
with destination address. The address is the node number. Each
node has one address which is unique on the particular CI to which
it is connected. A second copy of the destination address is sent
in complemented form to increase the reliability and preclude
single component failure sources. The source address is carried
to allow the destination port to return acknowledgement.
The integrity of the packet is checked by carrying a 32-bit
Cyclical Redundancy Check (CRC) Character. The CRC computation is
performed in the sending interface and the result is appended to
the packet. Upon receipt of the packet, the computation is
repeated and the result checked against the value sent with the
packet. If the comparison is true, the probability is high that
the packet was, in fact, correctly received.
Channel access and control consists of arbitration,
acknowledgement and retransmission (if necessary).
Arbitration uses a slotted, round-robin priority scheme.
Node priority is changed on a round-robin basis such that all
nodes have equal avcerage priority. The "slot" is the discrete
time interval required under worst case configurations to
synchronize all nodes. The slot is non-zero due to bus delays.
Carrier sense is used to determine when transmission should begin,
with each node waiting a unique number of slots in a saturated
system.
A node receiving a packet must immediately acknowledge the
receipt. Immediately following the transmission of a packet on
the bus, all nodes wishing to transmit must wait a minimum time
for the packet destination node to return an acknowledgement
packet.
The nature of the acknowledgement is dependent on the results
of the transmission. If the packet was not successfully received
due to collision, bus error or busy receiver (on other path), the
packet is not acknowledged The transmitting node detects this by
timing out on acknowledgement receipt (NO_RSP). If the packet was
successfully received and buffered in the interface, a positive
acknowledgement (ACK) packet is returned. If the packet was
correctly received but the interface was unable to buffer it, a
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 19
negative acknowledgement (NAK) is returned.
In the case of transmission failure (NO_RSP/NAK), the sending
node makes an equal probability decision to immediately arbitrate
and transmit or wait a delay. If delayed, the same decision is
made at the end of the delay period. This is repeated until
retransmission occurs. This random delay (exponentially
distributed) is used to break possible deadlock situations.
Retransmissions are limited. The limits are designed such
that under worst case conditions, failure to correctly transmit a
packet in a correctly functioning cluster will not occur more than
once per year. For further detail, see Data Link subsection on
acknowledgement and retransmission.
|
| The data link layer is logically duplicated in dual path
| interfaces. Implementations may actually share a considerable
| portion of the hardware in dual path implementations (see data
| link specification and minimal dual path implementation appendix).
7.3 Physical Channel Layer
The Physical Channel layer is the interface between the data
link layers of two nodes. The data packet is conditioned and sent
out on the media by line drivers to be received on the "other end"
of the media. The data, addressing, crc, leader and trailer are
complete when the packet is passed to the Physical Channel. This
layer performs media specific tasks in transferring the data over
the bus. Included are generating the data clock, manchester
encoding and decoding the data, and driving and receiving the
media, generation of carrier detect logic signals, and the
transport of data signals from node to node. This layer provides
the electrical compatibility between nodes and a dependable means
of data transport in a hostile environment.
A major design goal is to provide the ability to "dock merge"
the system, that is to ship working parts to the customer without
first testing the assembled configuration (ie, computer cluster).
The two important factors are electrical isolation and interface
circuit compatibility between nodes. In order to guarantee
interface compatibility and "dock mergability" a single
implementation for the Physical Channel is intended to be common
between all CI options presently planned. The actual circuit
design, component layout and media are critical in meeting the
interface specifications.
Another goal of the design is to provide for reliable and
available operation. Reliable operation means that normal
environmental affects and component failure (or service technician
mistake) will not break the communication channel. Environmental
affects considered are radiated/conducted interference, low
frequency voltage offsets between nodes, and static discharge.
The design also allows any one component to fail (or be yanked
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 20
out) without disrupting communications over the remainder of the
channel.
The Physical Channel is multipath and each path is half
duplex in theory. In practice there can be only one path or there
can be two paths with logic shared between them giving reduced
cost/performance and still maintain CI compatibility. A path of
the CI physical channel could be full duplex except for the nature
of some types of couplers. Many couplers will combine inputs from
all transmit cables and drive this signal on all receive cables,
only one driver at a time can use a path and full duplex isn't
possible for any node. The complete CI channel has four coaxial
cables, two for transmitting and two for receiving data. There is
one send/receive pair per path and two independent data paths.
Each path transfers 70 Megabit of serial data per second at
baseband frequency. In a path the transmit and receive data is on
separate media as opposed to being multiplexed onto one coax cable
(i.e., TDM or frequency multiplexing). The transmit and receive
cables are separate to allow future expandability using an active
center hub: an amplifier or packet switching exchange. Redundant
paths provide for reliable operation as one failure can only
affect one path and for availability as one path can be repaired
while the other provides communication over the physical channel.
If the redundancy or additional data bandwidth of two path CI
clusters is not important for an application only one path is
needed.
The functional blocks of the Physical Channel at an
individual node are: two drivers, two receivers, the carrier
detect circuits, encoders, decoders, and the transmit clock. All
of these get their power only from the host node and are connected
to logic reference of that node (logic ground). The circuits in
separate nodes do not share a common logic reference. These
functional blocks are described in the next two paragraphs.
From a practical design standpoint the driver, receiver and
carrier detect circuits must be dedicated to their cables (two of
each used for a two path system) while the rest of the parts may
be shared between paths to reduce cost. The driver is connected
to that path's transmit cable and the receiver/carrier detect
circuits to the receive cable with two separate transformers on
the circuit board. The carrier detect function is to provide a
logic signal that is true while valid data signal levels are
present on the receiver input (for each path). Carrier detect
cannot tell if the data is sensible or if only one driven signal
is present. The carrier detect circuit is intended to provide for
"look before talk with no collision detect" Link layer protocol.
Circuits at the node which may be easily shared between paths
are the encoder, decoder, and transmit clock generator. The
encoder/decoder are used to combine/separate the data from the
clock in a Manchester scheme. These circuits run at a data rate
of 70Mbit/sec. The coding scheme could also be called synchronous
baseband biphase encoding and guarantees a data transition in the
middle of every bit time by exclusive-or'ing the clock with the
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 21
data. The coding scheme not only allows clock and data to share
one signal line but also eliminates the low frequency (and DC)
components of the signal. The result is the fidelity of the media
need not be as high, there is no skew between clock and data, and
transformer AC coupling is possible. The final circuit at the
node is the transmit clock generator. The Physical Channel layer
makes a crystal stabilized 140.00 Mhz. clock which is used to
encode the data and is counted down and given to the Link Layer
circuits as a system clock.
The Physical Channel has a center hub to connect all cables
from the individual nodes together in a radial or star
arrangement. The center hub is composed of up to two independent
"star couplers"; there is one coupler for the each send/receive
path (redundancy). The coupler combines the signals from all node
transmit cables for a path and then splits the composite signal up
equally into all the receive cables going back to the nodes of
said path. The coupler also terminates all cables in their
characteristic impedance. A single coupler may be a passive
device without any power source for up to 16 node systems
(inclusive). The shields of all the cables in a path are
connected together to the coupler chassis. The cable shields and
the coupler chassis are isolated from all the nodes at low
frequency. Note that the cable shields are RF decoupled to node
chassis (I/O panel) using a capacitor. The coupler chassis may be
connected to the earth reference provided by another DEC chassis
but this is unnecessary.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 22
8.0 PORT SPECIFICATION
This section describes, in detail, the functionality of the
Port layer required by all CI ports for each communication
mechanism. Not all aspects of the protocols are specified. In
particular, the initialization protocols are not specified. This
is for the following reasons:
Although the CI is specified independent of implementation,
due to its high performance, it is very likely that portions of
the protocols will be implemented in hardware and firmware, rather
than in host software. In fact, the line has been drawn in just
such a manner in the first implementations. Therefore, the CI
specification includes primarily the aspects of the protocols that
are currently implemented in hardware and must therefore not
change for compatibility of nodes over the life of the CI. This
does not restrict hardware/software partitioning of future
implementations, but merely defines certain portions of the
protocol that must "appear" to be identical from the perspective
of another node on the CI. Obviously, the initialization
protocols in communicating nodes must be compatible, but, in fact,
multiple protocols may be used, depending on the particular
| application. For the purpose of this specification, the port/data
| link interface is modelled as a pair of buffers; one transmit,
| one receive. A buffer holds the entire body and parameters of a
| single packet. The port process performs operations as given by
| the port driver by loading the transmit buffer. The data link
| layer is responsible for transmitting the buffer and returning
| transmission status to the port.
|
| Whenever the data link receives a packet on the CI, it loads
| the receive buffer. The port unloads the packet and either passes
| it to the port driver or performs an operation internal to the
| port.
|
| Note that the specification of the port/port driver interface
| is beyond the scope of this document. Such information can be
| found in the individual port architecture specfications.
|
| The operations of the port, both those passed from the port
| driver and those intiated by received packets, are performed with
| certain guarantees of ordering. For further detail see the
| subsection on sequentiality and priority.
All implementations must be compatible with this model. Not
all mechanisms of this layer must be implemented in all ports. A
minimum subset as noted in the descriptions, must be provided.
The services are specified in terms of actions performed by
the port layers in the sending and receiving nodes and the format
of packets used in the service. The packets are, in fact,
described in the port layer as a packet body with a set of
parameters. The subsequent sections describe primarily the packet
bodies. of
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 23
The general format of the packet BODY passed between the port
and data link layers is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| FLAGS | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| |
| TYPE SPECIFIC |
| |
| | :B - 1
+-------------------------------+ + BODY_LEN
Where:
Byte Bits Field Description
B <7:0> OPC Opcode. Indicates
type of packet. All
opcode values with
bit 7 are reserved
for local port use.
B + 1 <7:0>= FLAGS Flags. Special
FLAGS<7:0> miscellaneous opcode
modifiers. Flags used
for each type are shown
in each packet diagram.
All unused flags Must Be
Zero (MBZ).
B + 1 <7>= PF Packing format. Implies
FLAGS<7> type of data packing to
be used in destination
port. Value is implemen-
tation specific. Used in
DG, LP and MSG packets only.
F Force Reset. Value of 1
indicates that reset is
unconditionally to be
performed. Used in RST
packet only.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 24
DSA Default Start Address.
Set to indicate that a
implementation-specific
default starting address
should be used. Used in
STRT packet only.
P Basic packet size for
return data transfer.
P = 0 for 512 bytes.
P = 1 for 576 bytes.
Used in data and maint-
enance data packets only.
B + 1 <6:4>= M Packet size multiple.
FLAGS<6:4> Packet data length
= (M + 1) * basic
size determined by P.
Used in data packets
only.
B + 1 <1>= NS Sending Sequence Number.
FLAGS<1> Used for virtual circuit
packets.
B + 1 <0>= LP Last Packet. Indicates
FLAGS<0> last packet of a data
transfer.
B + 2 TYPE Packet type specific
through SPECIFIC information.
B + 1 + BODY_LEN
The parameters passed to or from the data link layer with
each packet BODY are:
1. DST -- node number to receive the packet if transmitting
or number of this node if receiving this packet. The
value ranges from 0:15 if a passive hub is in use
(arbitration enabled) or 0:223 if an active exchange is in
use (arbitration disabled).
2. SRC -- Number of this node if sending this packet or
number of the node which sent the packet if receiving this
packet. The value range is the same as the Destination
address.
3. BODY_LEN -- Length of the body of this packet in bytes.
Type specific, value specified for each type of packet.
Note that BODY_LEN = Packet length minus 5 (see Data Link
Specification).
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 25
4. STATUS -- Packet status is passed with received packets
and returned subsequent to transmission of packets.
Possible received packet status values are:
- OK_0/1 -- Packet successfully received in entirety on
path 0/1.
- OVERSIZE_0/1 -- Packet was too large to buffer (in the
implementation) but was correctly received by the data
link layer on path 0/1. A minimum of the first 48
bytes of the packet body and all other parameters are
intact.
Possible transmit packet status values (after data link
retry) are:
- ACK_0/1 -- Successful transmission on path 0/1.
- NAK_0/1 -- Receiving interface was unable to buffer
the packet within specified retry limits on path 0/1.
- NO_RSP_0/1 -- Packet was never successfully
acknowledged by destination interface within specified
retry limits on path 0/1.
The path status values may be mixed with one status for
each path used. The data link layer may opt to try one or
both paths.
The subsequent sections show the type-specific values and
formats for each packet.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 26
8.1 Path Selection
Dual paths are supported by the CI for implementation of
highly reliable distributed clusters using standard systems. Dual
path clusters are designed such that a single component failure
will not totally prevent communication between other functioning
systems. Performance may be degraded until repairs are made.
|
| The port layer is primarily responsible for the multiplexing
| and demultiplexing of packets between paths. The data link layer
| is logically duplicated. Note that the parameters previously
| specified for the packet include path (data link) selection
| information. The port is responsible for maintaining the sequence
| of packets on a port-to-port basis. For details, see section on
| sequentiality and priority.
A dual path cluster must have two sets of CI cables for each
port and two couplers or exchanges. However, an interface may
range from total hardware (and software) duplication (two separate
data links) to a minimal implementation in a single interface
(with mostly shared hardware). Note that the interface still
consists of only one port. Reduced implementations are discussed
further in the Minimal Implementation Appendix.
It should be noted that the minimal implementation is
specified because of the additional transmission failure mode it
introduces. That is, if the interface is only capable of
receiving packets on one path at a time, it may ignore packets
transmitted to it on the other bus. The parameters of the data
link retransmission algorithms were selected to compensate for
this effect.
Another major implication arises from dual paths. This is
the selection of path for transmission. Interfaces must support
two types of control of path selection: Select and Automatic. In
select mode, the interface must be capable of transmitting on a
specified path. This mode is used for controller configuration
transactions and requires that packets be returned on the same
path in response to a request packet. In addition, it is likely
that this feature be required for diagnostic purposes.
The majority of packets should be sent in Automatic mode. In
this mode, the path for transmission of a packet should be made by
a two-way, equally probable, statistical choice ("coin-flip").
This provides a statistical load sharing between paths and results
in frequent exercising of both paths for early failure detection.
All retransmission attempts of a packet should be made on the same
bus until the limits are reached.
If a failure occurs, the other path can be tried, following
the same retransmission algorithms until the limits are exceeded.
At this point, it is most likely that a hard failure has occurred
or the destination interface is not in a state where
communications are enabled.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 27
A node should maintain a table of path status for each node.
Such a table should indicate whether a path to a given node is
correctly functioning or not. The table values should be based on
prior transmission results. The table should be used to make
automatic mode selection from only known good paths. This should
prevent known bad paths from being selected with great frequency,
since such transmissions waste bandwidth. If a bad path is to be
retried, it should be done with much lower frequency (every few
seconds or tens of seconds, for example).
Single path ports are allowed, but not encouraged. All
single path ports must be connected to path 0. This ensures that
all nodes on a CI may communicate. The danger that arises from
the use of single-path ports is that path load may be unequally
distributed to an extent that degrades performance. Such effects
must be considered when configuring a mixed single/dual path
cluster. Note that the minimal implementation of a dual path port
discussed in the appendix has very little incremental cost over a
single path interface.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 28
8.2 Sequentiality And Priority
| The operations of the port, both those initiated by the port
| driver and those intiated by the receipt of packets are performed
| at multiple priorities. This is to reduce the latency of
| performance-critical transactions. Real time response is not
| guaranteed, since latency will be primarily a function of cluster
| load. However, this mechanism can be used to disproportionately
| divide bandiwdth as desired.
|
| Sequentiality must be preserved on a per-packet basis between
| node pairs. Prioritization is optimally performed for each
| packet, but may, in fact, be limited due to pipelining in
| implementation. The only guarantees of prioritization are in fact
| on a per-operation basis. Operations are service specific, but
| consist of sending a single packet unless otherwise specified.
|
| The following is a set of rules defining the sequence and
| priority of operations:
|
| Two operations become available to the port. Operation OP0
| arrives at time T0. Operation OP1 arrives at time T1. T1 > T0.
|
| 1. If effective priority of OP0 >= effective priority OP1 then
| OP0 is performed in entirety before OP1 is begun.
|
| 2. If effective priority of OP0 < effective priority OP1, then a
| best effort is made to preempt OP0 between packets, perform
| OP1 in entirety, and then resume OP0. Best effort must be
| limited to 4 packets. That is, no more than 4 packets of OP0
| should be transmitted after T1.
|
|
| There are 5 levels of priority number 0 to 4. Priority 4 is
| the highest. The term effective priority is used because all
| priorities may in fact not be implemented in certain ports. Most
| importantly, priority relationships between operations must be
| maintained as specified. A different priority must be implemented
| for each supported operation that is specified to have a different
| effective priority. The relationship between any two implemented
| priorities must be the same as the corresponding effective
| priorities.
|
| If the data link is physically duplicated, it may be possible
| to transmit packets on both paths simultaneously. Due to
| independent retransmisison, the sequence of arrival could be
| different than the sequence of delivery to the data link. To
| preserve sequence on a port-to-port basis (required), the
| transmission of a packet to a remote port must be completed in
| entirety before another packet for the same port is delivered to
| the data link. The receiving must process the received packets in
| order of real time arrival.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 29
8.3 Datagrams
The datagram service provides a best-effort delivery of a
single packet from one node to another. A datagram may be
successfully transmitted (STATUS = ACK) but be discarded by the
port if unable to unload it immediately from the receive buffer
due to buffer shortage at subsequent layers.
Several of the communication mechanisms of the CI provide
datagram quality service, notably those of maintenance and
configuration. Additionally, a general purpose datagram is
provided for used by higher-level protocols that require such
service. Generally, protocols with unpredictable buffering
requirements should use the datagram service, since the port-level
discard provides some degree of protection against buffer
exhaustion problems.
|
| The receipt of datagrams of any type that would be passed to
| the port driver may be controlled on a port-to-port basis. A
| control bit, Datagram Queue Inhibit (DQI) should be kept for every
| possible port. If this bit is on for a particular port, all
| incoming datagrams for that port must be discarded. This bit
| should be cleared at initilization so that all datagrams are
| initally received.
|
| In addition to a DQI bit for each possible port, at least one
| DQI bit should be provided to control datagram reciept for illegal
| port numbers. It is permissible, though not required, to use a
| single bit for all illegal port numbers.
A performance counter tracks the number of datagrams
discarded due to buffer shortage (see Port Performance Counter
section). This allows higher-level protocols to determine if
sufficient buffering is available for the required performance
level.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 30
8.4 Virtual Circuits
A virtual circuit is the mechanism used to provide a higher
quality of service for a series of packets. Delivery of packets
under virtual circuit control is guaranteed to be sequential,
error-free and non-duplicated. The circuit is constructed of a
set of state variables in the sending and receiving nodes.
Virtual circuits are maintained on a per-node basis. That
is, each of a pair of nodes have virtual circuit state with
respect to the other node. Therefore, in each node, an array of
state values is maintained, with one set per node "connected" by
virtual circuit.
Several of the communication mechanisms specified in the Port
use virtual circuits. In fact, the same circuit is simultaneously
shared by any of the mechanisms that are in use. The circuit
guarantees are on a per-packet basis, independent of the
particular packet type (as long as that type uses the circuits).
The state of a circuit consists of three bits in each node:
Circuit State (CST), Sending Sequence Number (NS), and Receiving
Sequence Number (NR). The circuit state reflects whether or not
the particular circuit has been initialized. Its values are Open
(initialized and "on") and Closed (uninitialized and "off"). The
bit value representing each state can be implementation dependent
with suggested values being "1" (true) for Open and "0" (false)
for Closed.
The Sending Sequence Number is the number of the next packet
to be sent (or the value of the current packet for which delivery
is being attempted). The Receiving Sequence Number is the number
of the next packet to be received.
On the sending end, when a packet is to be delivered, it is
loaded with the current NS value in the defined bit of the FLAGS
field. When the data link layer returns successful transmission
status, the NS value is incremented modulo 2 (complemented).
In the receiving node, when a packet is received for the
circuit, the value of the NS bit of the FLAGS field is checked
against the current value of NR. If equal, the packet is accepted
and NR complemented. If not equal, the packet is discarded. This
is the mechanism for discarding duplicates. If an acknowledgement
(at the data link level) is lost due to bus error, the sending end
will retransmit the packet. If the packet was actually received
(and only the acknowledgement corrupted), NR will have be
complemented and the packet accepted. Upon receipt of the
retransmission, NS will not equal NR and the second packet (a
duplicate) will have been discarded.
The circuit state determines whether or not packets may be
sent or accepted on the circuit. If the circuit is closed in the
sending end, no virtual circuit packets may be sent for that
circuit. If the receiving node state is closed, then incoming
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 31
virtual circuit packets for that circuit will be discarded at the
port level.
The circuit state should be closed if the transmission of a
virtual circuit packet fails. Additionally, a node may close its
circuit at any time. In general, any type of error that may
result in disruption of sequentiality should result in circuit
closure.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 32
8.5 Datagrams (General-purpose)
All nodes must provide bidirectional (send and receive)
general purpose datagram service. The minimum datagram TEXT_LEN
| that a node must be able to handle is 58 bytes. Larger values up
to 4089 bytes may be used between nodes based on prior agreement.
The prior agreement on increased size limits is left to a higher
level protocol.
The BODY format of DG is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
|PF | MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| |
| TEXT |
| |
| | :B + 1
+-------------------------------+ + TEXT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 1 for DG.
B + 1 <7>= PF Packing format. Implies
FLAGS<7> type of data packing to
be used by certain types
of ports. Value is
implementation specific.
B + 2 TEXT Datagram text. Passed
through to Port layer. 0 - 4089
B + 1 + TEXT_LEN bytes in length.
For DG, BODY_LEN = TEXT_LEN + 2.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 33
8.6 Messages
The Message mechanism provides highly-reliable delivery of
single packets using the virtual circuits. Messages are variable
length, ranging from 0 to 4089 bytes in textual length. The
maximum size message that may be exchanged between two nodes is
determined by prior agreement in a higher level protocol.
However, any nodes capable of receiving messages must be able to
| receive messages of at least 58 bytes of textual length.
Nodes are not required to support the capability of sending
or receiving messages. In fact, a node may elect to support the
capability of only sending or receiving messages, but not both.
The BODY format of MSG is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
|PF | MBZ |NS |MBZ| :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| |
| TEXT |
| |
| | :B + 1
+-------------------------------+ + TEXT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 2 for MSG.
B + 1 <7>= PF Packing format. Implies
FLAGS<7> type of data packing to
be used by certain types
of ports. Value is
implementation specific.
B + 1 <1>= NS Sending Sequence Number.
FLAGS<1> Current value of NS for
destination node circuit.
B + 2 TEXT Message text. Passed
through to Port layer.
B + 1 + TEXT_LEN
For MSG, BODY_LEN = TEXT_LEN + 2.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 34
8.7 Data Transfers
The data transfer mechanism provides for the transfer of
large blocks of data not limited in size to a single packet.
Specifically, a block of data is broken into multiple packets
which are individually transferred by the data link layer. The
state of the transfer need only be maintained in the end sending
the data.
The mechanism provides for both a read and a write operation.
Both operations are confirmed upon completion in the initiating
node. All packets involved in data transfers use virtual circuits
to provide a high quality of service.
Data transfers reference named buffers. Buffer names are
32-bits in length. Mapping of names to actual memory space is
implementation specific. The CI packets reference only the name,
length (in bytes) and offset (32-bits) into the buffer. The
offset mapping is also implementation dependent. The name values,
offsets and lengths must be determined prior to the transfer
through higher level protocols.
To read data, a node sends a special request packet which
carries the transfer length, and names and offsets of the source
and destination buffers. The data is returned in as many packets
as necessary by the requested node. The last packet of the
transfer is marked with a special flag. This is the confirmation
(to the initiator) that the transfer was complete and successful.
To write data, a node merely sends the packets of the
transfer to the destination port. The last packet of the transfer
is again marked with a special flag. Upon receipt of such a
packet, if the transfer was successful, the receiving port must
send back a special confirmation packet. Note that, again, the
initiator of the transfer receives the confirmation.
Any errors in completing the either read or write transfers
should result in virtual circuit closure in the node where
detected. The closed circuit prevents completion of the transfer.
Only the node where the error was detected is aware of it. Higher
level protocols must be used to inform the other involved node of
the error (if necessary) and reinitialize the circuit.
The data packets of a single transfer need not be sent
consecutively. They may be interspersed with other packets
between the same pair of controllers. They should, however, be
sent in order of increasing offset.
The length of data packets is discretely variable. Single
data packets may contain 1 to 8 integral multiples of either 512
or 576 data bytes. All ports supporting data transfers must
accept at least 512 and 576 bytes. Nodes may use sizes larger
than 576 bytes only by prior agreement via higher level protocols.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 35
All the packets of a transfer except the last should be of
the agreed-upon size. The last packet should carry the remainder
and be less than or equal to the first packets in size.
All nodes are not required to support either of the data
mechanisms. However, if an operation is supported (reading or
writing), all the functions required by the operation must be
supported.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 36
8.7.1 Writing Data -
Data is written from one system to another by sending data
packets of the type Sent Data (SNTDAT). The last packet of the
transfer has a special flag called the Last Packet (LP) flag set.
Each packet carries a destination buffer name, offset and length
which determine where the data is written.
In the port receiving the packets, the receipt of a SNTDAT
packet with the LP bit set indicates conclusion of the transfer.
If no errors have occurred, a Confirmation (CNF) packet is sent
back to the port which sent the data. If any errors occur in
receiving the data or sending the CNF packet, the virtual circuit
must be closed, thereby aborting the transfer.
|
| The operation of returning the CNF packet must occur at an
| effective priority of three.
Fig. 8-1 shows the data write operation.
INITIATOR RESPONDER
CI DATA LINK
Data read SNTDAT buffer write (ok)
from buffer ----------------------> ---> (error -- close
into packets . virtual ckt)
+-- .
|
V SNTDAT (LP = 1)
+-- ----------------------> -+-> (error -- close
| | virtual ckt)
| |
V buffer write (ok)
(error -- close |
virtual ckt) |
CNF V
(ok -- transfer <--------------------- generate CNF (prio 3)
confirmed) |
+--> (error -- close
virtual ckt)
Fig. 8-1: Data Write Operation
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 37
The BODY format of SNTDAT is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | NS| LP| :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| REC_NAME |
| | :B + 13
+-------------------------------+
| | :B + 14
| REC_OFFSET |
| | :B + 17
+-------------------------------+
| | :B + 18
| |
| DATA |
| |
| | :B + 17
+-------------------------------+ + DAT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 16 for SNTDAT.
B + 1 <1>= NS Sequence number.
FLAGS<1>
B + 1 <0>= LP Last packet flag. Set
FLAGS<0> in last packet of
transfer.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
in last packet will be
the value of the XCT_ID
in the corresponding CNF.
B + 10 REC_NAME Receive buffer name.
through Byte B + 10 is the least
B + 13 significant byte.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 38
B + 14 REC_OFFSET Receive buffer offset.
through Byte B + 14 is the least
B + 17 significant byte of the
byte offset of byte B + 18
of this packet in the buffer.
B + 18 DATA Data. Byte B + 18
through is lowest offset byte.
B + 17 + DAT_LEN
For SNTDAT, BODY_LEN = DAT_LEN + 18.
The BODY format of CNF is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | NS|MBZ| :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 3 for CNF.
B + 1 <1>= NS Sequence number. Current
FLAGS<1> value of NS for destination
node.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Same
value as SNTDAT packet with
LP flag set that resulted
in its generation.
For CNF, BODY_LEN = 10.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 39
8.7.2 Reading Data -
Data is read from a remote system by requesting that the data
be returned. To request data, a Data Request (DATREQ) packet is
sent to the node from which the data is to be read. The DATREQ
specifies the names and offsets of buffers to supply and accept
the data and the length of the transfer (in byte).
(RETDAT) packets in much the same manner as data is sent in
SNTDAT packets. The last RETDAT is marked by the LP flag being
set. This is the confirmation of transfer success.
|
| The priority for the data return operation is specified by
| the particular DATREQ opcode value. DATREQ0, DATREQ1, and DATREQ2
| correspond to effective priorities of 0, 1 and 2, respectively.
| The data return operation consists of sending all the RETDAT
| packets of the transfer.
Any errors result in virtual circuit closure and therein
abort of the transfer. The size of individual packets to be
returned (except for the last packet) is specified in the request.
The maximum allowable size must be determined by prior agreement
between the involved nodes (using a higher level protocol). Fig.
8-2 shows the data write operation.
INITIATOR RESPONDER
CI DATA LINK
Data requested DATREQ
----------------------> -+-> (error -- close
| virtual ckt)
|
| (ok -- Return data)
RETDAT V
(ok -- buffer <--------------------- --+ Data read from
write) . | buffer into packets
(error -- close . |
virtual ckt) . +-> (error -- close
virtual ckt)
RETDAT (LP = 1)
(ok -- transfer <---------------------
confirmed)
Fig. 8-2: Data Read Operation
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 40
The BODY format of DATREQ is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| P | M | MBZ |NS |MBZ| :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| XCT_LEN |
| | :B + 13
+-------------------------------+
| | :B + 14
| SND_NAME |
| | :B + 17
+-------------------------------+
| | :B + 18
| SND_OFFSET |
| | :B + 21
+-------------------------------+
| | :B + 22
| REC_NAME |
| | :B + 25
+-------------------------------+
| | :B + 26
| REC_OFFSET |
| | :B + 29
+-------------------------------+
Where:
Byte Bits Field Description
| B <7:0> OPC OPC = 8 for DATREQ0.
| OPC = 9 for DATREQ1.
| OPC = 10 for DATREQ2.
B + 1 <7>= P Basic packet size for
FLAGS<7> return data transfer.
P = 0 for 512 bytes.
P = 1 for 576 bytes.
B + 1 <6:4>= M Packet size multiple.
FLAGS<6:4> Packet data length
= (M + 1) * basic
size determined by P.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 41
B + 1 <1>= NS Sequence number. Current
FLAGS<1> value of NS for destiation
node.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
to be used in generated
RETDAT packets.
B + 10 XCT_LEN Transfer length in bytes.
through Byte B + 10 is the least
B + 13 significant byte.
B + 14 SND_NAME Sending buffer name.
through Byte B + 14 is the least
B + 17 significant byte.
B + 18 SND_OFFSET Sending buffer offset.
through Byte B + 18 is the least
B + 21 byte of the byte offset
of the first byte of the
transfer to be sent.
B + 22 REC_NAME Receive buffer name.
through Byte B + 18 is the least
B + 25 significant byte.
B + 26 REC_OFFSET Receive buffer offset.
through Byte B + 22 is the least
B + 29 significant byte of the
byte offset of the first
byte of the transfer in
in the receiving buffer.
For DATREQ, BODY_LEN = 30.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 42
The BODY format of RETDAT is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | NS| LP| :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| REC_NAME |
| | :B + 13
+-------------------------------+
| | :B + 14
| REC_OFFSET |
| | :B + 17
+-------------------------------+
| | :B + 18
| |
| DATA |
| |
| | :B + 17
+-------------------------------+ + DAT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 17 for RETDAT.
B + 1 <1>= NS Sequence number.
FLAGS<1>
B + 1 <0>= LP Last packet flag. Set
FLAGS<0> in last packet of
transfer.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
is same as XCT_ID of
DATREQ that resulted in
generation of the RETDAT.
B + 10 REC_NAME Receive buffer name.
through Byte B + 10 is the least
B + 13 significant byte.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 43
B + 14 REC_OFFSET Receive buffer offset.
through Byte B + 14 is the least
B + 17 significant byte of the
byte offset of byte B + 18
of this packet in the buffer.
B + 18 DATA Data. Byte B + 18
through is lowest offset byte.
B + 17 + DAT_LEN
For SNTDAT, BODY_LEN = DAT_LEN + 18.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 44
8.8 Configuration
| All CI nodes must support the ability to supply configuration
| information in response to requests whenever they are
| acknowledging packets at the data link level. Though not strictly
| required to be implemented in hardware, such capablility should be
| provided without CI down-line loading.
Configuration information is transmitted in the
Identification (ID) packet. This packet contains port type,
functionality, and state information.
Systems that require knowledge of current cluster
configuration can request an ID packet from a node by sending a
Identification Request (IDREQ) packet. A node receiving a IDREQ
packet is always required to return an ID packet. ID packets must
be returned on the path on which the corresponding request was
received. A transaction identifier in both the IDREQ and
corresponding ID allow the requesting node to differentiate
between received ID packets.
|
| The IDREQ is the preferred method of determining the
| functional status of a particular path. The information on which
| path the returned ID packet was received must be available at any
| layer which intends to verify the status of the path.
| Additionally, the ID packet carries bits specifying on which path
| it was (alledgedly) transmitted. The correct path (cable)
| configuration of a cluster can be completely verified using the
| received path and sent path (SP) information.
The ability of an interface to send ID packets is generally
an indication that the interface is most likely capable of
performing other maintenance operations.
Some implementations or particular implementation states may
not support certain optional fields of the ID packet. In this
case, unsupported or inapplicable fields are to be returned as
zero. All fields are required unless specifically stated
otherwise. All unused fields must be zero to allow compatibility
of future expansion with existing interfaces.
All nodes are required to respond to received IDREQ packets
by returning ID packets. All ports are not required to support
the transmission of IDREQ packets, but if supported, the receipt
of the returned ID packets must also be supported.
The ID and IDREQ packets are delivered with a datagram-class
service. They are, therefore, subject to discard. Higher level
protocols using this mechanism must accomodate this fact.
Discarded incoming ID packets cause the datagram discarded counter
to be incremented.
|
| The operation of returning an ID in response to an IDREQ must
| be performed at an effective priority of 4.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 45
It must be considered that IDREQ packets may be discarded at
due to limited resources in the port. For details, see the
section on Maintenance/Configuration datagram service. The BODY
format of IDREQ is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 5 for IDREQ.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
to be used in returned
ID packet.
For IDREQ, BODY_LEN = 10.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 46
The BODY format of ID is:
7 0
+-------------------------------+
| OPC | :B
| +---+---+---+---+---+---+---+---+
| | MBZ | SP | MBZ | :B + 1
| +---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
+---+ MAINT_ID |
| D | | :B + 13
+---+---------------------------+
| | :B + 14
| CODE_REV |
| | :B + 17
+-------------------------------+
| | :B + 18
| PORT_FCN |
| | :B + 21
+-------------------------------+
| RST_PORT | :B + 22
+---+---+---+---+---+---+---+---+
| | PT_ST |MNT| :B + 23
| SYS_STATE +---+---+---+
| (Implementation-specific) | :B + 25
+-------------------------------+
| | :B + 26
| MBZ |
| | :B + 49
+-------------------------------+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 11 for ID.
| B + 1 <5:4>= SP Sent Path. Path on which
| FLAGS<5:4> ID packet was transmitted.
| SP = 1 for sent path 0.
| SP = 2 for sent path 1.
| SP = 0,3 reserved for
| local port use.
|
B + 2 XCT_ID Transaction identifier.
through Same value as XCT_ID of
B + 9 corresponding IDREQ.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 47
B + 10 <7:0> MAINT_ID Port identification.
through Implementation defined
B + 13 identifier for use in down-
loading, diagnosis and
booting.
B + 13 <7>= D Dual path. D = 1 for
MAINT_ID<31> dual-path interfaces.
D = 0 for single path
interfaces.
B + 14 CODE_REV Code revision. Value
through is implementation
B + 17 specific.
B + 18 <7:0> PORT_FCN Port Functionality. Value
through determined by which functions
B + 21 the node supports. Values
are defined in Implementation
Functionality Appendix.
B + 22 <7:0> SYS_STATE System State.
through Miscellaneous port and
B + 25 host state information.
Certain fields are defined
below. Remainder is
implementation specific.
| This field is optional.
B + 22 <7:0>= RST_PORT Port which last reset
SYS_STATE<7:0> the port.
B + 23 <0>= MNT Maintenance. Denotes whether
SYS_STATE<8> maintenance is enabled in
current port state. Value of
1 indicates /Maintenance states.
B + 23 <2:1>= PT_ST Port state. Current state
SYS_STATE<10:9> of port (see section on Port
State).
PT_ST = 0 for Uninitialized.
PT_ST = 1 for Disabled.
PT_ST = 2 for Enabled.
PT_ST = 3 reserved.
B + 23 <7:3> Must be zero.
through
B + 53 <7:0>
|
| For ID, BODY_LEN = 50.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 48
8.9 Diagnostic And Booting (Maintenance) Operations
The CI supports maintenance functions for initializing and
testing interfaces and systems, reading and writing remote system
memories and starting remote host computer execution. These
functions are only performed by remote ports in certain specified
states (see section on Controller and system States). The
maintenance functions are optional and implemented as noted in the
Implementation Functionality appendix. It is, however, required
that an entire mechanism be supported. That is, all the
components of any mechanism must be supported if the mechanism is
to be provided.
A maintenance control variable (RST_PORT) must be implemented
by all resettable ports. RST_PORT limits the maintenance
operations to be performed by only a single port. For further
details, see description of individual operations.
All maintenance packets are delivered with a datagram-class
service. Higher level protocols using these mechanisms must
accomodate this fact.
8.9.1 Loopback -
|
| A special datagram is supported to allow a node to verify
| correct functioning of the CI to the hub coupler. The loopback
| datagram (LB) appears to be equivalent to the general purpose
| datagram except in opcode value. Normally, the source port number
| is equal to the destination port number. However, any received LB
| packet should be passed to the port driver following the
| conventions for the general-purpose datagram (with the different
| opcode).
The implementation of this packet is system dependent. In
fact, the standard datagram may serve this function if its
implementation includes transmission and receipt on the media and
received path information. This special opcode is intended for
use by ports whose self-destined operations do not use the
physical interconnect (internal loopback). Such ports may require
special assistance from the host (such as transmit CRC
calculation) for this packet.
The received path information should be passed to any higher
layer performing path verification. Such information, along with
the knowledge of the (alleged) transmit path allows isolation of
cabling faults. A node which must verify and isolate faults in
cluster path connections must implement both this and the
configuration request (IDREQ) functions.
This is a datagram-class packet and is subject to discard if
buffering is unavailable. The datagram discarded counter is
incremented whenever a LB packet is discarded.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 49
The BODY format of LB is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
|PF | MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| |
| TEXT |
| |
| | :B + 1
+-------------------------------+ + TEXT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 13 for LB.
B + 1 <7>= PF Packing format. Implies
FLAGS<7> type of data packing to
be used by certain types
of ports. Value is
implementation specific.
B + 2 TEXT Datagram text. Passed
through to Port layer. 0 - 4089
B + 1 + TEXT_LEN bytes in length.
For LP, BODY_LEN = TEXT_LEN + 2.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 50
8.9.2 Resetting Remote Systems -
A system may send a Reset (RST) packet to a remote system to
reset its interface and host to a known state and to halt host
computer execution. The RST packet may cause a reset of a host
computer only with its interface in one of the three /Maintenance
states (see section on Controller and system State). If the
interface is not in this state but is receiving packets, the
controller will pass the RST packet to the port driver informing
of the attempted reset.
|
| A special maintenance state variable, RST_PORT, is used to
| synchronize access to maintenance the maintenance functions of a
| port. The RST_PORT variable of a port holds the number of the
| last port to reset it. At initialization, RST_PORT is set to the
| port's own number. Host control or port-detected host failure may
| also set the RST_PORT to the port's own number. If the port is
| successfully reset via the CI, RST_PORT is set to the number of
| the port initiating the reset.
|
| A reset is only performed if the RST_PORT value of the
| receiving port is equal to the node number of the sender.
| Optionally, a special Force Reset (F) flag in the RST packet may
| be set. If this flag is set, the RST_PORT field is ignored and
| the reset unconditionally performed (if the interface is in a
| /Maintenance state). Whenever a reset function is performed, the
| RST_PORT field of the port being reset is set to the number of the
| node that sent the RST. This offers a synchronization mechanism
| wherein a non-forced (conditional) reset may be used to determine
| if maintenance operations on a given node are already in progress
| by another node.
The Reset function (if executed) forces the interface to the
Uninitialized/Maintenance state and halts the host computer.
Therefore, systems implementing the Reset function must also
implement the Start function (which starts execution). For
further detail, see the next subsection).
RST is a datagram-class packet and is therefore subject to
duplication. It will, however, not be discarded if the conditions
for resetting are true (since it does not directly require a
returned packet). If the conditions for reset are not true, the
reset if passed to the port driver. It is only discarded in this
case if buffering is not available. If discarded, the datagram
discarded counter will be incremented.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 51
The BODY format of RST is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| F | MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 6 for RST.
B + 1 <7> = F Force Reset. F = 1
FLAGS<7> for unconditional
reset. F = 0 for reset
only if RST_PORT = SRC.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte.
For RST, BODY_LEN = 10.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 52
8.9.3 Writing Remote System Memories -
Remote system memories and interface control storage can be
written over the CI by sending maintenance data, in much the same
fashion as buffer data is sent. The data is sent in Sent
Maintenance Data (SNTMDAT) packets. The receive buffer and offset
are actually implementation dependent mapping information for
physically accessing the desired data in the system under
maintenance.
|
| The maintenance write operation is limited in length to a
| single 512 or 576 byte packet (as is the read). The Last Packet
| (LP) flag of the SNTMDAT packet must be set. If the RST_PORT and
| state are correct, but the packet is too large or does not have
| the LP bit set, it may be discarded.
|
| Upon receipt of a correct SNTMDAT packet (with LP bit set)
| and successful conclusion of the write operation (to the best
| knowledge of the port), the port returns a Maintenance Confirm
| (MCNF) packet, indicating that the packet was received. Note that
| the possible discard implies that multiple packet transfers
| (intermediate packets with LP bit not set) are not reliably
| tested. Any or all of the intermediate packets may fail or be
| discarded and the transfer may still be confirmed (if the last
| packet is successful).
Data can only be written if the remote interface is in the
Uninitialized/Maintenance state and if the RST_PORT value is equal
to the number of the node attempting the write. The remote system
must therefore have been reset by the node desiring to perform the
write.
|
| For local port testing, self-addressed maintenance writes may
| be performed in the Enabled/Maintenance state. Packets received
| in the Enabled/Maintenance that are not self-addressed are to be
| passed to the port driver as datagrams with unrecognized packet
| status.
In general, write operations should be verified with
corresonding read operations (if supported).
A Transaction ID (XCT_ID) is carried with the data and
returned with the MCNF.
|
| The operation of returning the MCNF packet in response to a
| SNTMDAT must be performed at an effective priority of 4.
SNTMDAT and MCNF are both datagram-class packets. SNTMDAT
packets with the LP = 1 may be discarded in the receiving
interface. If the MCNF is never received, the data may or may not
actually have been written. See section on
Maintenance/Configuration Datagram Service for details. MCNF
packets may be discarded if buffer space is unavailable in the
receiving interface. If discard of the MCNF occurs, the datagram
discarded counter is incremented.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 53
The SNTMDAT packet BODY format is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ |LP | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| REC_NAME |
| | :B + 13
+-------------------------------+
| | :B + 14
| REC_OFFSET |
| | :B + 17
+-------------------------------+
| | :B + 18
| |
| DATA |
| |
| | :B + 17
+-------------------------------+ + DAT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 18 for SNTMDAT.
B + 1 <0>= LP Last packet flag. Set
FLAGS<0> in last packet of
transfer.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
is same to be used in the
generated MCNF.
B + 10 REC_NAME Mapping information
through specifying memory area to
B + 13 be written. Implementation
dependent.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 54
B + 14 REC_OFFSET Mapping information
through specifying offset in memory
B + 17 to be written. Implementation
dependent.
B + 18 DATA Data. Byte B + 18
through is lowest address byte.
B + 17 + DAT_LEN
For SNTMDAT, BODY_LEN = DAT_LEN + 18.
The BODY format of MCNF is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
Where:
Byte Bits Field Description
|
| B <7:0> OPC OPC = 4 for MCNF.
|
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
is same as that of SNTMDAT
packet which resulted in
its generation.
For MCNF, BODY_LEN = 10.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 55
8.9.4 Reading Remote System Memories -
Remote system memories and interface control storage can be
read over the CI by requesting maintenance data, in much the same
fashion as buffer data is requested. The data is requested with
the Maintenance Data Request (MDATREQ) packet. The receiving
buffer and offset specify the buffer into which the data is to be
written. The send buffer and offset are actually implementation
dependent mapping information for physically accessing the desired
data in the system under maintenance.
Data can only be read if the remote interface is in the
Uninitialized/Maintenance state and if the RST_PORT value is equal
to the number of the node attempting the read. The remote system
must therefore have been reset by the node desiring to perform the
read.
|
| For local port testing, self-addressed maintenance read
| requests may be performed in the Enabled/Maintenance state.
| Packets received in the Enabled/Maintenance that are not
| self-addressed are to be passed to the port driver as datagrams
| with unrecognized packet status.
A maximum of one packet of data may be requested. Packets
may only be either 512 or 576 bytes. That is, if P = 0, then 512
bytes is the maximum request length. If P = 1, then the maximum
is 576. M must be 0. Interfaces that accept read requests must
check the requested length. If the state and RST_PORT are
correct, but the request is too large, the request should be
discarded.
The data is returned in Returned Maintenance Data (RETMDAT)
packets. The Last Packet (LP) flag must be set since the maximum
transfer length is one packet.
The data should only be returned if the memory read is
entirely successful. If any part of the operation is
unsuccessful, the request should be discarded. The requesting
node may detect this via timeout.
A Transaction ID (XCT_ID) is carried in the request and
returned with the data.
|
| The operation of returning the RETMDAT packet in response to
| a MDATREQ must be performed at an effective priority of 4.
MDATREQ and RETMDAT are both datagram-class packets. MDATREQ
packets may be discarded in the receiving interface. See section
on Maintenance/Configuration Datagram Service for details.
RETMDAT packets may be discarded if buffer space is unavailable in
the receiving interface. However, the data may or may not have
actually been written in the named buffer area. If discard
occurs, the datagram discarded counter is incremented.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 56
The MDATREQ packet BODY format is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| P | MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| XCT_LEN |
| | :B + 13
+-------------------------------+
| | :B + 14
| SND_NAME |
| | :B + 17
+-------------------------------+
| | :B + 18
| SND_OFFSET |
| | :B + 21
+-------------------------------+
| | :B + 22
| REC_NAME |
| | :B + 25
+-------------------------------+
| | :B + 26
| REC_OFFSET |
| | :B + 29
+-------------------------------+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 14 for MDATREQ.
B + 1 <7>= P Basic packet size for
FLAGS<7> return data transfer.
P = 0 for 512 bytes.
P = 1 for 576 bytes.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 57
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte. Value
to be used in generated
RETMDAT packets.
B + 10 XCT_LEN Transfer length in bytes.
through Byte B + 10 is the least
B + 13 significant byte. Maximum
value is 512 if P = 0 or
576 if P = 1.
B + 14 SND_NAME Sending buffer name.
through Byte B + 14 is the least
B + 17 significant byte.
Interpretation is
implementation specific.
B + 18 SND_OFFSET Sending buffer offset.
through Byte B + 18 is the least
B + 21 byte of the byte offset
of the first byte of the
transfer to be sent.
Interpretation is
implementation specific.
B + 22 REC_NAME Receive buffer name.
through Byte B + 18 is the least
B + 25 significant byte.
B + 26 REC_OFFSET Receive buffer offset.
through Byte B + 22 is the least
B + 29 significant byte of the
byte offset of the first
byte of the transfer in
in the receiving buffer.
For MDATREQ, BODY_LEN = 30.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 58
The RETMDAT packet BODY format is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
| MBZ | 1 | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| REC_NAME |
| | :B + 13
+-------------------------------+
| | :B + 14
| REC_OFFSET |
| | :B + 17
+-------------------------------+
| | :B + 18
| |
| DATA |
| |
| | :B + 17
+-------------------------------+ + DAT_LEN
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 19 for RETMDAT.
B + 1 <7> = LP LP = 1 for last (only)
FLAGS<7> packet.
B + 2 XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte.
B + 10 REC_NAME Receive buffer name.
through Byte B + 10 is the least
B + 13 significant byte.
B + 14 REC_OFFSET Receive buffer offset.
through Byte B + 14 is the least
B + 17 significant byte.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 59
B + 18 DATA Data. Byte B + 18
through is lowest address byte.
B + 17 + DAT_LEN
For RETMDAT, BODY_LEN = DAT_LEN + 18.
8.9.5 Starting Remote Systems -
Remote systems which have been halted can be started by
sending a Start (STRT) packet. The STRT packet should have no
effect on systems that are already running. STRT packets are only
accepted by interfaces in the Uninitialized/Maintenance state.
The start function will only be performed if the RST_PORT
field of the receiving port is equal to the source node number.
That is, a node may only be started by the last port to reset it.
If this requirement is not met, the packet is passed to the port
driver as a datagram of invalid format.
An optional start address may be specified. If the host
computer does not implement variable start addresses, this field
is ignored. For systems that do implement variable start
addresses, a default must exist that is specifiable by setting the
Default Start Address (DSA) bit.
STRT is a datagram-class packet. It is therefore subject to
duplication. It will not, however, be discarded if the state is
correct, since it does not require a packet to be returned.
Interfaces and nodes should not be adversely affected by the
receipt of duplicate STRT packets.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 60
The BODY format of STRT is:
7 0
+-------------------------------+
| OPC | :B
+---+---+---+---+---+---+---+---+
|DSA| MBZ | :B + 1
+---+---+---+---+---+---+---+---+
| | :B + 2
| XCT_ID |
| | :B + 9
+-------------------------------+
| | :B + 10
| STRT_ADDR |
| | :B + 13
+---+---+---+---+---+---+---+---+
Where:
Byte Bits Field Description
B <7:0> OPC OPC = 7 for STRT.
B + 1 <7> = DSA Default start address.
FLAGS<7> If set, system should
use implementation
specific default start
address. Ignored if not
implemented.
B + 2 <7:0> XCT_ID Transaction identifier.
through Byte B + 2 is the least
B + 9 significant byte.
B + 10 <7:0> STRT_ADDR Start address.
through Byte B + 10 is the least
B + 13 significant byte.
For STRT, BODY_LEN = 14.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 61
8.10 Maintenance/Configuration Datagram Service
It is likely that Maintenance and Configuration operations
(with the exception of Loopback) will be performed by systems in
states of less than full functionality, since, in fact, these
operations are intended for use in down-line loading, diagnostics
and bootstrapping. It is therefore probable that such packets
will be processed primarily in the interface hardware in the end
being "maintained". This implies that the amount of available
state storage may be severely limited.
|
| The processing of certain maintenance/configuration packets,
| namely, IDREQ, MDATREQ and SNTMDAT(LP) requires state to be
| maintained until the proper packet (ID, MDAT, MCNF, respectively)
| is returned. The number of concurrent operations is limited by
| the amount of storage available. In the lowest limit, this may be
| one operation. These packets are datagram-class; they may be
| discarded upon receipt if insufficient state storage exists to
| process them. Discard is therefore very likely under certain
| conditions, such as consecutively (and rapidly) receiving several
| packets of this type.
|
| For this reason, the maintenance and configuration operations
| must have the highest priority (effective priority 4). This
| should reduce the number of packets discarded due to storage
| limitations.
|
| This discard must be considered by the node that is sending
| the packets. It is also the reason for the single packet
| constraint on maintenance read and write operations.
In general, it is recommended that maintenance operations be
performed one transfer at a time, with verification of completion
between transfers. An example down-line load sequence might be:
1. Send a SNTMDAT (LP) packet.
2. Wait for the MCNF packet.
3. Retry previous two steps until successful or give up.
4. Send a MDATREQ for the same memory block.
5. Wait for RETMDAT(LP).
6. Retry previous two steps until successful or give up.
7. Compare data: If successful, do next block. Else retry or
give up.
For a more complete example, see appendix on remote system
booting.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 62
8.11 Unrecognized Packets
Packets that are illegal in any respect and are received in
the Enabled or Enabled/Maintenance states must be passed to the
port driver as datagrams with Unrecognized Packet status. They
may, in fact, be discarded by the driver or any higher layer.
However, this requirement is necessary to allow the visibility
necessary for CI diagnosis.
|
| Illegal packets are those with OPC, FLAGS or PORT values that
| are not correct or are received in states in which their
| respective function is not performed. Virtual circuit packets
| which are correct in these fields but are for circuits that are
| closed or have incorrect sequence numbers are NOT considered
| illegal packets and are simply discarded.
|
| In particular, MBZ fields MUST be checked wherever non-zero
| values will cause incorrect system response. Note that, as
| datagrams, unrecognized packets are subject to discard if
| buffering is not available or if the DQI bit for the corresponding
| port number is set.
|
| If buffering is available, all paramters and a minimum of the
| first 58 bytes of the body should be passed intact to the port
| driver to aid in determining the source of the error.
|
|
|
| 8.12 Port Performance Counters
|
| For purposes of monitoring cluster performance, a counter is
| required to be implemented in all CI nodes. This counter must be
| 32 bits in length and resetable and readable by higher layers such
| that its value may be collected via higher level protocols.
|
| The counter counts the number of datagrams discarded due to
| lack of buffering beyond the data link (after acknowledgement).
| The counter should be incremented for unrecognized packet
| datagrams, as well. If a packet is discarded due to the DQI bit
| being set, the counter should not be incremented.
|
| This counter should be controllable to count either all such
| events for all remote nodes (loopback should not be included) OR
| for a single (specifiable) remote node. The counter should be set
| to zero and assigned to count for all ports upon entering an
| Enabled (/Maintenance) state.
|
| Counter overflow should result in the counter being locked at
| a value of FFFFFFFF hex. Such a value must always be considered
| invalid.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 63
9.0 CI INTERFACE AND SYSTEM STATE
The port exists in one of six global states: Uninitialized,
Disabled, Enabled, with and without maintenance functions enabled
(/Maintenance). Essentially, the interface accepts and processes
datagram, message and data packets in the Enabled state. In the
Uninitialized state, the interface is essentially off, and not
accepting packets. The Disabled state appears on the CI to be
identical to the Uninitialized state. It is provided as an
implementation-specific intermediate state for "graceful" or
otherwise special state transitions.
|
| In the /Maintenance versions of the three states, special
| rules apply for the acceptance or rejection of packets at the port
| level. At the data link level, all packets are accepted.
| Essentially, ports are enabled to process maintenance commands for
| down-line loading and booting (subject to other command-specific
| constraints) in the /Maintenance states.
|
| It is not required that all states be implemented by a port.
| However, at least the Uninitialized/Maintenance state must be
| implemented if any one of the down-line load or reset/start
| functions is supported. The other /Maintenance states are
| optional.
|
| Any state implementation must be within the bounds of the
| description in this section.
|
| Any state may be entered from any other state. However,
| certain events should consistently cause specific state
| transitions. These transitions are specified in the description
| of each state and shown in Figure 9-1 at the end of the section.
|
| The host system is modeled as existing in either a running or
| a halted state. Where applicable, the host state is included in
| the port state description.
|
| 1. Uninitialized
|
| In this state the interface does not send or acknowledge
| packets at the data link level (resulting in NO_RSP). This is
| the normal power-up state of most interfaces during which the
| host may accomplish bootstrap and local load functions.
|
| This state can be entered by:
|
| 1. Power-up.
|
| 2. The occurrence of certain types of interface-detected
| errors. This state might be entered since the higher
| layers could not be trusted.
|
| 3. The occurrence of interface failures. This state would
| most likely be entered since the interface cannot be
| trusted.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 64
| 4. Hardware control by the host.
|
| This state can be exited by:
|
| 1. Hardware control by the host.
|
| 2. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| It is advisable that systems that are to be booted or
| diagnosed via the CI in cases of failure have a mechanism
| by which to enter a maintainable state if the host fails.
| An example of such a mechanism could be a sanity timer
| which must be "poked" by the host at regular intervals. A
| failure of the host to "poke" the timer should result in
| the port entering the Uninitialized/Maintenance state.
|
| The timer value in this state (as the start-up state)
| is an implementation-specific value (possibly variable).
| It is generally determined by the maximum power-up load
| and boot time of the host system.
|
|
| 2. Disabled
|
| In this state the interface does not send or acknowledge
| packets at the data link level (resulting in NO_RSP). This is
| normally only a transient state. On the CI, it is
| indistinguishable from the Uninitialized state.
|
| This state can be entered by:
|
| 1. Hardware control by the host.
|
| 2. The occurrence of certain types of interface-detected
| errors. This state might be entered since the higher
| layers could not be trusted.
|
| This state can be exited by:
|
| 1. Hardware control by the host.
|
| 2. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| The mechanism for detection of host failure is
| implementation-specific. However, it should be able to
| detect failure within a time of 100 seconds. This allows
| a uniform time specification for node reboot (as a failure
| correction tool) in cases of failures.
|
| 3. The occurrence of certain types of interface-detected
| errors. Another non-enabled state might be entered since
| the higher layers could not be trusted.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 65
| 4. The occurrence of interface failures. The Unitialized
| state would most likely be entered since the interface
| cannot be trusted.
|
|
| 3. Enabled
|
| In this state the port is processing packets (both
| sending and receiving). ID packets are returned in response
| to IDREQ packets. This is the normal operating state of most
| interfaces not requiring external maintenance. STRT, RST,
| SNTMDAT, MDATREQ and any illegal packets are passed to the
| next level from the port as Unrecognized Packets.
|
| This state can be entered by:
|
| 1. Hardware control by the host.
|
| This state can be exited by:
|
| 1. Hardware control by the host.
|
| 2. The occurrence of certain types of interface-detected
| errors. Some non-enabled state would most likely be
| entered since the higher layers could not be trusted.
|
| 3. The occurrence of interface failures. The Unitialized
| state would most likely be entered since the interface
| cannot be trusted.
|
| 4. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| The mechanism for detection of host failure is
| implementation-specific. However, it should be able to
| detect failure within a time of 100 seconds. This allows
| a uniform time specification for node reboot (as a failure
| correction tool) in cases of failures.
|
|
| 4. Uninitialized/Maintenance
|
| In this state the data link will acknowledge any packets
| received. No packets will be sent other than those sent in
| response to maintenance or configuration operations. Any
| packets other than maintenance or IDREQ packets will be
| discarded. ID packets will be sent in response to IDREQ
| packets. Maintenance packets will be processed and responded
| to as specified for the individual packets. Receipt of a RST
| packet under appropriate conditions will result in the host
| being reset as specified for the particular implementation.
| The port state will not change although internal
| initialization may occur, possibly resulting in the abort of
| other maintenance operations in progress.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 66
| This could be the power-up state of interfaces of systems
| requiring down-line load or bootstrap assistance over the CI.
| The value of the RST_PORT field should be equal to the number
| of the last node to reset this port. If this state was
| entered as the result of a CI Reset, then RST_PORT should
| equal the RST source node number. Otherwise, the value should
| be equal to the nodes own number.
|
| This state can be entered by:
|
| 1. Power-up in systems requiring down-line loading.
|
| 2. Hardware control by the host.
|
| 3. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| The mechanism for detection of host failure is
| implementation-specific. However, it should be able to
| detect failure within a time of 100 seconds. This allows
| a uniform time specification for node reboot (as a failure
| correction tool) in cases of failures.
|
| 4. The occurrence of certain types of interface-detected
| errors. This state might be entered since the higher
| layers could not be trusted.
|
| 5. Receipt of a RST packet in any /Maintenance state with
| correct RST_PORT and Force bit values.
|
| This state can be exited by:
|
| 1. Hardware control by the host.
|
| 2. The occurrence of certain types of interface-detected
| errors. Another non-enabled state might be entered since
| the higher layers could not be trusted.
|
| 3. The occurrence of interface failures. The Unitialized
| state would most likely be entered since the interface
| cannot be trusted.
|
|
| 5. Disabled/Maintenance
|
| In this state the interface will acknowledge any packets
| received. No packets will be sent other than those sent in
| response to configuration operations. Any packets other than
| RST or IDREQ packets will be discarded. ID packets will be
| sent in response to IDREQ packets. Receipt of a RST packet
| under appropriate conditions will result in the host being
| reset and halted. The port will enter the
| Uninitialized/Maintenance state.
|
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 67
| This state can be entered by:
|
| 1. Hardware control by the host.
|
| 2. The occurrence of certain types of interface-detected
| errors. This state might be entered since the higher
| layers could not be trusted.
|
| This state can be exited by:
|
| 1. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| The mechanism for detection of host failure is
| implementation-specific. However, it should be able to
| detect failure within a time of 100 seconds. This allows
| a uniform time specification for node reboot (as a failure
| correction tool) in cases of failures.
|
| 2. Hardware control by the host.
|
| 3. The occurrence of certain types of interface-detected
| errors. Some non-enabled state would most likely be
| entered since the higher layers could not be trusted.
|
| 4. The occurrence of interface failures. The Unitialized
| state would most likely be entered since the interface
| cannot be trusted.
|
|
| 6. Enabled/Maintenance
|
| In this state the port is processing packets (both
| sending and receiving). ID packets are returned in response
| to IDREQ packets. Maintenance packets other than RST that are
| not self-addressed should be passed to the higher layers as
| Unrecognized packets. Receipt of a RST packet under
| apprpriate conditions will result in the host being reset and
| halted. The port will enter the Uninitialized/Maintenance
| state.
|
| This is the normal operating state of most interfaces
| requiring external reset at any time. The value of the
| RST_PORT field should be equal to the nodes own number in this
| state.
|
| This state can be entered by:
|
| 1. Hardware control by the host.
|
| This state can be exited by:
|
| 1. Hardware control by the host.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 68
| 2. The occurrence of certain types of interface-detected
| errors.
|
| 3. Host failure. The Uninitialized/Maintenance state should
| be entered to allow down-line reboot.
|
| The mechanism for detection of host failure is
| implementation-specific. However, it should be able to
| detect failure within a time of 100 seconds. This allows
| a uniform time specification for node reboot (as a failure
| correction tool) in cases of failures.
|
|
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 69
| Power-up, Host Cntl, Power-up (remote ld),
| Interface Failure, Host Control,
| Intfc-detected Error Intfc-detected Error
| | |
| | |
| V V
| ************* Host Failure *************
| * *---------------------->* *-----+
| * UNINIT * * UNINIT/ * | CI RST
| * * * MAINT *<----+
| * * +--------- >* *<--------+
| * * H | +------>* *<---+ C |
| ************* o | | ************* | I |
| s | | | |
| t | | | R | C
| | | | S | I
| F | | | T |
| a | | | / | R
| i | | | H | S
| Host Control, l | | Host Control, | s | T
| Intfc-det Err. u | | Intfc-det Err. | t | /
| | r | | | | | H
| V e | | V | F | o
| ************* | | ************* | a | s
| * *-----------+ | * * | i | t
| * DISABLED * | * DISABLED/ *----+ l |
| * * | * MAINT * | F
| * * | * * | a
| * * | * * | i
| ************* | ************* | l
| | | u
| | | r
| | | e
| | |
| | |
| | |
| | |
| Host | Host |
| Control | Control |
| | | | |
| V | V |
| ************* | ************* |
| * * Host Failure | * * |
| * ENABLED *---------------+ * ENABLED/ * |
| * * * MAINT * |
| * * * *---------+
| * * * *
| ************* *************
|
|
| Fig. 9-1: CI Interface State Diagram
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 70
10.0 DATA LINK SPECIFICATION
This section describes, in detail, the functionality of the
data link layer of the CI. Although the implementation is not
specified, it is by nature somewhat more restricted than the port
layer, due to real-time constraints required for compatibility.
With the exception of packet size, the data link layer
basically has no optional features. The parameters are specified
to be minimally restrictive. However, complete compatibility
within specification is required for any interface attached to the
CI.
The specification of this layer assumes the same model as the
port layer, that is, transmit and receive packet buffers and
independent packet transmit and receive functions. In fact,
implementations are not restricted to providing entirely
independent transmit and receive functions. A minimal
implementation is described to clarify this aspect.
The two primary components of the data link layer are
packetization and channel control. Packetization is the
translation of port layer body information to and from packets for
transmission and reception by the physical channel. Channel
control includes such functions as arbitration for use of the
channel and retransmission on error. The following subsections
describe these functions in detail.
10.1 Packetization
Since all data on the CI is passed in packet form for
efficiency (low ratio of control information to actual data), one
of the primary functions of the data link layer is packetization.
This subsection specifies the packets passed (in both directions)
across the physical channel/data link interface. The primary
components of packetization are framing, addressing, and packet
data integrity.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 71
The basic packet format of the data link layer is:
+-------------------------------+
| | :0
| CHAR_SYNC |
| |
+-------------------------------+
| PACK_LEN/TYPE | :1
| |
+-------------------------------+
| | :3
| DST/SRC |
| |
+-------------------------------+
| | :6
| |
| BODY |
| |
| |
+-------------------------------+
| | :BODY_LEN + 6
| CRC |
| | :BODY_LEN + 9
+-------------------------------+
Fig. 10-1: Data Link Packet Format
The various fields an their functions are described in the
following subsections.
10.1.1 Framing -
The packet is framed by two fields. The beginning is marked
by a special starting character and the length is coded in one of
subsequent fields.
10.1.1.1 Character Sync -
The character sync denotes the first byte (byte 0) of the
packet and has a value of 96(hex). The first combination of
consecutive bits transmitted to or received from the physical
channel that have this value are specified to denote the first
byte of the packet.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 72
Any data link that uses shared hardware (cannot operate on
both paths simultaneously) should implement a header timeout
function (see Physical Channel section for definition of header).
This should discontinue the receive process if a correct character
synch is not detected within a certain time from the detection of
carrier. This time should be a maximum of 32 byte times, or 3.66
microseconds. The minimum time is the minimum header detect time,
which is dependent on the size of the header and carrier detection
and byte decode times. Note that a header extension is permitted
within bounds and may be enabled for special configurations. The
maximum header length is 18 bytes.
10.1.1.2 Packet Length/Type -
The two bytes of the packet that immediately follow the
character sync are the packet length/type field. This field
frames the end of packet by supplying the length of the packet
immediately following (but not including) the character sync byte
up to (but not including) the CRC bytes. The information packet
length (PACK_LEN) is always BODY_LEN + 5.
The type value identifies whether this packet is an
information packet (carrying data) or an acknowledgement packet
(transmitted as a result of successfully receiving an information
packet, see section on Acknowledgement).
The format of the Packet Length/Type field is:
Packet Byte
Number
+---+---+---+---+---+---+---+---+
|TYP|ACK| | PACK_LEN<11:8>| :1
+---+---+---+---+---+---+---+---+
| PACK_LEN<7:0> | :2
+---+---+---+---+---+---+---+---+
Where:
Byte Bits Field Description
1 <7> TYPE Packet type. TYPE = 0
for information packet.
TYPE = 1 for acknow-
ledgement packet.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 73
1 <6> ACK Acknowledgement type.
Valid only for acknow-
ledgement packets. MBZ
for information packets.
ACK = 1 for positive
acknowledgement of packet
receipt. ACK = 0 for
negative acknowledgment
(NAK) indicating that the
packet buffers were full.
Bits <5:0> MBZ for
Acknowledgement packets.
1 <3:0> PACK_LEN Packet length in bytes.
through Byte 1<3:0> = PACK_LEN<11:8>.
2 <7:0> Byte 2<7:0> = PACK_LEN<7:0>.
Byte 1<6:4> MBZ for
Information packets.
Byte 2 does not exist for
Acknowledgement packets.
A value of 0 indicates
a length of 4096 bytes (the
maximum).
10.1.2 Addressing -
Addressing is accomplished by the source and destination
address fields. Addresses are 8 bits, with each node having an
address value assigned that is unique within the particular CI.
The range of valid addresses is dependent on the type of hub
coupler. If a passive coupler is in use, the address values may
range from 0 to 15. If an active exchange is in use, the value
may range from 0 to 223.
The source address is that of the node transmitting the
packet. The destination address is that of the node intended to
receive the packet. A node should only receive and buffer packets
with its address in the destination field and should only transmit
packets with its address in the source field. Loopback of packets
is legitimate, that is, the source and destinations of a packet
may be the same value.
The destination field of the packet is replicated (in
complement form) to allow duplication of address comparison logic.
This permits the design of interfaces free from single component
failures capable of prohibitting communication on the CI (on at
least one path).
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 74
The format of the address field is:
Packet Byte
Number
+-------------------------------+
| DST | :3
+-------------------------------+
| DST_CMPL | :4
+-------------------------------+
| SRC | :5
+-------------------------------+
Where:
Bits Field Description
3<7:0> DST Destination node
number.
4<7:0> DST_CMPL Destination complement.
1's complement of byte 3.
5<7:0> SRC Source node number.
10.1.3 Packet Integrity -
The detection of packet errors due to bus noise or collision
is provided by use of a 32-bit Cyclical Redundancy Check (CRC)
character. The CRC character is the residue of the division
(modulo 2) of the packet bits expressed as a polynomial by a
special, defined polynomial. The CRC is generated as the packet
is transmitted (or prior to transmission) and appended to the end
of the packet. Upon receipt of the packet, the CRC is
re-calculated during reception (necessitated by acknowledgement
time constraints). If the residue of the calculation in the
receiver agrees with the value appended to the packet, the packet
is considered to be error free.
This technique, along with validity tests of the destination
address fields, should provide an undetected error rate of
10**-12. With a typical cluster load, this results in one
undetected erroneous packet approximately every 10 years at this
level. This assumes that collision and bus errors result in
uniformly unpredictable bit values. Note that if many of the
other values in the packet, particularly in the body, are not
exactly correct, the packet will be discarded at the port layer.
A similar rejection also occurs at higher levels. This reduces
the probability of an undetected error in the cluster by many more
orders of magnitude.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 75
The polynomial used to calculate the CRC is as follows
(Autodin-II):
32 26 23 22 16 12 11 10 8
X + X + X + X + X + X + X + X + X +
7 5 4 2
X + X + X + X + X + 1
The transmitter and receiver generator/checker accumulators
are preset to all ones prior to generating or checking the CRC
character. The transmitter sends the complement of the remainder
following the data bytes. In the receiver, an error free
reception of the packet should result in a remainder in the
accumulator of DEBB20E3(hex).
The bytes on which the CRC is calculated include all the
bytes after the Character sync (same as included in the packet
count). The packet byte counter should be after the Character
Sync is detected. It should be incremented for each successive
byte received. For acknowledgement packets, CRC accumulator value
should be tested when counter has a value of 4. For information
packets, the value should be checked when the count is equal to
the received packet length value.
10.2 Channel Control
The channel control of the data link layer includes all
functions employed to transfer a packet between the data link
layers of two nodes using the physical channel. Such functions
include arbitration for use of the media, selection of path (for
dual-path interfaces) and acknowledgement and retransmission of
packets.
10.2.1 Arbitration -
The arbitration mechanism is implemented in a distributed
fashion, with each node having equal priority and capability to
arbitrate for the channel for any packet transmission. The method
used is a slotted Carrier Sense Multiple Access (CSMA) type
referred to as Dual-Count Round-Robin. Its characteristics are:
1. Fairness. Under saturation, each system wins arbitration at
least one out of N times, where N is the number of nodes on
the cluster.
2. Efficiency. Saturation efficiency is approximately 80% in a
16 node cluster and higher with fewer nodes.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 76
3. Reliable. The frequency of collision under saturation is
zero. Collisions may occur under lighter loading but at a
maximum rate of approximately 0.5%.
The algorithm is based on a slot, or time interval which is
the maximum time for any node at any physical location to sense
that any other node at any other physical location is
transmitting.
A node desiring to transmit will examine the bus to determine
if carrier is present (another node is transmitting). As soon as
the bus becomes idle, the node will begin waiting a unique number
of quiet slots based on its address N (ranging from 0 to 16). The
number of slots waited may have two values: N + 1 or N + 17.
This value is determined by previous transmissions of other nodes
on the bus. The initial waiting period is N + 17 slots. If the
waiting period elapses without carrier being detected on the bus
(no other node attempting to transmit), the node will transmit its
packet. If, however, carrier is sensed, then the number of slots
waited before carrier detection is counted. The modulo 16 value
of this number minus one is the number of the node that
transmitted. The node will then set the waiting time value for
the next arbitration attempt based on this information. If the
number is less than its own, the new waiting value will be N + 1
(high priority). If the number is greater than its own, it the
new waiting value will be N + 17 (low priority). Under
saturation, this results in each node "waiting its turn", that is,
waiting for all nodes with higher numbers to transmit before
shifting to low priority. In cases of nodes waiting at equal
priorities, the node with the lowest address wins.
It should be noted that collisions can only occur when the
bus has been idle and two nodes begin arbitrating at times
different in slots by the same number as their addresses differ.
In this case, they will both attempt to transmit at the same time.
This results in corruption of the packet and failure of CRC
comparison.
A timeout period is specified for cases when the node is
unable to win arbitration; that is, when the absence of carrier
is never detected for the current arbitration count value. This
timeout period is a minimum of 25 ms. with no specified maximum.
If the timeout value is larger, it merely takes longer to detect
the problem. Arbitration timeouts result in a NO_RSP status for
the transmission on that path.
For a structured description of the arbitration function, see
the Data Link Structured Description subsection.
The arbitration "slot" time is nominally 800 nanoseconds.
This time, however, may be adjusted for special configurations in
the future. If the coupler in use is an active exchange, the
| arbitration may be disabled. If arbitration is disabled,
| transmission may be begun whenever a packet becomes available.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 77
See Active Exchange appendix for details of operation.
10.2.2 Acknowledgement And Retransmission -
The CI uses immediate acknowledgement at the data link level
to verify the successful transmission and reception of packets.
When a node successfully receives an information packet, it is
required to immediately acknowledge the receipt of that packet.
Acknowledgement is performed by the transmission of a special
packet that carries an acknowledgement type code. Arbitration for
transmission of the acknowledgement packet is not required. That
is, the packet should be transmitted as soon as the carrier of the
transmission is removed from the physical channel. The maximum
time between carrier removal and transmission is 600 nanoseconds.
The node that transmitted the information packet must attempt
to receive the acknowledgement packet as soon as it is finished
transmitting. If the acknowledgement is not received within an
acknowledgement timeout period, the transmission is considered to
have failed. This is termed No Response (NO_RSP). NO_RSP occurs
when the intended node did not correctly receive the packet and
therefore did not acknowledge it. The minimum arbitration timeout
time is a function of the implementation. The carrier from the
header of the acknowledgement should be on the cable at the packet
sender no later than 800 nanoseconds after the trailer is
finished. The maximum value should be limited to 3.66
microseconds for purposes of throughput, especially in interfaces
with shared hardware.
NO_RSP's may occur as the result of bus noise (CRC compare
failure), simultaneous transmission of multiple nodes (collision,
resulting in CRC compare failure), or inability of a node to
receive the packet on the path on which it was transmitted, either
due to malfunction of path or interface hardware, or unavailablity
of shared receiver hardware in minimally implemented dual-path
interfaces.
There are two types of acknowledgements to successfully
received packets. The first is positive Acknowledgement (ACK),
which indicates that the reception was successful, that is, the
transmitted packet is available to the port layer in the receiving
node. The second is Negative Acknowledgement, which indicates
that the packet was correctly received, but that the interface was
unable to buffer it (packet is discarded). Although the actual
buffering is implementation specific, the concept of the congested
interface that is unable to process a packet applies to all
implementations. The probability of congestion in interfaces is
not restricted by specification, but should be minimized as it
reduces the amount of bandwidth available on the media to all
nodes.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 78
| If the transmission results in either NO_RSP or NAK,
| retransmission must be attempted according to the following
| algorithm: For NO_RSP, if fewer than 64 consecutive NO_RSP on
| this packet have occurred, retransmission should be attempted.
| For NAK, if fewer than 128 NAK's on this packet have occurred (not
| necessarily consecutive), retransmission should be attempted.
|
| A "coin-flip" decision must be made when the packet is
| available for retransmission. If the result is TRUE,
| retransmission may be attempted. If FALSE, a delay time interval
| should be waited and the decision repeated. The delay time value
| should be a minimum of 16 slot times. The normally selected slot
| time value is 800 nanoseconds which implies a minimum delay
| interval of 12.8 microseconds. The maximum time is unlimited.
| Throughput considerations usually limit the maximum. The delay
| need not be consistent. This allows for software or firmware
| controlled retry with non-constant service latencies (such as in a
| polled system).
|
| The first decision has special properities. If, at the time
| of the decision to retransmit, synchronism of the arbiter is
| maintained after the transmission, that is, it remains
| synchronized to the last deassertion of carrier on the bus,
| transmission may occur when the arbitration is completed.
| However, if synchronism was lost, a single delay interval should
| be waited before the retransmission decison is made.
|
| This prevents consistent arbitration violation on succesful
| retransmit decisions. If an interface always takes a constant
| amount of time to determine that it must retransmit, collisions
| with the transmissions of another node (with difference in numbers
| times slots equalling the retransmit decision time) will
| consistently occur.
The random choice should be equal probability
success/failure. Pseudo random implementations are acceptable
with a minimum of 16 bits in the generator.
This scheme is designed to break deadlocks. The selection of
retry limits was calculated from simulation results to meet the
following criteria: The mistaking of failure in a correctly
functioning system (due to congestion) should occur no more than
once per year with typical factors in heavily loaded clusters.
|
| A path that has failed in retransmission need not be retried
| for the failing packet. Rather, it is appropriate to retry it at
| whatever frequency is used for configuration update polling.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 79
10.2.3 Data Link Performance Counters -
For purposes of monitoring cluster performance, a set of
counters is required to be implemented in all CI nodes. These
counters must be 32 bits in length and resetable and readable by
higher layers such that their values may be collected via higher
level protocols. The following counters must be implemented:
1. ACK_0 -- ACKS occurring on path 0.
2. ACK_1 -- ACKS occurring on path 1 (dual-path nodes only).
3. NAK_0 -- NAKS occurring on path 0.
4. NAK_1 -- NAKS occurring on path 1 (dual-path nodes only).
5. NO_RSP_0 -- NO_RSP's occurring on path 0.
6. NO_RSP_1 -- NO_RSP's occurring on path 1 (dual-path nodes
only).
|
| These counters should be controllable to count either all
| such events for all remote nodes (loopback should not be included)
| OR for a single (specifiable) remote node. The counter should be
| set to zero and assigned to count for all ports upon entering an
| Enabled (/Maintenance) state.
|
| Counter overflow should result in the counter being locked at
| a value of FFFFFFFF hex. Such a value must always be considered
| invalid.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 80
10.3 Data Link Structured Specification
This section specifies the data link transmitter and receiver
in PASCAL. Although the transmitter and receiver are specified as
procedures (for purposes of test compilation), they are actually
processes which pass parameters under flag control to and from the
Port layer.
10.3.1 Global Definitions -
procedure DATALINK( {Transmit and receive packets}
DST: PORT_ADRS; {Destination port number or port received from}
SRC: PORT_ADRS; {Source port number -- this port}
BODY: PACKET_BODY; {Packet body in a byte array}
BODY_LEN: BODY_LEN_TYPE; {Packet body length in bytes}
RCD_PACKET: BOOLEAN; {Packet received flag}
TX_PACKET: BOOLEAN; {Packet available to transmit flag}
PACKET_STATUS: STATUS); {Receive or transmit packet status}
const CHAR_SYNC = %X96; {Character Sync value}
| ACK_PACK = %XC0; {Packet Type High Codes}
| NAK_PACK = %X80;
INF_PACK = %X00;
OK_CRC0 = %XDE; {CRC remainder}
OK_CRC1 = %XBB;
OK_CRC2 = %X20;
OK_CRC3 = %XE3;
type STATUS = (NORSP,NAK,ACK,OVERSIZE,OK);
PORT_ADRS = 0..15;
BYTE = 0..255;
PACKET_BODY = array [0..4089] of BYTE;
BODY_LEN_TYPE = 0..4091;
TIMER = REAL; {Variable that decrements in time}
CRC = ARRAY[0..3] of integer; {CRC accumulator on BUSDATA}
OP_STATUS = (SUCCESS,FAIL); {General operation status}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 81
var CARRIER: BOOLEAN; {Carrier sense}
BUS_DATA: BYTE; {Bytes passed to/from phys. channel}
CRC_ACC: CRC; {CRC accumulator}
PACK_TYPLEN_H: BYTE; {Packet Type/Length high order byte}
PACK_LEN_L: BYTE; {Packet Type/Length low order byte}
PACK_SRC: PORT_ADRS; {Received packet source}
PACK_DST: PORT_ADRS; {Received packet destination}
PACK_DST_CMPL: BYTE; {1's complement of destination port number}
BUF_FULL: BOOLEAN; {True if no receive buffer available}
function CMPL(
N:INTEGER): INTEGER;
begin
{CMPL := 1's complement of parameter}
end; {CMPL}
function RAND: BOOLEAN;
begin
{return true 50% of time, otherwise false}
end; {RAND}
procedure STRTCHAN;
begin
{Transmit header bits on bus and open BUS_DATA for transmit data}
end; {STRTCHAN}
procedure ENDCHAN;
begin
{Transmit trailer bits on bus}
end; {ENDCHAN}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 82
begin
{start transmit and receive processes}
{transmit is woken by assertion of TX_PACKET flag by port}
{Returns status when it deasserts TX_PACKET}
{receive is woken by CARRIER}
{returns BODY and parameters when it asserts RCD_PACK}
end; {DATALINK}
10.3.2 Transmitter -
procedure SEND( {Send a packet}
DST: PORT_ADRS;
BODY_LEN: BODY_LEN_TYPE;
BODY: PACKET_BODY;
TX_PACKET: BOOLEAN;
PACKET_STATUS: STATUS);
const RTX_DELAY = 1.28E-05; {Retransmit delay value}
MAX_NAK = 128; {Maximum MAK count}
MAX_NORSP = 64; {Maximum consecutive NORSP count}
var NAK_CTR: integer; {NAK counter}
NORSP_CTR: integer; {NORSP counter}
RETRY: BOOLEAN; {Retry flag}
DELAY_TMR: TIMER; {Retransmit delay timer}
I: INTEGER; {General purpose index}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 83
function ARBITRATE: OP_STATUS; {Returns after arbitration or timeout}
const ARB_TIMEOUT = 25E-03; {Minimum arbitration timeout value}
SLOT_TIME = 800E-09; {Nominal slot time}
var CTR: INTEGER; {Slot counter}
INIT_CTR: INTEGER; {Initial slot counter value}
ARB_TMR: TIMER; {Arbitration timer}
SLOT_TMR: TIMER; {Slot timer}
begin
ARB_TMR := ARB_TIMEOUT;
INIT_CTR := SRC + 17; {Low priority value}
CTR := INIT_CTR;
while ((CARRIER) and (ARB_TMR <>0 )) do {Wait for carrier to go away}
begin
end;
while (ARB_TMR <> 0) do
begin
SLOT_TMR := SLOT_TIME;
while ((CTR <> 0)AND(NOT(CARRIER))) do
begin
if (SLOT_TMR = 0) then
begin
CTR := CTR - 1;
SLOT_TMR := SLOT_TIME
end
end;
if (CTR <> 0) then
begin
if (((CTR - 1) MOD 16) < SRC) then
CTR := SRC + 1 {high priority}
else if (((CTR - 1) MOD 16) > SRC) then
CTR := SRC + 17 {low priority}
else
CTR := INIT_CTR {Didn't wait -- ACK}
end;
end;
if (CTR = 0) then
ARBITRATE := SUCCESS
else
ARBITRATE := FAIL {Timeout has occurred}
end; {ARBITRATE}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 84
function RXACK( {Receive packet acknowledgement}
SRC: PORT_ADRS;
DST: PORT_ADRS): STATUS;
const ACK_TIMEOUT = 800E-09; {Acknowledgement wait timeout}
var ACK_TMR: TIMER; {Acknowledgement wait timer}
I: INTEGER; {General purpose index}
begin
for I := 0 to 3 do
CRC_ACC[I] := -1; {Initialize CRC accumulator}
ACK_TMR := ACK_TIMEOUT;
while (((not(CARRIER)) or
(CARRIER and (BUS_DATA <> CHAR_SYNC))) and
(ACK_TMR <> 0)) do
begin
end;
if (ACK_TMR <> 0) then {Acknowldgement being received}
begin
PACK_TYPLEN_H := BUS_DATA;
PACK_DST := BUS_DATA;
PACK_DST_CMPL := BUS_DATA;
PACK_SRC := BUS_DATA;
for I := 0 to 3 do
CRC_ACC[I] := BUS_DATA;
if ((CRC_ACC[0] = OK_CRC0) and
(CRC_ACC[1] = OK_CRC1) and
(CRC_ACC[2] = OK_CRC2) and
(CRC_ACC[3] = OK_CRC3) and
(PACK_TYPLEN_H >= ACK_PACK) and
(CMPL(PACK_DST_CMPL) = DST) and
(PACK_DST = SRC) and
(PACK_SRC = DST)) then
begin
| if (PACK_TYPLEN_H = NAKK_PACK) then
| RXACK := NAK
else
RXACK := ACK
end
else
RXACK := NORSP
end
else
RXACK := NORSP
end; {RXACK}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 85
begin
while (not (TX_PACKET)) do
begin
{Wait for packet to transmit}
end;
NAK_CTR := MAX_NAK;
NORSP_CTR := MAX_NORSP;
RETRY := TRUE;
while (RETRY) do
begin
if (ARBITRATE = SUCCESS) then
begin
STRTCHAN;
for I := 0 to 3 do
CRC_ACC[I] := -1;
| BUS_DATA := (BODY_LEN + 5) MOD 4096;
BUS_DATA := DST;
BUS_DATA := CMPL(DST);
BUS_DATA := SRC;
for I := 0 to (BODY_LEN - 1) do
BUS_DATA := BODY[I];
for I := 0 to 3 do
BUS_DATA := CMPL(CRC_ACC[I]);
ENDCHAN;
PACKET_STATUS := RXACK(SRC,DST);
if (PACKET_STATUS = NORSP) then
begin
NORSP_CTR := NORSP_CTR - 1;
if (NORSP_CTR = 0) then
RETRY := FALSE
end
else if (PACKET_STATUS = NAK) then
begin
NAK_CTR := NAK_CTR - 1;
if (NAK_CTR = 0) then
RETRY := FALSE
else
NORSP_CTR := MAX_NORSP
end
end
else
PACKET_STATUS := NORSP;
while ((RETRY) and (RAND)) do
begin
DELAY_TMR := RTX_DELAY;
while (DELAY_TMR <> 0) do
begin
end
end
end
end; {SEND}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 86
10.3.3 Receiver -
procedure RECEIVE( {Receive a packet}
DST: PORT_ADRS;
BODY_LEN: BODY_LEN_TYPE;
BODY: PACKET_BODY;
BUF_FULL: BOOLEAN;
RCD_PACKET: BOOLEAN;
PACKET_STATUS: STATUS);
| const HDR_TIMEOUT = 4.8E-06; {Minimum time for 40-bit header}
MAX_BODY_LEN = 4091; {Implementation specific maximum}
var HDR_TMR: TIMER; {Header timer}
JUNK: BYTE; {Byte bucket}
I: INTEGER; {General purpose index}
procedure TXACK( {Transmit an acknowledgement packet}
BUF_FULL: BOOLEAN;
SRC: PORT_ADRS;
DST: PORT_ADRS);
var I: INTEGER; {General purpose index}
begin
STRTCHAN;
for I := 0 to 3 do
CRC_ACC[I] := -1;
if (BUF_FULL) then
BUS_DATA := NAK_PACK
else
BUS_DATA := ACK_PACK;
BUS_DATA := DST;
BUS_DATA := CMPL(DST);
BUS_DATA := SRC;
for I := 0 to 3 do
BUS_DATA := CMPL(CRC_ACC[I]);
ENDCHAN;
end; {TXACK}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 87
begin
while (not (CARRIER)) do
begin
{Wait for carrier}
end;
RCD_PACKET := FALSE;
for I := 0 to 3 do
CRC_ACC[I] := -1;
HDR_TMR := HDR_TIMEOUT;
while ((BUS_DATA <> CHAR_SYNC) and (HDR_TMR <> 0)) do
begin
end;
if (HDR_TMR <> 0) then
begin
PACK_TYPLEN_H := BUS_DATA;
if (PACK_TYPLEN_H <= INF_PACK + 15) then
begin
PACK_LEN_L := BUS_DATA;
PACK_DST := BUS_DATA;
PACK_DST_CMPL := BUS_DATA;
SRC := BUS_DATA;
| BODY_LEN := ((4096 + PACK_LEN_L +
| (PACK_TYPLEN_H * 256)) MOD 4096) - 5;
if BODY_LEN > MAX_BODY_LEN then
BODY_LEN := MAX_BODY_LEN;
for I := 0 to (BODY_LEN - 1) do
BODY[I] := BUS_DATA;
for I := 0 to (MAX_BODY_LEN - BODY_LEN) do
JUNK := BUS_DATA;
for I := 0 to 3 do
CRC_ACC[I] := BUS_DATA;
if ((CRC_ACC[0] = OK_CRC0) and
(CRC_ACC[1] = OK_CRC1) and
(CRC_ACC[2] = OK_CRC2) and
(CRC_ACC[3] = OK_CRC3) and
(PACK_DST = SRC) and
(PACK_DST_CMPL = CMPL(SRC))) then
begin
TXACK(BUF_FULL,DST,SRC);
RCD_PACKET := TRUE;
if (BODY_LEN > MAX_BODY_LEN) then
PACKET_STATUS := OVERSIZE
else
PACKET_STATUS := OK
end
end
end
end; {RECEIVE}
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 88
11.0 PHYSICAL CHANNEL SPECIFICATION
|
|
| The physical channel performs the functions of transmitting
| and receiving the bits of packet bytes specified in the data link
| layer and detecting the presence of transmissions on the channel.
| The channel encompasses the bit encoding and decoding, drivers and
| receivers that interface to the media, and the media itself, that
| is, the cables and couplers.
|
|
|
| 11.1 Channel Character
|
| The physical channel design is largely determined by two
| factors:
|
| 1. Nodes on the CI needed to have isolated system grounds or
| earth references. The signal paths have to be AC coupled with
| isolation at primary power frequencies. A large amount of
| hardware needed per isolated signal line so bit-serial
| transmission techniques are used.
|
| 2. The bus is to be highly reliable and reconfigurable on line.
| The media connecting one node must not be critical to
| operation of other nodes. The central hub or star-coupled
| approach provides each node with an independant hook-up to the
| cluster. A daisy chain media configuration between nodes
| doesn't allow this goal.
|
|
|
|
| 11.2 Isolation Scheme
|
| Each node is isolated from the media that connects it to the
| hub. The shields of the individual node cables are tied together
| by the coupler. In a dual path system there may be two
| independant couplers which may or may not be isolated from each
| other. In any case, the coupler and all the external cables are
| "floating" with respect to nodes. The actual connection between
| the node and its bus cables is made as follows (a single path
| system is discribed):
|
| 1. The transmit and received data are transfomer coupled into the
| end of the cable at the node. The signal path is complete and
| requires no further referencing of the cable.
|
| 2. The transmit and receive cable shields are RF decoupled to the
| I/O panel of the node with a 4 to 8 nano-farad capacitor
| (value per cable). The capacitor is a filter with two
| purposes: 1) keep the internal noise inside the node cabinet,
| away from the FCC; 2) keep external noise outside the node
| cabinet to minimize susceptabilitly to RF interference or
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 89
| static discharge. The capacitive filter is effective above 30
| Mhz and transparrent at lower frequencies.
|
| 3. The cable shields are connected by a 300 ohm resistor to node
| logic reference to dampen common mode resonances of the
| internal cables.
|
|
|
|
| 11.3 Bit Transmission And Reception
|
| 11.3.1 Encoding And Decoding -
|
| Bits are encoded for transmission using Manchester phase
| encoding. This encoding scheme is used for the following reasons:
|
| 1. Guaranteed Transitions -- Encoded bits have at least one
| transition per bit cell, thereby allowing AC (transformer)
| coupling. AC coupling is needed to provide high intercabinet
| isolation at power-line frequencies.
|
| 2. Simplicity of Implementation -- Manchester coding can be
| implemented in a "reasonable" number of components.
|
| 3. Clock Encoding -- Encoding the clock in the data stream
| eliminates the problem of clock skew associated with
| separately cabled clock and data signals.
|
|
| The nature of bit transmission and the channel are as
| follows:
|
| 1. Serial data transmission with transmit and received data on
| seperate cables.
|
| 2. Raw data rate: 70 Mbit/second.
|
| 3. Syncronous manchester code (baseband bi-pahase) with data and
| clock on same cable.
|
| 4. Media bandwidth, 10 to 100 Mhz.
|
|
| The manchester code scheme is the same as "X-or'ing" the
| clock and the data. A signal transition occurs in the center of
| each bit cell. This transition is negative for a zero and
| positive for a one, as shown in the figure below.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 90
|
|
| |<---BIT CELL-->| | |
| | | | |
| | 1 | 1 | 0 |
|
| +-------+ +---------------+
| | | | |
| | | | |
| --------+ +-------+ +-------
|
|
| BIT CELL = 14.286 nanoseconds
|
|
| Fig. 11-1: MANCHESTER ENCODING
|
|
|
| 11.3.2 Packet Format -
|
| The packet must be preceeded by preamble bits and followed by
| trailer bits as specified below. The preamble of specified bit
| values is needed to start and synchronize the decoder. A string
| of trailer bytes follows is appended to ensure the correct
| decoding of all packet bits and insure smooth release of the bus.
| The format of the bit stream transmitted on the cable is:
|
|
| First Bit Packet Last Bit
| Transmitted Byte 0 Transmitted
| | | |
| V V V
| +-------+-----------------------+-------+
| | BIT | PACKET |TRAILER|
| | SYNC | BYTES | |
| +-------+-----------------------+-------+
|
|
|
|
| Fig. 11-2: Bit Format of Packet Envelope
|
|
|
|
| 11.3.3 Bit Synchronization -
|
| In order for decoder to synchronize to the center transition
| of the bit cell, each packet must start with a preamble consisting
| of 32 bits of Bit Synchronization. This Bit Sync consists of four
| bytes of value 55 (alternating 1's and 0's). This pattern results
| in the fewest possible transitions (one per bit) with every
| transition corresponding to the center of a bit cell of the value
| appropriate to the direction of transition.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 91
| 11.3.4 Trailer -
|
| The trailer is needed to ensure that all packet bits can be
| successfully decoded, that all bytes can be deserialized (framed)
| , and that the bus will become quiet quickly after the end of the
| packet. To allow for decoding, a minimum of a 32 bits is appended
| to the end of a packet. The maximum number of bits that may be
| added is
| <***** value needed>
|
| A longer trailer will interfere with the minimum time between
| packets on the bus. The trailer must be composed of all 0 bits to
| provide for carrier detect being dropped quickly after the end of
| the packet. (All 1's would be suitable as well.)
|
|
|
| 11.4 Carrier Detection
|
| \ TO BE ADDED \
|
|
|
| 11.5 Media -- Cables And Couplers
|
| \ TO BE ADDED \
|
|
|
| 11.6 Input/Output Signal Level Specification
|
| 11.6.1 Driver Power Output Specification -
|
| The power delivered by the driver is specified at the CI
| bulkhead connector for convience of measurement. This value
| includes assumed properties for the internal cables and
| connectors. If measured at the backplane the minimum value would
| be 1 db greater and the maximum value would be the same.
|
| The driver power output at the CI bulkhead connector is:
|
| 1. Minimum: 13.0 dbm
|
| 2. Maximum: 16.5 dbm
|
| The value is specified as "db above a milliwatt" in 50 ohms
| characteristic impedance and is a RMS power measurement. In 50
| ohms the dbm value corosponds to roughly 3 volts peak to peak for
| a periodic signal (ie, continous all 1's data).
|
| The driver power is best measured with a true power meter.
| Measuring the voltage and converting leads to errors if the output
| wave shape is not purely sinusoidal. Under some conditions the
| driver may approximate a sine wave although it isn't specified
| this way.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 92
| 11.6.2 Receiver Input Power Specification -
|
| The receiver input power level is specified at the bulkhead
| for convience. The same notes given for the driver power spec.
| apply here.
|
| The receiver power is as follows:
|
| 1. Minimum Power: -19.0 dbm
|
| 2. Maximum Power: -4. dbm
|
| Note that "dbm" is explained in the driver power specification
| section, above.
|
| The maximum power level specification is provided to prevent
| damage to the receiver input and to allow carrier detect circuit
| to detect the end of packet quickly after it occurs.
|
|
|
| 11.7 Input/Output Signal Timing Specification
|
| The data below specifies the timing of waveforms at the
| output of the CI driver and the input to the CI receiver. The
| difference between these waveforms is caused by the external
| cables, couplers, and environmental noise.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 93
| 11.7.1 Driver Output Signal Timing -
|
| The specification of the driven signal includes the bit
| frequency, jitter and the signal rise/fall times.
|
| The frequency of bits is relatively precise. The tolerance
| in the frequecy is +/- .006% and is the same as the transmit clock
| frequency tolerance.
|
| The jitter is relatively low at this point in the bus. The
| jitter is attributed to the inter-bit transition below but it is
| really equally divided up between all edges. The jitter is
| non-accumulating (the frequency is constant) so the jitter may be
| attributed to one edge or the other and viewed this way with an
| osciloscope.
|
| The rise/fall time of the driver output signal is nominally
| 2.0 nanoseconds. The rise time should be the same as the fall
| time to within .30 nanoseconds.
|
|
| |<---BIT CELL-->| | |
| | | | |
| | 1 | 1 | 1 |
|
| +------+++ +------+++ +--------
| | ||| | ||| |
| | ||| | ||| |
| --------+ +++------+ +++------+
| | | | |
| |<---- T ------>| ->| |<- J
|
| J = MAX JITTER = +/- 1.0 nanoseconds
|
|
| BIT FREQ= 70.000 +/- .004 MHZ.
|
|
| T = 1/Freq = 14.286 nanoseconds
| +/- .001
|
| Fig. 11-3: TIMING SPEC AT DRIVER OUTPUT
|
|
|
| 11.7.2 Receiver Input Signal Timing -
|
| The frequency of bits is unchanged and jitter in the edges is
| introduced as shown below. The jitter is attributed to the
| inter-bit transition below but it is really equally divided up
| between all edges. The jitter is non-accumulating (the frequency
| is constant) so the jitter may be attributed to one edge or the
| other and viewed this way with an osciloscope. The rise/fall time
| of the signal input to the receiver is less than or equal 3.5
| nanoseconds.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 94
|
|
| |<---BIT CELL-->| | |
| | | | |
| | 1 | 1 | 1 |
|
| +------+++ +------+++ +--------
| | ||| | ||| |
| | ||| | ||| |
| --------+ +++------+ +++------+
| | | | |
| |<---- T ------>| ->| |<- J
|
| J = MAX JITTER = +/- 2.8 nanoseconds
|
|
| BIT FREQ= 70.000 +/- .004 MHZ.
|
|
| T = 1/Freq = 14.286 nanoseconds
| +/- .001
|
| Fig. 11-4: TIMING SPEC AT RCVR INPUT
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 95
12.0 CONFIGURATIONS
This section discusses the recommended and allowable physical
cluster configurations for CI installation and maintenance. The
sections on installation rules give the limits on cable lengths,
limits on coupler size, general power and grounding needs for site
preparation, and proper node addressing. Next, recommended
procedures for maintenance operations involving the signal cables
are given. Finally, the limits to which a cluster may be
mis-configured and still function, either for maintenance or by
mistake, are given as "configuration exceptions".
12.1 Physical Topologies
The physical topology of the bus is that of a wheel with
computers or other nodes around the circumference and a central
coupler in the middle. The node cables radiate outward from the
middle, each node is connected "point-to-point" with the coupler.
If a dual path CI is involved there will be two separate sets of
node cables and couplers. All CI clusters must have a central
coupler, even in the two node case. The coupler can be designed
to allow any number of nodes from two to the maximum addressable
(given below) and in a given coupler all the ports do not need to
be used. The most popular coupler sizes are expected to be 2, 8,
and 16. For these three sizes the coupler can be a passive device
without any power source. The two node coupler is very small and
is envisioned as being a lump in the cable between the two nodes.
For larger clusters the coupler needs to be housed in a cabinet to
help manage the cables in the center. For 8 and 16 node dual path
clusters the coupler will usually need to have it's own cabinet.
12.2 Installation Rules
The node configuration rules for cluster installation are
given below in two categories: those for the signal cables and
couplers, and rules covering the "grounding" and cluster power
distribution. These rules represent the signal specifications
given in the CI Physical Channel section.
12.2.1 Installation Rules For Signal Cables And Couplers -
1. Minimum Cable Length from coupler to node: none
|
| 2. Maximum Cable Length from coupler to node: 45 meters.
3. Maximum Cable Length inside the node: 3 meters.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 96
4. There must be one coupler per CI path.
5. Unused node ports on a coupler must be terminated.
6. Minimum number of nodes: none.
7. Maximum number of nodes depends on coupler size:
For a passive coupler: 16 nodes (32 cables per path).
For an active coupler: 224 nodes (548 cables per path)
|
| 8. Unused cables must be disconnected at the coupler. Cables
| must be connected at the node end if connected at the coupler.
| The cable must be terminated for proper coupler operation and
| the terminator is in the node. Also, to preserve bus
| isolation, the end of the cable at a node must not be allowed
| to contact the node chassis. Disconnection at the coupler
| avoids the problem of cables shorting the coupler to a node.
12.2.2 Power, Grounding And Site Preparation For Installation -
CI related cluster power and grounding conforms with DEC STD
186 rules for a "conditioned" signal path between systems. The DC
loop in the cluster formed by the power and signal cables is
broken in the signal path. The CI bus is "isolated" at low
frequencies so no special consideration to power or grounding is
needed for the CI signal integrity. Each subsystem or node on the
CI may be installed as if they were entirely independent systems.
| Note, the installation must comply with all local codes and
| National Electrical Codes for safety.
12.2.2.1 Grounding:
1. The installation of a CI interconnection doesn't require
special grounding straps, bonding of cabinets, or other
special care.
2. If the CI is replacing another bus between two nodes remove
ground straps installed for the previous bus if possible.
Straps should always be removed when the systems (nodes) are
only interconnected by CI cables after the bus change. Straps
should not be removed if any non-isolated busses remain
between the systems. Removing unneeded straps will improve
the reliability of the individual systems.
3. All systems used with the CI must have the standard RF choke
in series between the unit chassis and the earth reference
wire of the power cord. This is a standard item in all DEC
power controllers.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 97
4. The coupler chassis or cabinet may be connected to any single
DEC chassis with primary power for safety referencing but this
is unadvisable. It may not be connected to more than one such
reference. This connection will never improve operation of
the bus.
5. The coupler chassis or cabinet must never be "grounded" by
connection to building structural metal, water pipes or other
random places. A DEC chassis can be used as it provides a
necessary RF choke (usually in the power controller).
12.2.2.2 Primary Power Distribution: -
Comply with NEC, local safety codes, and the node (computer
system) site spec's for power distribution on an individual basis.
Refer to DEC STD 186 if there is any doubt as to what is good.
The basic idea is that primary power is distributed to a normal
system such that ALL power and earth references might be
disconnected at one point. When this connection is made the
system is safety earth referenced and has power. If this
connection is not made there is no earth reference and no power to
the system. This point is typically the "breaker box" for large
systems (although the safety earth wire never has a circuit
breaker in it).
All systems used with the CI must have the standard RF choke
in series between the unit chassis and the earth reference wire of
the power cord. This is a standard item in all DEC power
controllers.
The actual conditions for proper CI operation are as follows.
The most important condition is that all node chassis be within 6
| Vrms or 18 Vpp of each other at frequencies below 10Khz. This
| will almost always be the case when primary power and saftey
| wiring meet safety codes and site spec's for the individual CI
| nodes. (Reference Dec Std 102.7) If the site doesn't meet this
| requirement the CI may be prone to bus data errors. A second
condition is that the CI cable shields never connect the chassis
reference of one node to another node or to building metal.
12.3 Addressing
Addresses should be assigned in a cluster consecutively from
0. This maximizes the efficiency of the arbitration algorithm.
Addresses are restricted to values of 0:15 in "passively" coupled
clusters and 0:223 in clusters coupled with "active" exchanges.
The addresses from 223:255 are reserved for future use.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 98
12.4 Installation Of A New Node Onto An Operational Cluster
-/to be added/-
12.5 Bus Maintenance And Temporary Configurations.
The maintenance procedures given below allow one node and
it's associated hardware to be removed from the cluster while the
rest of the cluster is using the same path. The configuration
rule given in the Installation Configuration section (above)
concerning unused ports on the coupler or cables may be violated
as given below for the purpose of maintenance. These allowed
exceptions to the rules provide for on-line bus repair and an
"available" bus. When the bus is configured as per the
installation rules no single point of failure exists, providing a
"reliable" bus. The configurations given below should not be used
as a routine matter of convenience as more than one violation may
lead to widespread cluster problems.
12.5.1 On-Line Maintenance Procedures -
The following procedures are to be used to repair one path or
node while the rest of the cluster is operational.
1. Always remove power from the CI logic backplane before
removing CI parts inside the node cabinet.
2. If a cable is to be disconnected at a node it should be
disconnected at the coupler first to minimize the effect on
the cluster and the chance of the cable shield "short
circuiting" between two ground references.
3. Disconnect cables at the coupler first, do one path at a time,
and terminate the coupler before breaking the second path. Do
not leave unterminated ports on the coupler. Do not leave
cables attached at the coupler and disconnected at a node,
terminated or not. Cables don't need to be removed from the
coupler cabinet while disconnected.
4. Disconnect cables for both paths at the coupler before
removing the module containing the Physical Channel circuits
(ILI module) for repair.
5. There is never a need to terminate the CI connectors on the
node bulkhead panel, only the unused coupler ports need to be
terminated.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 99
| 6. To reinstall the node, use the reverse of the above procedure.
| First, place the module containing the physical channel
| circuits (ILI) in the backplane and connect the internal
| cables. Second, install the external cables at the node end.
| Finally, install the external cables at the coupler(s).
12.5.2 Use Of Extender Cards -
A special version extender card must be used with the ILI or
Physical Channel module if CI bus functionality is needed. The
special extender card has coaxial cable connecting the CI bus
signals on the card. If the bus ports are disabled and not used
while the card is on the extender a regular CI extender card may
| be used. Check the specification for the particular CI
| implementation involved for extender compatability.
12.6 Allowed Configuration Exceptions
The CI will always work in many configurations that do not
meet the Installation Rules given above. These configurations,
given below, are intended to be used for maintenance or by
accident only. If a bus is configured as recommended above it is
immune to any single media problem while if configured as below a
failure may disrupt communication.
|
| The actual allowed configurations are summed up as follows:
| there can be one pair of unused cables or unterminated coupler
| ports on an otherwise correctly configured path. This situation
| will not disrupt the operation of properly connected nodes on same
| path in any way.
If a path is correctly configured to begin with, under no
circumstances does breaking the path(s) between the coupler and a
single node ever disrupt other nodes. Also, anything which
happens to only one path cannot disrupt the second path. It is
important to insure multiple ground or earth references do not
result from disconnected cables in casual contact with metal
things. The following are allowed while the cluster operates:
1. Removing and restoring power for an individual node.
2. One unterminated transmit/receive pair of cables or coupler
ports per path. The path to a node may be broken in any way
without affecting the rest of the nodes using that path. If
only one path for a node is disconnected the second path will
work.
3. Removal of the Physical Channel logic module while the node is
fully connected. This leaves the cables of both paths
unterminated but will only disrupt the involved node.
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 100
4. Disconnection of any or all cables at any point between the
coupler and the backplane in a node.
5. A damaged cable with an internal short or open circuit.
12.7 Mechanical Considerations
--- to be added ---
CI SPECIFICATION--COMPANY CONFIDENTIAL Page 101
13.0 DIAGNOSTIC AND MAINTAINABILITY REQUIREMENTS
ALL CI nodes must comply with the CI Diagnostic Strategy.
Reference applicable documents for further information. In
addition, all nodes must be compatible with both the CI Network
Exerciser and CI Node Tester. For further details, see
specifications listed in Reference Documents section.
APPENDIX A
CI OPCODE SUMMARY
CI PACKET DEC HEX OCTAL BINARY
DG 1 1 1 0000 0001
MSG 2 2 2 0000 0010
SNTDAT 16 10 20 0001 0000
CNF 3 3 3 0000 0011
|
| DATREQ0 8 8 10 0000 1000
|
| DATREQ1 9 9 11 0000 1001
|
| DATREQ2 10 A 12 0000 1010
|
RETDAT 17 11 21 0001 0001
IDREQ 5 5 5 0000 0101
RST 6 6 6 0000 0110
SNTMDAT 18 12 22 0001 0010
|
| MDATREQ 14 E 16 0000 1110
|
STRT 7 7 7 0000 0111
ID 11 B 13 0000 1011
RETMDAT 19 13 23 0001 0011
|
| MCNF 4 4 4 0000 0100
|
LB 13 D 15 0000 1101
NOTE: Opcode values with bit <7> = 1 are reserved for
local port use.
APPENDIX B
EXAMPLE OF NODE BOOTING VIA CI
The following sections show examples of use of the
configuration and maintenance commands. The examples show
bootstrapping. Remote system diagnosis is assumed to be similar
with respect to loading and starting diagnostic programs.
B.0.1 Locally-Loaded System
Action Local Port CI Packet Remote Action
State
Port power-up. Uninitialized
:
Host executes
bootstrap.
:
Host initializes port Disabled
and port driver.
:
Host enables port
and begins on-line Enabled
operations.
:
Host sends IDREQ's
to all CI nodes
on both paths. IDREQ -> Request is received.
:
ID packet received. <- ID ID packet returned.
Host updates
configuration tables.
:
Higher level protocol
initiated to establish
communication.
EXAMPLE OF NODE BOOTING VIA CI Page B-2
B.0.2 Remotely-Loaded System
Action Local Port CI Packet Remote Action
State
| Port power-up. Uninitialized
| RST_PORT = port no. /Maintenance
| Host sends IDREQ's
| to all CI nodes
| <- IDREQ on both paths in
| Request is received. configuration poll.
| :
| ID packet returned. ID -> ID packet received.
| Host updates
| configuration tables,
| recognizes state
| and type requiring
| down-line load.
| :
| RST received and Uninitialized <- RST Host sends RST (F=0)
| performed. Host /Maintenance :
| halted. RST_PORT :
| is set to remote :
| port no. :
| :
| :
| <- IDREQ Host sends IDREQ
| Request is received. to node being reset.
| :
| ID packet returned. ID -> ID packet received.
| Host checks returned
| RST_PORT value.
| Sequence is repeated
| until RST_PORT is
| this port's no. If
| neccessary, repeat
| RST.
| :
Data is loaded <- SNTMDAT Host loads remote
into physically (LP) system program
addressed memory. using maintenance
: write mechanisms.
:
Port generates MCNF -> MCNF confirmation
confirmation. passed to host.
:
Host verifies load
Port receives <- MDATREQ using maintenance
request and responds read mechanims.
by returning data
with last packet
having special RETMDAT -> Confirmation is
flag. (LP) passed to host.
:
EXAMPLE OF NODE BOOTING VIA CI Page B-3
:
Host compares data.
:
Repeat write/read
operation until
complete.
:
Load was successful,
Port receives start <- STRT Host sends STRT.
and responds by
starting host execution.
:
System operation
proceeds as in local
load and boot case.
EXAMPLE OF NODE BOOTING VIA CI Page B-4
B.0.3 A Booting Example -- 11/780
This outlines how an 11/780 system may be booted via the CI.
The definition of "booting" (in this case) is the load and
starting of a program in the host CPU. Although this description
is specifically only for the 11/780, it should be generally
extensible to other systems, particularly other VAX systems.
This is the sequence as defined from the node controlling the boot:
|
| 1. Send a RST packet that will perform the reset function in the
| remote node. This specifically implies a RST that will result
| in the destination port entering the Uninitialized/Maintenance
| state. This may, in fact, include sending an IDREQ to
| determine the initial state, and sending either a conditional
| or forced RST (or a sequence of both).
|
| 2. Poll for the reset being performed by sending IDREQ packets
| and waiting for returned ID. The reset is successful when the
| returned state is Uninitialized/Maintenance and the RST_PORT
| is the number of the port sending the reset.
|
| If the correct ID is not received, the RST should be
| re-transmitted after a suitable timeout period. Since the RST
is a datagram packet, it may be discarded under certain
conditions. A suitable timeout period would be 1 second. The
reset operation on an 11/780 takes on the order of 100 ms
under optimal conditions (no other packets are in the packet
buffer). At most, the reset should take on the order of 200
ms. The SNDRST should be retried some number of times. A
nominal suggested retry limit is 100. This is an arbitrary
limit, as no analytical method exists for determining what
this number should be for a given probability of failure.
3. Upon receipt and processing of the RST packet, the port will
assert and hold FAIL. 5 ms later, the port will assert DEAD
for 2 us. Upon release of DEAD, the console will attempt a
WCS reload from the floppy. Upon completion of the load, the
console will examine the AUTO RESTART switch. The switch must
be in the ON position. Otherwise, the processor will halt.
If the RESTART switch is ON, the console will attempt a
restart sequence. In the 11/780, this begins with execution
of the floppy command file "RESTAR.CMD". Any commands in this
file will be executed until a START command is encountered.
The start function will not be performed until FAIL is
released by the CI780 interface (upon receipt of a STRT
packet).
Note that the restart command file must not contain any
operations that will disturb the state of the port (such as
UNJAM or deposits to certain port registers). The standard
RESTAR.CMD (after version 2.0) is alledgedly compatible with
these requirements.
EXAMPLE OF NODE BOOTING VIA CI Page B-5
4. Using SNTMDAT packets (to write) and MDATREQ packets (to read)
the memory, load and verify the desired boot program. As with
the RST, these packets should retried. The suggested
algorithm is to send a data packet and wait some timeout
period (like 100 ms) for a MCNF. If not received before the
timeout, the packet should be retried some limited number of
times (like 100). A unique transaction ID should be used for
each operation (not necssarily for each retry). The
transaction ID of each response should be checked against the
current transaction ID value. If the ID is not correct, the
response should be ignored. This allows for duplication or
delayed responses.
Subsequent to the receipt of the MCNF, the corresponding
MDATREQ should be posted. A similar wait and retry algorithm
should be used for the RETMDAT packet with the LP flag set.
Upon receipt of the RETMDAT packet (LP = 1), a compare of
the buffer areas should be made to ensure correct loading. A
compare error should, in general, be considered fatal. Such
errors could, however, also be retried. Additionally, if the
retry limit is ever reached, it also should be considered
fatal.
A program of any size may be loaded with multiple
write/read operations.
As part of the load, a Restart Parameter Block (RPB) must
be set up at the base of the first usable 64 KB block in
memory. The RPB consists of four longwords of the following
format:
1. Longword 0 -- Address (physical) of the RPB (Longword 0).
2. Longword 1 -- Address (physical) of the program to be
started.
3. Longword 2 -- 32-bit checksum (32 bit additions without
carry) of first 31 longwords of program (starting at
address specified in Longword 1 of the RPB).
4. Longword 3 -- Bit 0 must be a 0 to restart. Otherwise,
cold start will occur.
The address of the first usable 64 KB block can be
determined via a remote "memory sizing test" using SNDMDAT and
REQMDAT for writes and reads. A response will not be received
for non-existent or failing memory.
5. Send a STRT packet. When the start packet is received, or
when the processor WCS has been loaded and RESTAR.CMD executed
(whichever comes first), the processor will begin executing
the restart referee of the ROM bootstrap code. If the RPB is
correct and no other errors occur, the ROM code will transfer
EXAMPLE OF NODE BOOTING VIA CI Page B-6
control to the address specified in the RPB. Otherwise, cold
start (from DEFBOO.CMD) will be attempted.
6. The booted program should eventually backload microcode and
send a message of some type to confirm success of the boot.
Note that if the port is restarted to load microcode, the
RST_PORT value that would be returned in an ID packet is
destroyed. Therefore, the port does not provide a mechanism
to determine which node booted the system. This information
could be passed in the loaded program. Otherwise, a boot
message could be sent (successively) to all possible node.
If the boot message is not received within a reasonable
timeout period, the STRT packet should be transmitted until
the program start is successful. The reasonable timeout
period may be on the order of 10's of seconds. In the case of
the 11/780, it is determined primarily by the console terminal
speed and the floppy disk operation time.
If the down-line load and start is complete before the
console restart sequence, execution will begin when the
console executes the START of the command file. If the
down-line load requires more time than the console restart,
execution will begin immediately on receipt of the STRT
packet.
This algorithm has been tested on an 11/780. The program
that was down-line loaded included a copy of the port microcode.
Upon starting, it initialized and loaded the port microcode,
enabled the port, printed a console message, and sent a boot
message (of text) to ports 0:15. The following sequence and times
were observed using a console terminal at 9600 baud:
EXAMPLE OF NODE BOOTING VIA CI Page B-7
1
EVENT TIME (from 0 in ms)
SNDRST 0
IDREC (RST_PORT correct) 110
SNDMDAT 110
MCNFREC 120
REQMDAT 120
MDATREC 130
: 2
: 25,911 bytes (51 operations)
:
MDATREC 1280
SNDSTRT 1290
MSGREC (booted) 14330
NOTES:
1. Resolution is 10 ms.
2. Load bandwidth = 22.1 KB/s (includes test program overhead.
APPENDIX C
MINIMAL IMPLEMENTATION OF DUAL PATH INTERFACE
CI interfaces are not required to support full operation on
both paths simultaneously. It is compatible and permissible to
share as much transmit and receive and path hardware as possible.
An example of a highly shared hardware interface is one which only
has path specific physical channel hardware, that is, duplicated
media drivers, receivers and carrier detect circuitry. An example
of such an implementation is fully described in the L0100 Link
specification (an appendix of this document).
Additionally, hardware may be shared for the transmit and
receive functions. An example of this is to use the same CRC
calculator for both checking and generation. This implies that
transmit and receive cannot take place simultaneously, notably in
loopback, where the higher layers (such as the port) may be
required to perform the CRC calculation and load the result into
the transmit buffer.
The combination of these reductions requires the careful
synchronization of the transmit and receive processes, since both
processes are required (due to the required acknowledgement) for
any transaction. In cases requiring prioritization decisions, the
receipt of packets from the bus should have higher priority, to
minimize the wasting of media bandwidth, otherwise available to
other nodes.
An example of such an implementation is described in detail
in the L0100 Link Specification Appendix. All future
implementations should use this design as a reference for minimal
implementation of functional compatibility.
APPENDIX D
IMPLEMENTATION FUNCTIONALITY
D.0.1 Implementation Functionality Field
This field is located in the ID packet and describes the
supported functionality of the port.
Each bit of this field corresponds to a function. If the
implementation supports the function, the corresponding bit value
should be one. If not, the bit should be zero. Unused bits are
reserved for future expansion and must be zero in current ports
for compatibility with future functions. The format of PORT_FCN
is:
|
| 3 2 2
| 1 6 5 8 7 0
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | STATES | PACKETS | RSVD (MBZ) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Where:
Bit Function
31 Enabled state.
30 Enabled/Maintenance state.
29 Disabled state.
28 Disabled/Maintenance state.
27 Uninitialized state.
26 Uninitialized/Maintenance state.
25 Snd MSG/Rcv MSG
24 Snd SNTDAT/Rcv CNF
23 Rcv SNTDAT/Snd CNF
| 22 Snd DATREQ0/Rcv RETDAT
| 21 Snd DATREQ1/Rcv RETDAT
| 20 Snd DATREQ2/Rcv RETDAT
| 19 Rcv DATREQ0/Snd RETDAT
| 18 Rcv DATREQ1/Snd RETDAT
| 17 Rcv DATREQ2/Snd RETDAT
| 16 Snd IDREQ/Rcv ID
IMPLEMENTATION FUNCTIONALITY Page D-2
| 15 Snd SNTMDAT/Rcv MCNF
| 14 Rcv SNTMDAT/Snd MCNF
| 13 Snd MDATREQ/Rcv RETMDAT
| 12 Rcv MDATREQ/Snd RETMDAT
| 11 Snd RST
| 10 Snd STRT
| 9 Rcv RST-STRT
| 8 Snd/Rcv LB
|
| 7 - 0 Reserved and MBZ.
|
|
D.0.2 Implementation Functionality Summary
"X" = Supported, "-" = Not Supported
| OPTION |
FUNCTION |-----+-----+-----+-------+-----+-----+-----+
|CI780|CI750|HSC50|JUPITER| KL10| CINT| |
------------------+-----+-----+-----+-------+-----+-----+-----+
MAINT_ID | 2 | 3 | 4 | 5 | 6 | 7 | |
------------------+-----+-----+-----+-------+-----+-----+-----+
| | | | | | | |
STATES | | | | | | | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Uninitialized | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Uninit/Maint | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Disabled | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Dsbld/Maint | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Enabled | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
Enbld/Maint | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
IMPLEMENTATION FUNCTIONALITY Page D-3
| OPTION |
FUNCTION |-----+-----+-----+-------+-----+-----+-----+
|CI780|CI750|HSC50|JUPITER| KL10| CINT| |
------------------+-----+-----+-----+-------+-----+-----+-----+
| | | | | | | |
PACKETS SND/RCV | | | | | | | |
------------------+-----+-----+-----+-------+-----+-----+-----+
MSG/MSG | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
SNTDAT/CNF | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
CNF/SNTDAT | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
DATREQ0/RETDAT | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
DATREQ1/RETDAT | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
DATREQ2/RETDAT | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
RETDAT/DATREQ0 | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
RETDAT/DATREQ1 | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
RETDAT/DATREQ2 | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
IDREQ/ID | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
SNTMDAT/MCNF | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
MCNF/SNTMDAT | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
MDATREQ/RETMDAT | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
RETMDAT/MDATREQ | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
RST/ | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
STRT/ | X | X | - | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
/RST-STRT | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
LB/LB | X | X | X | | | X | |
------------------+-----+-----+-----+-------+-----+-----+-----+
APPENDIX E
ACTIVE EXCHANGE HUB SPECIFICATION
\ TO BE ADDED IN THE FUTURE \
APPENDIX F
L0100 LINK SPECIFICATION
TITLE: L0100 CI LINK Functional and Interface
Specification
STATUS: Released
ABSTRACT: This document describes the hardware interface to
the CI LINK Interface module.
AUTHOR: John Buzynski
MAIL STOP: TW/C03
PHONE: 247-2329
REVISION HISTORY:
Date Revision Comments
____ ________ ________
1 OCT 1979 A (Draft) This document replaces and
supersedes the PORT to LINK
Interconnect (PLI) and the
LINK Interface spec of
August 7, 1979.
17 DEC 1979 B
18 MAR 1980 C
31 OCT 1980 D
1 MAY 1981 E Incorporate into CI spec.
Update with minor changes.
15 NOV 1981 F Corrections from review.
Update with CI spec rev 2.
L0100 LINK SPECIFICATION Page F-2
F.1 TABLE OF CONTENTS
F.1 TABLE OF CONTENTS . . . . . . . . . . . . . . . . F-2
F.2 REFERENCE DOCUMENTS . . . . . . . . . . . . . . . F-4
F.3 GENERAL . . . . . . . . . . . . . . . . . . . . . F-5
F.4 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . F-6
F.4.1 PROTOCOL . . . . . . . . . . . . . . . . . . . . F-6
F.4.1.1 INFORMATION PACKETS . . . . . . . . . . . . . F-6
F.4.1.1.1 Bit Synchronization . . . . . . . . . . . . F-8
F.4.1.1.2 Character Synchronization . . . . . . . . . F-8
F.4.1.1.3 Packet Type/Length (High) . . . . . . . . . F-8
F.4.1.1.4 Packet Length (Low) . . . . . . . . . . . . F-9
F.4.1.1.5 Destination . . . . . . . . . . . . . . . . F-9
F.4.1.1.6 Source . . . . . . . . . . . . . . . . . . F-10
F.4.1.1.7 Body . . . . . . . . . . . . . . . . . . . F-10
F.4.1.1.8 Cyclical Redundancy Check (CRC) . . . . . F-10
F.4.1.1.9 Trailer . . . . . . . . . . . . . . . . . F-11
F.4.1.2 ACKNOWLEDGE PACKETS . . . . . . . . . . . . F-11
F.4.1.2.1 Packet Type . . . . . . . . . . . . . . . F-13
F.4.1.3 ARBITRATION . . . . . . . . . . . . . . . . F-13
F.4.1.3.1 PACKET ACKNOWLEDGEMENT . . . . . . . . . . F-16
F.4.2 DUAL PATH CI STRUCTURE . . . . . . . . . . . . F-17
F.4.2.1 HEADER TIMEOUT . . . . . . . . . . . . . . . F-18
F.4.3 MAINTENANCE MODES . . . . . . . . . . . . . . F-18
F.5 LINK INTERFACE . . . . . . . . . . . . . . . . . F-18
F.5.1 LINK INTERFACE SIGNALS . . . . . . . . . . . . F-19
F.5.1.1 XMIT DATA (7:0) (TTL INPUT, ASSERTED HIGH) . F-21
F.5.1.2 XMIT DATA PARITY (TTL INPUT, ASSERTED HIGH) F-21
F.5.1.3 RCVR DATA (7:0) (TTL OUTPUT, ASSERTED HIGH) F-22
F.5.1.4 RCVR DATA PARITY (ODD) (TTL OUTPUT, ASSERTED
HIGH) . . . . . . . . . . . . . . . . . . . F-22
F.5.1.5 PORT DATA (7:0) (TTL INPUT, ASSERTED HIGH) . F-22
F.5.1.6 NODE ADDRESS (7:0) (TTL OUTPUT, ASSERTED
HIGH) . . . . . . . . . . . . . . . . . . . F-22
F.5.1.7 SELECT (TTL INPUT, ASSERTED HIGH) . . . . . F-22
F.5.1.8 LINK CONTROL (3:0) (TTL INPUT, ASSERTED HIGH) F-23
F.5.1.8.1 TRANSMIT . . . . . . . . . . . . . . . . . F-23
F.5.1.8.2 RESET TRANSMIT STATUS . . . . . . . . . . F-24
F.5.1.8.3 ABORT TRANSMISSION . . . . . . . . . . . . F-24
F.5.1.8.4 ENABLE LINK CONTROL/DISABLE LINK CONTROL . F-24
F.5.1.9 XMIT STATUS (7:0) (TTL OUTPUT, ASSERTED HIGH) F-28
F.5.1.10 XMIT ATTENTION (TTL OUTPUT, ASSERTED HIGH) . F-30
F.5.1.11 XMIT DATA ENABLE (TTL OUTPUT, ASSERTED HIGH) F-30
F.5.1.12 XMIT BUFFER EMPTY (TTL INPUT, ASSERTED HIGH) F-31
F.5.1.13 VALID RCVR DATA (TTL OUTPUT, ASSERTED HIGH) F-31
F.5.1.14 RCVR PACKET END (TTL INPUT, ASSERTED HIGH) . F-31
F.5.1.15 RCVR BUFFERS FULL (TTL INPUT, ASSERTED HIGH) F-31
F.5.1.16 VALID RCVR STATUS (TTL OUTPUT, ASSERTED HIGH) F-31
F.5.1.17 PACKET LENGTH (TTL OUTPUT, ASSERTED HIGH) . F-32
F.5.1.18 ICCS PATH B (TTL OUTPUT) . . . . . . . . . . F-32
F.5.1.19 CRC STATUS (TTL OUTPUT) . . . . . . . . . . F-32
F.5.1.20 PORT CLOCK (TTL INPUT) . . . . . . . . . . . F-32
F.5.1.21 XMIT CLOCK . . . . . . . . . . . . . . . . . F-33
F.5.1.22 RCVR CLOCK . . . . . . . . . . . . . . . . . F-33
F.5.1.23 INITIALIZE (TTL INPUT, ASSERTED HIGH) . . . F-33
L0100 LINK SPECIFICATION Page F-3
F.5.1.24 RCVR A ENABLE (TTL OUTPUT, ASSERTED High) . F-33
F.5.1.25 RCVR B ENABLE (TTL OUTPUT, ASSERTED High) . F-33
F.5.1.26 XTEND HDR (TTL INPUT, ASSERTED Low) . . . . F-34
F.5.1.27 ALTER DELTA TIME (TTL INPUT, ASSERTED Low) . F-34
F.5.1.28 DISABLE ARB (TTL INPUT, ASSERTED Low) . . . F-34
F.5.1.29 MODULE INSERTED LOOP . . . . . . . . . . . . F-34
F.5.1.30 EXTEND ACK TO (TTL INPUT, ASSERTED LOW) . . F-34
F.5.1.31 DISABLE RCVR CLK (TTL INPUT, ASSERTED Low) . F-34
F.5.1.32 RCVR TEST CLK (TTL INPUT, ASSERTED Low) . . F-35
F.5.1.33 XMIT TEST CLK (Low High) (TTL INPUTS) . . . F-35
_
F.5.1.34 XMIT CLK DISABLE (TTL INPUT, ASSERTED Low) . F-35
F.5.2 LINK INTERFACE TIMING . . . . . . . . . . . . F-36
F.6 MECHANICAL . . . . . . . . . . . . . . . . . . . F-41
F.6.1 General . . . . . . . . . . . . . . . . . . . F-41
F.6.2 Module Keying . . . . . . . . . . . . . . . . F-41
F.6.3 Power Requirements . . . . . . . . . . . . . . F-41
F.6.4 Cooling . . . . . . . . . . . . . . . . . . . F-41
F.6.5 LEDS . . . . . . . . . . . . . . . . . . . . . F-42
F.6.5.1 INTERNAL MAINTENANCE LOOP (RED) . . . . . . F-42
F.6.5.2 LOCAL CI ACTIVITY (GREEN) . . . . . . . . . F-42
F.7 APPENDIX A . . . . . . . . . . . . . . . . . . . F-42
F.8 APPENDIX B . . . . . . . . . . . . . . . . . . . F-43
F.9 APPENDIX C . . . . . . . . . . . . . . . . . . . F-44
L0100 LINK SPECIFICATION Page F-4
F.2 REFERENCE DOCUMENTS
1. VAX-11 CI PORT Architecture -(W. Strecker); describes the
VAX-11 software interface to the Computer Interconnect (CI).
2. CI Architecture Specification -(D. Thompson, J. Buzynski, J.
Hutchison); Describes the structure, electrical
characteristics, configuration, information format, and
protocol for the CI system.
3. CI780 PORT Specification -(M. Carrafiello) Describes and
specifies the interface between the SBI and CI.
L0100 LINK SPECIFICATION Page F-5
F.3 GENERAL
The PORT PROCESSOR and LINK combine to provide a device with
the control mechanism and interface to the CI Bus. The PORT
PROCESSOR is the interface to the host device and is responsible
for the data mapping, data buffering and the control of the LINK
interface.
The LINK provides the actual interface to the CI Bus and is
capable of servicing a dual path CI Bus. The LINK can only
transmit or receive over one CI path at any one time. The LINK
interface allows for discrete selection of the transmit path and
provides automatic selection of the receive path by monitoring the
"initial presence" of carrier on either path. The LINK has only a
single CRC circuit which is shared by the transmitter and
receiver, therefore, simultaneous transmissions and/or receptions
cannot occur at a single node unless the LINK is in one of the
maintenance loop modes.
The serialization and deserialization of data, 32-bit CRC
generation and checking, CI protocol handling, Dual Count-down
Round Robin arbitration and LINK Status information to the PORT
PROCESSOR are provided by the LINK. Internal and external
maintenance loop mechanisms are provided by the LINK.
L0100 LINK SPECIFICATION Page F-6
F.4 FUNCTIONAL DESCRIPTION
This section describes the LINK functionality. It is
expected that the reader has read and understands the "CI
Architecture Specification". Some pieces of the above
specification are repeated in this section for convenience.
F.4.1 PROTOCOL
The LINK hardware implements the CI Bus protocol to arbitrate
for the CI Bus, to transmit and receive packets, and to confirm
the reception of those packets. There are two types of packets
handled by the LINK, Information packets and Acknowledge packets.
F.4.1.1 INFORMATION PACKETS -
The organization and description of the contents of the
Information packet is given below. The Information packet is used
to transmit both message and data packets across the CI. Some of
the CI packet information is inserted by the LINK and some is
inserted by the PORT PROCESSOR as described below.
L0100 LINK SPECIFICATION Page F-7
7 0
+-----------------------------+
| BIT SYNC (55 HEX) | First byte
+-----------------------------+ Transmitted
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| CHAR SYNC (96 HEX) |
+-----------------------------+
| PACKET TYPE/LENGTH (High)| First byte loaded
+-----------------------------+ or read by PORT PROCESSOR
| PACKET LENGTH (Low) |
+-----------------------------+
| DESTINATION (TRUE) |
+-----------------------------+
| DESTINATION (COMPLEMENT) |
+-----------------------------+
| SOURCE |
+-----------------------------+
| BODY | Last byte loaded
+-----------------------------+ or read by PORT PROCESSOR
| CRC-0 |
+-----------------------------+
| CRC-1 |
+-----------------------------+
| CRC-2 |
+-----------------------------+
| CRC-3 |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
: TRAILER (00 HEX) :
+-----------------------------+
FIGURE F4-1
INFORMATION PACKET FORMAT
L0100 LINK SPECIFICATION Page F-8
F.4.1.1.1 Bit Synchronization -
Bit Synchronization (55 hexadecimal) is an alternating
pattern of 1's and 0's which is used to turn on the carrier detect
circuits and to synchronize the delay line decoder circuit in the
receiver. The LINK hardware inserts this bit pattern into the
data stream. There are normally 5 bytes of Bit Sync transmitted.
Bit sync may be extended to 15 bytes by grounding I/O pin B7.
F.4.1.1.2 Character Synchronization -
Character Synchronization (96 Hexadecimal) is the character
used to synchronize the receiver on an 8 bit character basis. The
receiver will monitor the serial bit stream for the SYNC Character
and will frame the stream into 8 bit characters once the SYNC
character is found. The LINK hardware inserts the SYNC character
into the data stream.
F.4.1.1.3 Packet Type/Length (High) -
The Packet Type/Length field contains information specifying
whether the packet is an Information type or whether it is an
Acknowledge type. Information packets are of variable length in 1
byte increments up to 4K bytes maximum with the minimum packet
length being 7 bytes. This byte contains the high 4 bits of the
12 bit packet length.
The Packet Type /Length field is described as follows:
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | | | |
| 0 | 0 | 0 | 0 | L11 | L10 | L9 | L8 |
| | | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0
FIGURE F4-2
PACKET TYPE/LENGTH FIELD
FOR INFORMATION PACKETS
L0100 LINK SPECIFICATION Page F-9
BIT 7: 0 = Information packet
BIT 6: This bit must be zero for information packets.
BITS (5:4): These bits are reserved for future use and must
be zero.
BITS (3:0): These bits form the high 4 bits of the 12 bit
packet length field.
F.4.1.1.4 Packet Length (Low) -
This byte contains the low 8 bits of the 12 bit packet length
field.
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | | | |
| L7 | L6 | L5 | L4 | L3 | L2 | L1 | L0 |
| | | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0
FIGURE F4-3
PACKET LENGTH (Low) BYTE
FOR INFORMATION PACKETS
The 12 bit packet length includes all data from the Packet
Type/Length byte up to and including the last byte of the body. A
value of 0 indicates 4096 byte length.
F.4.1.1.5 Destination -
The Destination is the 8 bit address of the target CI node.
There are two bytes; the first being the true node address value
and the second being the complement of the true value. The LINK
will save the true value during a transmission to be used to
verify the Source of the expected acknowledgement packet. The
PORT Processor supplies the Destination bytes as part of the
packet.
The true and complement forms are sent to accomodate high
availability systems as follows. One of the goals of a high
availability system is that no single component failure may
permanently bring down both CI paths. Since this LINK
implementation services 2 CI paths with a single transmit and
receive path, a failure in the common destination decode logic,
causing a node to decode another node's address might have
L0100 LINK SPECIFICATION Page F-10
resulted in both nodes transmitting an Acknowledge packet
simultaneously. This would result in a collision on the CI and
would be seen as a no response by the transmitting node.
To overcome this problem the LINK incorporates redundant
destination decode circuits, one decoding the true address and the
other decoding the complemented address.
F.4.1.1.6 Source -
The Source is the 8 bit address of the sending node and is
supplied by the PORT PROCESSOR as part of the packet. The
receiver will save this address and use it as the destination
address in the Acknowledge packet.
F.4.1.1.7 Body -
The Body contains the data and PORT-processed protocol
information. The Body contents are specified for Data and Message
packet types in the CI Architecture Specification. The Body is
supplied by the PORT as part of the packet.
F.4.1.1.8 Cyclical Redundancy Check (CRC) -
The Cyclical Redundancy Check (CRC, 32 bit) is provided for
error detection. The CRC is generated and checked using the
polynomial:
X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 +
X7 + X5 + X4 + X2 + X + 1
The transmitter and receiver CRC generators are preset to all
1's prior to generating the CRC characters. The transmitter sends
the complement of the generated CRC characters LSB first which is
the high order coefficient end of the CRC. An error free packet
reception results in the value DEBB20E3 (HEX).
CRC is generated by the LINK hardware on the Packet
Type/Length, Packet Length, Destination, Source and Body of the
packet. Four bytes of CRC are generated and transmitted with
CRC-0 being the least significant byte.
L0100 LINK SPECIFICATION Page F-11
F.4.1.1.9 Trailer -
The Trailer is normally 6 characters of NUL (00 HEX) data
which is used to insure that all bits of the packet have been
shifted through the LINK front end logic. The Trailer is inserted
by the LINK hardware.
F.4.1.2 ACKNOWLEDGE PACKETS -
The Acknowledge packet is sent by the receiving node to
inform the information transmitting node that the packet arrived
without collision or data loss (CRC checks OK). The packet
contains STATUS information as to whether the packet was accepted.
If the receiver's buffer(s) were unable to accept a packet, then a
NAK status is returned. If the receiving node successfully
accepted the packet into its buffer, an ACK is returned denoting
the successful bus transaction. The entire Acknowledge packet is
generated and transmitted by the LINK hardware. The format of the
Acknowledge packet is shown below.
L0100 LINK SPECIFICATION Page F-12
7 0
+-----------------------------+ First byte
| BIT SYNC (55 HEX) | Transmitted
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| BIT SYNC (55 HEX) |
+-----------------------------+
| CHAR SYNC (96 HEX) |
+-----------------------------+
| PACKET TYPE |
+-----------------------------+
| DESTINATION (TRUE) |
+-----------------------------+
| DESTINATION (COMPLEMENT) |
+-----------------------------+
| SOURCE |
+-----------------------------+
| CRC-0 |
+-----------------------------+
| CRC-1 |
+-----------------------------+
| CRC-2 |
+-----------------------------+
| CRC-3 |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
| TRAILER (00 HEX) |
+-----------------------------+
: TRAILER (00 HEX) :
+-----------------------------+
FIGURE F4-4
ACKNOWLEDGE PACKET FORMAT
As shown above, there is no Body in the Acknowledge packet.
The descriptions of all other fields except the Packet Type/Length
and the Packet Length fields are the same for Acknowledge packets
as they are for Information packets.
L0100 LINK SPECIFICATION Page F-13
F.4.1.2.1 Packet Type - The Packet Type field is defined as
follows:
+-----+-----+-----+-----+-----+-----+-----+-----+
| | ACK/| | | | | | |
| 1 | NAK | 0 | 0 | 0 | 0 | 0 | 0 |
| | | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0
FIGURE F4-5
PACKET TYPE/LENGTH FIELD
FOR ACKNOWLEDGE PACKETS
BIT 7: 1 = Acknowledge packet type.
BIT 6: 1 = Acknowledge with ACK status. Packet was
received correctly and accepted into the packet
buffer.
0 = Acknowledge with NAK status. Packet was
received correctly but was not accepted into
the packet buffer. Requires retransmission.
BITs (5:0) These bits must be zero for Acknowledge
packets.
F.4.1.3 ARBITRATION -
The arbitration used for the CI is a Dual Countdown Round
Robin algorithm. Consider an N node system where node I has two
possible countdown values I and N + I. The choice of which value
to use depends on whether (from the node I point of view) the last
node (modulo N) to win arbitration had a lower or higher node
number than node I. If the last winner had a lower number, node I
uses the I countdown value; if the last winner had the same or a
higher number, node I uses the N + I countdown value.
N is always = 16 = maximum # nodes allowed on the system.
I = this node number.
L0100 LINK SPECIFICATION Page F-14
The way a node determines who won the last arbitration is as
follows. At the beginning of arbitration, a node saves a copy of
its own countdown value. When the arbitration ends (either by
detection of carrier or countdown to 0), the difference (modulo N)
of the initial and final countdown values is the node number of
the node which won the arbitration. The above is true only when
there is activity on the CI since the de-assertion of carrier is
necessary to synchronize each LINK's arbitration logic.
Once the arbitration has been successful (count = 0), the
transmitter checks to see that the receiver is not busy on the
alternate CI path. If it is not, the receiver will be locked to
the selected transmit path and the transmission will begin. If
the receiver is busy, the transmitter will load 16 into the
arbitration counter and continue to arbitrate.
Receiver busy is defined as follows:
1. The receiver has detected carrier on the alternate path but
has not yet detected its own destination and has not exceeded
the header timeout.
2. The receiver has detected its own destination and is accepting
the packet on thee alternate CI path.
3. A valid packet has been received and the transmitter is in the
process of transmitting the Acknowledge packet.
Figure F4-6 below is a flow diagram of this LINK's
implementation of the arbitration algorithm.
L0100 LINK SPECIFICATION Page F-15
START ----->-<----------------------------------------
| ^ |
v | |
TRANSMIT | |
? | |
|------ NO |
YES | |
v |
COUNT <- N+I+1 |
| |
------------------>|<----------------------------------- |
| v | |
| CARRIER | |
| ? | |
| |--------------- | |
| YES | NO | | |
| | v | |
| | COUNT <- COUNT - 1 | |
| v | | |
| LW <,>= I v | |
| ----------- ? ------ COUNT = 0 | |
| | < >= | ? | |
| v v |------------------->| |
| COUNT <- I+1 COUNT <- N+I+1 | NO ^ |
| | | YES | | |
| -------------------- v | |
| | RCVR BUSY | |
------------------- ? | |
|------------ | |
NO | YES | | |
| | | |
| | | |
| | | |
| | | |
|NO | | |
v | | |
TAKE OVER RCVR & | | |
TRANSMIT PACKET | | |
N = Max # nodes on system | v | |
I = This node number | COUNT <- 16 | |
LW = Last winner (Mod N) | | |
| | | |
|<-------- ------- |
v | |
TRANSMISSION DONE | |
? | |
|--------- |
| NO |
YES |__________________________|
FIGURE F4-6
ARBITRATION FLOW DIAGRAM
L0100 LINK SPECIFICATION Page F-16
The arbitration count is the number of consecutive quiet
slots that must be observed before a node can transmit on an CI
path. The basic quite slot interval (refer to CI Architecture
Spec) is long enough to allow a receiving node to return an
Acknowledge packet. Acknowledge packets are the only packets
transmitted over the bus without first arbitrating for control.
Successful arbitration is defined as successfully transmitting a
packet without collision. A collision is detected by the CRC
calculation.
F.4.1.3.1 PACKET ACKNOWLEDGEMENT -
After the LINK has transmitted an Information packet, the
receiver waits for an Acknowledge packet to be returned. The
Contents of the Acknowledge packet will indicate either an ACK
(successful transmission) or NAK status. If an ACK is received,
then the transmission was received successfully and stored within
the responder's packet buffer. If a NAK status is received, then,
the Information packet was received without error. However, the
responder did not have a packet buffer available to accept the
packet and a retransmission is necessary. In the case when no
Acknowledge packet is received (no response) the indication is
that the packet became corrupted along the way, that the node was
not available, that the node was involved with the other
interconnect path at the time of the transmission, or some
hardware failure has occurred. In any case, a retransmission is
necessary.
If an Acknowledge packet is received with its Source field
matching the Destination field of the Information transfer and
correct CRC within an Acknowledge timeout period of D2 from the
end of Information packet transmit, where:
D2 >(Delta + Ack Turn-around time + Ack
verification time)
and
Delta = basic quiet slot time
Ack turn-around time = skews due to LINK logic
then, the receiver (in the transmitting node) notifies the PORT
PROCESSOR of successful transmission.
D2 is normally approximately equal to 32 byte times. This
time may be extended to approximately 256 byte times by grounding
I/O pin B10.
Delta is normally equal to 7 byte times (800 ns). This time
may be extended to 16 byte times (1.83 ns.) by grounding I/O pin
in B8.
If the Acknowledge packet is not received before the period
D2 expires, then, the no response status will be returned by the
LINK as described in section F5.1.9.
L0100 LINK SPECIFICATION Page F-17
F.4.2 DUAL PATH CI STRUCTURE
The LINK provides the capability of servicing two CI paths
allowing devices to connect to high availability systems. The two
paths are not completely redundant, but, are implemented by
providing dual drivers and receivers which are connected to common
transmit and receive logic circuits. Simultaneous transmission
and reception is not possible unless the LINK is in one of the
loop modes described in section F5.1.8.4. The PORT must indicate
which CI path it wants to transmit on when it issues the
"Transmit" function.
The LINK automatically selects which CI path to receive on by
constantly monitoring both CI paths to detect the "initial
presence" of a carrier on either path and switching its shared
logic to the path containing the transmission. If the LINK
detects a transmission on both paths simultaneously, it always
selects path A (arbitrary decision). The LINK will then decode
the Destination field of the transmission.
If, when the Destination field is decoded, the LINK
determines that the transmission is meant for it, the LINK will
continue receiving the information from the selected path. At the
completion of the receiving process the LINK will again assume a
state that will be able to detect the "initial presence" of a
transmission on either path.
If, when the destination field is decoded, the LINK
determines that the transmission is not meant for it, the LINK
will ignore the remainder of the transmission and immediately
assume the state that will be able to detect the "initial
presence" of a transmission on either interconnect path.
The above allows the LINK to detect and receive transmissions
under the following conditions with the corresponding results:
1. A single transmission on either path will be accepted.
2. If a transmission on each path is detected by this node at the
same time, the packet on path A will be accepted. The LINK
always selects path A when it detects the simultaneous
"initial presence" of carrier on both CI paths. If the packet
on path B was for this node, the packet will not be received.
Acknowledge will not be received by the transmitter and a
retransmission may be attempted by the Transmitter.
3. If transmissions occur on each path but are not detected by
this node at the same time, the transmission that is detected
first will be received. If the packet on the other path is
for this node, it will be accepted only if the length of time
between the two transmissions is longer than:
L0100 LINK SPECIFICATION Page F-18
- the time required for a LINK to determine that the
first transmission is not meant for it,
PLUS
- the time required to detect the initial presence of the
second transmission.
Otherwise, the second packet will be ignored.
The above discussion concerning the automatic selection of
the CI receive path is valid providing this node is not currently
in the process of transmitting a packet. The receiver is locked
to the selected CI path during the entire transmission and until
an acknowledgement is either received or timed out.
F.4.2.1 HEADER TIMEOUT -
The LINK receiver includes a Header timeout period of
approximately 32 byte times, starting from the time when a message
carrier is selected, which will release the receiver from a path
if the receiver is unable to detect the SYNC character within the
timeout period. The Header timeout is shut off when the SYNC
character is detected. Header timeout is disabled for ACK
reception where ACK timeout is utilized.
F.4.3 MAINTENANCE MODES
There are several maintenance features implemented as
diagnostic aids in isolating LINK module failures.
Internal and External Maintenance loop modes are provided to
allow a node to transmit a packet to itself. Wrong receiver
parity generation is possible. The ability to force a carrier
detect is provided to aid in isolating an arbitration logic
failure. Finally, there is provision for swapping the true and
complement node address sources.
All of the above features are described in detail in section
F5.1.8.4.
F.5 LINK INTERFACE
This section describes the hardware interface between the
PORT and the LINK. Detail timing diagrams are included in section
F5.2.
L0100 LINK SPECIFICATION Page F-19
F.5.1 LINK INTERFACE SIGNALS
The following figure lists the signals necessary to interface
to the LINK module.
All LINK interface signals must be capable of driving a
minimum of 2 Schottky loads except for the three clock signals and
Initialize which must be capable of driving 4 Schottky loads.
LINK interface input signals must be limited to 2 Schottky
loads except for the three clock signals and Initialize which may
be 4 Schottky loads.
In - Out - Assertion Module Pin
Signal Put Put Logic Level
__________________________________________________________________
XMIT Data 7 x TTL High B81
XMIT Data 6 x TTL High B82
XMIT Data 5 x TTL High B80
XMIT Data 4 x TTL High B78
XMIT Data 3 x TTL High B77
XMIT Data 2 x TTL High B76
XMIT Data 1 x TTL High B75
XMIT Data 0 x TTL High B74
XMIT Data Parity x TTL High B73
ILIF RCVR Data 7 x TTL High B58
ILIF RCVR Data 6 x TTL High B57
ILIF RCVR Data 5 x TTL High B56
ILIF RCVR Data 4 x TTL High B55
ILIF RCVR Data 3 x TTL High B54
ILIF RCVR Data 2 x TTL High B53
ILIF RCVR Data 1 x TTL High B52
ILIF RCVR Data 0 x TTL High B51
ILIF RCVR Data Parity x TTL High B50
Port Data 7 x TTL High B27
Port Data 6 x TTL High B28
Port Data 5 x TTL High B25
Port Data 4 x TTL High B26
Port Data 3 x TTL High B24
Port Data 2 x TTL High B22
Port Data 1 x TTL High B21
Port Data 0 x TTL High B20
ILIK NODE Address 7 x TTL High B19
ILIK NODE Address 6 x TTL High B17
ILIK NODE Address 5 x TTL High B18
ILIK NODE Address 4 x TTL High B15
ILIK NODE Address 3 x TTL High B13
ILIK NODE Address 2 x TTL High B14
ILIK NODE Address 1 x TTL High B11
ILIK NODE Address 0 x TTL High B12
Select x TTL High B29
LINK Control 3 x TTL High B36
L0100 LINK SPECIFICATION Page F-20
In - Out - Assertion Module
Signal Put Put Logic Level Pin
__________________________________________________________________
LINK Control 2 x TTL High B34
LINK Control 1 x TTL High B32
LINK Control 0 x TTL High B31
ILIL XMIT Status 7 x TTL High B59
ILIL XMIT Status 6 x TTL High B69
ILIL XMIT Status 5 x TTL High B70
ILIB XMIT Status 4 x TTL High B67
ILIL XMIT Status 3 x TTL High B68
ILIL XMIT Status 2 x TTL High B65
ILIL XMIT Status 1 x TTL High B66
ILIL XMIT Status 0 x TTL High B63
ILIL XMIT Attention x TTL High B64
ILIC XMIT Data Enable x TTL High B62
XMIT Buffer Empty x TTL High B60
ILIA Valid RCVR Data x TTL High B49
RCVR Packet End x TTL High B30
RCVR Buffers Full x TTL High B43
ILIC Valid RCVR Status x TTL High B44
ILIA Packet Length x TTL High B41
ILIJ ICCS Path B x TTL High B39
ILIV CRC Status x TTL High B40
Port Clock x TTL High B71
ILIR XMIT Clock x TTL High B85
ILIN RCVR Clock x TTL High B42
Initialize x TTL High B35
ILIM RCVR A Enable x TTL High B37
ILIM RCVR B Enable x TTL Low B38
Extend HDR/TR x TTL Low B7
Alter Delta Time x TTL Low B8
Disable ARB x TTL Low B9
Extend ACK to x TTL Low B10
Module Inserted B5
Indication B6
Disable RCVR CLK x TTL Low B83
RCVR Test CLK x TTL Low B84
XMIT Test CLK x TTL Low B88
XMIT Test CLK x TTL High B87
XMIT CLK Disable x TTL Low B86
CIB XMIT x 10K ECL C11
CIB XMIT Shield x 10K ECL C7, C8, C9, C10
C12, C13, C14
CIA XMIT x 10K ECL C29
CIA XMIT Shield x 10K ECL C25, C26, C27,
C28, C30, C31,
C32
CIA RCVR x C83
CIA RCVR SHIELD x C79, C80, C81,
C82, C84, C85,
C86
L0100 LINK SPECIFICATION Page F-21
In - Out - Assertion Module
Signal Put Put Logic Level Pin
__________________________________________________________________
CIB RCVR x C67
CIB RCVR SHIELD x C63, C64, C65,
C66, C68, C69,
C70
+5V x A3, A4, A91,
B3,B4,B46, B47
B91, B92,
C3, C91, C92
-5.2V x C2, C45, C46,
C47 C89, C90
GND x A2, A16, A23,
A33, A61, A72,
A79, A92, B1,
B16 B23, B33,
B61, B72, B79,
B90, B93, B94,
C1, C19, C20,
C39, C40, C48,
C53, C54, C75,
C76, C93, C94
___________________________________________________________________
FIGURE F5-1
LINK Interface Signals
F.5.1.1 XMIT DATA (7:0) (TTL INPUT, ASSERTED HIGH) -
These lines are used to transfer transmit data from the PORT
Processor transmit packet buffer to the LINK Output Buffer
Register. The LINK Strobes data from these lines when XMIT DATA
ENABLE is asserted and ignores the XMIT DATA Lines at all other
times. Data must update each XMIT Clock cycle as long as there is
data to be transmitted and XMIT DATA ENABLE is asserted.
F.5.1.2 XMIT DATA PARITY (TTL INPUT, ASSERTED HIGH) -
Odd parity must be calculated by the PORT Processor on each
packet data byte transferred to the LINK. This parity bit must be
conveyed to the LINK via the XMIT DATA PARITY line along with its
corresponding byte of data on the XMIT DATA lines when XMIT DATA
ENABLE is asserted. The LINK will check parity at the output of
L0100 LINK SPECIFICATION Page F-22
the LINK XMIT DATA Register and will terminate the transmission in
the event of an error.
F.5.1.3 RCVR DATA (7:0) (TTL OUTPUT, ASSERTED HIGH) -
These lines are used to transfer the data received from an CI
Path to the receive packet buffers in the PORT Processor. RCVR
DATA is valid and is updated each RCVR CLOCK cycle as long as
VALID RCVR DATA is asserted. The first byte of data is valid
during the same cycle in which VALID RCVR DATA is first asserted.
The PORT Processor is responsible for keeping a byte count to
determine when the last valid byte is transferred.
F.5.1.4 RCVR DATA PARITY (ODD) (TTL OUTPUT, ASSERTED HIGH) -
Data being transferred to the PORT Processor via the RCVR
DATA lines will be accompanied by an odd parity bit on the RCVR
DATA PARITY line. It is up to the PORT to store and check parity
on the received data. Parity will only be valid when VALID RCVR
DATA is asserted and there is still data to be transferred.
There is a maintenance feature which allows the wrong parity
to be generated by the LINK and it is discussed in section
(F5.1.8.4).
F.5.1.5 PORT DATA (7:0) (TTL INPUT, ASSERTED HIGH) -
The PORT DATA lines are used to transfer control information
to the LINK. Examples include the CI path selection and LINK
control set up information, with the Enable/Disable LINK
functions.
F.5.1.6 NODE ADDRESS (7:0) (TTL OUTPUT, ASSERTED HIGH) -
The 8 bit CI node address for this LINK is available to the
PORT via the NODE ADDRESS lines. The address is set up VIA an 8
bit PIANO Dip switch on the LINK. There are two 8 bit dip
switches, providing the true and compliment node addresses.
F.5.1.7 SELECT (TTL INPUT, ASSERTED HIGH) -
The SELECT line must be asserted by the PORT to indicate that
a valid control function exists on the LINK CONTROL lines.
L0100 LINK SPECIFICATION Page F-23
F.5.1.8 LINK CONTROL (3:0) (TTL INPUT, ASSERTED HIGH) -
There are four LINK CONTROL lines supplied by the PORT which
are used to control the LINK. Control functions denoted by (*)
utilize the PORT DATA lines to pass additional control information
to the LINK. The SELECT line must be asserted to make the LINK
CONTROL lines valid.
Note that all control codes with bit 3 = 1 are null
functions. This is because the LINK CONTROL functions are decoded
as a subset of the CI 780 Buffer control lines. Other PORT
designs may simply ground LINK CONTROL bit 3 on their backpanel if
only 3 LINK CONTROL bits are supplied to the LINK.
The LINK CONTROL lines are encoded as follows:
-----------------------------------------
| LINK CONTROL BIT | FUNCTION |
| 3 2 1 0 | |
|--------------------|--------------------|
| 0 0 0 0 | NULL |
| 0 0 0 1 | NULL |
| 0 0 1 0 | RESERVED |
| 0 0 1 1 | TRANSMIT (*) |
| 0 1 0 0 | RESET TRANSMIT |
| | STATUS |
| 0 1 0 1 | ABORT TRANSMISSION|
| 0 1 1 0 | ENABLE LINK |
| | CONTROL (*) |
| 0 1 1 1 | DISABLE LINK |
| | CONTROL (*) |
| 1 0 0 0 | NULL |
| THRU | " |
| 1 1 1 1 | NULL |
|____________________|____________________|
FIGURE F5-2
LINK CONTROL
F.5.1.8.1 TRANSMIT -
The "Transmit" function is used to initiate arbitration and
transmission on one of the CI paths. The CI path to be used is
selected by PORT DATA (7:0) bit 7 as follows.
PORT DATA bit 7 DESCRIPTION
________________________________________________
0 Select CI path A
1 Select CI path B
L0100 LINK SPECIFICATION Page F-24
Only one "Transmit" function can be executed at a time. That
is, a transmission must have been completed or aborted and the
Transmit Status must have been cleared before a second "Transmit"
function can be issued.
F.5.1.8.2 RESET TRANSMIT STATUS -
This function must always be executed at the end of a
transmission sequence, i.e., in response to a XMIT ATTENTION after
reading the Transmit Status. "Reset Transmit Status" will reset
all Transmit Status bits except bits 5 (CDA) and 6 (CDB).
F.5.1.8.3 ABORT TRANSMISSION - "Abort Transmission" will cause
the currently active transmission to be aborted and will set bit 4
(Transmission Aborted) of the Transmit Status. XMIT ATTENTION
will also be asserted.
F.5.1.8.4 ENABLE LINK CONTROL/DISABLE LINK CONTROL -
These functions are used to enable and disable certain long
term controls in the LINK. A particular control may be set by
executing "Enable LINK Control" with a 1 in the PORT DATA (7:0)
bit position corresponding to that control. A control may be
cleared by executing "Disable LINK Control" with a 1 in the proper
bit position. Transfer of a 0 in any bit position will have no
effect on the corresponding controls.
The PORT DATA (7:0) bit layout is as follows:
7 6 5 4 3 2 1 0
+------+-------+------+------+------+------+------+-------+
| RCVR |FORCE | VALID| EXTM | INTM |FORCE |SWAP |RCVR |
| B ENA|CDET | RPAR | LOOP | LOOP | ARB |ADR |A ENA |
| |ENA | ENA | ENA | ENA | ENA |ENA | |
+------+-------+------+------+------+------+------+-------+
FIGURE F5-3
ENABLE LINK CONTROL
L0100 LINK SPECIFICATION Page F-25
7 6 5 4 3 2 1 0
+------+-------+------+------+------+------+------+-------+
| |FORCE | VALID| EXTM |INTM |FORCE |SWAP | RCVR |
| RCVR |CDET | RPAR | LOOP |LOOP |ARB |ADR | A DIS |
| B DIS|DIS | DIS | DIS |DIS |DIS |DIS | |
+------+-------+------+------+------+------+------+-------+
FIGURE F5-4
DISABLE LINK CONTROL
Bit Description
________________________________________________________________
7 Receiver B Enable/Disable: "Enable...." activates LINK
receiver Path B making the node accessible on CI Path B
by remote nodes.
"Disable..." will cause this node to ignore all CI
traffic on Path B.
INITIALIZE will disable receiver Path B.
6 Force Carrier Detect: This function must only be used
in conjunction with Internal Maintenance Loop mode.
"Enable..." causes the LINK to see a detected carrier.
This forced carrier will start the header timeout logic
and will stop the arbitration sequence.
The normal carrier detect signals from CI paths A and B
are disabled when the Link is in Internal Maintenance
Loop mode.
"Disable..." and Initialize will disable this function.
5 Valid Receiver Parity: "Enable..." function will force
the LINK to generate odd parity on the data being
received.
"Disable..." will cause the receiver to generate even
parity on the data.
INITIALIZE will set the receiver to odd parity.
4 External Maintenance Loop: "Enable..." will allow the
LINK to receive its own transmission by looping on the
selected CI path.
NOTE: It is illegal to invoke more than 1 loop mode
simultaneously.
L0100 LINK SPECIFICATION Page F-26
The following requirements must be met:
1. The Destination fields in the CI packet must contain
the address of this node.
2. The PORT must load a pre-calculated CRC into the
buffer immediately following the data. CRC will be
checked by the receiver.
3. The packet byte count must not include the CRC
characters.
The normal CI arbitration sequence will occur when a
"Transmit" function is issued while in External
Maintenance Loop mode.
If External Maintenance Loop mode is invoked while on
line in an operating system, packets may still be
received from a remote node. There is, therefore, no
guarantee that there will be a receiver buffer available
when the local packet is transmitted. ACK/NAK responses
are prohibited while in External Maintenance mode,
therefore, a remote node will receive no response if it
attempts to access a node that is in this node. The
LINK will still accept packets from remote nodes and
pass them on to the PORT Processor packet buffer but
will not send an ACK/NAK in response while in External
Maintenance Loop mode. However, the Transmit Status
response will be set as though a normal transmission had
taken place if a node Transmits to itself in this node..
"Disable..." will take the link out of External
Maintenance Loop mode.
INITIALIZE will disable this function.
3 Internal Maintenance Loop: "Enable..." will cause the
LINK to receive its own transmission by looping inside
the CI driver/receiver. This loop will not interfere
with CI operation of other nodes. That is, neither CI
path will be driven while transmitting in this loop
mode. Traffic on both CI A and B will be ignored while
in Internal Maintenance Loop mode since the receivers
must be disabled when this mode is set. Receptions in
progress will be terminated when Internal Maintenance
Loop mode is set. Therefore, all packets destined for
this node will receive no response. The same
requirements (1,2,3) stated above for External
Maintenance Loop apply to Internal Maintenance Loop
mode. The normal arbitration sequence will occur in
this mode. The carrier detectors are disabled when in
this mode allowing this node to always win arbitration.
The FORCE CARRIER DETECT BIT described above may be used
L0100 LINK SPECIFICATION Page F-27
to cause arbitration to stop.
Acknowledge responses will occur in this mode. However,
CRC will not be calculated or checked on the Acknowledge
packet. The Transmit Status responses will be set as
though a normal transmission had taken place on the
CI.
Receiver Enables A & B must be disabled while operating
in this mode.
"Disable..." will take the LINK out of Internal
Maintenance Loop mode.
INITIALIZE will enable this function.
2 FORCE ARB: "ENABLE..." function will cause the LINK to
force a successful arbitration and to transmit
immediately upon receiving the "Transmit" function from
the PORT. This mode should not be used in an on-line
operating system since there is no arbitration. This
may result in collisions on the CI.
"Disable..." will allow the LINK to perform normal
arbitration sequences in response to the "Transmit"
function from the PORT.
Initialize will cause the LINK to perform normal
arbitration sequences.
1 Swap Address: "Enable..." will cause the true and
complement address sources to swap, i.e., true node
address becomes complement and complement node address
becomes true. This will cause an address mismatch if a
packet is sent in either of the maintenance loop modes
and will result in a no response status.
If, while in Internal Maintenance Loop mode, the PORT
Processor enables this function and also complements the
address in the packet to be transmitted, then address
comparison will take place. This has given the PORT
Processor the ability to test all node address bits in
both polarities.
Note that the later case should only be exercised while
in Internal Maintenance Loop mode since the LINK will be
using an address which was not assigned to it during
system configuration.
The Arbitration Logic will also use the complement of
the Low 4 address bits if this mode is set.
"Disable..." sets the node address sources to their
normal positions, i.e., true equals true etc.
L0100 LINK SPECIFICATION Page F-28
Initialize also sets the node address sources to their
normal positions.
0 Receiver A Enable/Disable: "Enable..." activates LINK
receiver Path A making the node accessible on CI Path A
by remote nodes.
"Disable..." will cause this node to ignore all CI
traffic on Path A.
INITIALIZE will disable receiver path A.
F.5.1.9 XMIT STATUS (7:0) (TTL OUTPUT, ASSERTED HIGH) -
The XMIT STATUS is used to report the status of a transmit
sequence. Some of the bits, indicated below by (*), are valid
only when XMIT ATTENTION is asserted. The remaining bits are
valid as described below. Transmit Status operate the same while
in any of the loop modes as when the LINK is responding to a
packet from a remote node.
The status bit allocation is as follows:
7 6 5 4 3 2 1 0
+------+-------+------+------+------+------+------+-------+
| XDAT | CDB | CDA | XMIT | ARB | NAK | ACK | XMTR |
| PE | | | ABRT | | | | BUSY |
+------+-------+------+------+------+------+------+-------+
* * * *
FIGURE F5-5
TRANSMIT STATUS
*Indicates that the bit is valid only when XMIT ATTENTION
is asserted.
BIT DESCRIPTION
----------------------------------------------------------------------
7 Transmit Data Parity Error: This bit is set if a parity
error was detected on the data from the XMIT DATA lines
during a transmission. A parity error will cause the XMIT
ATTENTION flag to be asserted and the transmission to be
aborted.
This bit is cleared by INITIALIZE and by the "Reset Transmit
Status" function.
L0100 LINK SPECIFICATION Page F-29
6 CI B Carrier Detect (CDB): This bit indicates the state of
the carrier on CI Bus B. There is a delay between the actual
transition of the carrier and this status bit due to
synchronizer logic.
0 = Carrier B off
1 = Carrier B on
5 CI A Carrier Detect (CDA): This bit indicates the state of
the carrier on CI Bus A. There is a delay between the actual
transition of the carrier and this status bit due to
synchronizer logic.
0 = Carrier A off
1 = Carrier A on
4 Transmission Aborted: This bit is set when a transmission is
aborted by the "Transmission Abort" function. Transmission
Aborted will cause the XMIT ATTENTION flag to be asserted.
Transmission Aborted is cleared by INITIALIZE and by the
"Reset Transmit Status" function.
3 Arbitration : This bit is set when the arbitration count has
expired after a "Transmit" function. This does not mean that
the transmission has taken place since rearbitration takes
place under certain conditions (See section 2.1.3).
Arbitration is cleared by INITIALIZE and by the "Reset
Transmit Status" function.
2 NAK: This is the response from the destination node that
both of its receive buffers were unavailable (busy). NAK
will cause the XMIT ATTENTION flag to be asserted.
NAK is cleared by INITIALIZE and by the "Reset Transmit
Status" function.
1 ACK: This bit is set when a valid positive acknowledgement
is received in response to a transmitted packet. ACK
indicates that the transmitted packet was accepted and stored
by the receiving node. ACK will cause the XMIT ATTENTION flag
to be asserted.
This bit is cleared by INITIALIZE and by the "Reset Transmit
Status" function.
Note: If XMIT ATTENTION is asserted with Transmit status bits
7,4,2, and 1 clear, the interpretation is that of a no
response, i.e., an acknowledge packet timeout has occurred.
L0100 LINK SPECIFICATION Page F-30
0 Transmitter Busy: This bit is set by the "Transmit" function
and indicates that a Transmit sequence is in progress or that
XMIT ATTENTION is asserted. Transmitter Busy in not asserted
synchronously to the Port Clock but to the XMIT Clock. It
will be asserted within 2 Port Clock cycles of the PORT
PROCESSOR issuing the Transmit function. The PORT Processor,
therefore, must not monitor this bit during the 2 PORT Clock
Cycles immediately following the Transmit function.
Transmitter Busy is cleared by INITIALIZE and by the "Reset
Transmit Status" function.
F.5.1.10 XMIT ATTENTION (TTL OUTPUT, ASSERTED HIGH) -
XMIT ATTENTION is asserted by the LINK when there is a
response to a "TRANSMIT" function for normal transmissions as well
as for transmissions in any of the loop modes. The response may
be any of the following:
ACK
NAK
Transmit Data Parity Error
Abort Transmission
Acknowledge packet timeout (no response)
The responses are described in the Transmit Status section
(F5.1.9).
XMIT ATTENTION is cleared by INITIALIZE and by the Reset
Transmit Status function.
F.5.1.11 XMIT DATA ENABLE (TTL OUTPUT, ASSERTED HIGH) -
XMIT DATA ENABLE is used to enable data from the transmit
packet buffers to the LINK. The first data byte must appear on
the XMIT DATA lines during the second XMIT CLOCK cycle after the
XMIT DATA ENA line is asserted and on all succeeding cycles until
the last data byte is transferred. The LINK will ignore the XMIT
DATA lines during the first cycle of XMIT DATA ENA. This allows
buffers to read the first byte out of their rams. XMIT data
enable will be de-asserted one cycle after the signal XMIT BUFFER
EMPTY appears.
L0100 LINK SPECIFICATION Page F-31
F.5.1.12 XMIT BUFFER EMPTY (TTL INPUT, ASSERTED HIGH) -
This line must be asserted by the PORT Processor during the
LINK CLOCK cycle in which the last transmit packet buffer data
byte is transferred on the XMIT DATA Lines.
F.5.1.13 VALID RCVR DATA (TTL OUTPUT, ASSERTED HIGH) -
This signal is asserted by the LINK when the first valid data
byte is present on the RCVR DATA lines. VALID RCVR DATA will
remain asserted throughout the entire packet, as long as there is
a valid packet destined for this node being received. Packet
buffer loading should be enabled with this signal. If the packet
is not for this node, VALID RCVR DATA will be de-asserted.
F.5.1.14 RCVR PACKET END (TTL INPUT, ASSERTED HIGH) -
RCVR PACKET END must be asserted by the PORT Processor, on
the trailing edge of the RCVR CLOCK that takes the last byte of a
packet from the RCVR DATA lines. The PORT Processor is
responsible for keeping a byte count to determine when a packet
has been completed.
This signal is used by the LINK to determine when to check
the CRC status.
F.5.1.15 RCVR BUFFERS FULL (TTL INPUT, ASSERTED HIGH) -
RCVR BUFFERS FULL originates at the PORT Processor and
indicates to the LINK that there is no receiver buffer available
for storing CI packets. The LINK will return a NAK response to
all packets received while this signal is asserted.
F.5.1.16 VALID RCVR STATUS (TTL OUTPUT, ASSERTED HIGH) -
VALID RCVR STATUS is asserted by the LINK to indicate that
valid receive status information may be clocked into the PORT
Processor receiver status at the end of the current PORT CLOCK
cycle. The LINK supplies a CRC STATUS bit and supplies the CI
path identification for received packets.
L0100 LINK SPECIFICATION Page F-32
F.5.1.17 PACKET LENGTH (TTL OUTPUT, ASSERTED HIGH) -
This signal indicates that the byte currently available to
the PORT specifies the length of the incoming packet. This signal
will remain asserted for two cycles to allow the two bytes
containing the high 4 bits (first cycle) and the low 8 bits
(second cycle) to be transferred. The PORT Processor must load
its packet byte counter accordingly.
F.5.1.18 ICCS PATH B (TTL OUTPUT) -
ICCS PATH B indicates on which CI path a packet is received.
This line is valid only when the Signal VALID RCVR STATUS is
asserted and is interpreted as follows:
0 = CI Path A
1 = CI Path B
F.5.1.19 CRC STATUS (TTL OUTPUT) -
CRC STATUS is to be used to indicate the status of the CRC
check on the Information packet just received. CRC STATUS is
valid only when the signal VALID RCVR STATUS is asserted and is
interpreted as follows:
0 = Bad CRC
1 = CRC OK
F.5.1.20 PORT CLOCK (TTL INPUT) -
The LINK requires a clock source from the PORT for some of
its operation. The PORT CLOCK will be used to load data such as
the LINK mode set up information from the PORT Processor into the
LINK and to synchronize LINK communication with the PORT.
The LINK interface will operate with a minimum cycle period
of 150ns as shown in section F5.2 (figure F5-6). The PORT CLOCK
may be single stepped but must stop with the clock asserted low.
Signals must be asserted by the trailing edge of the PORT
CLOCK and strobed by the leading edge unless otherwise specified
by the timing diagrams.
INITIALIZE must not stop this clock.
L0100 LINK SPECIFICATION Page F-33
F.5.1.21 XMIT CLOCK -
The LINK will supply a transmit clock source to the PORT to
be used to control the transfer of transmit data and control
information between the PORT and LINK. The XMIT CLOCK will be a
28ns pulse occurring every 114ns as shown in section F5.2 (figure
F5-7).
Signals must be asserted by the trailing edge of the XMIT
CLOCK and strobed by the leading edge unless otherwise specified
by the timing diagrams.
F.5.1.22 RCVR CLOCK -
The LINK will supply a receiver clock source (RCVR CLOCK) to
the PORT Processor to be used to control the transfer of receiver
data and control information between the LINK and the PORT
Processor. The RCVR CLOCK is a 28ns pulse occurring every 114ns
as shown in section F5.2 (figure F5-8).
Signals must be asserted by the trailing edge of the RCVR
CLOCK and strobed by the leading edge unless otherwise specified
by the timing diagrams.
F.5.1.23 INITIALIZE (TTL INPUT, ASSERTED HIGH) -
This signal from the PORT Processor is used for system
initialization. The LINK will provide a pullup resistor on this
signal so that, if the PORT Processor is not installed, the LINK
will not interfere with either of the CI paths. The LINK will not
respond properly to any commands from the PORT Processor for 2
PORT CLOCK cycles following the de-assertion of INITIALIZE. The
LINK will appear as non-existent to remote nodes during the INIT
sequence.
F.5.1.24 RCVR A ENABLE (TTL OUTPUT, ASSERTED High) -
RCVR A ENABLE is asserted when the PORT Processor enables the
A receiver path.
F.5.1.25 RCVR B ENABLE (TTL OUTPUT, ASSERTED High) -
RCVR B ENABLE is asserted when the PORT Processor enables the
B receiver path.
L0100 LINK SPECIFICATION Page F-34
F.5.1.26 XTEND HDR (TTL INPUT, ASSERTED Low) -
This input is provided to allow extending the number of bit
sync characters in the header from the normal 5 to 15.
Note that if XTEND HDR is asserted, the EXTEND ACK TO input
(B10) must also be asserted low.
F.5.1.27 ALTER DELTA TIME (TTL INPUT, ASSERTED Low) -
When asserted, ALTER DELTA TIME increases the basic quiet
slot delta time from 7 byte times ( 800ns) to 16 byte times ( 1.83
us).
F.5.1.28 DISABLE ARB (TTL INPUT, ASSERTED Low) -
Asserting DISABLE ARB will defeat the normal arbitration
sequence and allow the LINK to transmit after waiting only one
basic quiet slot (Delta Time).
F.5.1.29 MODULE INSERTED LOOP -
I/O pins B5 and B6 are connected together on the LINK and may
be used to pass a "module inserted" sensing signal through.
F.5.1.30 EXTEND ACK TO (TTL INPUT, ASSERTED LOW) -
Asserting EXTEND ACK TO will increase the timeout period for
an ACK return from the normal x 3.66 us to 25.8 us.
EXTEND ACK TO must be asserted if XTEND HDR/TR (B7) is
asserted.
F.5.1.31 DISABLE RCVR CLK (TTL INPUT, ASSERTED Low) -
Asserting this input low will disable the normal RCVR CLK
source from entering the TTL portion of the LINK and LINK
interface. External RCVR clocks may then be inserted via the RCVR
TEST CLK input described below.
L0100 LINK SPECIFICATION Page F-35
F.5.1.32 RCVR TEST CLK (TTL INPUT, ASSERTED Low) -
The RCVR TEST CLK input may be used (in conjunction with
Disable RCVR CLK) to produce RCVR CLK pulses from an external
source. One RCVR CLK pulse will be produced for every 4 RCVR TEST
CLK pulses. Timing relationships are shown in figure F5-9.
F.5.1.33 XMIT TEST CLK (Low High) (TTL INPUTS) -
_
The XMIT TEST CLK inputs may be used (in conjunction with
XMIT CLK DISABLE) to produce XMIT CLK pulses from an external
source.
XMIT TEST CLK Low and XMIT TEST CLK High must be asserted in
phase with each other. Both signals must be High when not in use.
Timing relationships are shown in figure F5-10.
F.5.1.34 XMIT CLK DISABLE (TTL INPUT, ASSERTED Low) -
Assertion of this input will disable the normal XMIT CLK
source from entering the TTL portion of the LINK and the LINK
interface. External clocks may then be inserted via the XMIT TEST
CLK inputs as described above.
L0100 LINK SPECIFICATION Page F-36
F.5.2 LINK INTERFACE TIMING
Complete timing diagrams for the above interface signals are
shown below in figures F5-6 through F5-10.
T0
|<-30ns-->|<------------150ns---------->|
| min | minimum |
| (6) | |
_________ _________
| |<--50ns min (6)--->| |
PORT CLOCK (1) ___| |___________________| |__
| | |
| |<-45ns(2)>| |
| | min | |
_____________ ____________________
LINK CONTROL, XXXXXXXXXX XXX
PORT DATA (7:0), _____________XXXXXXXXXX____________________XXX
SELECT,
INITIALIZE | | |
-->| 35ns |<-- | |
| max | --> | 35ns |<--
| | | max |
________________________
/////// \\\\\
XMIT ATTENTION, _____________/////// \\\\\______
XMIT STATUS 3
| |
-->| 35ns |<-- |
| max | |
_____________ ______________________
XXXXXXXX XXX
XMIT STATUS(6,5) _____________XXXXXXXX______________________XXX
XMIT STATUS (7,4,2,1) SEE NOTE 3 BELOW
XMIT STATUS 0 SEE NOTE 4 BELOW
RCVR A & B ENABLE SEE NOTE 5 BELOW
FIGURE F5-6
PORT CLOCK TIMING
L0100 LINK SPECIFICATION Page F-37
1. PORT CLOCK may be single stepped. However, it must
stop asserted low.
2. SET UP Time must not be less than the PORT CLOCK
pulse width used.
3. XMIT STATUS Bits 7,4,2,1 are valid only when XMIT
Attention is set and will be stable at that time.
These bits are not asserted via the PORT CLOCK.
4. XMIT STATUS 0 (XMIT Busy) is asserted within 2 port
clock cycles of the Port Processor issuing the
"Transmit" function to the LINK.
XMIT STATUS Bit 0 (XMIT Busy) is cleared by RESET
TRANSMIT STATUS function on the Leading edge of the
PORT clock.
5. RCVR ENABLE A & B are set by the PORT "ENABLE LINK"
function on the leading edge of the PORT Clock and
is passed directly back to the PORT.
| 6. Minimum PORT CLOCK cycle time (the sum of the high
| low portions) is 150 ns. For example, if the high
| portion is the minimum 30 ns., the low portion must
| be at least 120 ns.
|
L0100 LINK SPECIFICATION Page F-38
T0
|<-28ns(1)|<-----------114ns(2)-------->|
| | |
_________ _________
| | | |
XMIT CLOCK ___| |___________________| |__
| | |
| |<-20ns->| |
| | min | |
_____________ __________________
XMIT DATA (7:0), XXXXXXXXXXXX XXX
XMIT DATA PARITY _____________XXXXXXXXXXXX__________________XXX
| | |
|<--20ns-->| | |
| max | | |
_____________ __________________
XXXXXXXXXXXX XXX
XMIT DATA ENABLE _____________XXXXXXXXXXXX__________________XXX
| |
| |<--------45ns-------->|
| | min |
_______________________________
/////// \\\
XMIT BUFFER EMPTY _____________//////// \\\
FIGURE F5-7
XMIT CLOCK TIMING
1. Pulse width is actually 1/70mhz x2 = 28.572ns
2. Period is actually (1/70mhz)x8 = 114.286ns
L0100 LINK SPECIFICATION Page F-39
T0
|<-28ns(1)|<-----------114ns(2)-------->|
_________ _________
| | | |
RCVR CLOCK ___| |___________________| |__
| | |
|<-35ns-->| | |
| max | | |
_____________ ___________________
RCVR DATA (7:0), XXXXXXXXXXX XXX
RCVR DATA PARITY _____________XXXXXXXXXXX___________________XXX
ICCS PATH B,
VALID RCVR DATA,
PACKET LENGTH
| | |
|<--55ns-->| | |
| max | | |
_____________ ___________________
XXXXXXXXXXXX XXX
CRC STATUS _____________XXXXXXXXXXXX__________________XXX
|
| |<--45ns-->|
| | min |
_____________ ___________________
XXXXXXXXXX XXX
RCVR BUFFERS FULL _____________XXXXXXXXXX____________________XXX
| |
| |<-------45ns------->|
| | min |
_____________ ___________________
XXXXXXXXXX XXX
RCVR PACKET END _____________XXXXXXXXXX____________________XXX
FIGURE F5-8
RCVR CLOCK TIMING
1. Pulse width is actually 1/70mhz x2 = 28.572ns
2. Period is actually (1/70mhz)x8 = 114.286ns
L0100 LINK SPECIFICATION Page F-40
____
DISABLE RCVR |______________________________________________
CLK L
_________ _ _ _ _ _ _ _ _
RCVR TEST CLK L |__| |__| |__| |__| |__| |__| |__| |__| |
| | | |
| | | |
____ ____
RCVR CLK H (1) _______| |______________| |___________
FIGURE F5-9
RCVR TEST CLK TIMING
______
XMIT CLK DISABLE L |___________________________________
|
_____________ __ __ __
XMIT TEST CLK L |__| |__| |__| |___________
| | | | | | | |
________________ __ __ ___________
XMIT TEST CLK H |__| |__| |__|
| | | | | | | |
______ __ __ __ ___________
XMIT CLK H ______|______| |__| |__| |__|
FIGURE F5-10
XMIT TEST CLK TIMING
NOTES:
1. The first RCVR CLK pulse may appear from zero to
four Test CLK pulses depending on where the RCVR
CLK Shift Register is when the Disable RCVR CLK
Line is asserted Low.
L0100 LINK SPECIFICATION Page F-41
F.6 MECHANICAL
F.6.1 General
The LINK module (L0100) is an extended "L" series module
implemented with both Schottky and ECL (both 100K and 10K) logic.
The ECL consumes approximately one third of the module in the
"C" area of the board with the TTL occupying the remainder of the
board.
F.6.2 Module Keying
The LINK module is notched between I/O fingers C42 and C44 to
provide keying which will prevent the module from being inserted
backwards and more importantly will prevent any other module from
being inserted in the backplane slot used by the LINK.
A keying plug (DEC PN 1218624-00) must be inserted into the
backplane connector between connector pins C42 and C44.
F.6.3 Power Requirements
The LINK module requires the following voltages at the
specified current ratings.
+5V +5%,-5% @ 12.5A = 62.5W Worse Case
8.6A = 43.0W Typical
-5.2V +5%,-5% @ 6.5A = 33.8w Worse case
5.0A = 26.0w Typical
F.6.4 Cooling
Normally, ECL designs require 500 LFM of airflow to insure
that operating margins for the ECL circuits are maintained. This
is especially necessary if the ECL circuits are not contained on
the same module or are spread out on a module such that there may
be a temperature gradient across the circuits. If the entire ECL
circuit is contained in a small area on a single module where the
temperature gradient does not exist, then the requirement of 500
LFM does not have to be met. The ECL circuits on the LINK module
are contained in a small area and can be adequately cooled with
300 LFM of airflow.
L0100 LINK SPECIFICATION Page F-42
F.6.5 LEDS
F.6.5.1 INTERNAL MAINTENANCE LOOP (RED) -
The LED will be illuminated when the LINK is in Internal
Maintenance Loop mode.
F.6.5.2 LOCAL CI ACTIVITY (GREEN) -
This LED indicates that this node is either transmitting or
receiving on either path of the CI. The level of illumination is
relative to the amount of CI activity by this node.
F.7 APPENDIX A
LINK REGISTERS
TRANSMIT STATUS REGISTER:
07 06 05 04 03 02 01 00
_________________________________________________________
| XBUF | CDB | CDA | XMIT | ARB | NAK | ACK | XMTR |
| PE | | | ABRT | | | | BUSY |
| * | | | * | | * | * | |
|_______|______|______|______|______|______|______|_______|
* Indicates that the bit is valid only when XMIT
ATTENTION is asserted.
ENABLE/DISABLE LINK CONTROL:
07 06 05 04 03 02 01 00
________________________________________________________
| | | | | | | | |
| RCVR |FORCE |VALID | EXT | INT |FORCE | SWAP | RCVR |
| B |CDET | REC |MAINT |MAINT | ARB | ADRS | A |
| ENB | | PAR | LOOP | LOOP | | | ENB |
|______|______|______|______|______|______|______|______|
L0100 LINK SPECIFICATION Page F-43
F.8 APPENDIX B
LINK INITIALIZE STATE
CONTROL ENABLED DISABLED
RCVR B x
FORCE CARRIER DETECT x
VALID RCVR PARITY x
EXTERNAL MAINT. LOOP x
INTERNAL MAINT. LOOP x
FORCE ARBITRATION x
SWAP ADDRESS x
RCVR A x
L0100 LINK SPECIFICATION Page F-44
F.9 APPENDIX C
LINK MODE SEQUENCES
___________________________________________________________________
CURRENT | NEXT | CONTROL FUNCTION |CONTROL| PORT DATA
MODE | MODE | | CODE | BITS=1
| | | |
INT.MAINT |ON LINE |1)DISABLE INT.MAINT.LOOP | 0111 | 3
LOOP |(PATH A | | |
|and/or |2)RCVR ENABLE (A and/or B)| 0110 |0 and/or 7
(NOTE 1) |PATH B) | | |
____________________________________________________________________
INT.MAINT |EXT. |1)DISABLE INT.MAINT.LOOP | 0111 | 3
LOOP |MAINT. | | |
|(PATH A| | | |
|or B) |2)ENABLE EXT.MAINT.LOOP | | 4
(NOTE 1) | | and | 0110 |
| | RCVR ENABLE (A or B) | | 0 or 7
___________________________________________________________________
EXT.MAINT.|INT. |1)DISABLE EXT.MAINT.LOOP | 0111 | 4
LOOP |MAINT. | and | |
(PATH A |LOOP | | |
or B) |(NOTE 1) RCVR DISABLE (A or B) | | 0 or 7
| |2)ENABLE INT.MAINT.LOOP | 0110 | 3
___________________________________________________________________
EXT.MAINT.|ON LINE |1)UNWANTED RCVR DISABLE | |
LOOP |(PATH A | (A or B) and | 0111 | 0 or 7
(PATH A |and/or B)| DISABLE EXT.MAINT.LOOP | | 4
or B) | | | |
| |2)RCVR ENABLE (A or B) | 0110 | 0 or 7
| |
___________________________________________________________________
ON LINE |INT.MAINT|1)RCVR DISABLE(A and/or B)| 0111 | 0 and/or 7
(PATH A |LOOP | | |
or B) | | | |
|(NOTE 1) |2)ENABLE INT.MAINT.LOOP | 0110 | 3
___________________________________________________________________
ON LINE |EXT.MAINT|1)UNWANTED RCVR DISABLE | 0111 | 0 or 7
(PATH A |LOOP | (A or B) | |
or B) |(PATH A |2)ENABLE EXT.MAINT LOOP | |
|and/or B)| and RCVR ENABLE (A or B)| 0110 | 0 or 7
___________________________________________________________________
Note 1: INITIALIZE also puts the LINK in INT.MAINT.LOOP mode.
APPENDIX G
CHANGE HISTORY
G.0.1 Revision 1 To 2
1. Add DQI bit.
2. Change and add opcode values: DATREQ0, DATREQ1, DATREQ2, MCFN,
MDATREQ.
3. Add effective priority guarantees.
4. Add multiple effective priority Data Read operations.
5. Remove port state change restrictions.
6. Remove ID broadcast on entering Uninitialized/Maintenance
state.
7. Update Implementation Functionality table and field.
8. Add SP and received path information to LB and ID.
9. Miscellaneous corrections from review of revision 1.