Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-documentation/ni-info.memos
There are no other files named ni-info.memos in the archive.
MEMOS IN THIS FILE:
o NI Node Product Architecture Spec (NI-PRODUCT-ARCHITECTURE.SPC)
o NI Data Link Layer Spec (NIDLL.DOC)
o Interface to NI Remote Console Spec (NISVCS.DOC)
o NISRV Functional Specification (NISRV.MEM)
o LCG NI Port Architecture Spec (LCG-NI-PORT-ARCHITECTURE.MEM)
-------------------
NI Node Product Architecture
Draft Specification (Revision 0)
P. J. Nesbeda
15 July 1981
1.0 INTRODUCTION
This document describes the NI Node Product Architecture. This
architecture defines a set of functions that each node connecting
to the NI must be able to perform. This set includes functions
for system self test and initialization, system identification,
communications test, Ethernet maintenance, system loading, and
system dumping. The system self test functions model the start-up
behavior of a system. The communications test provides a facility
to ascertain the ability to communicate. The console functions
provide remote access to traditional front panel console
functions. The system load function provides the ability to
transfer an executeable image into the memory of an NI node. The
system dump function provides the ability to transfer an NI node
memory image to another node.
The requirement to include one or more of the aforementioned
functions depends on the node configuration and expected operating
environment. All NI nodes are required to implement the
communications test and system identification functions.
Optionally, some NI nodes will implement the console functions,
load function, and dump function.
There may be additional functions required of a node that are
specific to the node's task, but the specification of these
functions is beyond the scope of this document.
Unlike other architectural documents which deal with a single
architectural level, this document describes a set of functions
which exist at several different levels. The NI Node Product
Architecture defines modules in the data link, network management
and user layers of the Digital Network Architecture.
The motivation for this document results from the need to have a
common set of services available in each Digital NI product.
These services will be the foundation for higher level
installation and support tools.
This document describes the requirements and goals which motivate
the NI product architecture, presents a model which realizes these
objectives, and defines the operation of the individual
components.
NI Node Product Architecture Page 2
1.1 Related Documents
The reader is assumed to be familiar with the following documents.
1. The Ethernet - A Local Area Network V1.0, September 1980
2. Overview of Digital Network Architecture - V1.0, sometime
3. Digital Network Architecture - NI Data Link Architectural
Specification, V1.0, June 1981
4. Digital Network Architecture - Low Level Maintenance
Operations Architectural Specification, Vx.x, June 1981
1.2 Requirements, Goals, Non Goals
The requirements of the NI Node architecture are:
1. Communication: It must be possible to ascertain whether a
system which is connected to an Ethernet is capable of
communicating on the Ethernet.
2. Identification: A system must be able to ascertain
the identity and characteristics of other systems which
are connected to the Ethernet.
The goals of the NI Node architecture are:
1. Completeness: All remote diagnostic functions can be
performed on system which conforms to this architecture.
2. Simplicity: The functions defined by the NI product
architecture must be simple to implement.
3. Performance: Products complying with this architecture
must produce acceptable performance.
4. Flexibility: The functions defined by this architecture
must be realizable on a wide range of system
configurations.
The non-goals of the NI Node architecture are:
1. Comprehensive: This architecture does not specifiy all of
the functions that an NI connected node might require to
satisfy its assigned mission. Specifically not included
in this document are the minimum subset specifications
for DNA Transport, NSP, session control, or DNA network
managemnet.
NI Node Product Architecture Page 3
2. Complete Self Diagnosis: This architecture does not
address the problem of complete self diagnosis of a
system. It only provides primitive operations which
allow another system to aid in diagnosis.
3. System Diagnosis: This architecture does not address
diagnostic policies for attached systems. It only
provides the primitive operations required to support
such policies.
4. Transportability: This architecture does not
legislate any specific functional partition between
hardware and software, nor does it define any specific
implementation.
2.0 ARCHITECTURAL MODELS
This section describes the relationship of the NI Node
architecture to the Digital Network Architecture. The reader is
assumed to be familiar with the structure of the Digital Network
Architecture [ref 2] and the Ethernet specification [ref 1].
2.1 Relation To Digital Network Architecture
The NI Node architecture defines a set of services which reside in
the user and network management layers of the Digital Network
Architecture. These services model the behavior of a system which
is connected to an NI.
The acceptable subset implementation of these services is referred
to as the NI node minimum subset. Maintenance policies for the
Ethernet and systems which connect to it are predicated on the
proper behavior of these services.
This document does not address the operation of any system or
network transport system, their interface to the NI data link, or
network management functions other than the low level network
management operations.
2.2 General Architectural Model
The functions described in this document are modeled as
cooperating processes that interact using protocols defined in the
Low Level Maintenance Operations Architectural Specification [ref
4].
Figure 2-1 depicts the relationship of a requester process and a
server process. Each process provides a set of functions.
NI Node Product Architecture Page 4
Requesters are responsible for the initiation of functions. This
can be done either on behalf of a higher level user request, or
because of information obtained from a lower level. Requesters
are the active component of an operation. Servers provide
functions in response to protocol requests. Servers are the
passive component of an operation.
Functions provided by a process may be available at a user
interface, at a control interface, or at a protocol interface.
Functions requested at one interface do not necessarily result in
visible actions at other interfaces.
A process in one node interacts with a process in another node by
means of protocol messages. Within a node, processes share memory
with other processes using mechanisms that are not visible outside
the node boundary.
The boxes in Figure 2-1 represent processes. The vertical arrows
entering or leaving process boxes represent normal user interface
functions. The horizontal arrows entering a single process box
represent network management control interface functions. The
horizontal arrow between the process boxes represents the protocol
used between the processes.
Interfaces Interfaces
User Control User Control
A | A |
Functions: | | Functions: | |
1. a | | 1. x | |
2. b | | 2. y | |
3. c +-------------+ | 3. z +------------+ |
| |<-+ | |<-+
| Requester |<- - - -Protocol- - - ->| Server |
| | Messages | |
+-------------+ +------------+
| |
| |
| |
+---------Communication Channel--------+
Model of Network Management Server Pairs
Figure 2-1
2.3 NI Node Model
The following diagram shows the components in the NI node minimum
subset.
NI Node Product Architecture Page 5
+--------+ +--------------------------+
| Keep | | Self Test & |
| Alive | | Initialization |-------------+
+--------+ +--------------------------+ |
| A | | |
| | | | |
| | V | |
| +-----------+ +-----------+ | +---------+ |
| | Console | | Load/Dump | | | Loop | |
+->| Server | | Requester | +->| Server | |
+-----------+ +-----------+ +---------+ |
A | A |
| | | |
+-----------+ | +------------+ |
| | | |
| V | |
+------------------------------+ |
| NI Data Link | Net Mgmt |<--------+
| | Interface|
+------------------------------+
|
+------------------------------+
| Ethernet Data Link |
| & Physical Link |
+------------------------------+
|
|
Cable
NI Node Processes and Interfaces
Figure 2-2
The self test and initialization module resides in the user layer.
This module determines the system behavior following a power up or
other initialization sequence. The self test and initialization
module controls the NI Data Link module using the NI Data Link
Network Management Interface and invokes services provided by
modules in the network management layer.
The keep alive process resides in the user layer. This module
aids in detecting system failures. It is especially important to
detect failures in systems that normally operate with the console
functions disabled. The keep alive process is modelled as a timer
which is periodically reset by the system. When the keep alive
timer expires, the process sets the console server state to
enabled. This state transition will allow the console server to
periodically transmit its identification message and will allow
the console server to process incoming console request messages.
Modules in the network management layer implement the console,
loopback, load, and dump functions. Although these functions are
modeled as pairs of cooperating processes (see section 2.2), the
minimum subset includes only the console server, the loopback
NI Node Product Architecture Page 6
server, the load requester, and the dump requester.
The console server provides access to system console functions at
its protocol interface. These functions may be used for system
diagnosis and maintenance.
The loop server responds to messages defined in the Ethernet
specification [ref 1] which are designed to verify the ability to
communicate on the NI. When a message is received, the loop
server either forwards the datagram to the destination address
that is contained in the data field of the message or returns the
datagram to the node that sent the message.
The load requester initiates program load requests on command of
the user process.
The dump requester initiates memory dump requests on command of
the user process.
2.4 Compliance With The Minimum Subset
The NI Node architecture requires that all NI nodes support a self
test and initialization function, the loop server, and the
identification function of the console server.
Systems which restrict the console server's operation during
normal system operation must support the keep alive process in
addition to the loop server and the console identification
function.
Systems that depend on other systems for their load images must
support the load requester and the dump requester in addition to
the loop server and the console identification function.
3.0 INTERFACES
The following sections describe the interfaces to the processes
which compose an NI Node. These descriptions are only a summary;
the NI Data Link [x] and the Low Level Maintenance Operations [x]
architectural specifications should be consulted for complete
definitions.
These interfaces are:
1. NI Data Link Interface
. Datagram Interface
. Data Link Network Management Interface
NI Node Product Architecture Page 7
2. Network Management Server Interfaces
. Loop Server Interface
. Console Server Interface
. Load Requester Interface
. Dump Requester Interface
3. Application module Interfaces
. Keep Alive Interface
. Self Test and Initialization Interface
3.1 NI Data Link Interfaces
This section summarizes the two interfaces to the NI Data Link
module; the normal datagram interface and the network management
interface.
3.1.1 NI Datagram Interface -
This section describes the interface that the NI Data Link
provides for the normal user. In order to receive or transmit
over the NI, the user must have an open port. The port is a
collection of resources that the NI data link uses to keep track
of user requests. It also contains the list of protocol type and
address pairs that the user has enabled for reception of incoming
datagrams.
The NI Data Link Architectural Specification [ref 3] describes the
interface functions and their operation. The functions required
at this interface are:
. Open
. Enable
. Transmit Datagram
. Receive Datagram
NI Node Product Architecture Page 8
3.1.1.1 Open - Opens a port for datagram transmission and
reception. The minimum subset must include sufficient resources
to support the ports used by the processes in the minimum subset.
3.1.1.2 Enable - Enables a protocol type and station address for
receive. Multiple type and address pairs may be enabled for a
single port.
3.1.1.3 Transmit Datagram - Sends a datagram.
The 48 bit destination address may be either the address of a
specific station or may be a multicast address.
Transmission of datagrams with the following protocol types
(reserved for maintenance operations) is required.
. Loopback Type TBD.
. Console Type TBD.
. Load Type TBD.
. Dump Type TBD.
The minimum subset does not require datagram transmission with
protocol types other than those in the previous list.
NOTE
The maintenance multicast addresses and the
maintenance protocol types will be included as soon as
they are assigned by Xerox.
3.1.1.4 Receive Datagram - The data link interface must support
reception of datagrams. Sufficient resources must be allocated to
allow the processes to open ports and enable protocol type and
address pairs on each port. Multicast address recognition is not
required.
NI Node Product Architecture Page 9
3.1.2 NI Data Link Network Management Interface -
A subset of the NI data link network management interface is
required in the minimum subset. This subset allows the self test
procedure to control the operation of the data link.
The complete definition of the network management interface is
defined in the NI Data Link Architectural Specification [ref 3].
The following list defines the subset. Only a subset of the
parameters normally associated with each function (for
non-maintenance use) is used by the maintenance modules.
. Set-address
. Start-channel
. Stop-channel
Multicast address filtering, event reporting and counter support
are not required in the minimum subset.
3.1.2.1 Set-address - A unique 48 bit physical address is
required by the Ethernet specification for proper operation.
3.1.2.2 Start-channel - The self test and initialization process
uses the start-channel function to enable operation of the NI data
link.
3.1.2.3 Stop-channel - The self test and initialization process
uses the stop-channel function to terminate the operation of the
NI data link. Prior to execution of self test procedures, the NI
data link must be placed in a stopped state. This will prevent
reception of loopback and console messages.
NOTE
The Stop-channel function need not be explicitly
implemented if the power on or other reset sequence
prevents packet reception.
NI Node Product Architecture Page 10
3.2 Network Management Server Interfaces
There are three required network management server modules; the
loop server, the console server, the load requester. The
interfaces to these modules are described in the following
sections.
3.2.1 Loop Server Interfaces -
3.2.1.1 User Interface - There are no normal interface functions
to the loop server.
3.2.1.2 Control Interface - There is a single network management
interface function to the loop server. It is:
. Switch-state (on, off)
The switch-state function allows the self test and initialization
module to control whether the loop server will respond to incoming
loop requests.
3.2.1.3 Protocol Interface - There are two protocol interface
functions.
. Loop-data
. Forward-data
Operation of loop-data and forward-data are defined in the Low
Level Network Management Operations Architectural Specification
[ref 4]. Both functions must be supported.
Loop servers are not required to enable multicast addresses on
their NI ports.
3.2.2 Console Server Interface -
The console server provides remote access to system console
functions. These functions are:
. Identification
NI Node Product Architecture Page 11
. Examine and Deposit
. Initialize
. Halt and Continue
. Start (at address)
. Boot
The console server provides a service that prevents more that one
system from using console functions at the same time. A timer
based reservation scheme prevents a single remote system that
fails after reserving the console from permanently holding the
reservation.
3.2.2.1 User Interface - There is one required user interface
function to the console server process. It is:
. Request-poll
The request-poll interface function allows the system self test
and initialization module to determine if certain control requests
have been received at the protocol interface.
The control requests that can be observed at this interface are:
initialize, halt, continue, start and boot. For a start request,
a transfer address is made available. For a boot request, a
device identification and the identification of the system that
sent the request is made available. The interface is modeled such
that only the most recent control function received is made
available. Each request can be read only once.
3.2.2.2 Control Interface - There are two network management
interface functions to the console server process. They are:
. Switch-state
. Set-console-parameters
The switch-state function allows the self test and initialization
module to control whether the node will respond to incoming
console protocol messages. Switch-state allows the console server
to be placed in one of three states; disabled, identification,
enabled. In the disabled state, the console server responds to no
messages. In the identification state, the console server will
reply to a state-identity request message. The server will not
respond to other console request messages. In the enabled state,
the console server will process incoming console request messages.
The set-console-parameters interface function sets the port type,
NI Node Product Architecture Page 12
the reservation timer, and the help timer. The reservation timer
determines the length of time that a console will remain in the
reserved state without receiving messages from the system that
holds the reservation. The help timer determines the time
interval between multicast transmission of identification
messages.
The legal values for the port type may be found in the Low Level
Maintenance Operations Specification.
3.2.2.3 Protocol Interface - The identification, examine, and
deposit functions are available only at the protocol interface.
The server responds to another system's read-identity request with
the state information maintained by the console server. This
information includes the console state, the communication and
system processor types, and the system status. The complete list
of state information may be found in the Low Level Maintenance
Operation Specification [ref 4].
The examine and deposit functions require that the console server
process have access to the entire address space of the node.
3.2.3 Load Requester Interface -
3.2.3.1 User Interface - There are two user interface functions
to the load requester module. They are:
. Load-self
. Load-self-poll
The load-self function directs the load requester process to
initiate a down-line load operation. Load requests may be
directed to a specific destination address or a multicast address
if the address of a specific load server is not known. The
load-self function includes parameters that specify the system
bus, system processor type, communication processor type, and a
software-id. The list of legal parameter values may be found in
the Low Level Maintenance Operation Specification.
The load-self-poll function allows the system self test and
initialization module to determine the status of a previously
requested load-self operation. The status indicates if the load
has failed, if the load is still active, or if the load completed
successfully. If the load completes successfully, the starting
address of the load image is made available.
NI Node Product Architecture Page 13
3.2.3.2 Control Interface - There are no control interface
functions to the load requester process that are required in the
minimum subset.
3.2.3.3 Protocol Interface - The load server generates request
block messages and receives data block messages at its protocol
interface. These functions are not directly visible at any other
of the process's interfaces.
3.2.4 Dump Requester Interface -
3.2.4.1 User Interface - There are two user interface functions
to the dump requester module. They are:
. Dump-self
. Dump-self-poll
The dump-self function directs the dump requester process to
initiate an up-line dump operation. Dump requests may be directed
to a specific destination address or a multicast address if the
address of a specific dump server is not known. The dump-self
function includes parameters that specify the system bus, system
processor type, communication processor type, and a software-id.
The list of legal parameter values may be found in the Low Level
Maintenance Operation Specification [ref 4].
The dump-self-poll function allows the system self test and
initialization module to determine the status of a previously
requested dump-self operation. The status indicates if the dump
has failed, if the dump is still active, or if the dump completed
successfully.
3.2.4.2 Control Interface - There are no control interface
functions to the dump requester process that are required in the
minimum subset.
3.2.4.3 Protocol Interface - The dump server generates request
block messages and receives data block messages at its protocol
interface. These functions are not directly visible at any other
of the process's interfaces.
NI Node Product Architecture Page 14
3.3 Application Process Interfaces
3.3.1 Keep Alive Interface -
The keep alive process supports two user interface functions.
These are:
. Keep-alive
. Set-alive
. Set-dead
The keep alive interface function is called by the system to
inform the keep alive process that the system is still
functioning. This interface function must be invoked
periodically. The keep alive process will assume that the system
has failed if the interface call has not been issued within the
last TBD seconds.
The set-alive interface function is used to arm the keep alive
process.
The set-dead interface function is used to disable the keep alive
process.
There are no control or protocol interfaces to the keep alive
process.
3.3.2 Self Test And Initialization Interface -
There is a single user interface function to the self test and
initialization process.
. Poll-status
The poll-status function returns the status of the self test
operation; self test running, self test successfully complete,
self test failure.
There are no control or protocol interface functions to the self
test and initialization process. This process determines that an
initialization sequence must be performed by sampling a state
variable that is set by the hardware. The mechanism which causes
that state variable to be set is beyond the scope of this
specification.
NI Node Product Architecture Page 15
4.0 OPERATION
The following sections describe the operation of the modules
depicted in Figure 2-1. (Procedural definitions are in order.)
4.1 System Self Test And Initialization Operation
The system self test and initialization module is required to test
a suitable set of functions which are necessary to support the
proper operation of the loop server, console server and load
requester. Prior to enabling the remote console, or issuing a
load request, the self test procedure must successfully test the
loop back path(s) through the NI hardware, firmware and software
as is appropriate for the implementation. Loopback operation to
oneself on the channel is desirable but not required.
4.2 Keep Alive Operation
The keep alive process is only required in systems whose normal
mode of operation is with the console functions disabled. The
keep alive process enables the console functions and broadcasts an
identification message if the system fails to call the keep alive
interface function within the keep alive interval. The keep alive
interval is set at 30 seconds.
The keep alive process has two states; alive and dead. The
initial state is alive. A timeout causes a transition to the dead
state. The console functions will be enabled on this transition.
The set-alive function will cause a transition to the alive state
and disable the console functions.
4.3 Network Management Server Operation
This section defines the operation of the network management
servers which provide loopback, console and down-line load
functions.
4.3.1 Loop Server Operation -
All NI nodes support the loop server functions. Both loop-data
and forward-data are required in the minimum subset. Response to
a multicast request for loop assistance is not required.
When the loop server receives a message, it either forwards the
message to the destination address that is contained in the data
field of the message or it returns the message to the node that
NI Node Product Architecture Page 16
sent it. The loop server protocols are designed such that the
loop server retains no state information about any of the messages
it processes.
4.3.2 Console Server Operation -
The minimum NI node must support the identification function of
the console server. Upon receipt of a request-id message, the
console server sends the console server state data. This data
minimally includes the system identification. The Low Level
Maintenance Operation Architectural Specification defines the
complete set of identification data.
The additional console control functions require that the local
system has placed the console server in the enabled state (via a
switch-state interface call) and that a reserve-console protocol
message has been received from another system. In the time
interval between the enable functions and the reservation request,
the console server periodically transmits its state information in
an identification message to the console maintenance multicast
address TBD. The period is 60 seconds.
Receipt of a reserve-console message disables that periodic
transmission of the identification message and enables the
complete set of console functions. Console commands, however,
will only be accepted if they contain a source node address that
is identical to the source address contained in the
reserve-console message. The console server will release the
reservation unless the reservation holder maintains a minimum
traffic rate. The maximum time interval between messages is 60
seconds.
Support of the additional console functions are not required by
the minimum subset.
NOTE
Products that plan to use NI based diagnostic and
maintenance policies must ascertain that their NI
connection provides these services.
4.3.3 Load Requester Operation -
The load requester initiates requests for down-line loading system
images and controls the operation of the loading sequence. Load
requests are the result of the load-self interface function. A
request is made either to a specific physical address or a
multicast address. For specific requests, responses only from the
NI Node Product Architecture Page 17
specific physical address will be accepted. For multicast
requests, responses from any node will be accepted. The Low Level
Maintenance Operations Architectural Specification [ref 4] defines
the algorithm for selecting a node in the event of multiple
responses.
The caller of the load-self function may determine the status of
the load operation by calling the load-self-poll function. If
after a period of time, the status is load pending, the caller
should issue another load-self function. The time interval
between successive requests should be greater that 20 seconds and
less that 60 seconds.
The load requester process maintains a sequence number and
requests data blocks by sequence number. Data blocks received out
of order or duplicate data blocks are discarded. The load server
is responsible for timeout and retransmission in the event of a
lost block or lost request.
4.3.4 Dump Requester Operation -
The dump requester initiates requests for upline dumping system
images and controls the operation of the dumping sequence. Dump
requests are the result of the dump-self interface function. A
request is made either to a specific physical address or a
multicast address. For specific requests, responses only from the
specific physical address will be accepted. For multicast
requests, responses from any node will be accepted. The Low Level
Maintenance Operations Architectural Specification [ref 4] defines
the algorithm for selecting a node in the event of multiple
responses.
The caller of the dump-self function may determine the status of
the dump operation by calling the dump-self-poll function. If
after a period of time, the status is dump pending, the caller
should issue another dump-self function. The time interval
between successive requests should be greater that 20 seconds and
less that 60 seconds.
The dump requester process maintains a sequence number and
transmits each data block with a sequence number. Requests
received out of order or duplicate requests are discarded. The
dump server is responsible for timeout and retransmission in the
event of a lost block or lost request.
4.4 NI Data Link And Network Management Operation
Refer to the NI Data Link Specification for detailed operational
description. It is necessary to transmit and receive datagrams in
accordance with the Ethernet specification.
NI Node Product Architecture Page 18
[end]
Document: AJR-83-001-03-X
Date: July 27, 1983
Project: TOPS-20 V6.1
ABSTRACT
This document describes the interfaces between the NI data link
layer and his users. It also describes the interfaces between the
NIDLL and the port driver.
Issued By: Anthony J. Rizzolo
Approved By:
Reviewed By:
Page 1
DOCUMENTATION REFERENCE LIST
1. "NI Node Product Architecture Specification",Version
1.0,March 24,1982.
2. "NI Data Link Architectural Specification",Version
1.0,March 24,1982.
3. "Routing Layer Functional Specification",Version
2.0.0,March 24,1982.
4. "LCG NI Port Architecture Specification",Revision
3.0,January 5,1983.
CHAPTER I
INTRODUCTION
This document is a description of the TOPS-10/20 implementation of
the Digital Network Interconnect(NI) Data Link layer. The Data
link layer is the section of Digital's network architecture (DNA)
which multiplexes packets coming off the NI wire via the port
driver to the users of the NI. It's relationship to the other
parts of the DECnet architecture can be seen in the following
Diagram.
Layer Module
Session Control !------------------------------------!
! Network users interface !
!-----------------+------------------!
!
Logical Link Management !-----------------+------------------!
! NSP !
!-----------------+------------------!
!
Router !-----------------+------------------!
! ROUTER !
!----+----------------------+--------!
Data Link Layer ! !
!-------! !-------------!
!NIDLL* ! ! DTE-20 !
!-------! !-------------!
The Data link is intended to be coded in such a manner so that it
is readily transportable between TOPS-20 on the KLNI as well as
TOPS-20 on the KC.
CHAPTER II
DESIGN OVERVIEW
II.1 PHILOSOPHY
The NI Data Link layer is being designed to be completely
transportable between DECnet implementations running under TOPS-20
on both the KL with an NI adapter and the KC when it becomes
available. It is intended that all that will need to be replaced
is the actual port driver. All calls to the port driver are to
routines which should not change, or change very little from the
KL NIA to the KC NIA.
II.2 THE FUNCTIONS OF THE NI DATA LINK LAYER
The Data link layer covers the following functions for it's users.
o Opens a portal for the user to talk on the NI.
o Maintains a list of portal to physical channel mappings.
After the open call the user routine calls all other
routines in the DLL with this portal-id.
o Performs network management functions for the NI by
calling the port driver to queue up requests to the port
for information.
o Informs the user of any line state change or error on the
NI on which it is using.
o Provides an interface whereby messages may be sent out
over the NI.
o Provides for assignment of multi-cast addresses to an NI
port.
o Provides for an interface for turning the port off and
on.
DESIGN OVERVIEW Page II-2
The NIDLL provides the user with a call back method of
notification of any event which effects the users process. These
callbacks take the form of a callback to the users call back
routine which is specified on the call to DLLOPN. The Call back
sequence is somewhat similiar to the way in which the DLL gets
called. He calls the user back with a callback code in T1 and the
address of the information block in T2. The following is a list
of valid callbacks which the user should expect to handle:
Status Symbol Value
----------------------------------------------
Message Recieved NU.RCV 2
Transmit complete NU.TRN 3
Line State Change NU.LSC 4
Read Counters Completed NU.RCC 5
Read Station Info Comp NU.RSC 6
CHAPTER III
CALLS TO AND FROM THE DLL TO THE USER
All calls to the DLL to and from the user take place via the
NI User to Data Link control block or just the UN control block.
This block of information contains a location for information
which the user must pass to the data link as well as what the data
link must pass to the user. The use of STOR and LOAD for this
structure is recommended as many of the fields do not occupy full
word values and can be changed when neccesary. The definition for
this block as well as the function codes which the DLL and the
user interface use to talk with are both defined in D36PAR. The
following is a list of the data structure used for communication:
!-------!------!------!--------!---------------------------!
!CHN<9> !PSC<1>!PMD<2>! RSV<8> ! PRO <16> !
!-------!------!------!--------!---------------------------!
! Portal ID (Returned on OPEN) !
!----------------------------------------------------------!
! What user wants us to talk to him with !
!----------------------------------------------------------!
! !
! Source address or address to assign(2 Words) !
!----------------------------------------------------------!
! !
! Destination address !
!----------------------------------------------------------!
! Buffer Address !
!----------------------------------------------------------!
! Buffer Data Pointer !
!----------------------------------------------------------!
! Buffer size ! Data Size !
!----------------------------------------------------------!
! Status from Port !
!----------------------------------------------------------!
! Call Back address (only on open) !
!----------------------------------------------------------!
The following is a list of the function codes. In the
following list there are two meanings associated with a given
function. The USER meaning is if the User calls the DATA LINK
with this function what the Data link will do, and the NIDLL is
what the function means when the data link calls the user back
CALLS TO AND FROM THE DLL TO THE USER Page III-2
with it. The Values can be found in D36PAR, but it is recommended
that you use the symbols in case the values change:
Function User NIDLL
------------------------------------------------------
NU.OPN=1 Open a Portal Illegal
NU.RCV=2 Specify Recieve Buffer Message Recieved
NU.TRN=3 Transmit message Message transmitted
NU.LSC=4 Illegal Line State change
NU.RCC=5 Read Port Counters Read counters complete
NU.RSC=6 Read Station information Read Station info comp
-------
NU.RES=7 Reset Port
NU.DCH=10 Disable Channel
NU.EPT=11 Enable Protocol type
NU.DPT=12 Disable Protocol type
NU.EPM=13 Enable Promiscous mode
NU.DPM=14 Disable Promiscous mode
NU.CLO=15 Close the Portal
NU.DPA=15 Declare Multicast address
NU.RVA=16 Revoke Multicast address
NU.RPL=17 Read Portal List
NU.RPR=20 Read Portal Function
CHAPTER IV
COMMON FORMAT DEFINITIONS
PORTAL-ID The portal-ID is a 36 bit quantity and should be stored
as such.
PROTOCOL The Protocol type is a 16 bit quantity right justified in
the word
!---------------------------------19----------27----------35!
! MBZ ! BYTE 1 ! BYTE 0 !
!--------------------------------!------------!-------------!
ADDR1,ADDR2 This is the high and low order respectively of the 6
Byte (48 Bit) NI address. It is passed right justified in
the double word.
!=====================================================!
! !
!0-------!---------!----------!-----------!---------35!
! MBZ ! Byte 3 ! Byte 2 ! Byte 1 ! Byte 0 !
!--------!---------!----------!-----------!-----------!
! ! ! ! ^!
! ! ! ! Multicast address bit !
!--------!---------!----------!-----------!-----------!
! MBZ ! Byte 4 ! Byte 5 !
!=====================================================!
CHAPTER V
SPECIFIC INTERFACES
V.1 INTERFACE BETWEEN THE USER AND THE DLL
V.1.A DLLOPN - Open A DLL Portal
MOVEI T1,NU.OPN ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ;GET THE ADDRESS OF THE BLOCK
CALL DLLUNI
error return (code in T1)
good return
Where:
UNCHN This is the physical NI channel on which this protocol is to
be enabled. If SCAN is set(-1), then this is the first
physical channel in a list of physical channels which the
port driver is to scan through until it finds one that
works.
UNPSC This is the SCAN switch. If it is set(-1) then the physical
port address (CHANNEL) is the first in a list of physical
port addresses to be scanned by the port driver. If the
switch is not set (0), then no scanning is done or allowed
and this is the only NI channel which should be used.
UNCBA This is the addtess of the routine to call the user back at
for various events that affect his link. It has meaning
only on the open.
UNUID This is the ID which the user would like to see in when he
is called back by the Data link with messages and status
changes.
The following is returned to the user:
UNPID Value returned by routine to identify this PORTAL in a
unique way for calls to the other DLL routines. This
value is returned in T1.
UNCHN This is the actual NI channel on which the portal was opened
SPECIFIC INTERFACES Page V-2
and is returned strictly for informational purposes. If
SCAN (UNPSC) was not set then this should (and will)
correspond to the channel which the data link was called
with.
This routine is called to open a DLL port by the protocol server.
A DLL port corresponds to a single protocol type and no other port
may be enabled for that protocol type. If there is a promiscuous
receiver active, the routine will give the error return and the
error return DL.PRA (Promiscuous Receiver Active). The routine
will set up it's data bases for the user and return to him his
unique ID PORTAL-ID which is a full word value which the port uses
to identify this user with his particular data base in the DLL.
All future calls to the DLL should use this ID. The first routine
called must be DLLOPN, or all other routines will return an error.
The following errors can be returned for this call:
DL.PRA A promiscuous receiver is now active. The port will allow
no other users if there is a promiscuous receiver active
on any NI. In order for you to use the port, the
promiscuous receiver must close his portal.
DL.RES Resource Allocation failure.
DL.URC The channel was unrecognized by the port driver.
SPECIFIC INTERFACES Page V-3
V.1.B DLLEPT - Enable Protocol Type
MOVEI T1,NU.EPT ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ;GET THE ADDRESS
CALL DLLUNI ;CALL THE DLL
error return (code in T1)
good return
Where:
UNPID This is the PORTAL ID which the OPEN routine has assigned to
you.
UNPRO This is the protocol type which is to be assigned to this
portal.
UNPSC This is a flag to indicate whether or not padding is to be
done on this protocol type. A value of 1 for this flag
means that padding is to be added and a value of zero
means not to do padding.
UNPMD This is the packing mode for this protocol type. It should
be left zero for now.
This routine is called by the the user to enable a protocol type
for the specified PORTAL ID.
This routine has the following error returns:
DL.PTI The protocol type that you have requested is currently in
use by another user of the DLL.
DL.RES The NI Data link layer did not have the resources to enable
the specified protocol type for you.
DL.UPR The portal which you have called the routine with is not a
valid portal id.
DL.PRA A promiscuous receiver is active.
DL.CNO The call failed because the channel is not on.
SPECIFIC INTERFACES Page V-4
V.1.C DLLDPT - Disable A Protocol Type
MOVEI T1,NU.DPT ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ;GET THE ADDRESS
CALL DLLUNI ;CALL THE DLL
error return (code in T1)
good return
Where:
UNPID This is the portal ID assigned on the open call.
UNPRO This is the Protocol type which is no longer to be
recognized.
This routine is called to disable a protocol which has previously
been enabled by a call to DLLEPT.
This routine has the following error returns:
DL.UPR The portal with which the function was called is not
recognized.
DL.PNE The protocol type you are trying to deassign was not
assigned to your portal.
SPECIFIC INTERFACES Page V-5
V.1.D DLLEPM - Enable Promiscuous Mode
MOVEI T1,NU.EPM ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ;GET THE ADDRESS
CALL DLLUNI
error return (code in T1)
good return
Where:
UNPID This is the portal ID which is assigned on the open call
which is to be enabled in promiscuous mode.
This routine is called to enable the promiscuous receiver if it is
not already active. If there are any ports with Multicast
addresses assigned or protocol types, then the routine will not
allow the receiver to be activated.
This routine has the following error returns
DL.NIM The function is not implemented.
DL.NEX The implementation allows only exclusive use of the
promiscuous receiver and this or some other portal has a
protocol type or multicast address enabled.
DL.URP The portal with which the function was called is not a
valid portal.
DL.CNO The channel is not turned on.
SPECIFIC INTERFACES Page V-6
V.1.E DLLDPM - Disable Promiscuous Mode
MOVEI T1,NU.DPM ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ; AND THE ADDRESS
CALL DLLUNI
error return (code in T1)
good return
Where:
UNPID This is the portal ID which is assigned on the open call
which is to be taken out of promiscuous mode.
This routine is called to disable the promiscuous receiver. It
will always return even if the receiver was not active.
This routine has the following error returns
DL.URP The portal is not a valid portal id.
DL.PME Promiscuous mode was not enabled.
SPECIFIC INTERFACES Page V-7
V.1.F DLLCLO - Close A Data Link Layer Portal
MOVEI T1,NU.CLO ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK> ; AND THE ADDRESS
CALL DLLUNI
error return (in T1)
normal return
Where:
UNPID This is the portal ID which is assigned on the open call
which is to be closed
This routine is called to close the portal with ID contained in
UNPID. It should be called only to close the portal as once it is
called the DLL will purge it's data base of any information about
this portal. All message buffers will be returned to the user
before the portal is closed.
The following errors can be returned for this call:
DL.URP No such portal ID. If this error is returned it means
that the user attempted to call the close routine with a
non valid portal-id, or perhaps did not call the open
routine as the first routine in his sequence.
SPECIFIC INTERFACES Page V-8
V.1.G DLLDPA - Enable A Multicast Address
MOVEI T1,NU.DPA ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return (in T1)
good return
Where:
UNPID Is the Portal-ID assigned by the open.
UNSAD,UNSAD+1 (ADDRESS) Is the multicast address to enable on this
portal.
This routine is called to assign the multicast addresses for a DLL
portal. Please be advised that the assignment of the physical
address takes place during the open and if the multi-cast bit is
not set on this call an error is returned. If not, the routine
adds this to the list of enabled multi-casts for this portal.
These are the error codes returned by this routine:
DL.URP No such portal ID error.
DL.ACA The routine was called without the multicast bit set. It
is illegal to use this routine to set the physical address
of the portal.
DL.RES Resource allocation failure. A call to allocate core
failed to obtain it.
DL.PRA A promiscuous receiver is currently active, so no multicast
addresses may be assigned.
DL.CNO The channel is currently not on.
SPECIFIC INTERFACES Page V-9
V.1.H DLLRVA - Disable A Multicast Address
MOVEI T1,NU.RVA ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return (in T1)
good return
Where:
UNPID This is the portal ID returned on the open call.
UNSAD,UNSAD+1 (ADDRESS) This is the address to deassign.
This routine is called to deallocate any of the addresses assigned
to you by the DLLDPA routine. If the address is not found or the
routine can not find your portal ID in it's internal table the
error return is taken.
The following error codes are returned from this routine.
DL.URP No such portal-id.
DL.MAN Multicast address not enabled.
SPECIFIC INTERFACES Page V-10
V.1.I DLLSNM - Send An NI Datagram
MOVEI T1,NU.TRN
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
Where:
UNPID This is the PORTAL-ID returned on the open call.
UNBFA This is the address of the buffer (for non MSD lists) and
the address of the MSD chain for MSD style lists.
UNBSZ For non MSD buffers, this is the buffer size. It should be
left 0 for MSD style buffers. This buffer length includes
the CRC.
UNPRO This is the protocol type for which this message is
destined.
UNDAD,UNDAD+1(ADDRESS) This is the NI address for which the
message is bound. It may be multicast, broadcast or any
other allowable address.
UNPSC A flag to indicate that the CRC is included in this message.
This routine is called to send an NI datagram out over the wire
(to the port driver). It accepts as it's arguments either an MSD
style pointer or a non-msd style pointer. On the non-msd pointer
you must give a buffer count along with the buffer address. It
will then queue the message out through the port. Please be
advised that no guarantee of delivery is made.
The following error codes are returned from the send datagram
routine:
DL.URP There is no such portal id as the one you specified.
Perhaps the open routine was not called.
DL.MNS Message not sent because of some error in the ports
routine.
SPECIFIC INTERFACES Page V-11
V.1.J Data Link Specify Receive Buffer
MOVEI T1,NU.RCV
XMOVEI T2,<ADDRESS OF BLOC>
CALL DLLUNI
error return
normal return
Where:
UNPID This is the portal id assigned on the open.
UNPRO This is the protocol type for which this buffer is to be
used.
UNBFA This is the full word address of the buffer.
UNBSZ This is the total size of the buffer (ie:Data Length+CRC
length<4>) and is specified in bytes.
This routine is called by the protocol server in order to specify
a buffer which the DLL can use to store incomming messages from
the NI. It is the servers responsibility to specify enough
buffers for the task that it needs done. If the NI finds it does
not have enough buffers, it will throw away frames.
The following error codes are returned by this routine.
DL.URP No such portalid.
DL.ULB Unable to link receive buffer. For some reason the Port
was unable to link in your receive buffer to its chained
list of buffers.
DL.RES Resource allocation failure.
DL.CNO The current state of the channel is not on.
SPECIFIC INTERFACES Page V-12
V.2 CALL BACKS TO THE USERS CALL BACK VECTOR
V.2.A Call Back For Output Done (NU.TRN)
MOVEI T1,NU.TRN
XMOVEI T2,<ADDRESS OF INFORMATION BLOCK>
CALL <CALLBACK ROUTINE FROM OPEN>
always return
Where:
UNPID The portal ID on which the message was received.
UNUID This is the ID which the user asked us to specify on his
posted messages.
UNBFA The message block pointer of the buffer just sent.
UNBSZ This is the size of the buffer as supplied by the user.
UNSTA Status of the message:
Value Event Type
00 No error
01 Internal Hardware error
02 Transmit aborted
03 Local unrecognized command
04 Buffer length violation [1]
05 Carrier lost
06 Frame too short [2]
07 Remote Failure to defer [3]
10 Frame too long
11 Open Circuit
12 Short Circuit
13 ** SPARE
14 Carrier detect check failed
15 Excessive collisions
[1] The length of the information transmitted and the length of the
BSD is inconsistent.
[2] This error occurs only when padding of the transmitted frame is
not specified and the length of the data is less than 46 bytes.
[3] This error is not detectable by the NIA module and thus will never
be set. They are only included to conform to the Network Management
specification.
This call back signifies that a message has been transmitted, but
does not mean that it was delivered to the user as no gaurantees
are made on delivery at this level.
SPECIFIC INTERFACES Page V-13
V.2.B Input Complete Callback
MOVEI T1,NU.RCV
XMOVEI T2,<ADDRESS OF BLOCK>
CALL <CALLBACK ROUTINE SUPPLIED BY USER>
always return
Where:
UNPID This is the portal id assigned at open time.
UNUID This is the ID which the user is using to identify incoming
messages.
UNBSZ This is the total length of the data in the buffer (ie:Data
Length+CRC length<4>) and is specified in bytes.
UNBFA The address of the buffer into which the message has been
placed.
UNPRO This is the protocol type for which the message was
received.
UNSAD,<1+UNSAD> The 48 bit NI address of the source of this
message.
UNDAD,<1+UNDAD> The 48 bit NI address for whom this is destined.
UNSTA This is the returned status of the message.
Value Event type
00 No error
01 Internal Hardware error
02 Receive aborted
03 **SPARE
04 Queue entry too short
05 Packet too long
06 Invalid Remote port
07 Framing error
10 CRC error
This is the callback for when the port receives a message into one
of this users buffers.
SPECIFIC INTERFACES Page V-14
V.2.C Call Back For Line State Change
MOVEI T1,NU.LSC
XMOVEI T2,<ADDRESS OF BLOCK>
CALL <USER SUPPLIED CALL BACK ROUTINE>
always return
Where:
UNPID Is the portal ID affected
UNUID This is the ID which the user has said to place on all his
messages.
NEWSTATE This is one of the following and specifies the new state
of the line.
Value State
0 The line state is off.
1 The line state is in INIT
2 The line state is on
3 The line state is BROKEN
This call back is to tell a portal when there is a line state
which involves the current line that he is using. Any line state
change other than to the on state should be regarded as making the
port unavailable.
SPECIFIC INTERFACES Page V-15
V.3 CALLS FROM THE DLL TO THE NI PORT
V.3.A NIDSP - Call The NI Port Driver
MOVEI T1,FUNCTION
XMOVEI T1,ADDRESS OF BLOCK
CALL NIDSP
error return
normal return
Where:
FUNCTION The function that the port is to perform for us. It can
be any of the following list of functions. (See D36PAR
for symbolic definitions which should be used in case of
changes.)
o Transmit a buffer
o Post a Receive buffer
o Read port counters
o Read station information
o Write Station information
o Enable/Disable Protocol type
o Enable/Disable Multicast address
SPECIFIC INTERFACES Page V-16
ADDRESS Points to a the information block. The format of this
block is as follows:
!-----------------------------------------------------------------!
!Chan<3> !Status <8> ! IND <1> ! MBZ <6> ! Protocol type <2+16> !
!-----------------------------------------------------------------!
! MBZ <4> ! Port Address !
!-----------------------------------------------------------------!
! MBZ <20> ! Port Address Low !
!-----------------------------------------------------------------!
! Buffer Address !
!-----------------------------------------------------------------!
! Data Text Length+4 !
!-----------------------------------------------------------------!
! MBZ <4> ! Source ID !
!-----------------------------------------------------------------!
! MBZ <20> ! Source ID Low !
!-----------------------------------------------------------------!
! MBZ <4> ! Destination ID !
!-----------------------------------------------------------------!
! MBZ <20> ! Destination ID Low !
!-----------------------------------------------------------------!
! Portal ID (IDCODE) !
!-----------------------------------------------------------------!
The way this scheme works is that you need only supply enough
words to contain the argument which you wish to send to the PORT.
For example if you would like to just get the status for a
channel, you would just specify and allocate one word. However if
you require the PORTAL-ID to be sent along you must allocate the
whole block even though you do not perhaps use the BUFFER address.
This scheme is perhaps wasteful memory wise, but since these
blocks are to be relatively short lived, it was felt that a
consistent interface was more important.
SPECIFIC INTERFACES Page V-17
V.4 PORT INTERFACE ROUTINES
V.4.A DLLPCB - Port Call Back Routine
MOVEI T1,FUNCTION
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLPCB
always return
This is the address at which all calls from the port driver to the
DLL are made. The function codes are:
o Message Transmitted
o Message Available
o Line State change
o Read counters complete
o Read station information complete
o Write Station information (not a real call back)
The format of the block is exactly the same as for the call from
the DLL to the port driver. The same restrictions are placed on
the length of the block as in the above call.
SPECIFIC INTERFACES Page V-18
V.5 NETWORK MANAGEMENT INTERFACE
V.5.A Network Management Read Channel Status Function
MOVEI T1,NU.RCS ;GET THE FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return (in T1)
normal return
Where:
UNCHN This is the channel about which the status is requested.
This routine is called by the network management interface to
queue up a request to the port for information about a channel.
The caller must supply the channel for which the status is to be
read. When the command completes the user will be called back.
SPECIFIC INTERFACES Page V-19
V.5.B Network Management Read Portal List Function
MOVEI T1,NU.RPL
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
Where:
UNCHN The physical channel for which information is to be read.
UNBSZ Size of the buffer
UNBFA Address where the buffer is
This routine will read the list of all open portals into the user
supplied buffer. If there is not enough space in the buffer, the
list will be truncated and the error return taken.
SPECIFIC INTERFACES Page V-20
V.5.C Network Management Read Portal Function.
MOVEI T1,NU.RPF ;FUNCTION CODE
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
UNPID The portal for which information is desired.
UNBSZ The size of the users buffer.
UNBFA The address of the users buffer.
This function returns the information from the portal data base in
the user supplied buffer.
SPECIFIC INTERFACES Page V-21
V.5.D Network Management Channel Reset
MOVEI T1,NU.RES
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
Where:
UNCHN This contains the physical NI channel which is to be reset.
This routine is called to reset the channel to its initial state.
The physical address will be unset and all counters zeroed. All
portals associated with the channel will be closed. The channel
state is set to off.
SPECIFIC INTERFACES Page V-22
V.5.E Turn A Channel Off
MOVEI T1,UN.DCH
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
Where:
UNCHN This is the physical NI channel which is to be disabled.
This routine is called to stop a channel. The channel is passed
in T1. If the error return is taken, the port driver supplies an
error code in T1.
SPECIFIC INTERFACES Page V-23
V.5.F Read The Port Counters.
MOVEI T1,NU.RCC
XMOVEI T2,<ADDRESS OF BLOCK>
CALL DLLUNI
error return
normal return
Where:
UNCHN The physical channel for which the counters are to be read.
UNPSC A flag which when set (negative) means to clear the counters
after reading them. If this is not set the routine will
just read the counters.
UNBSZ The size of the buffer
UNBFA The address of the buffer.
This function performs either read or read and zero counters for
the port. It places the counters in BUFFER. If there is not
enough space in the buffer the counter list will be truncated. If
zero is also specified the counters will be zeroed. Please not
that even if the list is not complete, all counters will be zeroed
if this is specified.
[NISVCS.DOC]
1.0 INTERFACE TO NI REMOTE CONSOLE
This interface provides access to the IDENTIFY-SELF, BOOT,
READ-IDENTITY, READ-COUNTERS, and CONSOLE-ABORT functions as defined
in the DNA Low Level Maintenance Operation Specification (LLMOP). The
interface provides multiple process access to a single NI protocol
type by user mode programs. This interface uses the Remote Console
protocol, type 60-02. It also provides for access, by a single
privileged user process, to unsolicited remote console protocol type
datagrams received by the protocol server. This interface is to be
used primarily by NML and NI diagnostic programs.
The interface provides four basic functions; gaining access to
the NI Remote Console Service, initiating a request, checking the
status of a pending request, and enabling to read unsolicited
datagrams.
1.1 Access To The NI Remote Console Service
Access to the NI Remote Console Service is obtained through the
use of the LLMOP% JSYS. The LLMOP% JSYS provides the following remote
console functions:
o .RCIDS IDENTIFY SELF
o .RCRBT REMOTE BOOT
o .RCRID READ IDENTITY
o .RCRCT READ COUNTERS
o .RCCHK CHECK REQUEST STATUS
o .RCENU ENABLE UNSOLICITED RECEIPT
o .RCRDU READ UNSOLICITED
o .RCRSV RESERVE REMOTE CONSOLE
o .RCREL RELEASE REMOTE CONSOLE
o .RCSND SEND CONSOLE COMMAND
o .RCPOL CONSOLE RESPONSE POLL
o .RCABT CONSOLE ABORT
Page 2
1.2 Performing Ethernet Remote Console Operations
The above LLMOP% functions are used to perform the actual
operations. There eight functions provided, requesting a
read-identity of a remote system, requesting a read-counters,
requesting transmission of the system identity with identify-self,
forcing the boot of a remote system, checking the status of a request,
enabling a process to receive unsolicited remote console datagrams,
and reading an unsolicited remote console datagram.
The appropriate function codes contained in AC1 are:
.RCRID Read Identity
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Flags,,Interrupt Channel
B0(NI%DNB) Do Not Block for
Response
If this flag is on the
JSYS returns
immediately. The
.RCCHK function must
then be used to
determine the status
of the request
operation.
B18-B35(NI%ICH) Interrupt Channel
Number
1 .NIREQ Request Number
This field is set by the JSYS upon
return if the NI%DNB flag is set. The
returned request number must be used
in any later .RCCHK calls.
2 .NICID Channel-id
3 .NIDST Destination Address
4 .NIBFL Remote Console Data Buffer Length
5 .NIDAT Pointer to Remote Console Data
.RCRCT Read Counters
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Flags,,Interrupt Channel
B0(NI%DNB) Do Not Block for
Response
Page 3
This field is set by
the JSYS upon return
if the NI%DNB flag is
set. The returned
request number must be
used in any later
.RCCHK calls.
B18-B35(NI%ICH) Interrupt Channel
Number
1 .NIREQ Request Number
This field is set by the JSYS upon
return. The returned request number
must be used in any later .RCCHK
calls.
2 .NICID Channel-id
3 .NIDST Destination Address
4 .NIBFL Remote Console Data Buffer Length
5 .NIDAT Pointer to Remote Console Data
.RCIDS Identify Self
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Not Used
1 .NIREQ Not Used
2 .NICID Channel-id
3 .NIDST Destination Address
.RCRBT Remote Boot
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Not Used
1 .NIREQ Not Used
2 .NICID Channel-id
3 .NIDST Destination Address
4-5 .NIPWD Password Verification Code
6 .NICIF Control Information
B0-B7(NI%PRO) Processor to boot
0 = System Processor
1 = Communication
Processor
B8(NI%BSV) Boot Server
0 = System Default
1 = Requesting System
B9(NI%BDV) Boot Device
Page 4
0 = System Default
1 = Specified Device
7 .MODID Device Id
13 .MOSID Software Id
.RCCHK Check Request Status
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIRNO Request Number
1 .NIRTC Status Return Code
Upon return contains a status code for
the request as follows:
0 .NIPND Pending, Not Complete
1 .NISUC Success
2 .NIABT Aborted
4 .NITXF Transmit Failed
5 .NICCE Channel Communication
Error
2 .NIBFL Remote Console Buffer Length
3 .NILBD Pointer to Remote Console Data
.RCENU Enable Unsolicited Receipt
This function returns an error for all but the first
process to request it. AC2 contains flags and data as
follows:
B0(NI%AIC) Assign Interrupt Channel
B18-B35(NI%ICH) Interrupt Channel Number
.RCRDU Read Unsolicited Remote Console Datagram
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 Not Used
1 Not Used
2 .NICID Channel-id
3 .NISRC Source Address
4 .NIBFL Datagram Buffer Length
5 Not Used
6 .NIREP Pointer to Buffer for Received Data
.RCRSV Reserve Remote Console
This function reserves the remote systems ASCII
console for use by the process issuing the call on
this system. AC2 contains the address of an argument
block. The format of the argument block is as
follows:
Page 5
0 .NIFLG Not Used
1 .NIREQ Not Used
2 .NICID Channel-id
3 .NIDST Destination Address
4-5 .NIPWD Password Verification Code
6 .NIPID Port Id
This field is returned upon successful
completion of the function. The Port
Id is used as a handle for the
remainder of the ASCII console
functions.
.RCREL Release Remote Console
This function releases the access to the remote ASCII
console. AC2 contains the address of an argument
block. The format of the argument block is as
follows:
0 .NIFLG Not Used
1 .NIREQ Not Used
2 .NICID Not Used
3 .NIDST Not Used
4-5 .NIPWD Not Used
6 .NIPID Port Id
.RCSND Send Console Command
This function sends ASCII console command data to the
remote console and polls for response data. With no
command data this function may be used to poll for
more response data without sending a command. AC2
contains the address of an argument block. The format
of the argument block is as follows:
0 .NIFLG Console Command Flags
B0(NI%DNB) Do Not Block for
Response
This field is set by
the JSYS upon return
if the NI%DNB flag is
set. The returned
request number must be
used in any later
.RCCHK calls.
B1(NI%CBF) Command Break Flag
Precede data in the
command data buffer
with a break condition
in the serial byte
Page 6
stream.
B18-B35(NI%ICH) Interrupt Channel
Number
1 .NIREQ Request Number
2 .NICID Not Used
3 .NIDST Not Used
4-5 .NIPWD Not Used
6 .NIPID Port Id
7 .NICDL Command Data Buffer Length
8 .NICDB Pointer to ASCII Command Data Buffer
9 .NIRBL Response Data Buffer Length
10 .NIRDB Pointer to ASCII Response Data Buffer
.RCPOL Console Response Poll
This function polls for completion of the Send Console
Command function. AC2 contains the address of an
argument block. The format of the argument block is
as follows:
0 .NIFLG Data Lost Flags
B2(NI%CDL) Command Data Lost Flag
B3(NI%RDO) Response Data Lost
Flag
B4(NI%RDL) Receive Data Lost Flag
1 .NIREQ Request Number
2 .NICID Not Used
3 .NIDST Not Used
4-5 .NIPWD Not Used
6 .NIPID Not Used
7 .NICDL Command Data Buffer Length
8 .NICDB Pointer to ASCII Command Data Buffer
9 .NIRBL Response Data Buffer Length
10 .NIRDB Pointer to ASCII Response Data Buffer
2.0 INTERFACE TO NI LOOPBACK REQUESTOR/SERVER
This interface provides access to the LOOP-DIRECT and
LOOP-ASSISTED functions as defined in ref [4]. The interface provides
multiple process access by user mode programs on the JUPITER system.
This interface uses the cross-company Loopback protocol, type 60-00.
It also provides for access to unsolicited loopback protocol type
datagrams received by the protocol server. This is a private
interface for use by NML and diagnostics only.
The interface is provided by the LLMOP% JSYS. There are three
basic functions provided, checking the status of a pending request,
initiating a request, and enabling to read unsolicited datagrams.
Page 7
2.1 Performing Ethernet Loopback Operations
The LLMOP% JSYS is used to perform the actual operations. There
are five functions provided, requesting a loop-direct, requesting a
loop-assisted, enabling a process to receive unsolicited loopback
datagrams, checking the status of a request, and reading an
unsolicited loopback datagram.
The appropriate function codes contained in AC1 are:
.ELDIR NI Ethernet Loop Direct
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Flags,,Interrupt Channel
B0(NI%DNB) Do Not Block for
response
If this flag is on the
.NIREP field is
ignored and the JSYS
returns immediately.
The .RCCHK function
must then be used to
determine the status
of the loopback
operation.
B18-B35(NI%ICH) Interrupt Channel
Number
1 .NIREQ Request Number
This field is set by the JSYS upon
return. The returned request number
must be used in any later .RCCHK
calls.
2 .NICID Channel-id
3 .NIDST Destination Address
4 .NIBFL Loopback Data Buffer Length
5 .NIDAT Pointer to Loopback Data to Send
6 .NIREP Pointer to Buffer for Reply Data
.ELAST NI Ethernet Loop Assisted
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIFLG Flags,,Interrupt Channel
B0(NI%DNB) Do Not Block for
Response
Page 8
If this flag is on the
.NIREP field is
ignored and the JSYS
returns immediately.
The .ELCHK function
must then be used to
determine the status
of the loopback
operation.
B18-B35(NI%ICH) Interrupt Channel
Number
1 .NIREQ Request Number
This field is set by the JSYS upon
return. The returned request number
must be used in any later .ELCHK
calls.
2 .NICID Channel-id
3 .NIDST Destination Address
4 .NIBFL Loopback Data Buffer Length
5 .NIDAT Pointer to Loopback Data to Send
6 .NIREP Pointer to Buffer for Reply Data
7 .NIAST Assistant Address
8 .NIHLP Assistance Level
1 .NIXMT Transmit
2 .NIRCV Receive
3 .NIFUL Full
.ELCHK Check Request Status
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 .NIRTC Status Return Code
Upon return contains a status code for
the request as follows:
0 .NIPND Pending, Not Complete
1 .NISUC Success
2 .NIABT Aborted
3 .NICPE Compare Error
4 .NITXF Transmit Failed
5 .NICCE Channel Communication
Error
1 .NIREM Remote Assistant Address
Upon completion of a loop assisted
operation contains the address of the
remote system that satisfied the
Page 9
request.
2 .NILBD Pointer to Looped Back Data
.ELENU Enable Unsolicited Receipt
This function returns an error for all but the first
process to request it. AC2 contains flags and data as
follows:
B0(NI%AIC) Assign Interrupt Channel
B18-B35(NI%ICH) Interrupt Channel Number
.ELRDU Read Unsolicited Loopback Datagram
AC2 contains the address of an argument block. The
format of the argument block is as follows:
0 Not Used
1 Not Used
2 .NICID Channel-id
3 .NISRC Source Address
4 .NIBFL Loopback Data Buffer Length
5 Not Used
6 .NIREP Pointer to Buffer for Received Data
NISRV Functional Specification
By: Stu Grossman
March 16, 1984
11:11:23
2
NISRV Functional Specification
| 1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 5
| 2.0 WHAT THIS DOCUMENT DOES NOT COVER: . . . . . . . . . 5
| 3.0 PREREQUISITES . . . . . . . . . . . . . . . . . . . 5
| 4.0 RELATIONSHIP TO OTHER MODULES . . . . . . . . . . . 6
| 5.0 OVERVIEW OF NISRV . . . . . . . . . . . . . . . . . 7
| 5.1 Definitions . . . . . . . . . . . . . . . . . . . 7
| 5.2 Portals . . . . . . . . . . . . . . . . . . . . . 7
| 5.3 Portal ID . . . . . . . . . . . . . . . . . . . . 7
| 5.4 Byte Pointers . . . . . . . . . . . . . . . . . . 7
| 5.5 Message Segment Descriptors . . . . . . . . . . . 8
| 5.6 Padding . . . . . . . . . . . . . . . . . . . . . 8
| 6.0 BUFFERS . . . . . . . . . . . . . . . . . . . . . . 9
| 6.1 Receive Buffers . . . . . . . . . . . . . . . . . 9
| 6.2 Transmit Buffers . . . . . . . . . . . . . . . . 11
| 7.0 ETHERNET ADDRESSES AND PROTOCOL TYPES . . . . . . 12
| 7.1 Addresses . . . . . . . . . . . . . . . . . . . 12
| 7.2 Protocol Types . . . . . . . . . . . . . . . . . 12
| 8.0 STATE MACHINE . . . . . . . . . . . . . . . . . . 14
| 9.0 CALLS AND CALLBACKS . . . . . . . . . . . . . . . 16
| 9.1 Callbacks . . . . . . . . . . . . . . . . . . . 17
| 9.2 General Error Returns For All Functions . . . . 18
| 9.3 Open A Portal . . . . . . . . . . . . . . . . . 19
| 9.4 Close A Portal . . . . . . . . . . . . . . . . . 21
| 9.5 Close A Portal Callback . . . . . . . . . . . . 22
| 9.6 Post A Receive Buffer . . . . . . . . . . . . . 23
| 9.7 Datagram Received Callback . . . . . . . . . . . 25
| 9.8 Send A Datagram . . . . . . . . . . . . . . . . 27
| 9.9 Datagram Sent Callback . . . . . . . . . . . . . 29
| 9.10 Enable A Multicast Address . . . . . . . . . . . 31
| 9.11 Enable Multicast Address Callback . . . . . . . 33
| 9.12 Disable A Multicast Address . . . . . . . . . . 34
| 9.13 Disable Multicast Address Callback . . . . . . . 36
| 9.14 Read Portal Counters . . . . . . . . . . . . . . 37
| 9.15 Read Portal Counters Callback . . . . . . . . . 39
| 9.16 Read Channel Information . . . . . . . . . . . . 40
| 9.17 Channel State Change Callback . . . . . . . . . 41
| 9.18 Return Portal List . . . . . . . . . . . . . . . 42
| 9.19 Return Channel List . . . . . . . . . . . . . . 43
| 9.20 Read Portal Information . . . . . . . . . . . . 44
| 9.21 Set Channel Address . . . . . . . . . . . . . . 46
| 9.22 Set Channel Address Callback . . . . . . . . . . 47
| 9.23 Read Channel Counters . . . . . . . . . . . . . 48
| 9.24 Read Channel Counters Callback . . . . . . . . . 51
| 9.25 Set Channel State . . . . . . . . . . . . . . . 52
|
|
| APPENDIX A A
|
|
| APPENDIX B FUNCTION CODES
|
3
NISRV Functional Specification
| APPENDIX C ERROR CODES
|
4
NISRV Functional Specification
1.0 INTRODUCTION
This document describes the Tops-10/TOPS-20 monitor
interface to the Ethernet. All functions, arguments, callbacks,
and data formats are described here.
2.0 WHAT THIS DOCUMENT DOES NOT COVER:
1. Diagnostic interfaces to the Ethernet
2. The KLNI device driver
3. Design philosophy, except where it would clarify an
explanation within this document
4. Higher level protocols
3.0 PREREQUISITES
A basic knowledge of the Ethernet User Layer is assumed. All
terms used herein will be derived from the "Ethernet Blue Book"
spec, and from the "Ethernet Data Link Layer" spec published by
the DNA.
5
NISRV Functional Specification
4.0 RELATIONSHIP TO OTHER MODULES
The module that implements this interface is called NISRV.
NISRV in turn interfaces to PHYKNI which is the device dependant
Ethernet interface. PHYKNI controls the KLNI (KL10 Network
Interconnect), and is the only monitor module that directly
manipulates it.
The other modules which are conceptually "above" the NISRV
are it's "users". These typically are protocol drivers such as
DECnet's routing layer, LLMOP, LAT, TCP/IP, etc...
|
| This interface does NOT implement the interface described
| in the "Ethernet Data Link Layer" specification. However, it
| provides all the facilities and information that would be
| required to implement that interface. There are a number of
| reasons for not implementing directly to that spec. The first,
| and most important, is efficiency. In that regard, callbacks
| were used instead of polling. The second reason is due to the
| word size of this machine. Returned values such as counters are
| always 36. bit quantities. The third reason is that this
| interface interfaces to more than just DECnet.
| +-------------+
| | ROUTER |
| +------+------+
| +-------------+ !
| | Diagnostics | V
| +---+---+---+-+ +-------------+ +-------+ +--------+
| ! ! ! | DNADLL | | LAT | | LLMOP |
| ! ! ! +----+--------+ +--+----+ +---+----+
| ! ! !______________ ! _____________! !
| ! ! ! ! ! ________________________!
| ! ! V V V V
| ! ! +-------------+
| ! ! | NISRV |
| ! ! | |
| ! !----------------+ PHYKNI |
| ! +------+------+
| ! !
| ! V
| ! +-------------+
| !--------------------+ KLNI |
| +-------------+
|
6
NISRV Functional Specification
5.0 OVERVIEW OF NISRV
| 5.1 Definitions
|
| All symbols and definitions presented in this module are
| contained in the MACRO universal file NIPAR. MSD's are defined
| in D36PAR.
5.2 Portals
The basic working entity of NISRV is the "portal". A portal
uniquely identifies a particular user of the Ethernet.
Associated with a portal are a "channel", a callback address, a
protocol type, and zero or more multicast addresses. A channel
is the hardware that actually accesses the Ethernet. A system
with multiple channels will most likely have each channel hooked
up to a different Ethernet. A callback address is used for
returning asynchronus information to the user.
5.3 Portal ID
All calls to NISRV must supply a "portal id". Portal IDs are
generated by NISRV when the "Open a Portal" function is
executed. A portal ID is a full word (36 bit) value that has
utterly no meaning except that it uniquely identifies a portal
to NISRV.
5.4 Byte Pointers
| All four types of byte pointers are acceptable for those
| arguments that can be byte pointers. This includes:
|
|
| o One word local byte pointers
|
| o One word global byte pointers
|
| o Two word local byte pointers
|
| o Two word global byte pointers
|
|
| There are three restrictions on all byte pointers:
|
| 1. Indexing is not allowed
7
NISRV Functional Specification
| 2. Indirection is not allowed
|
| 3. Only 8 bit bytes are allowed
|
|
| It is strongly suggested that global byte pointers be used
| because NISRV may not be running in the same section that the
| byte pointer was generated in.
|
|
|
| 5.5 Message Segment Descriptors
|
| For transmits, a special form of buffer descriptor may be used
| which allows fragmented buffers. These are called Message
| Segment Descriptors (MSD's for short). An MSD chain basically
| consists of a number of contiguous segment descriptors. Each
| segment descriptor consists of a byte count and a byte pointer
| to it's associated data. For more details see Appendix A.
5.6 Padding
If you will be receiving or transmitting datagrams shorter than
46. bytes in length, you should enable padding for your portal.
On transmits a two byte (byte swapped) data length field will
automatically be prepended to the User Data part of the
datagram. This field will contain a count of the number of
valid data bytes immediately following. Also, if the total data
length (including the data length field) is less than 46. bytes,
the datagram will be padded (after the last byte of user data)
until it is at least 46. bytes long. On receives, the data
length field will automatically be stripped off, and used as the
received data length.
Note that there is no way for the receiver of a datagram to
determine if it is padded. Therefore, all users of a protocol
type must agree on whether or not they will be using padding.
Additionally, since the data length field is two bytes
long, the maximum data length for a portal using padding is
1498. bytes.
8
NISRV Functional Specification
6.0 BUFFERS
| 6.1 Receive Buffers
|
| Each portal may have a number of receive buffers associated with
| it. Receive buffers are queued up to the channel by the "Post a
| Receive Buffer" function. There is no limit on the number of
| receive buffers that may be queued. These buffers are returned
| to the portal owner via the "Datagram Received Callback" when an
| incoming datagram has been successfully received for that
| portal's protocol type.
|
|
|
| 6.1.1 Receive Buffer Pointer - The location of a receive buffer
| is specified by an IDPB style byte pointer stored in UNBFA and
| UNBFA+1. A receive buffer may be in exec virtual, user virtual,
| or physical memory. This is specified by the value stored in
| UNADS.
|
|
|
| 6.1.2 Receive Buffer Size - The size of a receive buffer is
| specified in UNBSZ. The size in UNBSZ depends upon whether or
| not padding is enabled.
|
| If padding is not being used with this portal the buffer size
| must include room for:
|
| 1. User data field from the received datagram. This can be
| from 46. to 1500. bytes long.
|
| 2. Cyclic Redundancy Check. This is 4 bytes long.
|
| For example, if the maximum message size for your protocol is
| 100 bytes, you will have to use receive buffers that are 104
| bytes long.
|
| For portals that use padding, the buffer size must include room
| for:
|
| 1. Data Length Field. This is 2 bytes long.
|
| 2. User data field from the received datagram. This can be
| from 44. to 1498. bytes long.
|
| 3. Cyclic Redundancy Check. This is 4 bytes long.
|
| An example using padding: If your protocol specifies that
| padding should be used, and states that the maximum message size
| (excluding padding) is 200 bytes long, you will have to use
| receive buffers that are 206 bytes long.
9
NISRV Functional Specification
| Note that one implication of the preceding paragraphs is
| that the absolute minimum receive buffer size is 50. bytes, and
| the absolute maximum receive buffer size is 1504. bytes.
|
|
|
| 6.1.3 Received Datagram Pointer - The byte pointer returned in
| UNBFA will be of the same type that was specified when the
| buffer was originally queued. This is an ILDB style pointer to
| the first byte of user data.
|
| If padding is not in use, the byte pointer will be
| identical to the one that was used to post the buffer.
|
| If padding is being used, the byte pointer will be advanced
| past the pad bytes.
|
|
|
| 6.1.4 Received Datagram Length - UNBSZ contains the length of
| just the data portion of the message (not including the CRC).
| If padding is being used, UNBSZ contains the value in the data
| length field of the padded datagram.
|
|
|
| 6.1.5 Receive Buffer constraints There are a number of
| constraints on receive buffers:
|
| o Physical contituity.
|
| o Word aligned.
|
| o Trailing bytes are indeterminate.
|
| Each of these points is discussed below in greater detail.
|
| Buffers used for receiving incoming Ethernet data must
| reside in physically contiguous memory. This means that if the
| buffer crosses a virtual page boundary, the physical pages which
| the buffer occupies must be adjacent and in ascending order.
| For example, a valid buffer might occupy virtual pages 5 and 6,
| if these pages map onto physical pages 100 and 101, then the
| buffer is fine.
|
| Due to a hardware restriction, the buffer must be word
| aligned. Therefore, the byte pointer must indicate a word
| aligned byte. As an example, byte pointers like 441000,,ADDR or
| 011000,,ADDR-1 would be valid byte pointers to a word aligned
| buffer at ADDR.
10
NISRV Functional Specification
| Note that if the length of the received datagram is not a
| multiple of four, the trailing bytes, up to the end of the last
| word are indeterminate after the buffer has been filled. Ie:
| if you specified a length of 41. bytes, there will be room for
| three more bytes within the last word of the buffer, and the
| contents of those bytes are indeterminate.
6.2 Transmit Buffers
Transmit buffers are queued up to the channel by the "Send a
Datagram" function. Any number of buffers may be queued up at a
given time. When the channel has completed transmission of a
buffer, it is returned via the "Datagram Sent Callback".
Two types of transmit buffers are supported. The first
type is a contiguous single buffer pointed to by a byte pointer.
The second type of buffer is the MSD style buffer. MSD's are
DECnet-36 defined structures which allow fragmented
(non-contiguous) transmits.
The value in UNBSZ indicates which type of buffer is being
used. If the value is zero, MSD style buffers are being used,
and UNBFA contains the address of the first MSD in the MSD
chain. If UNBSZ is non-zero, then UNBFA and UNBFA+1 contains an
ILDB style byte pointer to a single contiguous buffer, and UNBSZ
contains the length of that buffer.
Unlike receive buffers, transmit buffers do not need to be
word aligned. They can also occupy non-contiguous physical
memory. This applies to both types of transmit buffers.
The maximum and minimum data lengths depend upon whether
padding is in use. If padding is in use, the maximum data
length is 1498. bytes, and the minimum data length is 0. When
padding is not being used, the maximum data length is 1500.
bytes, and the minimum data length is 46. bytes. Note that for
MSDs, data length refers to the total length of all segments in
an MSD chain.
11
NISRV Functional Specification
7.0 ETHERNET ADDRESSES AND PROTOCOL TYPES
7.1 Addresses
| The user has two options when supplying Ethernet addresses. He
| may supply a byte pointer to the address, or he may supply the
| address itself within the UN block. If the field UNPTR contains
| 0, the address is contained in the UN block. Otherwise, the UN
| block contains an 8 bit byte pointer to the address string.
An address written as XX-YY-ZZ-SS-TT-UU would be
represented as a stream of 8 bit bytes as follows:
+--------+--------+--------+--------+--------+--------+
| XX M| YY | ZZ | SS | TT | UU |
+--------+--------+--------+--------+--------+--------+
An immediate address would occupy two words and would look like:
Bit # 0 7 15 23 31 35
+--------+--------+--------+--------+----+
Word 1: | XX M| YY | ZZ | SS | |
+--------+--------+--------+--------+----+
Word 2: | TT | UU | |
+--------+--------+--------+--------+----+
In the preceding diagrams, the "M" bit represents the location
of the multi=cast bit of the address.
Note that the immediate format is exactly the same as what
would be produced by an IDPB loop. Also, the byte pointer for
the first format should be an ILDB style byte pointer.
Immediate addresses or byte pointers to addresses are
usually supplied in the UNDAD or UNSAD fields of the UN block.
Each of these fields are two words long. On callbacks, the
address is always supplied in immediate format.
7.2 Protocol Types
The protocol type (usually in UNPRO) is treated as a 16 bit
number with the high order bits on the left, just like a natural
PDP-10 integer. A protocol type written as XX-YY would have
this format when being manipulated (perhaps in an AC):
20 27 35
+----+--------+--------+--------+--------+
| | XX | YY |
+----+--------+--------+--------+--------+
12
NISRV Functional Specification
Note that although UNPRO may have a somewhat different alignment
than this diagram, when a LOAD is done from it, the AC would
look like the preceding diagram.
13
NISRV Functional Specification
8.0 STATE MACHINE
| All channels participate in a state machine which can be
| observed and partially controlled by the user. The state
| machine is actually in two parts. The "external" part describes
| the state of the channel from the user's point of view. This
| state machine is rather simple, and should be used by protocol
| drivers to determine the useability of the channel. The second
| part is the "internal" state machine. This describes the state
| of the channel from NISRV's point of view. It is provided
| mainly for informational purposes.
|
| Both internal and external states are returned in the field
| UNSTA which is updated upon return from every call to NISRV, and
| is supplied in every callback generated by NISRV. The high
| order bit of this field is called UNRUN and indicates that NISRV
| beleives the channel to be running and capable of handling
| requests immediately. The sub-field UNEXS contains value which
| indicates the state of the external state machine. The
| sub-field UNSST contains a code which represents the current
| state of the internal state machine.
|
| The following is a table describing all state codes, their
| text names, and various other things.
|
| Symbol | Name | U-set | X-ient | Timed | External
| --------+---------------+-------+--------+-------+----------
| UNS.VG | Virgin | No | Yes | No | UNS.OF
| --------+---------------+-------+--------+-------+----------
| UNS.RE | Reload | Yes | Yes | Yes | UNS.RN
| --------+---------------+-------+--------+-------+----------
| UNS.CR | Can't Reload | No | No | No | UNS.OF
| --------+---------------+-------+--------+-------+----------
| UNS.IN | Init | Yes | Yes | Yes | UNS.RN
| --------+---------------+-------+--------+-------+----------
| UNS.RN | Run | No | - | No | UNS.RN
| --------+---------------+-------+--------+-------+----------
| UNS.DP | Dump | Yes | Yes | Yes | UNS.RN
| --------+---------------+-------+--------+-------+----------
| UNS.DR | Dump & Reload | Yes | Yes | Yes | UNS.RN
| --------+---------------+-------+--------+-------+----------
| UNS.BK | Broken | No | No | No | UNS.OF
| --------+---------------+-------+--------+-------+----------
| UNS.OF | Off | Yes | No | No | UNS.OF
| --------+---------------+-------+--------+-------+----------
|
|
| The column titled U-set indicates those states which can be
| set by the user. The column X-ient indicates those states that
| are transient, and may not exist for very long. The Timed
| column indicates those functions which are timed out if they
| take too long. All timed states that time out automatically
| make a transition to a terminal state (either "Can't Reload" or
14
NISRV Functional Specification
| "Broken"). The external column indicates the "external" state
| that maps onto the indicated "internal" state.
|
| Changes in the "external" state (ie: UNEXS) are indicated
| by the "Channel State Change" callback.
15
NISRV Functional Specification
9.0 CALLS AND CALLBACKS
All calls and callbacks use the same argument block. It is of
the form:
| BEGSTR UN
| FIELD CHN,3 ; Storage for the NI channel number
| FIELD SCN,1 ; Scan for channel on NU.OPN
| FIELD PAD,1 ; Use padding for this portal (NU.OPN only)
| FIELD ZRO,1 ; Zero counters after reading
| FIELD ADS,2 ; Address space of xmit or rcv buffer
| UNA.EV==0 ; Exec virtual
| UNA.UV==1 ; User virtual
| UNA.PH==2 ; Physical
| FIELD PTR,1 ; UNDAD contains a byte pointer
| FIELD RSP,1 ; Response desired
| HWORD PRO ; Protocol type
| HWORD TDR ; Time Domain Reflectometry value
| HWORD PMS ; PI mask
|
| WORD PID ; Portal ID
| WORD UID ; User's ID for this portal
| WORD RID ; Request ID
| WORD STA ; Channel status
| ; Subfields of UNSTA are UNRUN, UNSST, and UNEXS.
| OVRLAY STA ; Overlay UNSTA
| BIT UNRUN ; Channel is running (must be 1B0)
| FILLER 17 ; Align the fields
| FIELD SST,9 ; Secondary state
| FIELD EXS,9 ; External state
|
| WORD CBA ; Call back address (NU.OPN only)
| WORD BFA ; Buffer address
| WORD BFL ; 2nd word of buffer address
| WORD BSZ ; Buffer size
| WORD SAD ; Source Ethernet address
| WORD SAL ; 2nd word of Source Ethernet address
| WORD DAD ; Destination Ethernet address
| WORD DAL ; 2nd word of Dest Ethernet address
| WORD SPI ; Secondary portal ID
| WORD CAR ; Current Ethernet address
| WORD CAL ; 2nd word of Current Ethernet address
| WORD HAD ; Hardware address
| WORD HAL ; 2nd word of Hardware address
| HWORD OXM ; # Outstanding transmits
| HWORD ORC ; # Outstanding receives
| ENDSTR
|
|
| Fields in the UN block are never changed by the called
| function unless explicitly stated otherwise in the function's
| description.
16
NISRV Functional Specification
All fields that are not explicitly described in a
function's description are ignored, and will not be changed by
the function.
All functions take the function code in T1 and the UN block
addesss in T2 as arguments. All functions will give a skip
return to indicate success, and a non-skip to indicate failure
with the error code in T1.
9.1 Callbacks
When the Ethernet has completed certain commands, or when events
of an asynchronus nature happen, NISRV will call you back at the
address previously specified in the "Open a Portal" function.
The function code, and a pointer to an argument block will be
supplied (in ACs) as arguments to this routine. While in a
callback routine, any function may be invoked except for the
OPEN or CLOSE portal functions.
The actual calling sequence is specified in the "Callback"
description of a given function. However, there are some common
rules about all callbacks. They are:
1. The function code is always in T1, a UN block address (if
supplied) is always in T2, and a return status code is in
T3. If T3 contains a zero, then the function completed
successfully. Otherwise T3 contains a standard NISRV error
code (ie: UNxyz%).
2. The callback routine may use either a skip or a non-skip
return. Both types of returns are treated the same -- they
are ignored.
3. The callback routine must follow standard AC saving
conventions. Ie: it may use T1-T4 without preserving them.
P1-P7, Q1-Q3, P and 0 must be preserved.
4. During a callback, you may invoke other NISRV functions with
the exception of Open a Portal, and Close a Portal.
5. If a UN block is supplied, it belongs to NISRV, not to you.
Do not deallocate it.
6. The UN block that NISRV provides to the callback routine may
have it's contents altered without any problems. This means
that if the callback routine needs to perform another NISRV
function during a callback, it may use the UN block that was
supplied by NISRV.
17
NISRV Functional Specification
9.2 General Error Returns For All Functions
UNIFC%: - Illegal Function Code - The caller supplied an
unknown function code.
18
NISRV Functional Specification
Open A Portal
9.3 Open A Portal
9.3.1 Calling Sequence: -
UNCHN/ Channel number this portal is to use
UNPAD/ 1 if this protocol type uses padding
| UNPMS/ PI level mask
UNPRO/ Protocol type for transmits and receives
UNUID/ Callback ID
UNCBA/ Callback routine address
MOVX T1,NU.OPN
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNPID/ Portal ID
UNCHN/ Actual channel used (UNSCN/ 1)
UNSTA/ Channel status
9.3.2 Semantics: - This function creates portals. It returns a
portal ID in UNPID. The same portal ID must be used in all
subsequent calls that are associated with this portal. This
function also associates a callback routine (in UNCBA), and a
user ID (in UNUID) with the portal. If UNSCN was one, NISRV
will scan for a useable channel starting with the value that the
caller supplied in UNCHN. On return, UNCHN contains the channel
number that actually was used for this portal.
The field UNPRO determines what protocol type is associated
with this portal. This field can have several meanings
depending on the value stored in it. If the value is -1, then
no protocol type is associated with this portal. The portal
will be able to do any function except "Send a Datagram", "Post
a Receive Buffer", and "Read Portal Counters". If UNPRO
contains a -2, you will be enabling promiscuous mode. No other
protocol types can be enabled while promiscuous mode is enabled.
If the value is -3 the "Unknown Protocol Type Queue" will be
assigned to this portal. This queue receives messages that do
not match any enabled protocol types. If UNPRO contains a value
from 0 to 65535 (decimal), it will be interpreted as a protocol
type. The protocol type must not be associated with any
existing portals.
UNPAD should be set to one if you wish to use the padding
feature with this portal.
19
NISRV Functional Specification
Open A Portal
| The field UNPMS contains a bit mask which indicates all
| PDP-10 PI levels you may be calling this code at. The bits are
| in the same order as for a CONO PI, instruction. This allows
| you to call NISRV at any of the specified PI levels without
| incurring a race.
The callback address in UNCBA must point to a routine in
the resident (non-swappable) monitor. This is because callbacks
can occur at interrupt level.
The portal will always be created even if the channel is
not running (as indicated by UNSTA). This is done so that a
user can be notified of the channel coming online without having
to poll.
In case of failure, all fields in the UN block must be
considered invalid.
9.3.3 Restrictions: -
This function may not be called at callback level.
9.3.4 Related Functions: -
Close a Portal
9.3.5 Error Returns: -
UNRES%: - No resources - The NISRV was unable to allocate
memory for a portal data base.
UNNSC%: - No such channel - The specified channel does not
exist, or if UNSCN was set, there are no Ethernet channels on
this machine.
UNIVP%: - Illegal value for protocol type field - UNPRO did not
contain a valid protocol type or service class.
UNPIU%: - Protocol type already in use - The protocol type in
UNPRO contains a protocol type that is already in use by some
other portal.
UNPRA%: - Promiscuous receiver active - Another portal is using
protocol type -2 (ie: the promiscuous receiver).
UNICL%: - Illegal while at callback level
20
NISRV Functional Specification
Close A Portal
9.4 Close A Portal
9.4.1 Calling Sequence: -
UNPID/ Portal ID
MOVX T1,NU.CLO
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
9.4.2 Semantics: - This function destroys portals. UNPID
indicates which portal is to be destroyed. All outstanding
transmit buffers, receive buffers, and other commands will be
returned in an asynchronus manner via the callback mechanism.
This function only puts the portal in the "closing" state.
It remains in this state until all resources have been returned
to the user. The last callback made to the user will be with
the function code NU.CLO. After this callback, the portal will
cease to exist, and any attempts to use this portal will fail.
The only function that may be done in the "closing" state
is "Read Portal Information". Note that this function will fail
after the NU.CLO callback has been completed.
9.4.3 Restrictions: -
This function may not be called at callback level.
9.4.4 Related Functions: -
Open a Portal
9.4.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
UNICL%: - Illegal while at callback level
21
NISRV Functional Specification
Close A Portal Callback
9.5 Close A Portal Callback
9.5.1 Arguments: -
T1/ NU.CLO
T2/ UN block address
UNPID/ Portal ID
UNUID/ User ID
9.5.2 Semantics: - This callback occurs when all portal data
base cleanups have been completed. Immediately after this
returns, the portal ceases to exist.
22
NISRV Functional Specification
Post A Receive Buffer
9.6 Post A Receive Buffer
9.6.1 Calling Sequence: -
UNPID/ Portal ID
UNRID/ Request ID
| UNBFA/ Byte pointer to buffer
UNBFA+1
| UNADS/ Address space descriptor (See UN BEGSTR)
UNBSZ/ Size of buffer (in bytes)
MOVX T1,NU.RCV
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.6.2 Semantics: - This function supplies buffers to the
channel driver for the asynchronus receipt of datagrams.
The 36 bit value in UNRID will be associated with this
buffer, and will be returned by the Received Datagram callback
when this buffer is returned.
See the section on Receive Buffers for more information.
9.6.3 Restrictions: -
There are no restrictions on this function.
9.6.4 Related Functions: -
Send a Datagram
9.6.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
UNIFB%: - Improperly formatted buffer - The buffer is not in
physically contiguous memory, is non-resident, or does not start
on a word boundary.
UNIBP%: - Invalid byte pointer - The byte pointer contained
indexing or indirection.
23
NISRV Functional Specification
Post A Receive Buffer
UNRES%: - No resources - The channel driver was unable to get
memory for queueing up the receive buffer to the channel.
UNIBS%: - Illegal buffer size - The given buffer size does not
match the size of previously specified buffers, or the buffer
size is less than or equal to zero.
24
NISRV Functional Specification
Datagram Received Callback
9.7 Datagram Received Callback
9.7.1 Arguments: -
T1/ NU.RCV
T2/ UN block address
T3/ Status/error code
UNSAD/ Source address
UNSAD+1/
UNDAD/ Destination address
UNDAD+1/
UNPRO/ Protocol type (Promiscuous mode, or
Unrecognised protocol type only)
UNPID/ Portal ID
UNUID/ User ID
UNRID/ Request ID
UNBFA/ Buffer pointer (byte pointer)
UNBSZ/ Size of buffer (in bytes)
UNSTA/ Channel status
9.7.2 Semantics: - This callback occurs each time a datagram is
received. The return status (in T3) is one of:
|
| o UNRDL%: - Datagram too long - The received datagram was
| longer than the buffer size allocated for it by the NU.RCV
| function.
|
| o UNRAB%: - Receive aborted - The datagram is being returned
| because the channel is shutting down, or the portal is being
| closed.
|
| o UNLER%: - Length Error - (Padding only) - The data length
| field in the datagram was longer than the actual amount of
| received data.
For a desciption of the received datagram, UNBSZ and UNBFA, see
the sections on "Receive Datagram Pointer" and "Received
Datagram Length".
If you get the error "Datagram too long", UNBFA will point
to the portion of the data that fits into the buffer. In this
case UNBSZ will contain the "attempted" length, as opposed to
the "actual" length of the data. Ie: if the datagram was
actually 300 bytes, and your buffer was only 200 bytes, then
UNBSZ will contain 300. This error cannot happen when padding
is enabled.
25
NISRV Functional Specification
Datagram Received Callback
If you get the error "Length Error", the data length field
is ignored, and returned to the user along with the rest of the
datagram. UNBSZ contains the actual length of the datagram (ie:
the number of bytes received over the wire).
26
NISRV Functional Specification
Send A Datagram
9.8 Send A Datagram
9.8.1 Calling Sequence: -
UNPID/ Portal ID
UNRID/ Request ID
UNDAD/ Destination Ethernet address
UNDAD+1
UNPTR/ 1 if UNDAD is a byte pointer
| UNBFA/ Byte pointer (for non-MSD), 1st MSD address
| for MSD xmits
| UNBFA+1
| UNADS/ Address space of the data. Non-MSD only.
UNBSZ/ Size of buffer (in bytes)
MOVX T1,NU.XMT
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.8.2 Semantics: - This function transmits buffers to the
Ethernet address in UNDAD and UNDAD+1. If UNPTR is non-zero,
UNDAD will be treated as a byte pointer to the actual
destination address. The protocol type will be the one supplied
in UNPRO the "Open a Portal" call.
The 36 bit value placed in UNRID will be returned by the
Send a Datagram callback when this buffer has been sent.
9.8.3 Restrictions: -
This function may only be used on portals that have a protocol
type set.
9.8.4 Related Functions: -
Post a Receive Buffer
27
NISRV Functional Specification
Send A Datagram
9.8.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
UNNPE%: - No protocol type enabled - This portal does not have
a protocol type associated with it
UNIFB%: - Improperly formatted buffer - The buffer is not in
physically contiguous memory, or is non resident.
UNRES%: - No resources - The channel driver was unable to get
memory for queueing up the transmit buffer to the channel.
UNIBS%: - Illegal buffer size - The given buffer size was
negative. If padding is not in use, the buffer size was less
than 46. or greater than 1500. bytes. If padding was in use,
the buffer size was greater than 1498. bytes.
UNIBP%: - Illegal byte pointer - The byte pointer supplied in
UNDAD is indexed, indirected, or does not specify 8 bit bytes.
28
NISRV Functional Specification
Datagram Sent Callback
9.9 Datagram Sent Callback
9.9.1 Arguments: -
T1/ NU.XMT
T2/ UN block address
T3/ Status/error code
UNPID/ Portal ID
UNUID/ User ID
UNRID/ Request ID
UNBFA/ Buffer pointer
UNBFA+1/
UNBSZ/ Size of buffer, 0 if MSD style send
UNSTA/ Channel status
9.9.2 Semantics: - This callback occurs each time a datagram is
sent. The return status (in T3) is one of:
|
| o UNDNS%: - Datagram not sent - The datagram is being
| returned because the portal is being closed.
|
| o UNEXC%: - Excessive collisions - Heavy Ethernet traffic has
| prevented the transmission of this datagram. It may be
| reasonable to wait a random amount of time and try again
| later.
|
| o UNCCF%: - Carrier check failed. The Ethernet transceiver
| did not detect a carrier during a transmission.
|
| o UNSHT%: - Short circuit - The datagram could not be sent
| because the Ethernet cable was shorted out.
|
| o UNOPN%: - Open circuit - The datagram could not be sent
| because the Ethernet cable was unterminated.
|
| o UNRFD%: - Remote failure to defer - A collision occurred
| after the channel acquisition slot time.
For all errors except "Datagram not sent", the field UNTDR will
contain the Time Domain Reflectometry value returned by the
channel. This value indicates the distance (but not the
direction) where the error occurred. The distance is measured
from the transceiver, and is the number of bit times from the
start of transmission.
For MSD style sends, UNBFA will contain the address of the
MSD chain, and UNBSZ will be zero. For non-MSD sends, UNBFA
will contain a byte pointer to the data, and UNBSZ will be the
29
NISRV Functional Specification
Datagram Sent Callback
length supplied by the user.
30
NISRV Functional Specification
Enable A Multicast Address
9.10 Enable A Multicast Address
9.10.1 Calling Sequence: -
UNPID/ Portal ID
UNRSP/ 1 if a completion callback is desired
UNRID/ Request ID (only if UNRSP is 1)
UNDAD/ Multicast address to be enabled for this
portal
UNDAD+1
| UNPTR/ 1 if UNDAD is a byte pointer
MOVX T1,NU.EMA
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.10.2 Semantics: - This function enables your portal for the
receipt of datagrams destined for the Ethernet multicast address
specified in UNDAD.
The specified Ethernet address must be a multicast address.
Ie: the low order bit of byte zero of the address must be one.
The UNRSP bit may be used to cause a callback to occur when
this function actually completes. In this case UNRID will be
passed to the callback routine also.
9.10.3 Restrictions: -
This function may only be used on portals that have a protocol
type set. This function may not be invoked while a promiscuous
receiver is active.
9.10.4 Related Functions: -
Disable a Multicast Address
9.10.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
UNNPE%: - No protocol type enabled - This portal does not have
a protocol type associated with it.
31
NISRV Functional Specification
Enable A Multicast Address
UNIMA%: - Illegal multicast address - The address specified by
UNDAD does not have the multicast bit on.
UNIBP%: - Illegal byte pointer - The byte pointer supplied in
UNDAD is indexed, indirected, or does not specify 8 bit bytes.
UNRES%: - Resource failure - NISRV was unable to get enough
memory to satisfy this request.
UNNRE%: - No room for entry - There can be a maximum of 16
multicast addresses enabled at one time.
32
NISRV Functional Specification
Enable Multicast Address Callback
9.11 Enable Multicast Address Callback
9.11.1 Arguments: -
T1/ NU.EMA
T2/ UN block address
UNPID/ Portal ID
UNUID/ User ID
UNRID/ Request ID
UNDAD/ Multicast address that was enabled for this
portal
UNDAD+1
UNSTA/ Channel status
9.11.2 Semantics: - This callback occurs when the channel has
recognised this multicast address. After this callback is
complete, this portal will be able to receive datagrams destined
for the specified address.
33
NISRV Functional Specification
Disable A Multicast Address
9.12 Disable A Multicast Address
9.12.1 Calling Sequence: -
UNPID/ Portal ID
UNRSP/ 1 is a completion callback is desired
UNRID/ Request ID (only if UNRSP is 1)
UNDAD/ Multicast address to be disabled for this
portal
UNDAD+1
| UNPTR/ 1 if UNDAD is a byte pointer
MOVX T1,NU.DMA
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.12.2 Semantics: - This function disables your portal from
receiving datagrams bound for the multicast address specified in
UNDAD.
The specified Ethernet address must have been previously
enabled via the Enable a Multicast Address function.
The UNRSP bit may be used to cause a callback to occur when
this function actually completes. In this case UNRID will be
passed to the callback routine also.
9.12.3 Restrictions: -
There are no restrictions on this function.
9.12.4 Related Functions: -
Enable a Multicast Address
9.12.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
UNNPE%: - No protocol type enabled - This portal does not have
a protocol type associated with it.
UNANE%: - Address not enabled - The specified multicast address
was not enabled for your portal.
34
NISRV Functional Specification
Disable A Multicast Address
UNIMA%: - Illegal multicast address - The address specified by
UNDAD does not have the multicast bit on.
UNIBP%: - Illegal byte pointer - The byte pointer supplied in
UNDAD is indexed, indirected, or does not specify 8 bit bytes.
UNRES%: - Resource failure - NISRV was unable to get enough
memory to satisfy this request.
35
NISRV Functional Specification
Disable Multicast Address Callback
9.13 Disable Multicast Address Callback
9.13.1 Arguments: -
T1/ NU.EMA
T2/ UN block address
UNPID/ Portal ID
UNUID/ User ID
UNRID/ Request ID
UNDAD/ Multicast address that was disabled for this
portal
UNDAD+1
UNSTA/ Channel status
9.13.2 Semantics: - This callback occurs when the channel no
longer recognizes this multicast address for your portal. After
this callback is complete, this portal will not be able to
receive datagrams destined for the specified address.
36
NISRV Functional Specification
Read Portal Counters
9.14 Read Portal Counters
9.14.1 Calling Sequence: -
UNPID/ Portal ID
UNSPI/ Portal ID of portal that counters are
actually desired for
UNRID/ Request ID
UNBFA/ Address of buffer to put counters into
UNBSZ/ Length of buffer (in words) pointed to by
UNBFA
UNZRO/ 1 if counters should be cleared after reading
MOVX T1,NU.RPC
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
UNBSZ/ Number of words actually written into the
buffer
| 9.14.2 Semantics: - This function queues up a request to read
| (and optionally zero) portal counters. The counters are
| returned via the "Read Portal Counters Callback". The buffer
| pointed to by UNBFA is "owned" by NISRV until the callback
| occurs.
|
| There are two portal ID's actually associated with this
| function. UNPID is "your" portal ID. It indicates which
| callback routine should receive the counters. UNSPI is the
| "secondary" portal ID. This indicates which portal's counters
| are actually desired. Ie: if portal A wanted portal B's
| counters, UNPID would contain A and UNSPI would contain B.
|
| Counters are only kept for portals that have protocol types
| associated with them. The names are fairly self explanatory.
|
| All counters except for "User Buffer Unavailable" are
| updated just prior to giving the appropriate callback.
| BEGSTR PC
| FILLER 36 ; Network management data
| WORD SLZ ; Seconds since last zeroed
| FILLER 36 ; Network management data
| WORD BYR ; Bytes received
| FILLER 36 ; Network management data
| WORD DGR ; Datagrams received
| FILLER 36 ; Network management data
| WORD BYS ; Bytes sent
| FILLER 36 ; Network management data
37
NISRV Functional Specification
Read Portal Counters
| WORD DGS ; Datagrams sent
| FILLER 36 ; Network management data
| WORD UBU ; User buffer unavailable
| ENDSTR
|
| The network management data is a series of constants that
| describes the parameter number and width of the associated data.
|
|
|
| 9.14.3 Restrictions: -
| There are no restrictions on this function.
|
|
|
| 9.14.4 Related Functions: -
| Read Channel Counters
| Read Portal Information
|
|
|
| 9.14.5 Error Returns: -
| UNNSP%: - No such portal - Either your portal, or the secondary
| portal did not exist.
|
| UNIBS%: - Illegal buffer size - The buffer size was too small
| to hold all the required counters.
|
| UNRES%: - Resource failure - NISRV was unable to get enough
| memory to satisfy this request.
|
38
NISRV Functional Specification
| Read Portal Counters Callback
| 9.15 Read Portal Counters Callback
|
| 9.15.1 Arguments: -
|
| T1/ NU.RPC
| T2/ UN block address
|
| UNPID/ Portal ID
| UNUID/ User ID
| UNRID/ Request ID
| UNBFA/ Address of buffer containing counters
| UNBSZ/ Size of buffer (in words) pointed to by UNBFA
| UNSTA/ Channel status
|
|
|
|
| 9.15.2 Semantics: - This callback occurs when the Read Portal
| Counters function is complete. For the format and meaning of
| the data returned by this function, refer to the Read Portal
| Counters function.
|
| Upon completing this function, the counter buffer is
| "released", and may be manipulated by the user.
39
NISRV Functional Specification
Read Channel Information
9.16 Read Channel Information
9.16.1 Calling Sequence: -
UNCHN/ Channel ID
MOVX T1,NU.RCI
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
UNCAR/ Current address of the channel
UNCAR+1
UNHAD/ Hardware Ethernet address of the channel (Ie:
the builtin address)
UNHAD+1
UNSST/ Secondary channel status
9.16.2 Semantics: - This function returns various parameters of
the channel. The first address is returned in UNCAR, and
represents the current address the channel is responding to.
9.16.3 Restrictions: -
There are no restrictions on this function.
9.16.4 Related Functions: -
Read Channel Counters
Read Portal Information
9.16.5 Error Returns: -
UNNSC%: - No such channel - The specified channel does not
exist.
40
NISRV Functional Specification
| Channel State Change Callback
| 9.17 Channel State Change Callback
|
9.17.1 Arguments: -
T1/ NU.RCI
T2/ UN block address
UNPID/ Portal ID
UNUID/ User ID
UNSTA/ Channel status
UNCAR/ Current address of the channel
UNCAR+1
UNHAD/ Hardware Ethernet address of the channel (ie: the
builtin address)
UNHAD+1
UNSST/ Secondary channel status
9.17.2 Semantics: - This callback occurs when the channel
undergoes a state change which would be reflected in UNSTA.
This callback is unsolicited. It does not occur as the direct
result of doing any particular command.
All arguments are identical to the Read Channel Information
function, and you should refer to the description of that
function for complete information about them.
41
NISRV Functional Specification
Return Portal List
9.18 Return Portal List
9.18.1 Calling Sequence: -
UNBFA/ Address of buffer to hold list of portal IDs
UNBSZ/ Size of buffer pointed to by UNBFA
MOVX T1,NU.RPL
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
UNBSZ/ Number of portal IDs actually returned
9.18.2 Semantics: - This function returns a list of all open
portals.
The list is returned in the buffer pointed to by UNBFA.
Each portal ID occupies a full word, and is right justified so
that you can just move the portal ID into an AC, and directly
store it in UNPID (using the STOR macro).
9.18.3 Restrictions: -
There are no restrictions on this function.
9.18.4 Related Functions: -
Read Channel Counters
Read Portal Information
9.18.5 Error Returns: -
UNIBS%: - Illegal buffer size - The specified buffer size was
too small to hold all the portal IDs.
42
NISRV Functional Specification
| Return Channel List
| 9.19 Return Channel List
|
| 9.19.1 Calling Sequence: -
|
| UNBFA/ Address of buffer to hold list of channel IDs
| UNBSZ/ Size of buffer pointed to by UNBFA
| MOVX T1,NU.RCL
| MOVX T2,UN block address
| CALL DLLUNI
| <Error return. Reason in T1>
| <Good return>
|
| UNSTA/ Channel status
| UNBSZ/ Number of portal IDs actually returned
|
|
|
| 9.19.2 Semantics: - This function returns a list of all known
| channels.
|
| The list is returned in the buffer pointed to by UNBFA.
| Each channel number occupies a full word, and is right justified
| so that you can just move the channel number into an AC, and
| directly store it in UNCHN (using the STOR macro).
|
|
|
| 9.19.3 Restrictions: -
| There are no restrictions on this function.
|
|
|
| 9.19.4 Related Functions: -
| Read Channel Counters
| Read Portal Information
|
|
|
| 9.19.5 Error Returns: -
| UNIBS%: - Illegal buffer size - The specified buffer size was
| too small to hold all the channel numbers.
|
43
NISRV Functional Specification
Read Portal Information
9.20 Read Portal Information
9.20.1 Calling Sequence: -
UNPID/ Portal ID
UNBFA/ Address of buffer to receive multicast
address list
UNBSZ/ Size of buffer pointed to by UNBFA, or 0 if
not wanted
MOVX T1,NU.RPI
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNPRO/ Protocol type this portal is enabled for
UNPAD/ 1 if this portal is using padding
| UNPMS/ PI mask
UNCHN/ Channel number
UNBSZ/ Buffer size (in bytes) of receive buffers
UNOXM/ Number of outstanding transmits
UNORC/ Number of receive buffers outstanding
UNCBA/ Callback address
UNSTA/ Channel status
9.20.2 Semantics: - This function returns all information
(except for counters) in the portal data base for a given
portal.
UNOXM and UNORC indicate the number of buffers that haven't
been returned via the Transmit Complete or Receive Complete
callbacks.
The multicast address list (only returned if UNBSZ is
non-zero) looks like:
+-----------------------------------+
| # returned ! # set |
+-----------------------------------+
| High order bytes of first address |
+-----------------------------------+
| Low order bytes of first address |
+-----------------------------------+
n-1 / / . /
address < / . /
pairs \ / . /
+-----------------------------------+
44
NISRV Functional Specification
Read Portal Information
The left half of the first word returned contains the
number of multicast addresses actually returned. The right half
contains the number of addresses that were set. If the number
returned was less than the number set, then the block should be
made large enough to hold the number set. In words this would
be < set * 2>+1.
9.20.3 Restrictions: -
There are no restrictions on this function.
9.20.4 Related Functions: -
Read Channel Counters
Read Portal Information
9.20.5 Error Returns: -
UNNSP%: - No such portal - The specified portal does not exist.
45
NISRV Functional Specification
Set Channel Address
9.21 Set Channel Address
9.21.1 Calling Sequence: -
UNCHN/ Channel number
UNDAD/ New physical "soft" address for the channel
UNDAD+1
MOVX T1,NU.SCA
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.21.2 Semantics: - This function sets the physical address
associated with a channel.
The address specified in UNDAD must not be a multicast
address.
9.21.3 Related Functions: -
Read Channel Counters
Read Portal Information
9.21.4 Error Returns: -
UNNSC%: - No such channel - The specified channel does not
exist.
UNICA%: - Illegal channel address - The address supplied was a
multicast address.
46
NISRV Functional Specification
Set Channel Address Callback
9.22 Set Channel Address Callback
9.22.1 Arguments: -
T1/ NU.SCA
T2/ UN block address
UNPID/ Portal ID
UNUID/ User ID
UNSTA/ Channel status
UNDAD/ New physical address of channel
UNDAD+1/
9.22.2 Semantics: - This callback occurs when the channel's
address has changed. It is unsolicited, even though it is a
direct result of doing the Set Channel Address function. All
open portals receive this callback.
47
NISRV Functional Specification
Read Channel Counters
9.23 Read Channel Counters
9.23.1 Calling Sequence: -
UNCHN/ Channel ID
UNBFA/ Address of buffer to put counters into
UNBSZ/ Length of buffer (in words) pointed to by
UNBFA
UNZRO/ 1 if counters should be zeroed after reading
MOVX T1,NU.RCC
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
UNBSZ/ Number of words actually written into the
buffer
9.23.2 Semantics: - This function returns (and optionally
zeros) the counters associated with a channel.
The counters are returned in a block whose format is:
48
NISRV Functional Specification
Read Channel Counters
| BEGSTR CC
| FILLER 36 ; Network management data
| WORD SLZ ; Seconds since last zeroed
| FILLER 36 ; Network management data
| WORD BYR ; Bytes received
| FILLER 36 ; Network management data
| WORD BYS ; Bytes sent
| FILLER 36 ; Network management data
| WORD DGR ; Datagrams received
| FILLER 36 ; Network management data
| WORD DGS ; Datagrams sent
| FILLER 36 ; Network management data
| WORD MBR ; Multicast bytes received
| FILLER 36 ; Network management data
| WORD MDR ; Multicast datagrams received
| FILLER 36 ; Network management data
| WORD DSD ; Datagrams sent, initially deferred
| FILLER 36 ; Network management data
| WORD DS1 ; Datagrams sent, single collision
| FILLER 36 ; Network management data
| WORD DSM ; Datagrams sent multiple collisions
| FILLER 36 ; Network management data
| WORD SF ; Send failures
| FILLER 36 ; Network management data
| WORD SFM ; Send failure bit mask
| FILLER 36 ; Network management data
| WORD RF ; Receive failure
| FILLER 36 ; Network management data
| WORD RFB ; Receive failure bit mask
| FILLER 36 ; Network management data
| WORD UFD ; Unrecognized frame destination
| FILLER 36 ; Network management data
| WORD DOV ; Data overrun
| FILLER 36 ; Network management data
| WORD SBU ; System buffer unavailable
| FILLER 36 ; Network management data
| WORD UBU ; User buffer unavailable
| ENDSTR
|
|
| The text description of all counters is in the "Ethernet
| Data Link Architectural Specification".
|
|
|
| 9.23.3 Restrictions: -
| There are no restrictions on this function.
49
NISRV Functional Specification
Read Channel Counters
| 9.23.4 Related Functions: -
| Read Channel Counters
| Read Portal Information
|
|
|
| 9.23.5 Error Returns: -
| UNNSC%: - No such channel - The specified channel does not
| exist.
|
| UNIBS%: - Illegal buffer size - The buffer size was too small
| to hold all the required counters.
|
50
NISRV Functional Specification
| Read Channel Counters Callback
| 9.24 Read Channel Counters Callback
|
| 9.24.1 Arguments: -
|
| T1/ NU.RCC
| T2/ UN block address
|
| UNPID/ Portal ID
| UNUID/ User ID
| UNRID/ Request ID
| UNBFA/ Address of buffer containing counters
| UNBSZ/ Size of buffer (in words) pointed to by UNBFA
| UNSTA/ Channel status
|
|
|
|
| 9.24.2 Semantics: - This callback occurs when the Read Channel
| Counters function is complete. For the format and meaning of
| the data returned by this function, refer to the Read Channel
| Counters function.
|
| Upon completing this function, the counter buffer is
| "released", and may be manipulated by the user.
51
NISRV Functional Specification
Set Channel State
9.25 Set Channel State
9.25.1 Calling Sequence: -
UNCHN/ Channel number
UNDAD+1
UNSTA/ New channel state
MOVX T1,NU.SCS
MOVX T2,UN block address
CALL DLLUNI
<Error return. Reason in T1>
<Good return>
UNSTA/ Channel status
9.25.2 Semantics: - This function enables or disables the
channel. If the channel is disabled, it is left in a state such
that it can be continued later via the enable mechanism. All
functions that require the channel will be queued up and
executed when the channel is enabled.
9.25.3 Restrictions: -
There are no restrictions on this function.
9.25.4 Related Functions: -
Read Channel Counters
Read Portal Information
9.25.5 Error Returns: -
UNNSC%: - No such channel - The specified channel does not
exist.
52
|
|
|
|
|
|
|
|
|
|
|
|
| APPENDIX A
|
| A
|
|
|
| The format of an MSD follows:
|
| BEGSTR MD ;Input Meaning, ;Output Meaning
| WORD NXT,QP.LEN ;MUST BE ZERO ;PTR TO NEXT MSD
| WORD PTR ;ILDB PTR INTO MSG ;IDPB PTR INTO MSG
| WORD AUX ;NOT USED ;ILDB PTR TO BEG OF MSG
| WORD BYT ;BYTES LEFT TO READ ;BYTES WRITTEN SO FAR
| FIELD VMC,3 ;VIRTUAL MAP CONTEXT
| VMC.XC==:0 ;EXEC Context (Map through EPT)
| VMC.US==:1 ;USER Context (Map through UPT)
| VMC.NO==:2 ;DO NOT Map (Physical Address)
| HWORD ALL ;ALLOCATED LENGTH IN BYTES
| WORD ALA ;ALLOCATED ADDRESS OF SEGMENT'S DATA
| ENDSTR
|
| Not all fields are used by NISRV when doing MSD style transmits. The
| fields and NISRV's interpretation of them are described below.
|
| The field MDNXT contains a pointer to the next MSD in the MSD chain.
| It is treated as a 30 bit address. A contents of zero indicates that this
| is the last MSD in the chain.
|
| MDAUX is contains a one word local indexed byte pointer to the start
| of the data for this particular MSD. The index AC is ignored by NISRV,
| but during normal operation would contain the 30 bit address of the
| beginning of the data buffer (ie: the contents of MDALA).
|
| The contents of MDBYT is treated as the data length for this MSD.
| This field may contain 0. In that case, the MSD is ignored, and NISRV
| procedes to the next MSD in the chain.
|
| The field MDVMC indicates the address space that contains this MSD's
| data.
|
| MDALA contains a 30 bit address to the start of this MSD's data
| buffer. This address normally resides in the index AC used by the byte
| pointer in MDAUX.
A-1
| A
| When computing the start of the text portion of an MSD, NISRV takes
| the right half of the byte pointer in MDAUX and adds it to the contents of
| MDALA. The left half of the byte pointer is evaluated to determine if the
| address needs to be incremented, and to determine the offset of the first
| byte of data.
|
| There are two other aspects of MSD processing that should be
| mentioned here:
|
| 1. The fields MDPTR, and MDALL are ignored by NISRV.
|
| 2. The MSD is never changed by NISRV. Upon completion of the
| transmission it is returned intact.
|
A-2
|
|
|
|
|
|
|
|
|
|
|
|
| APPENDIX B
|
| FUNCTION CODES
|
|
|
| NU.OPN - Open a Portal
| NU.CLO - Close a Portal - Close a Portal Callback
| NU.RCV - Post a Receive Buffer - Datagram Received Callback
| NU.XMT - Send a Datagram - Datagram Sent Callback
| NU.EMA - Enable a Multicast - Enable Multicast Callback
| NU.DMA - Disable a Multicast - Disable Multicast Callback
| NU.RPC - Read Portal Counters - Read Portal Counters Callback
| NU.RCI - Read Channel Info - Read Channel Info Callback
| NU.RPL - Read Portal List
| NU.RPI - Read Portal Info
| NU.SCA - Set Channel Address - Set Channel Address Callback
| NU.RCC - Read Channel Counters - Read Channel Ctrs Callback
| NU.SCS - Set Channel State
| NU.MAX - Maximum function
B-1
|
|
|
|
|
|
|
|
|
|
|
|
| APPENDIX C
|
| ERROR CODES
|
|
|
|
| UNIFC% - Illegal Function Code
| UNRES% - No Resouces
| UNNSC% - No Such Channel
| UNICR% - Illegal Callback Routine
| UNIVP% - Illegal Protocol Type
| UNPIU% - Protocol Type In Use
| UNPRA% - Promiscuous Receiver Active
| UNICL% - Illegal Function at Callback Level
| UNNSP% - No Such Portal
| UNIFB% - Improperly Formatted Buffer
| UNIBS% - Illegal Buffer Size
| UNRDL% - Received Datagram Too Long
| UNRAB% - Receive Aborted
| UNLER% - Length Error
| UNNPE% - No Protocol Type Enabled For This Portal
| UNIBP% - Illegal Byte Pointer
| UNEXC% - Excessive Collisions
| UNDNS% - Datagram Not Sent
| UNNRE% - No Room For Entry
| UNANE% - Address Not Enabled
| UNIMA% - Illegal Multicast Address
| UNICA% - Illegal Channel Address
|
| UNMAX% - Maximum error code
C-1
LCG NI Port Architecture Specification
COMPANY CONFIDENTIAL
Mike Wolinski
Thomas G. Arnold
MRO1-2 E/18
DTN 231-5707
7 May 1984
Revision 8.0
LCG NI Port Architecture Specification REV 8.0 Page 2
COMPANY CONFIDENTIAL
1.0 GOALS . . . . . . . . . . . . . . . . . . . . . . . 4
2.0 NON-GOALS . . . . . . . . . . . . . . . . . . . . . 4
3.0 NOTATIONAL CONVENTIONS . . . . . . . . . . . . . . . 4
4.0 REFERENCES . . . . . . . . . . . . . . . . . . . . . 4
5.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 5
5.1 Port Usage . . . . . . . . . . . . . . . . . . . . 5
5.2 Port Services . . . . . . . . . . . . . . . . . . 6
5.3 NI Packet Format . . . . . . . . . . . . . . . . . 6
6.0 ARCHITECTURE OVERVIEW . . . . . . . . . . . . . . . 8
6.1 Port Addresses . . . . . . . . . . . . . . . . . . 8
6.2 Port Control Block . . . . . . . . . . . . . . . . 8
6.2.1 Queue Headers . . . . . . . . . . . . . . . . . 9
6.2.2 Queue Interlocks . . . . . . . . . . . . . . . . 9
6.3 States And Programming . . . . . . . . . . . . . 15
6.3.1 Port States . . . . . . . . . . . . . . . . . 15
6.3.2 Command Queue . . . . . . . . . . . . . . . . 15
6.3.3 Unknown Protocol Type Free Queue . . . . . . . 16
6.3.4 Response Queue . . . . . . . . . . . . . . . . 16
6.3.5 Protocol Type Table Starting Address . . . . . 17
6.3.6 Multi-Cast Address Table Starting Address . . 17
6.4 Queue Structures . . . . . . . . . . . . . . . . 17
6.4.1 Queue Headers . . . . . . . . . . . . . . . . 17
6.4.2 Queue Entries . . . . . . . . . . . . . . . . 18
6.4.3 Protocol Type Table . . . . . . . . . . . . . 19
6.4.4 Buffer Descriptors . . . . . . . . . . . . . . 22
6.5 Multi-cast Address Table . . . . . . . . . . . . 24
6.6 Received Packet Filtering . . . . . . . . . . . 27
6.7 Port Commands And Responses . . . . . . . . . . 28
6.7.1 Command Processing . . . . . . . . . . . . . . 28
6.7.2 Responses . . . . . . . . . . . . . . . . . . 28
6.7.3 Remote Responses . . . . . . . . . . . . . . . 29
6.7.4 Self Directed Commands . . . . . . . . . . . . 29
6.7.5 Port Functions . . . . . . . . . . . . . . . . 30
6.8 Error Handling . . . . . . . . . . . . . . . . . 30
6.8.1 Port Hardware Errors . . . . . . . . . . . . . 31
6.8.2 Error Events . . . . . . . . . . . . . . . . . 32
6.8.3 Datagram Discarded . . . . . . . . . . . . . . 32
6.9 Event Counters . . . . . . . . . . . . . . . . . 33
6.10 MOP Message Handling . . . . . . . . . . . . . . 35
6.11 Broadcast Of System ID . . . . . . . . . . . . . 35
7.0 COMMAND SPECIFICATION . . . . . . . . . . . . . . 35
7.1 FLAGS Field . . . . . . . . . . . . . . . . . . 36
7.2 Status Field . . . . . . . . . . . . . . . . . . 37
7.3 Send Datagram . . . . . . . . . . . . . . . . . 39
7.3.1 SNDDG Command . . . . . . . . . . . . . . . . 39
7.3.2 DGSNT Response . . . . . . . . . . . . . . . . 42
7.3.3 DGRCV Response . . . . . . . . . . . . . . . . 44
7.4 Load Protocol Type Table . . . . . . . . . . . . 48
LCG NI Port Architecture Specification REV 8.0 Page 3
COMPANY CONFIDENTIAL
7.4.1 LDPTT Command . . . . . . . . . . . . . . . . 49
7.4.2 PTTLD Response . . . . . . . . . . . . . . . . 49
7.5 Load Multi-cast Address Table . . . . . . . . . 50
7.5.1 LDMCAT Command . . . . . . . . . . . . . . . . 50
7.5.2 MCATLD Response . . . . . . . . . . . . . . . 51
7.6 Read And Clear Performance Counters . . . . . . 52
7.6.1 RCCNT Command . . . . . . . . . . . . . . . . 52
7.6.2 CNTRC Response . . . . . . . . . . . . . . . . 53
7.6.2.1 WRTPLI Command . . . . . . . . . . . . . . . 60
7.6.2.2 PLIWRT Response . . . . . . . . . . . . . . 61
7.6.3 Read Port/Link Interface . . . . . . . . . . . 62
7.6.3.1 RDPLI Command . . . . . . . . . . . . . . . 62
7.6.3.2 PLIRD Response . . . . . . . . . . . . . . . 63
7.6.4 Read NI Station Address . . . . . . . . . . . 64
7.6.4.1 RDNSA Command . . . . . . . . . . . . . . . 65
7.6.4.2 NSARD Response . . . . . . . . . . . . . . . 65
7.6.5 Write NI Station Address . . . . . . . . . . . 68
7.6.5.1 WRTNSA Command . . . . . . . . . . . . . . . 68
7.6.5.2 NSAWRT Response . . . . . . . . . . . . . . 70
8.0 PORT REGISTERS . . . . . . . . . . . . . . . . . . 71
9.0 DATA FORMATTING MODE . . . . . . . . . . . . . . . 74
9.1 Industry Compatible Mode . . . . . . . . . . . . 74
10.0 NI OPCODE SUMMARY . . . . . . . . . . . . . . . . 75
11.0 PROGRAMMING NOTES . . . . . . . . . . . . . . . . 76
11.1 LOADING AND DUMPING OF THE PORT . . . . . . . . 78
11.2 Reset . . . . . . . . . . . . . . . . . . . . . 80
11.3 Initialization . . . . . . . . . . . . . . . . . 80
LCG NI Port Architecture Specification REV 8.0 Page 4
COMPANY CONFIDENTIAL
1.0 GOALS
This document describes the software interface to control an
LCG NI port. The LCG NI port will implement the necessary
functionality to meet the required DEC corporate specs for devices
connected to the NI. These include, but are not limited to, the
bluebook Ethernet specification, the corporate NI Product
Architecture, the DNA NI Data Link Specification, and the Low Level
Maintenance Operation (MOP) specification. Port services and
functionality are described.
2.0 NON-GOALS
It is not a goal of this specification to describe the
physical channel, or to resolve higher level network issues. No
specific network architecture beyond that defined in the data link
Ethernet specification is implied.
3.0 NOTATIONAL CONVENTIONS
All numbers in this specification will be in decimal unless
explicitly stated otherwise. Numbering of bits in words conforms
to the DEC-20 standard of numbering the left most (highest order)
bit as 0, and proceeding to the right from there. The number of
the right most (least significant) bit in a PDP-20 word is 35.
4.0 REFERENCES
The reader is assumed to be familiar with the the following
documents:
1. LCG Network Interconnect Adaptor (NIA) Interface Specification.
Author Bernie Hall and John Halstead.
2. NI Node Product Architecture. Version 1.0 Author: P.J.
Nesbeda. This document describes the minimum requirements of a
DEC NI node.
3. DNA Low Level Maintenance Operations Architecture. Version
3.0.0 Authors: Bob Stewart and Ken Chapman This documents
describes the maintenance features available in most NI nodes.
LCG NI Port Architecture Specification REV 8.0 Page 5
COMPANY CONFIDENTIAL
4. DNA NI Data Link Architecture. Version 1.0 Author: Bob
Stewart. This document integrates the "Ethernet" spec into
DNA.
5. VAX-11 NI Port Architecture. Author: William Strecker, Bruce
Mann. This documents defines the architecture of the NI port
for the VAX family of processors. This document is the model
for the LCG NI port architecture.
6. The Ethernet - A Local Area Network - Data Link Layer And
Physical Layer Specifications. Version 2.0 Author: DEC,
Xerox, Intel. This is THE description of the NI itself.
5.0 INTRODUCTION
The NI is a multiaccess serial interconnect that allows up to
1024 different stations to share a common 10 Megabit bus and
communicate by exchanging data packets. The maximum length of the
NI interconnection is 2.5 kilometers (1.5 miles). The transmission
medium is a coaxial cable, using base band signaling. The
arbitration protocol used by the NI is carrier sense multiple
access with collision detect (CSMA/CD.) The service provided by the
NI is a datagram-class of service in which the data packets are
delivered on a best-effort basis; no confirmation of delivery is
made, and no guarantee of sequentiality or non-duplication is made.
Higher levels of network software must provide these services based
upon the basic Ethernet service offered by this port. A full
description of the NI itself appears in the Ethernet specification
referred to above.
5.1 Port Usage
The NI20 will interface between the NI and the KL10 E/Cbus.This
port provides the Data Link and Physical Channel layers of the ISO
(International Standards Organization) OSI (Open Systems
Interconnection) reference model.
LCG NI Port Architecture Specification REV 8.0 Page 6
COMPANY CONFIDENTIAL
5.2 Port Services
The NI port performs queued retrieval of commands, queued
reporting of received packets, packet transfer to and from host
memory, packetization, framing, CRC generation and checking,
Ethernet arbitration, transmission retries, and error reporting.
The NI also does filtering for multi-cast addresses, and broadcast
addresses, as well as physical destination addresses. Protocol
type filtering is done. Free queue entries for enabled protocol
types are obtained from a list of protocol types and associated
free queue pointers.
Received packet address filtering is done in the following
manner: In order to receive a datagram, the destination field of
the datagram must pass the received address filter. If the
destination address is -1 (all ones), then the message is a
BROADCAST message, and the port accepts it. If the destination
address has bit 47 a zero, then it is a physical address; If this
destination address matches the physical address of the link, the
port accepts it. If the destination address has bit 47 a one, then
it is a multi-cast address. If this destination address matches
one of the multi-cast addresses enabled for the port, the datagram
is accepted.
If the packet is accepted by the port address filter, Protocol
Type filtering occurs as follows: When a message is received, the
protocol type is checked against the table of enabled protocol
types. If a match is found in this table, the associated free list
is used to obtain the queue entry to store the received packet.
This feature allows effective queue management by the port driver.
If a match is not found, the required queue entry is obtained from
the Unknown Protocol Type free list queue anchored in the PCB. If
the queue checked in order to get the free entry is empty, the
datagram is discarded.
5.3 NI Packet Format
The basic format of a frame (packet) of data which appears on
the NI wire follows:
LCG NI Port Architecture Specification REV 8.0 Page 7
COMPANY CONFIDENTIAL
+-------------------------+
| |
| DESTINATION ADDRESS | 6 BYTES
| |
+-------------------------+
| |
| SOURCE ADDRESS | 6 BYTES
| |
+-------------------------+
| |
| PROTOCOL TYPE | 2 BYTES
| |
+-------------------------+
| |
| DATA | 46-1500 BYTES
+-------------------------+
| |
| FRAME CHECK SEQUENCE | 4 BYTES
| |
+-------------------------+
The following definitions apply:
1. Destination address - These 6 bytes contain the address of the
port that is the intended recipient of this frame.
2. Source address - These 6 bytes contain the address of the port
that transmitted this frame.
3. Protocol type - These 2 bytes defined the format and content of
the remainder of the packet.
4. Data - These bytes are the actual data bytes intended for the
receiver.
5. Frame check sequence - This is the 4 byte CRC field that is
used to guarantee the uncorrupted reception of the packet.
LCG NI Port Architecture Specification REV 8.0 Page 8
COMPANY CONFIDENTIAL
6.0 ARCHITECTURE OVERVIEW
The LCG NI port model is a single port communicating with a
single port driver which provides the multiplexing and
demultiplexing services necessary for many users to share the NI
wire. The port and port-driver software communicate with each
other through the use of queues and a Port Control Block.
6.1 Port Addresses
All host memory addresses used by this port are physical
addresses in KL10 memory. All pointers in the Port Control Block,
the Protocol Type Table, the Multi-cast Address Table, the queue
entries, and the free standing queue headers refer to physical
addresses. Reserved for software words are provided for the use of
the driver program. One use may be to hold the virtual address
counterpart for these structures.
6.2 Port Control Block
The Port Control Block is used to anchor the queues at a known
point in the host memory and to provide certain initial parameters
to the port. The queues are used to pass commands from the
port-driver software to the port for either local execution or for
transmission over the NI wire. The queues are also used by the
port to pass responses back to the port driver software and to
deposit packets received over the NI wire.
The Port Control Block (PCB) is a data structure based in the
host memory that allows the sharing of the queues by the port
driver and the port. The Port Control Block is pointed to by port
register 2, the PCB Base register.
The port is informed of the location of the PCB at micro code
intialization time by the port driver software. When this is
detected by the port, it will cache the following variables from
the PCB: the unknown protocol type queue entry length, the
portocol type table starting address, and the multi-cast address
table starting address.
Both the host port driver and port read and write locations in
the PCB. There is exactly one PCB for each NI port controlled by
the host system. The PCB is the main control structure for the NI
port. It anchors all of the tables and queue structures. The PCB
LCG NI Port Architecture Specification REV 8.0 Page 9
COMPANY CONFIDENTIAL
contains queue headers to anchor the command queue, the response
queue, and the unknown protocol type free queue. Base pointers to
the Multi-cast address table, and the protocol type table are
located in the PCB. In addition, an error logout area, and several
free words provided for the use of the driver program are included
in the PCB. The reseved words will never be altered or examined by
the NI port. The error logout area may be written at any time by
the port to record an error event.
6.2.1 Queue Headers - A queue consists of a queue header which
anchors the queue and a number of entries, each occupying a spot on
the queue. All LCG NI queues are doubly linked structures. The
queue header and each queue entry contain a forward link (FLINK)
and a backwards link (BLINK.) The forward link of a queue header
points at the first entry of the queue. The forward link of a
queue entry points to the next entry of the queue, if any. The
backwards link of a queue header points at the last entry of the
queue. The backwards link of a queue entry points back at the
entry before the entry on the queue, if any. If a flink does not
point to a queue entry, it points at the queue header flink. If a
blink does not point to a queue entry, it points at the queue
header flink.
Queue headers anchor a queue structure. A queue header may be
located in the PCB, or located in host memory as a free standing
structure. A queue header is composed of a reserved word, a FLINK,
a BLINK, and a Queue Length. The FLINK (forward link) points to
the first word, the FLINK, of the first entry of the queue. The
BLINK points to the FLINK word of the last entry of the queue. The
first and last entries may be the same entry. If there are no
entries on the queue, the queue header FLINK points to itself.
The Queue Length word, where applicable, specifies the length
in words, of the entire entry, including the FLINK, BLINK, Command
header, and data words. The queue length applies to every entry on
the queue. All queue entries on one queue must be the same length.
6.2.2 Queue Interlocks -
The NI20 requires special KL10 microcode support to allow the
NI20 to perform a memory increment operation using read-pause-write
memory references. This is needed to allow the port to interlock
the queues.
LCG NI Port Architecture Specification REV 8.0 Page 10
COMPANY CONFIDENTIAL
There is a separate interlock word for each queue. When a
queue is available, the corresponding interlock word has a value of
-1. When either the operating system or the port want to interlock
the queue, they must perform a non-interruptable
increment-store-test operation, such as an AOSE. If the
incremented location has a value of zero, then the queue has been
successfully interlocked and the process may now manipulate the
queues. If the incremented value is greater than zero, then the
queue is not available. The interlock word should not be set back
to zero. When the process is finished with the queues, the
interlock word must be set back to -1 (all ones). This marks the
queue as available. Both the port driver and the port microcode
are responsible for leaving the queues in a well defined state.
The PCB must be allocated starting on a four word boundary.
The format of the Port Control Block is illustrated below:
LCG NI Port Architecture Specification REV 8.0 Page 11
COMPANY CONFIDENTIAL
PCB Format OCT
+--------------------------------------------------------+
| Command Queue Interlock | 0
+--------------------------------------------------------+
| Command Queue FLINK | 1
+--------------------------------------------------------+
| Command Queue BLINK | 2
+--------------------------------------------------------+
| Reserved for Software | 3
+--------------------------------------------------------+
| Response Queue Interlock | 4
+--------------------------------------------------------+
| Response Queue FLINK | 5
+--------------------------------------------------------+
| Response Queue BLINK | 6
+--------------------------------------------------------+
| Reserved for software | 7
+--------------------------------------------------------+
| Unknown Protocol Type Free Queue Interlock | 10
+--------------------------------------------------------+
| Unknown Protocol Type Free Queue FLINK | 11
+--------------------------------------------------------+
| Unknown Protocol Type Free Queue BLINK | 12
+--------------------------------------------------------+
| Unknown Protocol Queue Entry Length | 13
+--------------------------------------------------------+
| Reserved for Software | 14
+--------------------------------------------------------+
| Protocol Type Table starting address | 15
+--------------------------------------------------------+
| Multi-cast Address Table starting address | 16
+--------------------------------------------------------+
| Reserved for Software | 17
+--------------------------------------------------------+
| Error Logout 0 | 20
+--------------------------------------------------------+
| Error Logout 1 | 21
+--------------------------------------------------------+
| EPT Channel Logout Word 1 Address | 22
+--------------------------------------------------------+
| EPT Channel Logout Word 1 Contents | 23
+--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 12
COMPANY CONFIDENTIAL
+--------------------------------------------------------+
| PCB Base Address | 24
+--------------------------------------------------------+
| PIA Assignment | 25
+--------------------------------------------------------+
| Reserved to Port | 26
+--------------------------------------------------------+
| Channel Command Word | 27
+--------------------------------------------------------+
| Read Counters Data Buffer Starting address | 30
+--------------------------------------------------------+
The Error Words (words 20,21) are written by the port when it
encounters fatal errors associated with Queue manipulation. This
error reporting strategy requires the port to write as much
information as possible directly into the host memory. This
approach requires the smallest subset of port hardware and
microcode to be working to report these errors.
The information in these words provides sufficient data for
the port driver to determine the type of error and where the error
occurred. When the error is detected, the port will write the
contents of the Error Words in the PCB, enter the Disabled State,
and generate a host interrupt.
The format of Error Word 0 is:
0 1 2 3 4 11 12 35
+-------+-------+-------+-----------------------+---------------+
| CMD | MBZ | RESP | MUST BE ZERO | FLINK ADDRESS |
+-------+-------+-------+-----------------------+---------------+
BITS NAME DESCRIPTION
==== ==== ===========
0 CMD Error occurred while reading a command
queue entry.
1-2 MBZ These bits will be zero
3 RESPONSE This bit is on if the error occurred
while the port was attempting to build a
response queue entry.
LCG NI Port Architecture Specification REV 8.0 Page 13
COMPANY CONFIDENTIAL
4-11 MBZ These bits will be zero.
12-35 FLINK ADR This is the address of the FLINK word of
the queue in question.
Error Word 1 contains the API function word that the port
processor used to access memory when the memory error occurred.
This word is written here in the same format as it should have
appeared on the EBUS. The format of this word is:
0 2 3 5 6 7 12 13 35
+------+------+---+----+----------------------------+
| Addr | Func | Q | 0 | Physical Address |
| Code | | | | |
+------+------+---+----+----------------------------+
Word 22 of the PCB is written by the port during
initialization time with the address of the EPT Channel Logout Word
1 which the port gets from the port driver software. Words 22 and
23 of the PCB are used by the port during Channel Error recovery.
Word 23 contains the Channel Logout Word 1 written by port on
any kind of channel error detected during or immediatly after, a
DMA transfer. The format of Error Word 3 is:
0 01 02 03 04 05-08 09 10 11 12 13 14 35
+-+---+----+---+---+-----+---+--+----+-----+----+--------------+
|1|MEM|-ADR|-WC|NXM| 0 |LXE|0 |LONG|SHORT|OVER| ADDR OF CURR |
| |PE | PE |=0 | | | | | WC | WC |RUN | CCW+1 |
+-+---+----+---+---+-----+---+--+----+-----+----+--------------+
BITS NAME DESCRIPTION
==== ==== ===========
01 MEM PE Memory Parity Error.
02 -ADR PE Not Address Parity Error.
03 -WC=0 Chan Word Count did not = 0 when
chan did a store to EPT.
04 NXM Chan ref non exist mem.
LCG NI Port Architecture Specification REV 8.0 Page 14
COMPANY CONFIDENTIAL
09 LXE Error detected after port term
transfer.
Chan aborts next transfer.
11 LONG WC Port comp Xfer, But word count in
CCW not reached.
12 SHORT WC Chan Xferred data spec by CCW, But
port still has data.
13 OVER RUN If dev read, Port sent data but chan
buff were full.
If dev write, Port req data but chan
buff were empty.
Word 24 of the PCB is the address of the first word of the
PCB; the NI20 has no other way of finding the PCB.
Word 27 is reserved for the Channel Command Word. The port
will write a CCW-style word here when it wishes to transfer data
over the KL10 CBus. The port driver is responsible for writing a
Channel Jump Word into the appropriate EPT location corresponding
to the RH20 backplane slot that the NI20 is installed in.
Word 25 is always reserved to the port microcode for its use;
the port driver should never write this location nor depend upon
its value.
Word 30 of the PCB is a pointer to the beginning of the Read
Counter Data Buffer. This address is supplied by the port driver
software at initialization.
When the NI20 is being initialized, the port driver must set
up the channel to transfer the contents of the PCB into the port.
This is done by setting up a CCW to transfer 3 words starting with
word 24 of the PCB from KL10 memory to the channel. The port will
start the channel and will read the contents of these locations.
This provides the port with the base of the PCB, and its PI
assignment.
It is important to realize that since the port will be using
the channel to transfer large blocks of data, the channel will be
writing logout information into the EPT. An error that the channel
discovers will be reported in the usual manner via the EPT.
LCG NI Port Architecture Specification REV 8.0 Page 15
COMPANY CONFIDENTIAL
6.3 States And Programming
6.3.1 Port States -
There are 4 defined states in which the port can be.
1. Uninitialized - The port is not running. This is the power up
state. The port enters this state after a power-on or a master
reset. The port may exit this state only if valid microcode is
loaded into the port and the port clocks are started.
2. Disabled - The port is running, but it is not accepting NI packets.
The port will process local port commands. This state can only be
entered from the uninitialized state by starting the port microcode
running and setting the Disable bit (Bit 30) in the CSR. The
microcode will put the port into this state and signal it by
setting Disable Complete (Bit 12) in the CSR. The Disabled state
is entered from the Enabled state through a command from the host
to enter this state or when the port microcode detects a
non-recoverable internal port error.
3. Enabled - The port is fully functional; it is processing commands
and NI packets. This is the normal state for the port. This state
can only be entered from the Disabled state via command from the
host (Bit 31 in CSR).
4. Halted - The port microsequencer is halted no port functionally is
availible. This state is only entered by either planned or non
planned CRAM parity error, (Bit 6 in the CSR), or by port hardware
detecting a MBUS error (Bit 7 in the CSR).
6.3.2 Command Queue -
The command queue is the basic communication structure for the
LCG NI. Through it, all commands are passed to the port interface.
A command consists of a queue entry, with a FLINK (Forward LINK),
pointing to the next command in the queue, if any, and a BLINK,
(Backward LINK) pointing to the previous command in the queue, if
any. From the OPCODE field of the command queue entry is obtained
what function is to be performed. The queue entry contains the
information needed to process the command. Commands are delinked
from the beginning of the queue by the port, and executed.
Commands are executed in the order in which they are placed in the
command queue. The driver places command entries to be executed on
the tail of the command queue. If the queue was previously empty
when this occurs, the driver writes the Command Queue Available
LCG NI Port Architecture Specification REV 8.0 Page 16
COMPANY CONFIDENTIAL
(CQA) bit in the CSR register. The length of the command entry is
inferred from its format, and the function being performed.
6.3.3 Unknown Protocol Type Free Queue -
This queue is a linked list of free queue entries to be used
to report to the driver all received packets which passed address
filtering, and which are addressed to a protocol type which is not
enabled in the Protocol Type Table. The driver links new free
entries onto the end of this queue as it obtains them. The port
delinks these entries when it must build a response, and cannot use
one of the enabled protocol type free queues.
The unknown protocol queue entry length word specifies, in
words, how long the entries on the queue are. This length included
the FLINK, BLINK, Reserved and Opcode words of the entry. These
different queues are provided to help insure that heavy traffic on
one protocol type will not disturb the availability of ready queue
entries for other protocol types. In addition, by having different
queues for different sorts of messages, all queue entries need not
be the maximum length for Ethernet messages; protocol types which
use only a limited size packet can allocate more entries of smaller
size, and yet run with other protocol types which require larger
messages.
It is recommended that queue entries for the Unknown Protocol
Type Free Queue be large enough to hold the largest legal Ethernet
packet. This is 388 (decimal) words, assuming industry compatible
is the packing mode. This figure includes the flink, blink, etc.
of the send datagram non-BSD command format.
6.3.4 Response Queue -
The Response Queue is used by the port to submit to the driver
packets which were accepted by the packet address filter over the
NI wire, or which resulted from a completed command, or an error
packet. The port links such packets onto the end of the queue. If
the queue was previously empty when this occurs, an interrupt is
submitted to the host, to inform it of the presence of a new
response. This queue is accessed according to the interlocked
queue protocol for the KL10.
LCG NI Port Architecture Specification REV 8.0 Page 17
COMPANY CONFIDENTIAL
6.3.5 Protocol Type Table Starting Address -
This word points to the beginning of the protocol type table.
This table, described elsewhere, lists the protocol types to be
accepted, and pointers to appropriate free queue headers, from
which free entries to hold received responses for that protocol
type. The PTT must be allocated beginning on a four word boundary.
The protocol types listed in this table do not come into effect
until after the execution of a Load PTT command. Once this table
has been allocated and its address specified in the PCB the
location of the table cannot be changed.
6.3.6 Multi-Cast Address Table Starting Address -
This word points to the beginning of the multi-cast address
table. This table lists the multi-cast addresses to which the port
is to respond. Multi cast addresses on the NI wire that are not
present in this table will be ignored. The addresses in this table
come into effect only after the execution of a Load MCAT command.
This table must be allocated beginning on a four word boundary.
Once this table has been allocated and its address specified in the
PCB, its location cannot be changed.
6.4 Queue Structures
Queued structures comprise the basic communication between the
host driver and the NI port. This section describes these memory
structures.
6.4.1 Queue Headers -
The format ofthe queue header is illustrated below:
+--------------------------------------------------------+
| Queue Interlock Word |
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Queue Entry Length |
+--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 18
COMPANY CONFIDENTIAL
Queue Entry Length
| The Queue Entry Length specifies the length, in bytes, of the queue
| entries on the queue. This queue length included the FLINK, BLINK,
| reserved, and opcode words. All entries on a queue are of the same
| length.
Reserved For Software
The reserved word may be used by the driver program for
whatever purpose it wishes. The independent queue header must be
allocated on a four word boundary. Independent queue headers are
subject to the same rules for interlocking that the PCB queues
enjoy.
6.4.2 Queue Entries -
Queue entries are the structures out of which commands and
responses are built. They possess forward and backward links, to
enable the construction of a doubly-linked list. The format of a
queue entry is given below:
+--------------------------------------------------------+
| FLINK |
+--------------------------------------------------------+
| BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| Operation Code (Entry type) |
+--------------------------------------------------------+
| Queue Data 0 |
+--------------------------------------------------------+
| Queue Data 1 |
+--------------------------------------------------------+
.
.
.
+--------------------------------------------------------+
| Queue Data N |
+--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 19
COMPANY CONFIDENTIAL
The FLINK points to the next entry of the queue (Forward
LINK). BLINK, on the other hand, points to the previous queue
entry. If there is no next entry, then the FLINK points back to
the queue header FLINK. If there is no previous entry, the BLINK
points back to the FLINK word of the queue header.
The word reserved for software will never be altered or
examined by the LCG NI port. The Operation Code specifies the type
of the entry; i.e., Send Datagram, Load MCAT, etc. Words
following the Operation code are type dependent.
6.4.3 Protocol Type Table -
The Protocol Type Table specifies a set of protocol types,
with their associated free queue pointers that are considered
enabled by the port. When a message which passes the received
address filter is detected, this table will be examined. Thus, for
a multi-cast packet to be received into a protocol type queue
(either known or unknown) its destination address must be enabled
in the multi-cast address table. If the protocol type of a
received packet matches an entry in the PTT, then the associated
free queue of that PROTOCOL TYPE entry is used to supply the free
queue entry used to store the incoming packet. A protocol type is
not considered unless the corresponding enable bit (sign bit) is
on. It is required to have the protocols arranged in the table in
ascending numerical order. This allows the microcode to stop
searching the table after the first time that the protocol type of
the incoming packet is less than an examined entry in the protocol
type table.
The number of protocol types allowed for a particular version
of the NI microcode is specified in the NI read station
information. The port driver must read this number in order to
discover how many entries are available for both MCAT entries, and
PTT entries. The Protocol Type Table must be allocated beginning
on a four word boundary. The table must be built with the number
of entries specified in the NI read station information, even if
some of the entries are not enabled. Listed below is the general
format of the Protocol Type Table:
LCG NI Port Architecture Specification REV 8.0 Page 20
COMPANY CONFIDENTIAL
Protocol Type Table
OCT
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 0
| Enable | MBZ | Protocol Type value 0 | |
+--------------------------------------------------------+
| FREEQ 0 queue header address | 1
+--------------------------------------------------------+
| Reserved for Software | 2
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 3
| Enable | MBZ | Protocol Type value 1 | |
+--------------------------------------------------------+
| FREEQ 1 queue header address | 4
+--------------------------------------------------------+
| Reserved for Software | 5
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 6
| Enable | MBZ | Protocol Type value 2 | |
+--------------------------------------------------------+
| FREEQ 2 queue header address | 7
+--------------------------------------------------------+
| Reserved for Software | 10
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 11
| Enable | MBZ | Protocol Type value 3 | |
+--------------------------------------------------------+
| FREEQ 3 queue header address | 12
+--------------------------------------------------------+
| Reserved for Software | 13
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 14
| Enable | MBZ | Protocol Type value 4 | |
+--------------------------------------------------------+
| FREEQ 4 queue header address | 15
+--------------------------------------------------------+
| Reserved for Software | 16
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | 17
| Enable | MBZ | Protocol Type value 5 | |
+--------------------------------------------------------+
| FREEQ 5 queue header address | 20
+--------------------------------------------------------+
| Reserved for Software | 21
---+--------------------------------------------------------+---
LCG NI Port Architecture Specification REV 8.0 Page 21
COMPANY CONFIDENTIAL
. .
. .
. .
---+--------------------------------------------------------+---
| 0 |<1---------------15>| <16-31> | | M-2
| Enable | MBZ | Protocol Type value N | |
+--------------------------------------------------------+
| FREEQ N queue header address | M-1
+--------------------------------------------------------+
| Reserved for Software | M
---+--------------------------------------------------------+---
The LCG NI caches the PTT internally when the LOAD PTT command is
issued. The driver is free to alter the PTT whenever the LOAD PTT
command is not pending. The protocol values within the table must
be assembled in ascending numerical order. Only the binary value
of the protocol type itself is considered in the sorting order.
Non enabled protocol types are ignored.
If a protocol type is received which is not in this table, the
message will be placed onto the Unknown Protocol Type queue,
anchored in the PCB.
If the port is enabled without having loaded the PTT after
initialization, all protocol types are disabled, except for those
MOP protocol types which are implied active by the setting of the
RMOP mode bit.
Enable
This bit, when set, indicates that the associated protocol
type is valid, and should be considered when the PTT is cached.
Protocol Type Value
This variable specifies the value of protocol type that should
be placed on the associated queue when a message of the protocol
type is received.
Note that the free queue indirection scheme such as the one
discussed above allows the sharing of free queue lists between
protocol types.
LCG NI Port Architecture Specification REV 8.0 Page 22
COMPANY CONFIDENTIAL
Queue Header Address
This word contains the physical address of the FLINK word of
the associated free standing queue header block.
6.4.4 Buffer Descriptors -
At times it is desirable to have different portions of a
datagram be in different packing modes, or to allow different
portions of a datagram to be built at different times without
incurring substantial overhead in copying the datagram from buffer
to buffer. An example of this is when lower layers of network
software wish to prepend data to a user's data in order to
facilitate flow control, routing, session control, etc. This
feature is accomplished through the mechanism of buffers.
The use of buffers for a commands is activated by setting the
BSD bit of the flags byte.
A buffer consists of a list of segments of memory, each
segment being physically contiguous, and resident within physical
memory. Different segments of a buffer are not assumed contiguous,
and may lie anywhere within the physical address space of the host.
It is assumed in normal use that different segments of a buffer are
unique (i.e., they do not overlap) within a host, and that each
segment is in only one packing mode. A buffer is described by a
list of Buffer Segment Descriptors (BSDs).
Each buffer segment descriptor describes a single contiguous
piece of a buffer. Each descriptor is a four word block, allocated
on a four word boundary, and built by the driver in physical host
memory. In each of these blocks is a pointer to the next
descriptor block (if any), a pointer to the segment of the buffer
so described, and a field indicating what packing mode the segment
is in. In addition, within each block is a field giving the size
of the buffer segment in bytes.
A buffer is referenced by giving the physical address of the
first word of the first BSD in the chain of BSDs. This address is
called out in the SEND DATAGRAM command packet, when the flags byte
of that command indicates that buffer descriptors are in use. The
format of the SEND DATAGRAM command is effectd by the setting of
this flags bit.
LCG NI Port Architecture Specification REV 8.0 Page 23
COMPANY CONFIDENTIAL
Note that this is unlike the CI20, wherein buffers are called
out by name and a key, and are referenced by indexing within a
table of buffer header blocks in order to obtain the address of the
chain of buffer segment descriptors. The BSD format is specified
below:
|
| (buffer segment descriptor)
| +--------------------------------------------------------+
| | | <6> | | <12-35> |
| 0 | MBZ | Packing Mode | MBZ | Segment Base address |
| +--------------------------------------------------------+
| | | <12-35> |
| 1 | MBZ | Next BSD address |>---+
| +--------------------------------------------------------+ |
| | |<20----------35>| |
| 2 | MBZ | Segment Length | |
| +--------------------------------------------------------+ |
| 3 | Reserved for use by software | |
| +--------------------------------------------------------+ |
| |
| |
| |
| (buffer segment descriptor) |
| +--------------------------------------------------------+ |
| | | <6> | | <12-35> | |
| 0 | MBZ | Packing Mode | MBZ | Segment Base address |<---+
| +--------------------------------------------------------+
| | | <12-35> |
| 1 | MBZ | Next BSD address |
| +--------------------------------------------------------+
| | |<20----------35>|
| 2 | MBZ | Segment Length |
| +--------------------------------------------------------+
| 3 | Reserved for use by software |
| +--------------------------------------------------------+
|
| Packing Mode 0<6>
| 0 = industry compatible mode
| 1 = This mode is reserved for future DEC use.
Segment Base Address 0<12-35>
This field gives the physical address of the beginning of the
buffer segment. The buffer segment must begin on a whole word
boundary.
LCG NI Port Architecture Specification REV 8.0 Page 24
COMPANY CONFIDENTIAL
Next BSD address 1<12-35>
The next BSD address points to the first word of the next
buffer segment descriptor in the chain. If the next BSD field is
zero, then there is no next segment descriptor.
Segment Length 2<20-35>
This field gives the length in bytes of the buffer segment
pointed to. Note that the total legal length of the text portion
of an Ethernet packet is 1500 bytes.
It is allowed that BSDs may be built in the queue entries on
the command queues. Indeed, it is assumed that this is the
standard use. BSDs must be allocated on a four word boundary.
6.5 Multi-cast Address Table
The MCAT is the Multi-Cast address table. This table
specifies which multi-cast NI addresses are to be accepted by the
LCG NI address filter. Note that an address is not considered for
comparison unless the associated enable bit is on.
The MCAT is cached internally when the Load MCAT command is
issued. The port driver should refrain from altering the MCAT when
such a load command is pending, that is, after the command is
linked onto the command queue and before the command is linked
either onto the response queue or the unknown protocol type free
queue. The port will not examine the MCAT until such a command is
issued. The port will never change data in the MCAT, although it
will read all entries whenever the load command is issued.
In ALL MULTI-CAST mode, all received packets with the
MULTI-CAST bit set in the destination address will pass received
packet address filtering. In order to enable ALL MULTI-CAST mode,
the driver must set the AMC bit in the write NI Station Address
command for the KL10. The following is the arrangement of a pair
of words that specify one multi-cast address. Byte 0 is the first
byte received or transmitted over the NI wire. Byte 5 is the last
| byte received or transmitted. Therefore, bit 7 of the first word
| of the pair is the first bit on the wire, and is thus the MULTICAST
| bit.
LCG NI Port Architecture Specification REV 8.0 Page 25
COMPANY CONFIDENTIAL
|
| Binary Order Of Multi-cast Address
|
| 0.........7 8.........15 16........23 24........31 32-35
| +--------------------------------------------------------+
| | Byte 0 | Byte 1 | Byte 2 | Byte 3 | MBZ | Word 0
| +--------------------------------------------------------+
| ^
| multicast bit
|
| 0..........7 8.........15 16........23 24...........34 35
| +--------------------------------------------------------+
| | Byte 4 | Byte 5 | MBZ |ENA| Word 1
| +--------------------------------------------------------+
|
|
The following illustrates the format of the MCAT. Entries that
have the enable bit off when the MCA is cached are not used in
address comparison. Each MCAT entry conforms to the binary order
of NI addresses format shown above.
LCG NI Port Architecture Specification REV 8.0 Page 26
COMPANY CONFIDENTIAL
|
| MCAT Format
|
| < 0. . . . . . . . . . . . . . . . . . . .31> <32:34><35>
| +--------------------------------------------------------+
| | Multi-cast address 0, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address 0, Word 1 |ENA|
| +--------------------------------------------------------+
| | Multi-cast address 1, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address 1, Word 1 |ENA|
| +--------------------------------------------------------+
| | Multi-cast address 2, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address 2, Word 1 |ENA|
| +--------------------------------------------------------+
| | Multi-cast address 3, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address 3, Word 1 |ENA|
| +--------------------------------------------------------+
| | Multi-cast address 4, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address 4, Word 1 |ENA|
| +--------------------------------------------------------+
| .
| .
| .
| +--------------------------------------------------------+
| | Multi-cast address N-1, word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address N-1ord 1 |ENA|
| +--------------------------------------------------------+
| | Multi-cast address N, Word 0 | MBZ |
| +--------------------------------------------------------+
| | Multi-cast address N, Word 1 |ENA|
| +--------------------------------------------------------+
|
The table is always considered full (i.e., the port will always
read the entire table), although word pairs without the enable bit
on are not considered. The MCAT must be allocated beginning on a
four word block. The number of MCAT entries allowed is specified
by the NI Configuration port register.
Note that the high order bit of word 1 of each MCAT entry is
an enable bit. This enable bit specifies whether the two word pair
is to be treated as a valid multi-cast address or not. The bit
must be set for the address to be considered valid. The enable bit
LCG NI Port Architecture Specification REV 8.0 Page 27
COMPANY CONFIDENTIAL
is not considered when sorting the addresses within the table in
order to present them in numerical order.
If the port is enabled after initialization without loading
the MCAT, no multi-cast addresses are enabled. The only packets
that will pass the receive address filter will be those that match
the physical address of the port, and BROADCAST (destination
address of all ones) packets.
6.6 Received Packet Filtering
For a packet to be processed by the port it must pass the
receive address filter. This filtering occurs according to mode
for every packet received over the NI wire. Packets which do not
pass the address filter are discarded without increment of a
Datagram Discarded event counter; by definition packets which fail
to pass the address filter are not addressed to the receiving port.
Received packet filetering only occurs for packets intercepted
by the NI link while the microcode is in the ENABLED state.
If a received packet has an address of BROADCAST (destination
field all ones,) then the packet passes the receive address filter,
and is processed.
If PROMISCUOUS mode is set, all packets received by the port
are considered addressed to it, and are processed. Otherwise...
If ALL MULTI-CAST mode is set, all received packets with the
multi-cast address bit in the destination address field set will
pass the address filter. This mode is a promiscuous mode for
multi-cast packets only. In addition under this mode, if a
received packet's destination matches the physical address of the
port, the packet passes the receive address filter. Otherwise...
A packet passes the filter if its destination address matches
the port physical address, or if the destination address is a
multi-cast address, and matches a multi-cast address enabled in the
multi-cast address table.
LCG NI Port Architecture Specification REV 8.0 Page 28
COMPANY CONFIDENTIAL
6.7 Port Commands And Responses
Commands and Responses are the packets that the driver and the
port send to each other in order to communicate. A Command is a
request from the port driver for the port to provide some service.
The placing of a command on the command queue triggers processing
in the NI port. "Placing a command on the queue" includes setting
the command queue available bit in the port status register if the
command is linked onto an empty command queue.
A response is a packet from the port to the driver informing
it of an event. This event may be the reception of an incoming
packet, the completion of a command, or an error which occurred
while processing a command.
6.7.1 Command Processing -
When commands are present upon the command queue, the port
microcode will delink the first command on the command queue,
process the command, and build a response if either an error
occurred or if the port driver specifically requested a response
packet by setting the Response bit (R bit) in the FLAGS field.
Command processing commences when the port discovers it has a
packet linked on the command queue (see PCB definition.) The port
always checks after processing a command to see if another exists
on the command queue. If not, the port goes idle. The port wakes
up again after the NI driver has placed a command upon the command
queue, and writes the Command Queue Available bit in the CSR
Register to indicate that a new command is available.
6.7.2 Responses -
Responses to commands are built if either an error occurred
while processing a command, or if the RESP bit is set in the FLAGS
field of the original command packet. If a response is not built,
then the command entry is linked onto the end of one of the various
free queues, depending upon the protocol type of the message, if
the command is a Send Datagram, and onto the Unknown Protocol Type
free queue if the command does not generate a packet.
When a response is built, it will be linked onto the end of
the Response queue anchored in the PCB. The driver is to remove
these entries by delinking them from the head of the queue, and
LCG NI Port Architecture Specification REV 8.0 Page 29
COMPANY CONFIDENTIAL
processing them. If the response queue is empty when a new entry
is added by the port, then a host interrupt is submitted, if
interrupts are enabled.
6.7.3 Remote Responses -
Packets which are received over the NI wire also generate
response packets, which are linked onto the end of the response
queue, as above. Received datagrams are marked as such by an
opcode of 5. There is no BSD type processing for incoming
datagrams.
Remote responses are built in queue entries gotten from one or
the other of the free queues. If the Protocol Type of the received
datagram is found as an enabled entry in the Protocol Type Table,
then the free queue entry is obtained from the free entry list
pointed to by the queue header pointer of the PTT entry. If the
Protocol Type is not found in the PTT, then the free entry is
obtained from the Unknown Protocol Type free queue, anchored in the
PCB. If the queue examined in order to get the free entry is
empty, then the received datagram is DISCARDED, and the Datagram
Discarded event counter for that queue is incremented.
Note that processing of a received packet takes priority over
processing a command packet. Processing of both command packets
and received packets are atomic operations, and will not interrupt
each other.
6.7.4 Self Directed Commands -
It is specifically allowed for a datagram transmitted to be
destined for the transmitting node. The design of the NI Adapter
(the NI physical channel), however, shares the CRC
generator/checker between the receive and transmit circuits. Thus,
since the CRC circuits must be used to check the incoming packet,
packets destined for the transmitting node must supply a CRC code
that will be transmitted in place of the internally generated CRC.
This driver CRC is appended onto the end of the normal data packet,
and the ICRC (Included CRC) bit of the packet FLAGS field is set.
The text length does not include the appended CRC, which must be
generated according the algorithm specified in the Ethernet
bluebook specification. This CRC is four bytes in length.
LCG NI Port Architecture Specification REV 8.0 Page 30
COMPANY CONFIDENTIAL
6.7.5 Port Functions -
The following functions are available to the port driver:
1. SNDDG - Send Datagram - Causes a NI datagram to be built and
transmitted as an Ethernet packet.
2. LDPTT - Load Protocol Type Table - Causes the Protocol Type
Table (PTT) to be internally cached by the port.
3. LDMCAT - Load Multi-cast Address Table - Causes the Multi-cast
Address Table (MCAT) to be internally cached by the port.
4. RCCNT - Read and Clear Counters - Causes the event counters
kept by the port microcode to be cleared according to the FLAGS
bit CLRCTR supplied in the command packet. If the Response
(RESP) bit in the FLAGS field is set, a response is generated
containing the event counters kept by the port microcode. This
command is a performance monitoring and diagnostic feature.
5. WRTPLI - Write PLI- Causes a PLI write with the specified
function and data byte. This command is a diagnostic feature.
6. RDPLI - Read PLI - Causes a PLI read with the specified
function. If a response is built for this command, the data
byte read from the PLI is returned. This command is a
diagnostic feature.
7. RDNSA - Read NI Station Address - Reads the NI station address
from the NI link physical address ROMs. This command also
reports the state of several link mode bits.
8. WRTNSA - Write NI Station Address - Writes the NI station into
the NI link address RAMs. Also sets the state of several link
mode bits.
6.8 Error Handling
The port microcode is capable of retrying many operations that
fail; this allows a large part of the error recovery to be built
into the port microcode, and removed from the port driver. When
the port encounters a fatal, non-recoverable error, the port will
stop processing any more commands.
LCG NI Port Architecture Specification REV 8.0 Page 31
COMPANY CONFIDENTIAL
The error handling procedures for the NI20 are specified in
the KLNI Error Specification, written by Joe Holewa.
6.8.1 Port Hardware Errors -
In addition, there are a class of more severe errors which
cause the port to cease operations immediately, and to exit to a
special microcode location that has a CRAM parity error. The
console will notice the error location, and will re-initialize the
port, if possible. The errors that result in this action are
listed below:
1. Loc. 7750 -INTERNAL.ERROR -internal consistancy error
2. Loc. 7751 -FAIL.SELFTEST -start up self test failed
3. Loc. 7752 -FAIL.EBUS -ebus parity error
4. Loc. 7753 -FAIL.EBUS.QUE -ebus parity error during queue
operation
5. Loc. 7754 -FAIL.PLIPE -unrecoverable PLI parity error
6. Loc. 7755 -FAIL.CBUSPE -unrecoverable cbus parity error
7. Loc. 7756 -FAIL.PARPRE -unrecoverable formatter parity
predictor error
8. Loc. 7757 -CBUS.REQ.TIMEOUT -cbus request timeout
9. Loc. 7760 -EBUS.REQ.TIMEOUT -ebus request timeout
10. Loc. 7761 -GRANT.CSR.TIMEOUT -csr grant timeout
11. Loc. 7762 -CHANNEL.ERROR -channel error
12. Loc. 7763 -SPUR.CHAN.ERROR -spurrious channel error
13. Loc. 7764 -FAIL.XMIT.AT -spurrious transmitter attention
14. Loc. 7765 -USED.BUFFER.PE -used buffer list parity error
15. Loc. 7766 -FREE.BUFFER.PE -free buffer list parity error
LCG NI Port Architecture Specification REV 8.0 Page 32
COMPANY CONFIDENTIAL
16. Loc. 7767 -XMIT.BUFFER.PE -unrecoverable transmit buffer
parity error
6.8.2 Error Events -
Various errors may occur which do not necessarily imply a
hardware malfunction. These errors include excessive collisions,
CRC errors, Framing errors, etc. The occurrence of these errors
terminates the packet transmission or reception in progress when
the error occurs, but do not effect the processing of other
commands or packets being received. Errors of this sort are
reported by creating a response packet for the transfer involved,
and setting the STATUS field accordingly. A list of possible error
conditions is provided below:
1. Unrecognized command - Packet has invalid operation code.
2. Buffer length violation - BSD has inconsistent buffer length
information.
3. CRC error - Received packet has CRC error.
4. Framing error - Received data not byte aligned.
5. Packet too long - Packet length exceeds maximum Ethernet packet
length.
6. Excessive Collisions - Packet collided 16 times in succession.
7. Carrier Lost - Carrier lost before end of packet detected.
8. Collision detect check - Collision detect heartbeat failed to
assert.
6.8.3 Datagram Discarded -
Under certain conditions, received datagrams may be discarded
due to insufficient buffer space. This is a characteristic of the
datagram class service that is offered by the NI port. To wit, if
a received datagram is occupying buffer space in the NIA, and
obtaining a free queue entry from some free queue fails, then the
datagram involved is discarded, and the Datagrams Discarded counter
LCG NI Port Architecture Specification REV 8.0 Page 33
COMPANY CONFIDENTIAL
for the appropriate free queue is incremented. This occurs even if
buffer space in the link is still available. The rationale for
this is that 1) other packets being received may be able to be
stored since the free queue error condition is protocol type
dependent, and 2) if the link fills up, datagrams will be discarded
without increment of a Datagrams Discarded event counter. No other
error indication or response is made. It is up to higher levels of
the network to detect and recover from such errors.
If the port is addressed by a burst of packets such that the
internal buffer space in the NI physical channel is exhausted,
datagrams may be discarded without increment of the Datagrams
Discarded counter. The buffer space allowed in the physical
channel (NI link) is sufficient to make this a low probability
event. The NIA has 16K bytes of buffering organized as 32 X 512
byte buffers. This is sufficient to store thirty two (32) minimum
sized packets and ten (10) maximum sized packets.
6.9 Event Counters
In order to provide for performance measurement, and
diagnostic purposes, a number of event counters are provided by the
port. These record the occurrence of certain events, and can be
read and cleared upon command by the driver program. These event
counters do not necessarily record, or imply, abnormal errors,
although high counting rates for some of them may indeed point to a
hardware or software failure. A list of the applicable events is
given below:
1. Received a byte [1]
2. Transmited a byte [1]
3. Received a frame
4. Transmited a frame
5. Received a multi-cast byte [1]
6. Received a multi-cast frame
7. Transmited a frame that was initially defered
8. Transmited a frame with a single collision
LCG NI Port Architecture Specification REV 8.0 Page 34
COMPANY CONFIDENTIAL
9. Transmited a frame with multiple collisions
10. Failed to successfully transmit a frame
11. Send failure reason bit mask [2]
12. Transmited a frame with a late collision
13. Collision detect check failed to assert
14. Failed to successfully receive a frame
15. Received failure reason bit mask [2]
16. Discarded a datagram for Unknown Protocol Type free queue
17. Discarded a datagram for Protocol Type entry 1 free queue
18. Discarded a datagram for Protocol Type entry 2 free queue
19. Discarded a datagram for Protocol Type entry 3 free queue
20. Discarded a datagram for Protocol Type entry 4 free queue
21. Discarded a datagram for Protocol Type entry 5 free queue
22. Discarded a datagram for Protocol Type entry 6 free queue
23. Discarded a datagram for Protocol Type entry 7 free queue
24. Discarded a datagram for Protocol Type entry 8 free queue
25. Discarded a datagram for Protocol Type entry 9 free queue
26. Discarded a datagram for Protocol Type entry 10 free queue
27. Discarded a datagram for Protocol Type entry 11 free queue
28. Discarded a datagram for Protocol Type entry 12 free queue
29. Discarded a datagram for Protocol Type entry 13 free queue
30. Discarded a datagram for Protocol Type entry 14 free queue
31. Discarded a datagram for Protocol Type entry 15 free queue
LCG NI Port Architecture Specification REV 8.0 Page 35
COMPANY CONFIDENTIAL
32. Discarded a datagram for Protocol Type entry 16 free queue
[1] Although this counter is indicated as counting when a byte
is transfered, in the interest of efficiency the total of bytes
transfered in a packet transmit or receive is added to the
appropriate counter after the transfer is complete. Listing these
event counters in the fashion indicated is a good abstraction.
[2] This bit mask provides an indication of which errors have
occured, but does not indicate how many of which errors have
occured. The bit mask is defined in the section describing the
Read Counters command.
The Read and Clear Performance Counters command reads the
values of these counters and returns them in a response packet.
6.10 MOP Message Handling
It is required by the Network Managment specification that
each NI node handle certain Maintenance Operation Protocol
messages, in particular, Request ID (REQID), Loopback (LPBK), and
Read Counters (RDCNT.) In addition, the Ethernet blue book
specifies these client layer protocols. Due to microcode space
considerations, these features are not implemented in the NI20 port
microcode.
6.11 Broadcast Of System ID
It is required by the NI product architecture for each NI node
to periodically transmit a system ID message on the system
configuration multicast address. The port will not perform this
function. It is the responsibility of the port driver and
operating system to provide this feature.
7.0 COMMAND SPECIFICATION
The following sections discuss the format of the various
commands and responses that the LCG NI port recognizes, and can
produce.
LCG NI Port Architecture Specification REV 8.0 Page 36
COMPANY CONFIDENTIAL
7.1 FLAGS Field
The format of the FLAGS field is show below: Note that there
are two formats; one for the Send Datagram command and response
(and the Datagram Received response,) and one for all other
commands and responses.
Send Datagram
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Pack | ICRC | PAD | RSVD | BSD | RSVD | RSVD | Resp |
+-------+-------+-------+-------+-------+-------+-------+-------+
Not Send Datagram
+-------+-------+-------+-------+-------+-------+-------+-------+
| RSVD | RSVD | RSVD | RSVD | RSVD | RSVD |CLRCTR | Resp |
+-------+-------+-------+-------+-------+-------+-------+-------+
Pack
| 0 = industry compatible mode
| 1 = This mode is reserved for future DEC use.
BSD
Buffer Segment Descriptor - If this bit is 1, the datagram is
using the BSD format described under the Send Datagram command. If
the bit is 0, the datagram is in 'immediate' mode; that is, the
data to be transmitted follows the destination address in the queue
entries.
ICRC
When set, the port driver has appended a four character CRC at
the end of the datagram. This CRC is to be used instead of the
internally generated CRC. This feature must be used in the
transmission of self-directed datagrams. The length fields in the
command packets do NOT reflect the addition of the four extra
characters.
LCG NI Port Architecture Specification REV 8.0 Page 37
COMPANY CONFIDENTIAL
PAD
When set, the port will pad packets less than the Ethernet
minimum size by appending bytes of zeros to the end of the packet.
In addition, two bytes indicating the valid data length will be
prepended to the text data. These length bytes are transmitted low
order byte first, and indicate the number of actual text bytes (not
including padding) that occur within the packet. The two length
bytes are always transmitted when padding is enabled, regardless of
whether padding was necessary for a particular packet transmitted.
When clear, the port does not do such padding. If a packet is
padded, it will be padded with zeros. If a packet is presented to
the port without this bit set, and it is less than 46 bytes, an
error response for a "runt" packet is generated. Packets presented
that are larger than the maximum Ethernet packet size always cause
a length error, and generate an error response packet.
Resp
Response - When this bit is 1, the port will always build a
response after processing the command.
CLRCTR
This field is valid only for the Read Counters command. If
this bit is set, all the counters will be cleared after their
values are reported in the response packet for this command.
7.2 Status Field
The following field is used by the port to report the status
of a completed command. This field appears in the command opcode
word of the queue entry. When valid, this field indicates the
logging of an exception event.
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| spare | Send/ | Error Type | Error |
| |Receive| | | | | | |
+-------+-------+-------+-------+-------+-------+-------+-------+
LCG NI Port Architecture Specification REV 8.0 Page 38
COMPANY CONFIDENTIAL
Send / Receive
When this bit is zero, an error occurred on receive; receive
failed. When this bit is one, an error occurred on transmit;
transmission failed.
Error Type
This field indicates the error event being logged. The field
is set according to the following table:
Bit value Event type
(octal)
00 Excessive collisions [2]
01 Carrier check failed (carrier lost) [2]
02 Collision detect check failed
03 Short circuit [4]
04 Open circuit [4]
05 Frame too long
06 Remote failure to defer (late collision)
07 Block check error (CRC error)
10 Framing error
11 Data overrun (NIA buffer space exhausted)
12 Unrecognized protocol type
13 Frame too short [3]
|
| 27 Spurious Channel error
| 30 Channel error wc not eql zero
| 31 Queue Length violation [5]
| 32 Illegal PLI function
| 33 Unrecognized command
| 34 Buffer length violation [1]
| 35 Rsvd
| 36 Transmit buffer parity error
| 37 Internal error
| [1] This error means that the length information in the BSD was
| inconsistent. One such case is when the length field of the
| transmitted datagram does not match the total length of the BSDs to
| be transmitted.
[2] When this event is being logged, bits 26-35 of the opcode
word in the queue entry become the TDR reference number obtained
from the NIA when the error occurred. This indicates the time, in
100 nsec tics, from the time the transmission started until the
error event was detected by the NIA hardware.
LCG NI Port Architecture Specification REV 8.0 Page 39
COMPANY CONFIDENTIAL
[3] This error occurs only when padding of the transmitted
frame is disabled, and the frame length is smaller than the
smallest legal Ethernet frame size of 46 data bytes (64 bytes
including all physical channel protocol.) No indication is given if
the frame size would be runt, and padding is enabled. In that
case, the frame is padded as noted in the description of the PAD
flag.
[4] These errors are not detectable using the NIA module.
These error bits will never be set. They are included to conform
with the Network Management functional specification.
|
| [5] This error means that host memory free space for this
| frame was exhausted while there was data remianing in the NIA
| receive buffer.
|
|
Error
When this bit is zero, the status field has no meaning; and
Must Be Zero. When this bit is one, the status field is reporting
an error event; the above definition of the error type fields, and
of the direction field comes into effect.
7.3 Send Datagram
Send Datagram causes an NI datagram to be built and sent to
the destination port address.
7.3.1 SNDDG Command -
The queue entry must be allocated on a four word boundary.
Data bytes are always transmitted from left to right. That is, for
a given word, the data in bits 0-7 is transmitted first, the data
in bits 8-15 is transmitted second, the data in bits 16-24 is
transmitted third, etc. This left to right format is the norm for
all data transmitted.
Note that chains of BSDs and text length fields must always
describe full bytes. It is illegal for a buffer to terminate in
the middle of a byte. The result if this restriction is violated
is undefined; the system may fail.
LCG NI Port Architecture Specification REV 8.0 Page 40
COMPANY CONFIDENTIAL
A byte may be split accross two BSDs if both are in high
density mode, and the first BSD terminates in a word boundary which
is the end of the first word of a two word pair.
The format of this command as a command queue entry is
specified below:
SNDDG Command Format (BSDs)
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| <0-19> | <20-35> |
| MBZ | Length of text data |
+--------------------------------------------------------+
| | <16-31> | |
| MBZ | Protocol Type Value | |
+--------------------------------------------------------+
| FREEQ header address |
+--------------------------------------------------------+
| High order Destination |
+--------------------------------------------------------+
| Low order Destination |
+--------------------------------------------------------+
| BSD base address |
+--------------------------------------------------------+
.
.
.
+--------------------------------------------------------+
| *Queue End |
+--------------------------------------------------------+
Note that although the BSD may be allocated within the queue
entry that the BSD header must still be allocated on a four word
boundary. From the diagram it is clear that the BSD base address
is not allocated at the end of a four word block. Thus, the driver
cannot start the BSD until the first four word boundary following
the BSD base address pointer. Also remember that this BSD base
pointer is a physical address.
LCG NI Port Architecture Specification REV 8.0 Page 41
COMPANY CONFIDENTIAL
SNDDG Command Format (non-BSD)
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| <0-19> | <20-35> |
| MBZ | Length of text data |
+--------------------------------------------------------+
| | <16-31> | |
| MBZ | Protocol Type Value | |
+--------------------------------------------------------+
| FREEQ header address |
+--------------------------------------------------------+
| High order Destination |
+--------------------------------------------------------+
| Low order Destination |
+--------------------------------------------------------+
| Text Data 0 |
+--------------------------------------------------------+
| Text Data 1 |
+--------------------------------------------------------+
| Text Data 2 |
+--------------------------------------------------------+
.
.
.
+--------------------------------------------------------+
| Text Data N-1 |
+--------------------------------------------------------+
| Text Data N |
+--------------------------------------------------------+
| *Queue End |
+--------------------------------------------------------+
When this command is issued, the port will build and send a
datagram to the port designated.
LCG NI Port Architecture Specification REV 8.0 Page 42
COMPANY CONFIDENTIAL
Opcode
For a Send Datagram command, the opcode field is a 1.
High / Low Destination
| These two words specify the destination address of the packet.
| Their format is described below: Note that byte 0 is the first
| byte transmitted on the NI, and byte 5 is the last byte
| transmitted. Bit 7 of the high order destination is therefore the
| Multicast address bit.
|
| Destination Address Format
|
| 0.........7 8.........15 16........23 24........31 32-35
| +--------------------------------------------------------+
| | Byte 0 | Byte 1 | Byte 2 | Byte 3 | MBZ | Word 0
| +--------------------------------------------------------+
| ^
| multicast bit
|
| 0..........7 8.........15 16.............................35
| +--------------------------------------------------------+
| | Byte 4 | Byte 5 | MBZ | Word 1
| +--------------------------------------------------------+
7.3.2 DGSNT Response -
A response to the SNDDG command will be built if 1) an error
occurred during processing of the command, or 2) the Resp bit of
the FLAGS field of the original datagram packet was set. The
format of the returned packet is shown below. Note that the format
of the command follows the format of the original response; i.e.,
if the BSD bit of the FLAGS field was on, then the response will be
in BSD format as well. The format will be as follows for a Non-BSD
packet:
LCG NI Port Architecture Specification REV 8.0 Page 43
COMPANY CONFIDENTIAL
DGSNT Response Format (Non-BSD)
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| <0-19> | <20-35> |
| MBZ | Length of text data |
+--------------------------------------------------------+
| | <16-31> | |
| MBZ | Protocol Type Value | |
+--------------------------------------------------------+
| FREEQ header address |
+--------------------------------------------------------+
| High order Destination |
+--------------------------------------------------------+
| Low order Destination |
+--------------------------------------------------------+
| Text Data 0 |
+--------------------------------------------------------+
| Text Data 1 |
+--------------------------------------------------------+
| Text Data 2 |
+--------------------------------------------------------+
.
.
.
+--------------------------------------------------------+
| Text Data N-1 |
+--------------------------------------------------------+
| Text Data N |
+--------------------------------------------------------+
The format of a response for a send datagram command packet
with the BSD bit of the FLAGS field set is shown below:
LCG NI Port Architecture Specification REV 8.0 Page 44
COMPANY CONFIDENTIAL
DGSNT Response Format (BSD)
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| <0-19> | <20-35> |
| MBZ | Length of text data |
+--------------------------------------------------------+
| | <16-31> | |
| MBZ | Protocol Type Value | |
+--------------------------------------------------------+
| FREEQ header address |
+--------------------------------------------------------+
| High order Destination |
+--------------------------------------------------------+
| Low order Destination |
+--------------------------------------------------------+
| BSD base address |
+--------------------------------------------------------+
.
.
.
+--------------------------------------------------------+
| Text N |
+--------------------------------------------------------+
The format of the individual words and the bits therein
conform to the information given for the Send Datagram command
format, above.
7.3.3 DGRCV Response -
|
| When a datagram is received, a response packet is built. The
| format of a received datagram is as follows. Note that a received
| datagram is always received as a BSD packet.
LCG NI Port Architecture Specification REV 8.0 Page 45
COMPANY CONFIDENTIAL
|
| DGRCV Response Format
|
| +--------------------------------------------------------+
| | Queue FLINK | 0
| +--------------------------------------------------------+
| | Queue BLINK | 1
| +--------------------------------------------------------+
| | Reserved for Software | 2
| +--------------------------------------------------------+
| | <0-7> | <8-15> | <16-23> | |
| | Status | Flags | Opcode | MBZ | 3
| +--------------------------------------------------------+
| | <0-19> | <20-35> |
| | MBZ | Length of text data | 4
| +--------------------------------------------------------+
| | High order Destination | 5
| +--------------------------------------------------------+
| | Low order Destination | 6
| +--------------------------------------------------------+
| | High order Source | 7
| +--------------------------------------------------------+
| | Low order Source | 10
| +--------------------------------------------------------+
| | | <16-31> | |
| | MBZ | Protocol Type Value | | 11
| +--------------------------------------------------------+
| +-| BSD Base Address | 12
| | +--------------------------------------------------------+
| |
| |
| |
| | (buffer segment descriptor)
| | +--------------------------------------------------------+
| +>| | <6> | | <12-35> |
| | MBZ | Packing Mode | MBZ | Segment Base address |---+
| +--------------------------------------------------------+ |
| | | <12-35> | |
| | MBZ | Next BSD address | |
| +--------------------------------------------------------+ |
| | |<20----------35>| |
| | MBZ | Segment Length | |
| +--------------------------------------------------------+ |
| | Reserved for use by software | |
| +--------------------------------------------------------+ |
| |
| |
| V
LCG NI Port Architecture Specification REV 8.0 Page 46
COMPANY CONFIDENTIAL
| |
| |
| |
| +--------------------------------------------------------+ |
| | Text Data 0 |<--+
| +--------------------------------------------------------+
| | Text Data 1 |
| +--------------------------------------------------------+
| | Text Data 2 |
| +--------------------------------------------------------+
| .
| .
| .
| +--------------------------------------------------------+
| | Text Data N-1 |
| +--------------------------------------------------------+
| | Text Data N |
| +--------------------------------------------------------+
|
Opcode
The Opcode field for a received datagram is 5.
Length of Text Data
This field contains the length of the transfered text data in
bytes, plus four (4) to include the cyclic redundancy check bytes
at the end of the packet.The length value does not include the
packet header. This is the length of the data portion of the
datagram. The packet length field always indicates the actual
number of bytes in the packet, even if the packet is too long, or
in an error of some sort occurs. Note that the received CRC bytes
are placed into the host memory buffer immediately following the
end of memory data. This is to allow a software double check of
packet integrity. If the packet is too large for the receiving
buffer, data is delivered until the end of the buffer is reached.
No CRC is appended to the data in this case. In no case will the
data transfered to memory (including CRC) exceed the boundary of
the buffer.
Protocol Type
LCG NI Port Architecture Specification REV 8.0 Page 47
COMPANY CONFIDENTIAL
This field contains the protocol type of the received packet.
The format for this field is the same as for the send datagram
command, and as for the protocol type field of an PTT entry. Note
that the protocol type free queue header address is omitted from
the received packet. In this case, the information is superfluous.
Destination High/Low
This field contains the destination port address as received
from the NI wire. This field is included so that messages received
for a multicast address can be distinguished from messages received
for the physical address of the port.
Source High/Low
| This field contains the originating port address. The format of
| this address is given below. In the following diagram, byte 0 is
| the first byte received over the NI wire. Byte 5 is the last byte
| received. Thus, bit 7 is the multicast address bit.
|
| Port Address Format
|
| 0.........7 8.........15 16........23 24........31 32-35
| +--------------------------------------------------------+
| | Byte 0 | Byte 1 | Byte 2 | Byte 3 | MBZ | Word 0
| +--------------------------------------------------------+
| ^
| multicast bit
|
| 0..........7 8.........15 16.............................35
| +--------------------------------------------------------+
| | Byte 4 | Byte 5 | MBZ | Word 1
| +--------------------------------------------------------+
Data Pointer
This word contains the physical address of the area where data
is stored. The text area pointed to is assumed word aligned, and
in industry compatible mode.
LCG NI Port Architecture Specification REV 8.0 Page 48
COMPANY CONFIDENTIAL
Text Data
Text Data 0 contains the first byte of the received packet.
The text portion of a received datagram is always stored left to
right. That is, the first byte of text received will be placed
into bits 0-7 of the first text word, the second byte of text
received will be placed into bits 8-15, the third into bits 16-23,
the fourth into bits 24-31, etc. This occurs for all data modes.
7.4 Load Protocol Type Table
When this command is issued, the PTT specified will be cached
internally to the port. Note that the protocol free queue
addresses are cached internally as well; this means that the free
queue headers cannot change addresses unless this command is issued
as well. Note that the addresses specified in this table point to
the free queue header, not to the first queue entry of the queue
chain.
After port initialization, no protocol types are enabled. All
frames which pass receive address filtering will be delivered to
the Unknown Protocol Type queue.
The address of the PTT specified in the PCB may not be altered
in a running port without doing an initialization.
In order to add or delete a new protocol type to or from a
running port, a new protocol type table is built over the old at
the address specified by the driver in the PCB pointer to the PTT,
including the new protocol types, and omitting any which are to be
deleted. As before, the table must be built with the protocols in
ascending order. This applies even to entries which are disabled
when the table is loaded. The port sets the enable bits of the
protocol types that are to be enabled, and issues the LDPTT
command. When the PTTLD response is received by the driver, the
new protocol types are in effect.
Since no responses to received datagrams will be started while
the load of this table is in progress, there is no danger of
compromising the queue structures.
In order to enable or disable a given protocol type without
removing or adding protocols from the PTT, the port need only set
the enable bits in the protocol type table as appropriate, and
issue a LDPTT command as before.
LCG NI Port Architecture Specification REV 8.0 Page 49
COMPANY CONFIDENTIAL
7.4.1 LDPTT Command - The format of this command is specified
below:
LDPTT Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
Opcode
The opcode for this command packet is 3. When the command is
recognized, the Protocol Type Table is internally cached. There is
no additional queue data.
If the LDPTT command is not executed before enabling the port
after initialization, then no protocol types are enabled. Any
packets that pass the receive address filter will be linked onto
the Unknown Protocol Type queue.
7.4.2 PTTLD Response -
The Load Protocol Type Table command signals completion by
building a response, and putting that response onto the end of the
response queue. The format of that response is given below:
LCG NI Port Architecture Specification REV 8.0 Page 50
COMPANY CONFIDENTIAL
PTTLD Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
The driver should not assume that a protocol type has been
enabled until this response is received from a Load PTT command.
The Opcode and flags are not modified by this command.
7.5 Load Multi-cast Address Table
When this command is issued, the Multi-cast address table
(MCAT) is loaded from the table whose address is specified by the
PCB. At initialization time, no multi cast addresses are enabled.
In order to add or delete a multi-cast address to or from a
running port, a MCAT is built in memory at the address pointed to
by the PCB MCAT base address pointer with the addresses in
increasing numerical order. Then the LDMCAT command is issued.
When the response to this command is returned the multi-cast
addresses specified in this table are in effect.
7.5.1 LDMCAT Command -
The table is loaded into the internal cache of the port. This
table must follow the format stated for the MCAT. This table must
be loaded before address checking will take effect.
LCG NI Port Architecture Specification REV 8.0 Page 51
COMPANY CONFIDENTIAL
LDMCAT Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
Opcode
The operation code for this command is 2. There is no other
queue data.
If the multi-cast address table is not loaded before enabling
the port after initialization, then no multi-cast address are
enabled. The receive address filter will reject all multi-cast
packets, except for those noted above.
7.5.2 MCATLD Response -
The successful completion of the LDMCAT command is signaled by
the building of the following response on the response queue. The
format of the response is illustrated below: Note that the driver
can assume that the specified Multi-cast address table has been
loaded only after it has received this response packet.
MCATLD Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 52
COMPANY CONFIDENTIAL
Note that the response is built only if the driver sets the RESP
bit of the flags field in the original command packet. The command
opcode and flags are not modified by this command.
7.6 Read And Clear Performance Counters
This command will read the performance counters, returning
their value in the CNTRC response, and clear the performance event
counters as specified by the CLCNT bit in the flags byte of the
command.
7.6.1 RCCNT Command -
The format of the command queue entry to accomplish this is
given below:
RCCNT Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> |<8-13> <14> <15>| <16-23> | |
| Status | Flags CLRCTR | Opcode | MBZ |
+--------------------------------------------------------+
Opcode
The opcode for this command packet is 4. This command does
not generate an NI packet. A response is built if the RESP bit in
the flags word is set.
CLRCTR <14> (Clear Counters)
This bit in the flags byte specifies whether the event
counters are to be cleared by the command after the values are
read. If this bit is a 1, then the counters will be cleared.
LCG NI Port Architecture Specification REV 8.0 Page 53
COMPANY CONFIDENTIAL
The Datagrams discarded counters are kept for each of the
protocol type queues, and for the unknown protocol type queue.
Thus, the driver can get an indication when a protocol type free
queue is exhausted by execution of this command. A counter is
returned for every protocol type entry allowed in the PTT. Those
counters which correspond with protocol type entries which are not
enabled are returned with a value of zero.
7.6.2 CNTRC Response -
If the RESP of the FLAGS field of the original command packet
is on, then a response to the above command is built. The response
has the following format:
|
| CNTCL Response Format
|
| +--------------------------------------------------------+
| | Queue FLINK | 0
| +--------------------------------------------------------+
| | Queue BLINK | 1
| +--------------------------------------------------------+
| | Reserved for Software | 2
| +--------------------------------------------------------+
| | <0-7> | <8-15> | <16-23> | | 3
| | Status | Flags | Opcode | MBZ |
| +--------------------------------------------------------+
| | BR | 4
| +--------------------------------------------------------+
| | BX | 5
| +--------------------------------------------------------+
| | FR | 6
| +--------------------------------------------------------+
| | FX | 7
| +--------------------------------------------------------+
| | MCBR | 10
| +--------------------------------------------------------+
| | MCFR | 11
| +--------------------------------------------------------+
| | FXID | 12
| +--------------------------------------------------------+
| | FXSC | 13
| +--------------------------------------------------------+
| | FXMC | 14
| +--------------------------------------------------------+
| | XF | 15
| +--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 54
COMPANY CONFIDENTIAL
| | XFBM | 16
| +--------------------------------------------------------+
| | CDCF | 17
| +--------------------------------------------------------+
| | RF | 20
| +--------------------------------------------------------+
| | RFBM | 21
| +--------------------------------------------------------+
| | DDUPT | 22
| +--------------------------------------------------------+
| | DDPT1 | 23
| +--------------------------------------------------------+
| | DDPT2 | 24
| +--------------------------------------------------------+
| | DDPT3 | 25
| +--------------------------------------------------------+
| | DDPT4 | 26
| +--------------------------------------------------------+
| | DDPT5 | 27
| +--------------------------------------------------------+
| | DDPT6 | 30
| +--------------------------------------------------------+
| | DDPT7 | 31
| +--------------------------------------------------------+
| | DDPT8 | 32
| +--------------------------------------------------------+
| | DDPT9 | 33
| +--------------------------------------------------------+
| | DDPT10 | 34
| +--------------------------------------------------------+
| | DDPT11 | 35
| +--------------------------------------------------------+
| | DDPT12 | 36
| +--------------------------------------------------------+
| | DDPT13 | 37
| +--------------------------------------------------------+
| | DDPT14 | 40
| +--------------------------------------------------------+
| | DDPT15 | 41
| +--------------------------------------------------------+
| | DDPT16 | 42
| +--------------------------------------------------------+
| | URFD | 43
| +--------------------------------------------------------+
| | DOVR | 44
| +--------------------------------------------------------+
| | SBUA | 45
| +--------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 55
COMPANY CONFIDENTIAL
| | UBUA | 46
| +--------------------------------------------------------+
| |0 PLI REG RD PAR ERROR 17|18 PLI PARITY ERROR 35| 47
| +--------------------------------------------------------+
| |0 MOVER PARITY ERROR 17|18 CBUS PARITY ERROR 35| 50
| +--------------------------------------------------------+
| |0 EBUS PARITY ERROR 17|18 EBUS QUE PARITY ERROR 35| 51
| +--------------------------------------------------------+
| |0 CHANNEL ERROR 17|18 SPUR CHANNEL ERROR 35| 52
| +--------------------------------------------------------+
| |0 SPUR XMIT ATTN ERROR 17|18 CBUS REQ TIMEOUT ERROR 35| 53
| +--------------------------------------------------------+
| |0 USED BUFF PARITY ERROR 17|18 XMIT BUFF PARITY ERROR 35| 54
| +--------------------------------------------------------+
| |0 RSVD FOR uCODE 17|18 RSVD FOR uCODE 35| 55
| +--------------------------------------------------------+
| |0 RSVD FOR uCODE 17|18 RSVD FOR uCODE 35| 56
| +--------------------------------------------------------+
| |0 RSVD FOR uCODE 17|18 RSVD FOR uCODE 35| 57
| +--------------------------------------------------------+
|
By combining the read and clear commands, the driver knows
that the event counters are not skewed when a clear command is
issued. In the following, note that a packet is not "received"
unless it passes the receive address filter.
BR
Bytes Received
This counter represents the number of 8 bit data text
characters received as datagrams over the NI.
BX
Bytes Transmitted
This counter represents the number of 8 bits data text
characters transmitted successfully as datagrams over the NI.
FR
Frames Received
This counter represents the number of frames (packets) that
have been received over the NI wire.
LCG NI Port Architecture Specification REV 8.0 Page 56
COMPANY CONFIDENTIAL
FX
Frames Transmitted
This counter represents the number of frames (packets) that
have been successfully transmitted over the NI wire.
MCBR
Multi-Cast Bytes Received
This counter represents the number of 8 bit bytes received in
packets with the multi-cast bit set in the destination field.
MCFR
Multi-Cast Frames Received
This counter represents the number of frames (packets) that
were received with the multi-cast bit in the destination field set.
FXID
Frames Transmitted, Initially Deferred
This counter represents the number of frames (packets)
transmitted that had to defer to other tranffic on the NI wire
before transmission.
FXSC
Frames Transmitted, Single Collision
This counter represents the number of frames (packets) that
were successfully transmitted, and which collided with another
transmission exactly once.
FXMC
Frames Transmitted, Multiple Collisions
This counter represents the number of frames (packets) that
were successfully transmitted, and which collided with another
transmission more than once.
LCG NI Port Architecture Specification REV 8.0 Page 57
COMPANY CONFIDENTIAL
XF
Transmit Failures
This counter represents the number of frames that were not
successfully transmitted. This counter is incremented for
excessive collisions, parity errors, etc. This counter is
associated with the XFBM, which notes occurance of error classes.
XFBM
Transmit Failure Bit Mask
This counter gives the accumulated reasons for transmission
failures. The bit meanings are listed below:
1. Bits 0-23 -- Unassigned
2. Bit 24 -- Loss of Carrier
3. Bit 25 -- Transmiter buffer parity error
4. Bit 26 -- Remote failure to defer
5. Bit 27 -- Frame too long
6. Bit 28 -- Open circuit
7. Bit 29 -- Short circuit
8. Bit 30 -- Carrier check failed (collision detect check failed)
9. Bit 31 -- Excessive collisions
CDCF
Collision Detect Check Failed
This counter gives the number of times that the collision
detect check failed after a transmit. This is the number of times
that heartbeat failed to assert after a transmit ended. This
counter has meaning only if the H4000 mode bit is set.
LCG NI Port Architecture Specification REV 8.0 Page 58
COMPANY CONFIDENTIAL
RF
Receive Failures
This counter gives the number of received frames whose
reception ultimately failed. This counter is associated with the
RFBM counter, which marks occurance of the various error types.
RFBM
Receive Failure Bit Mask
This counter gives the accumulated reasons for receive
failures. The bit definitions are given below:
1. Bits 0-26 -- Unassigned
2. Bit 27 -- Free list parity error
3. Bit 28 -- Data overrun (No free buffers)
4. Bit 29 -- Frame too long
5. Bit 30 -- Framing error
6. Bit 31 -- Block check error
DDUPT
Datagram Discarded for Unknown Protocol Type
This counter keeps track of the number of datagrams discarded
for the Unknown Protocol Type free queue. Any time a datagram is
discarded with an unrecognized protocol type, this counter is
incremented.
DDPT1 - DDPT16
Datagram Discarded for Protocol Type N
These counters keep track of the number of datagrams discarded
for each of the protocol type free queues. Any time a datagram is
discarded due to no available free space, one of these counters is
incremented, if the protocol type was enabled.
LCG NI Port Architecture Specification REV 8.0 Page 59
COMPANY CONFIDENTIAL
URFD
UnRecognized Frame Destination
This counter has no meaning for the NI20, and will always be
reported as zero.
DOVR
Data Overrun
This counter represents the number of packets that were
received incorrectly due to buffer space in the NIA being
exhausted.
SBUA
System Buffer UnAvailable
This counter has no meaning for the NI20, and will always be
reported as zero.
UBUA
User Buffer UnAvailable
This counter represents the total number of packets discarded
due to a free queue being exhausted. This number is the sum total
of the Datagram Discarded for Protocol Type 'n' counters plus the
Datagram Discarded for Unknown Protocol Type counter.
Words 47-55 are the NIA20 port recoverable errors. These
counters have an initial threshold of 5 that is set during port
initialization. This threshold count is variable and can set via a
write station information command.
RSVD
Reserved for Microcode
These counters are reserved for the port microcode and
presently it will be returned as zeroes.
LCG NI Port Architecture Specification REV 8.0 Page 60
COMPANY CONFIDENTIAL
7.6.2.1 WRTPLI Command -
Note that execution of illegal or random commands will
compromise the functionality of the interface in an indeterminate
fashion. It is recommended that the port not be executing
meaningful commands when this command is issued. This command is
for diagnostic purposes only.
The command has the following format:
WRTPLI Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| | <20-23> | | <28-35> |
| MBZ | Control | MBZ | PLI data |
+--------------------------------------------------------+
Opcode
The operation code for this packet is 6. If the response bit
in the Flags word is on, then a response confirming the correct
execution of this command will be built and placed onto the
response queue anchored in the PCB. This command, along with
RDPLI, gives the port driver the same visibility into the Port Link
Interface that the port itself has.
Control
This field specifies the PLI command which is to be put onto
the PLI when the write cycle is done. The command codes map into
PLI commands as defined in the following table:
LCG NI Port Architecture Specification REV 8.0 Page 61
COMPANY CONFIDENTIAL
Value Function
(octal)
0 - Illegal
1 - REL.T0.XMIT.BUF
2 - WR.FREE.LIST
3 - SEL.REL.BUF
4 - WR.XMIT.ACTION
5 - RES.REL.ATTN
6 - ENA.LINK.CTL
7 - DIS.LINK.CTL
10 - WR.PREP
11 - WR.XMIT.BUF
12 - WR.REG
For more information as to what these commands do
functionally, please consult the NIA hardware specification. Any
function attempted which is not defined by this table will return
with the status field indicating an Illegal PLI function.
PLI data
This field specifies the PLI data bits to be placed onto the
PLI when the write cycle is done. This field is eight bits wide.
7.6.2.2 PLIWRT Response -
The Write PLI command results in a response if the RESP bit of
the FLAGS field of the original packet was set. If built, the
response has the following format:
LCG NI Port Architecture Specification REV 8.0 Page 62
COMPANY CONFIDENTIAL
PLIWRT Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| | <20-23> | | <28-35> |
| MBZ | Control | MBZ | PLI data |
+--------------------------------------------------------+
The driver is assured that the port interface has executed this
command only after the response has been received.
7.6.3 Read Port/Link Interface -
When executed, this command causes a READ PLI cycle to be
executed, using the control bits specified. The data is returned
in the response queue entry.
7.6.3.1 RDPLI Command -
The data for this command is returned in the response entry
built if the RESP flag is set when the command is executed.
The format of this command is specified below:
LCG NI Port Architecture Specification REV 8.0 Page 63
COMPANY CONFIDENTIAL
RDPLI Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| | <20-23> | |
| MBZ | Control | MBZ |
+--------------------------------------------------------+
7.6.3.2 PLIRD Response -
The format of the response given to this command if the Flags
RESP bit is on is specified below:
PLIRD Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
| | <20-23> | | <28-35> |
| MBZ | Control | MBZ | PLI data |
+--------------------------------------------------------+
Opcode
The operation code for this packet is 7. This command does
not generate an NI packet. Through this command, the port driver
can read any quantity that the port processor itself can read over
the PLI.
LCG NI Port Architecture Specification REV 8.0 Page 64
COMPANY CONFIDENTIAL
Control
These four bits specify the control function to be executed
during the read cycle. The function executed is defined by the
following table:
Value Function
(octal)
0 - Illegal
1 - RD.REG
2 - RD.REL.BUF
3 - RD.USED.LIST
4 - RD.XMIT.STATUS
5 - RD.REL.STATUS
If a command is selected which is not defined in this table as
a legal function, a response will be generated which the status
field set to "Illegal PLI function."
PLI data
This field (and the word that contains it) is present only in
the response built for this command. This occurs when the RESP bit
in the flags field is set. In the response, this field is the data
that was read from the PLI by the execution of the RDPLI command.
It is not recommended for the driver to execute this command
while other commands are pending or while packet reception is
enabled. Careless use of this command can cause the normal port
functionality to be compromised.
7.6.4 Read NI Station Address -
When executed, this command causes the NI station address to
be read from the NI link module. In addition, some status mode
bits are read. This data is returned in the response queue entry,
if specified by the RESP bit in the flags of the command.
LCG NI Port Architecture Specification REV 8.0 Page 65
COMPANY CONFIDENTIAL
7.6.4.1 RDNSA Command -
The data for this command is returned in the response entry
built if the RESP flag is set in the command's flags field when the
command is executed. The format of this command is specified
below:
RDNSA Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
Opcode
The operation code for this packet is 8. If the response bit
in the flags word is on, a response confirming the correct
execution of the command will be built and placed onto the response
queue anchored in the PCB
7.6.4.2 NSARD Response -
If built, the response to the RDNSA command is as follows:
LCG NI Port Architecture Specification REV 8.0 Page 66
COMPANY CONFIDENTIAL
RDNSA Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
|<0--------------------------------------------31><32-35>|
| High Order NI Address | MBZ |
+--------------------------------------------------------+
| Low Order NI Address | MBZ |
+--------------------------------------------------------+
| <0---31>| <32> | <33> | <34> | <35> |
| MBZ | ACRC | AMC | H4000 Mode | PRMSC Mode |
+--------------------------------------------------------+
|<0-------------------15>|<16---------23>|<24-29>|<30-35>|
| MBZ | Ucode Version | #MCAT | #PTT |
+--------------------------------------------------------+
High/Low NI Address
This value is the physical station address stored in the
physical address RAM on the NI link board. It corresponds to the
address of the NI link. The format for these words is identical to
the NI station address format for the KL10 station address
registers described in an earlier section. The initialization
value of the physical address RAM is the value stored in the
physical address ROM of the NIA.
ACRC
This bit indicates whether the NI link will discard incoming
packets with CRC errors. If set the link will accept all incoming
packets with CRC errors and place them on the unknown protocol type
free queue if an entry is availible. If reset the link will
discard all incoming packets with CRC errors.
LCG NI Port Architecture Specification REV 8.0 Page 67
COMPANY CONFIDENTIAL
The inialization value if this bit is zero
AMC
This bit indicates whether the NI link will accept All
Multi-Cast packets, (if set), or will perform normal multi-cast
address filtering (if reset.)
The initialization value of this bit is 0.
H4000 Mode
This bit shows the current state of the H4000 mode bit. This
bit if set enables the heartbeat detection checking for the H4000
type NI bus tranceiver. The initialization value of this bit is 0.
PRMSC Mode
This bit if set indicates that the link is operating in
promiscious mode. All packets detected on the wire will be
interpreted as being addressed to this node. The initialization
value of this bit is 0.
Ucode Version
This field gives the version of microcode loaded into the
IPA20-L port. The initialization value of this field depends upon
the microcode version loaded.
#MCAT
This field gives the number of Multi-Cast Address Table
entries allowed.
#PTT
This field gives the number of Protocol Type Table entries
allowed.
LCG NI Port Architecture Specification REV 8.0 Page 68
COMPANY CONFIDENTIAL
7.6.5 Write NI Station Address -
When executed, this command will set the physical address RAM
on the NI link board, as well as set several mode bits for the
datalink operation.
7.6.5.1 WRTNSA Command -
A response for this command is built only if the RESP bit in
the command packet flags byte is on. The format of this command is
illustrated below:
WRTNSA Command Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
|<0-------------------------------------------31>|<32-35>|
| High Order NI Address | MBZ |
+--------------------------------------------------------+
| Low Order NI Address | MBZ |
+--------------------------------------------------------+
| <0---31>| <32> | <33> | <34> | <35> |
| MBZ | ACRC | AMC | H4000 Mode | PRMSC Mode |
+--------------------------------------------------------+
|<0-------------------------------23> <24-------------35>|
| Must Be Zero | # Retries Allowed |
+--------------------------------------------------------+
Opcode
The opcode for this command is 9.
LCG NI Port Architecture Specification REV 8.0 Page 69
COMPANY CONFIDENTIAL
High/Low NI Address
This address is written to the physical address RAM on the NI
link board. After the command completes, the NI link will accept
packets with the physical address specified.
ACRC
This bit indicates whether the NI link will discard incoming
packets with CRC errors. If set the link will accept all incoming
packets with CRC errors and place them on the unknown protocol type
free queue if an entry is availible. If reset the link will
discard all incoming packets with CRC errors.
The inialization value if this bit is zero
AMC
Setting this bit will put the port into Receive All Multi-Cast
mode. When enabled all multicast packets received are passed by
the receive address filter.
The initialization value of this bit is 0.
H4000 Mode
If set by the driver, this bit will enable H4000 mode; this
will enable heartbeat detection checking by the bus transceiver.
This feature is to allow the NI link to accept tranceivers that do
heartbeat checking (DEC only), or ones that do not.
PRMSC Mode
If set by the driver, this bit will enable promiscious mode.
In this mode all packets seen on the NI cable will pass the
received address filter. This is a diagnostic feature. Turning
this mode on can cause significant degradation of system network
performance, depending upon network load.
LCG NI Port Architecture Specification REV 8.0 Page 70
COMPANY CONFIDENTIAL
# Retries Allowed
This field specifies how many retires of retrieable errors are
to be attempted by the port before the error is declared
uncorrectable. The default number of retries is 5.
7.6.5.2 NSAWRT Response -
The response format to the command listed above is given
below:
NSAWRT Response Format
+--------------------------------------------------------+
| Queue FLINK |
+--------------------------------------------------------+
| Queue BLINK |
+--------------------------------------------------------+
| Reserved for Software |
+--------------------------------------------------------+
| <0-7> | <8-15> | <16-23> | |
| Status | Flags | Opcode | MBZ |
+--------------------------------------------------------+
|<0-------------------------------------------31>|<32-35>|
| High Order NI Address | MBZ |
+--------------------------------------------------------+
| Low Order NI Address | MBZ |
+--------------------------------------------------------+
| <0---31>| <32> | <33> | <34> | <35> |
| MBZ | ACRC | AMC | H4000 Mode | PRMSC Mode |
+--------------------------------------------------------+
|<0-------------------------------23>|<24-------------35>|
| Must Be Zero | # Retries Allowed |
+--------------------------------------------------------+
The bits for this response will be unchanged from the
definitions for the WRTNSA command.
LCG NI Port Architecture Specification REV 8.0 Page 71
COMPANY CONFIDENTIAL
8.0 PORT REGISTERS
The Control/Status register is briefly defined in the
following table. In the table, the symbol "*" indicates that the
bit is not writable and is always read as zero. "R" means the bit
is readable and "W" means that the bit is writable. Refer to the
IPA20-L Port Hardware Specification for additional details.
LCG NI Port Architecture Specification REV 8.0 Page 72
COMPANY CONFIDENTIAL
+---+----------------+-----------++---+----------------+-----------+
|BIT| BIT DEFINITION | ACCESS ||BIT| BIT DEFINITION | ACCESS |
| | +-----+-----++ | +-----+-----+
|NO.| |KL10 | PORT||NO.| |KL10 | PORT|
+---+----------------+-----+-----++---+----------------+-----+-----+
|00 |PORT PRESENT | R | * ||18 |CLEAR PORT | R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|01 |DIAG RQST CSR | R | * ||19 |DIAG TEST EBUF | R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|02 |DIAG CSR CHNG | R | * ||20 |DIAG GEN EBUS PE| R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|03 |DIAG INITIALIZED| R | * ||21 |DIAG SEL LAR/SQR| R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|04 |PI 00 L | R | R ||22 |DIAG SINGLE CYC | R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|05 |RQST INTERRUPT | R | W ||23 | | R/W | * |
+---+----------------+-----+-----++---+----------------+-----+-----+
|06 |CRAM PARITY ERR | R | * ||24 |EBUS PARITY ERR | R/W | R |
+---+----------------+-----+-----++---+----------------+-----+-----+
|07 |MBUS ERROR | R | * ||25 |FREE QUEUE ERR | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|08 | | * | * ||26 |PORT ERROR | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|09 | | * | * ||27 |CMD QUEUE AVAIL | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|10 | | * | * ||28 |RSP QUEUE AVAIL | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|11 |IDLE LOOP | R | R/W ||29 |SPARE | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|12 |DISABLE COMPLETE| R | R/W ||30 |DISABLE | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|13 |ENABLE COMPLETE| R | R/W ||31 |ENABLE | R/W | R/W |
+---+----------------+-----+-----++---+----------------+-----+-----+
|14 | | * | * ||32 |MPROC RUN | R/W | R |
+---+----------------+-----+-----++---+----------------+-----+-----+
|15 | | * | * ||33 |PIA 00 | R/W | R |
+---+----------------+-----+-----++---+----------------+-----+-----+
|16 | | * | * ||34 |PIA 01 | R/W | R |
+---+----------------+-----+-----++---+----------------+-----+-----+
|17 | | * | * ||35 |PIA 02 | R/W | R |
+---+----------------+-----+-----++---+----------------+-----+-----+
Bit 26, PORT ERROR is used by the KLNI to inform the driver that an
error has occured. When this bit is set by the port, the error
logout area of the PCB has been written with valid error
information. If port interrupts are enabled, an interrupt is
submitted. Otherwise, the bits have the same definition as the
LCG NI Port Architecture Specification REV 8.0 Page 73
COMPANY CONFIDENTIAL
KLIPA, the KL Computer Interconnect device microcode. This bit is
cleared by reading the status register.
LCG NI Port Architecture Specification REV 8.0 Page 74
COMPANY CONFIDENTIAL
| 9.0 DATA FORMATTING MODE
|
| NI20 supports only one data formatting mode. This mode is
| industry compatible and is shown below.
9.1 Industry Compatible Mode
The following figure illustrates the industry compatible mode
for mapping 8 bit NI bytes into 36 bit KL10 words.
INDUSTRY COMPATIBLE
KL10 WORD
0 7 8 15 16 23 24 31 32 35
+------------+------------+------------+------------+------+
| | | | | |
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | ZERO |
| | | | | |
+------------+------------+------------+------------+------+
7 0 7 0 7 0 7 0
PLI BYTE
LCG NI Port Architecture Specification REV 8.0 Page 75
COMPANY CONFIDENTIAL
10.0 NI OPCODE SUMMARY
command/response NI packet dec octal binary
**************** ********* *** ***** ******
snddg/dgsnt dg 1 1 0000 0001
ldmcat/mcatld * 2 2 0000 0010
ldptt/pttld * 3 3 0000 0011
rccnt/cntrc * 4 4 0000 0100
/dgrcvr dg 5 5 0000 0101
wrtpli/pliwrt * 6 6 0000 0110
rdpli/plird * 7 7 0000 0111
rdnsa/nsard * 8 10 0000 1000
wrtnsa/nsawrt * 9 11 0000 1001
LCG NI Port Architecture Specification REV 8.0 Page 76
COMPANY CONFIDENTIAL
11.0 PROGRAMMING NOTES
The port driver uses KL10 I/O instructions to communicate with
and control the port. Starting, stopping and communicating with
the port is done by the CONI (CONditions In) and CONO (CONditions
Out) instructions. Loading and dumping of the microcode and
manipulation of the port while it is not running is done by the
DATAI (DATA IN) and DATAO (DATA OUT) instructions.
The CSR (Control and Status Register) is the mechanism used by
the port and the port driver to indicate happenings or events. The
format of the CSR is:
0 1 2 3 4 5 6 7 8 10 12 14 18 20 22 24 26 28 30 32 35
+-+-+-+-+-+-+-+-+----+-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+
|P|D|C| |R|R|C|M| |I|D|E| |PRT|C|D|D|D|D| |E|F|D|C|R| |D|E|R|PIA|
|P|R|C| |E|I|P|B| |L|C|C| |ID |L|T|E|S|S| |P|Q|P|Q|Q| |I|N|U| |
| |C| | |D| |E|E| | | | | | |R|E|P|L|S| |E|E|E|A|A| |S|A|N| |
+-+-+-+-+-+-+-+-+----+-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+
BITS NAME DESCRIPTION
==== ==== ===========
0 PORT_PRESENT This bit is a hardware wire which
indicates the presence of a NIA20.
1 DIAG_RQST_CSR This is for diagnostic purposes only.
2 DIAG_CSR_CHNG This is for diagnostic purposes only.
4 RQST_EXAM_DEP This is for diagnostic purposes only.
5 RQST_INT This is for diagnostic purposes only.
6 CRAM_PARITY_ERROR Set by the port hardware when a word
with bad parity is read from the
CRAM.
7 MBUS_ERROR Set by the port hardware when more
than 1 driver connected to the MBUS
is detected as being active.
11 IDLE_LOOP Indicates when the microcode is in
the IDLE LOOP.
12 DISABLE_COMPLETE Indicates the microcode has placed
the port in the Disabled state.
LCG NI Port Architecture Specification REV 8.0 Page 77
COMPANY CONFIDENTIAL
13 ENABLE_COMPLETE Indicates the microcode has placed
the port in the Enabled state.
15-17 PORT_ID A code for the type of port present.
Only 1 code is implemented at this
time (7).
18 CLEAR_PORT When set by the port driver the port
is placed in a RESET state.
19 DIAG_TEST_EBUF For diagnostic purposes only.
20 DIAG_GEN_EBUS_PE For diagnostic purposes only.
21 DIAG_SELECT_LAR For diagnostic purposes. If this bit
is set by the port drivr when the
port is not running a DATAI will get
the contents of the Last Address
Register. The LAR contains the
address of the last microinstruction
executed.
22 DIAG_SINGLE_CYCLE For diagnostic purposes only.
24 EBUS_PARITY_ERROR Set by the hardware when an EBUS
Parity Error is detected by the
port during an examine operation.
25 FREE_QUEUE_ERROR Set by the port microcode when it
detects that a received frame has to
be discarded for an enabled protocol
type. This occurs because the port
cannot get a free queue to store the
frame.
26 DATA_PATH_ERROR Set by the port microcode when it
detects the MVR/FMTR Error Threshold
has been reached.
27 CMD_QUEUE_AVAIL Set by the port driver to indicate
that a command has been placed on a
previously empty Command Queue in
the PCB.
28 RSP_QUEUE_AVAIL Set by the port microcode when a
command has been placed on the
Response Queue in the PCB and it
was empty.
LCG NI Port Architecture Specification REV 8.0 Page 78
COMPANY CONFIDENTIAL
30 DISABLE Set by the port driver to put the
port into the Disabled state.
31 ENABLE Set by the port driver to put the
port into the Enabled state.
32 MPROC_RUN Set by the port driver to start
the port microcode running.
33-35 PIA These bits are set by the port
driver to indicate what priority
level an interrupt by the port
will be given.
11.1 LOADING AND DUMPING OF THE PORT
The port microcode generates an interrupt when it sets certain
bits in the CSR, A CONI instruction is used by the port driver to
read the contents of the CSR. The CONO instruction is used by the
port to write bits 18-35 of the CSR. When the port driver writes
the CSR, bit 2 of the CSR gets set by the port hardware and is
sensed by the port microcode. When the port microcode reads the
CSR bit 2 in the CSR is cleared.Both DATAI and DATAO instructions
have multiple functions with this port. A DATAI with bit 21 of the
CSR set and bit 19 of the CSR not set reads the LAR (Last Address
Register) in the port. The LAR contains the address of the last
micro instruction fetched by the port. The format of the LAR as it
is returned by the DATAI is:
0 1 13 14 15 35
+-+----------------+-+----------------------------------+
|1| LAR |0| -1 |
+-+----------------+-+----------------------------------+
If bit 19 of the CSR is set a DATAI reads the EBUF. The EBUF
is the register in the port that is used to communicate over the
EBUS. The format of the EBUF is:
0 35
+-------------------------------------------------------+
| EBUF |
+-------------------------------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 79
COMPANY CONFIDENTIAL
If both bits 19 and 21 of the CSR are not set a DATAI reads
either the right or left half of a microword (see DATAO). The
format of the microword half returned by the DATAI is:
0 5 6 35
+------+------------------------------------------------+
| -1 | BITS 0-29 OR 30-59 OF UWORD |
+------+------------------------------------------------+
A DATAO with bit 19 of the CSR set will write data to the
EBUF. The format of the written data is:
0 35
+-------------------------------------------------------+
| EBUF DATA TO BE WRITTEN |
+-------------------------------------------------------+
A DATAO with bit 19 of the CSR not set will write data to the
right or left half of the microword addressed by the RAR (Ram
Address Register). The format of the data to be written is:
0 5 6 35
+------+------------------------------------------------+
| N/A | BITS 0-29 OR 30-59 OF UWORD |
+------+------------------------------------------------+
A DATAO with bit 0 of the CSR set and bit 19 of the CSR not
set will be write the RAR. The RAR is used to address the CRAM for
purpose of writing and reading the CRAM. Bit 13 of the RAR is used
to indicate on which half of the CRAM the operation is performed.
The format of the data to be written is:
0 1 13 14 15 35
+---+----------------+-+----------------------------------+
|N/A| RAR |L| N/A |
+---+----------------+-+----------------------------------+
LCG NI Port Architecture Specification REV 8.0 Page 80
COMPANY CONFIDENTIAL
If bit 14 is set the operation is performed on the left half
of the microword. If bit 14 is not set the operation is performed
on the right half.
11.2 Reset
When a port reset is issued to a running port, the hardware
will be reset, and the port microcode PC will be set to zero so
that the power-up, self-check initialization code will be executed.
This guarantees that the port will enter a well defined state after
the reset. It is important to realize that all of the port state
will be lost; all state will revert to power-up state.
11.3 Initialization
When the LCG NI port is powered up, there is no valid
microcode in the control RAMs (CRAMS); valid microcode must be
loaded and started. This is the responsibility of the TOPS20
monitor or the NI20 diagnostic. During the initialization, the
port microcode will perform a self-check test if it detects an
error it will stop at a preset CRAM parity error. If there is no
error, the microcode will also set the registers to initialization
values, and enter the DISABLED state. When the port microcode sets
the DISABLE COMPLETE bit in the CSR, the port driver should then
write the PCB and the PI Level. It is not possible for the port to
request a host interrupt until the PI level has been written with a
valid assignment.
It is recommended that queue entries for the Unknown Protocol
Type Free Queue be large enough to hold the largest legal Ethernet
packet. Including flink, blink, and other overhead words, this is
388. words for an industry compatible mode received datagram.
*****FINIS*****
LCG NI Port Architecture Specification REV 8.0 Page Index-1
COMPANY CONFIDENTIAL
Address Filter, 16, 19, 27, 55 Destination Address, 42
AMC, 24 Error Logout Area, 11
BROADCAST, 27 Industry Compatible, 74
Specification, 27 Multi-cast Address, 24
NI Packet, 6
Buffer Header Descriptor, 23 Port Control Block, 10
Buffer Segment Descriptors, 23, Protocol Type Table, 19
36, 38, 41 Frame
Cyclic Redundancy Check, 7,
CCW 29, 36
See Channel Command Word Destination Address, 7
Channel Command Word, 14 Format, 7, 37
Command Protocol Type, 7
List of, 30 Size, 39
Load Multi-cast Address Table, Source address, 7
50
Load Protocol Type Table, 48 Host Addressing, 8
Processing, 28
Read Counters, 35, 37, 52 Interlocks, 9
Read NI Station Address, 65 Interrupts, 29
Read PLI, 62 IPA20-L, 71
Self Directed, 29
Send Datagram, 39 KL10
Write NI Station Address, 68 Addressing, 8
Write PLI, 60 Cbus, 14
CRC Channel Errors, 14
See Frame Cyclic Redundancy Check Microcode Version, 67
Mode bits
Datagram Discard, 29, 33, 52, 58 ACRC, 66
Destination Address, 7, 42, 47 AMC, 67
BROADCAST, 27 H4000, 67
PRMSC, 67
EPT, 14 PLI Read, 63
Error PLI Write, 61
Counts, 32-33 Read NI Station Address, 65
Events, 14, 37, 39, 55, 57-58
Reporting, 72 MOP Message Handling, 35
Retries, 70 Multi-cast Address, 51, 66
Error Word, 12 AMC, 24
Format, 24
FLAGS Table, 9, 19, 24, 27, 50-51
BSD, 36, 39, 43 Base address, 17
CLRCTR, 37 Multi-cast Address Table
Format, 36 Number of entries, 67
ICRC, 29, 36
Pack, 36 NI Packet Format, 6
PAD, 37
Resp, 28, 37, 42, 52-53, Opcode
LCG NI Port Architecture Specification REV 8.0 Page Index-2
COMPANY CONFIDENTIAL
61-65, 68 Datagram Received, 46
Response Bit Load Multi-cast Address Table,
See Resp 51
Format Load Protocol Type Table, 49
Buffer Header Descriptor, 23 Read Counters, 52
Buffer Segment Descriptors, 23 Read PLI, 63, 65
LCG NI Port Architecture Specification REV 8.0 Page Index-3
COMPANY CONFIDENTIAL
Send Datagram, 42 INTRPT ENABL, 72
Summary, 75 PORT ENABLD, 72
Write NI Station Address, 68 PRMSC, 67
Write PLI, 60 PRMSC MODE, 27
RSP AVAL, 72
Packing Mode, 23 Response, 28, 37
for Datagrams, 36 Counters Read and Cleared, 53
in BSD, 23 Datagram Received, 44
Industry Compatible, 74 Datagram Sent, 42
PCB Local, 29
see Port Control Block Multi-cast Address Table Loaded,
Port Control Block, 8, 17, 50 51
Base Address, 14 NI Station Address Read, 65
Format, 10 NI Station Address Written, 70
Port State PLI Read, 63
INITIALIZE, 14, 48 PLI Written, 61
Protocol Type, 7, 46 Protocol Type Table Loaded, 49
Table, 9, 19, 48-49 Remote, 28-29
Base address, 17
Format, 19 Source Address, 47
Protocol Type Table
Number of entries, 67 Time Domain Reflectometry, 38
Queue
BLINK, 9, 18-19
Entry, 9, 18, 37
FLINK, 9, 18-19
Header, 9, 17
Address, 22
Interlocks, 9, 17
Length, 9, 18
Queues, 8
Command, 9, 15-16, 28
Response, 9, 16, 28
Unknown Protocol Type Free,
9, 16, 21
Registers
Microcode Version, 67
NI Configuration, 19
NI Station Number, 65
PCB Base Address, 8
Port Status, 28
ACRC, 66
AMC, 27, 67
CMD AVAL, 72
ENABL PORT, 72
ERROR, 72
LCG NI Port Architecture Specification REV 8.0 Page Index-4
COMPANY CONFIDENTIAL
FREE Q AVAL, 72
FREE Q EMTY, 72
H4000, 67
IDLE, 72
INIT CMPLT, 72
INIT PORT, 72
INT REQD, 72