Proprietary and Confidential to PMC-Sierra, Inc.
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
ABOUT THIS MA NUA L A ND S/UNI-4X622
This manual describes the S/UNI-4x622 (PM5358) device driver. It describes the driver’s
functions, data structures, and architecture. This manual focuses on the driver’s interfaces and
their relationship to your application, real-time operating system, and to the device. It also
describes in general terms how to modify and port the driver to your software and hardware
platform.
Audience
This manual was written for people who need to:
• Evaluate and test the S/UNI-4x622 devices
• Modify and add to the S/UNI-4x622 driver’s functions
• Port the S/UNI-4x622 driver to a particular platform.
References
For more information about the S/UNI-4x622 driver, see the driver’s release notes. For more
information about the S/UNI-4x622 device, see the documents listed in Table 1 and any related
errata documents.
Table 1: Related Documents
Document NumberDocument Name
PMC-1991044Saturn User Network Interface (4x622) Telecom Standard Product
Data Sheet
Note: Ensure that you use the document that PMC-Sierra issued for your version of the device
and driver.
Revision History
Issue No.Issue DateDetails of Change
Issue 1April, 2001Document created
Proprietary and Confidential to PMC-Sierra, Inc.2
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Legal Issues
None of the information contained in this document constitutes an express or implied warranty by
PMC-Sierra, Inc. as to the sufficiency, fitness or suitability for a particular purpose of any such
information or the fitness, or suitability for a particular purpose, merchantability, performance,
compatibility with other parts or systems, of any of the products of PMC-Sierra, Inc., or any
portion thereof, referred to in this document. PMC-Sierra, Inc. expressly disclaims all
representations and warranties of any kind regarding the contents or use of the information,
including, but not limited to, express and implied warranties of accuracy, completeness,
merchantability, fitness for a particular use, or non-infringement.
In no event will PMC-Sierra, Inc. be liable for any direct, indirect, special, incidental or
consequential damages, including, but not limited to, lost profits, lost business or lost data
resulting from any use of or reliance upon the information, whether or not PMC-Sierra, Inc. has
been advised of the possibility of such damage.
The information is proprietary and confidential to PMC-Sierra, Inc., and for its customers’
internal use. In any event, no part of this document may be reproduced in any form without the
express written consent of PMC-Sierra, Inc.
Proprietary and Confidential to PMC-Sierra, Inc.12
Document ID: PMC-2010419, Issue 1
1 INTRODUCTION
The following sections of the S/UNI-4x622 Device Driver Design Specification describe the
S/UNI-4x622 device driver. The code provided throughout this document is written in ANSI-C.
This has been done to promote greater driver portability to other embedded hardware (Section 5)
and Real-Time Operating System (RTOS) environments (Section 6).
Section 2 of this document, Software Architecture, defines the software architecture of the
S/UNI-4x622 device driver by including a discussion of the driver’s external interfaces and its
main components. The Data Structure information in Section 3 describes the elements of the
driver that either configure or control its behavior. Included here are the constants, variables, and
structures that the S/UNI-4x622 device driver uses to store initialization, configuration, and status
information. Section 4 provides a detailed description of each function that is a member of the
S/UNI-4x622 driver Application Programming Interface (API). This section outlines function
calls that hide device-specific details and application callbacks that notify the user of significant
device events.
PM5358 S/UNI-4x622 Driver Manual
Introduction
Proprietary and Confidential to PMC-Sierra, Inc.13
Document ID: PMC-2010419, Issue 1
2 SOFTWARE ARCHITECTURE
This section describes the software architecture of the S/UNI-4x622 device driver. This includes a
discussion of the driver’s external interfaces and its main components.
2.1 Driver External Interfaces
Figure 1 illustrates the external interfaces defined for the S/UNI-4x622 device driver.
Figure 1: Driver External Interfaces
Application
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Function CallsApplication Callbacks
Service Callbacks
S/UNI-4x622 Device Driver
Service Calls
Hardware
Interrupts
S/UNI-4x622 Devices
Register
Accesses
RTOS
Application Programming Interface
The driver Application Programming Interface (API) is a list of high-level functions that can be
invoked by application programmers to configure, control and monitor S/UNI-4x622 devices.
The API functions perform operations that are more meaningful from a system’s perspective. The
API includes functions such as:
Proprietary and Confidential to PMC-Sierra, Inc.14
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
• Initialize the device(s)
• Perform diagnostic tests
• Validate configuration information
• Retrieve status and counts information
The driver API functions use the services of the other driver components to provide this systemlevel functionality to the application programmer.
The driver API also consists of callback routines that are used to notify the application of
significant events that take place within the device(s) and module.
Real-Time OS Interface
The driver’s RTOS interface provides functions that let the driver use RTOS services. The driver
requires the memory, interrupt, and preemption services from the RTOS. The RTOS interface
functions perform the following tasks for the driver:
• Allocate and de-allocate memory
• Manage buffers for the ISR and the DPR
• Enable and disable preemption
The RTOS interface also includes service callbacks. These are functions installed by the driver
using RTOS service calls such as installing interrupts. These service callbacks are invoked when
an interrupt occurs.
Note: You must modify RTOS interface code to suit your RTOS.
Hardware Interface
The hardware interface provides functions that read from and write to the device registers. The
hardware interface also provides a template for an ISR that the driver calls when the device raises
a hardware interrupt. You must modify this function based on the interrupt configuration of your
system.
2.2 Main Components
Figure 2 illustrates the top level architectural components of the S/UNI-4x622 device driver. This
applies in both polled and interrupt driven operation. In polled operation the ISR is called
periodically. In interrupt operation the interrupt directly triggers the ISR.
The driver includes eight main components:
• Module and device(s) data-blocks
• Interrupt-service routine
• Deferred-processing routine
Proprietary and Confidential to PMC-Sierra, Inc.15
Document ID: PMC-2010419, Issue 1
• Alarm, status and counts
• Section Overhead
• Line Overhead
• Path Overhead
• Payload Processor
• Interface Configuration
• APS Configuration
Figure 2: Driver Architecture
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Application
Function
Calls
Application
Callbacks
Deferred
Processing
Routine
Interrupt
Context
Interrupt
Service
Routine
Hardware
Interrupts
Driver API
Alarm, Status &
Statistics
Diagnostics
Module
Data Block
Device Data Blocks
.......
Hardware Interface
S/UNI-4x622 Devices
APS Configuration
Section Overhead
Line Overhead
Path Overhead
Payload Processor
Interface Configuration
Register
Accesses
Service
Callbacks
RTOS
RTOS Interface
Service
Calls
Module Data-Block and Device(s) Data-Blocks
The Module Data-Block (MDB) is the top layer data structure, created by the S/UNI-4x622 driver
to store context information about the driver module, such as:
•Module state
Proprietary and Confidential to PMC-Sierra, Inc.16
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
• Maximum number of devices
• The DDB(s)
The Device Data-Block (DDB) is contained in the MDB, and initialized by the driver module for
each S/UNI-4x622 device that is registered. There is one DDB per device and there is a limit on
the number of DDBs, and that limit is set by the USER when the module is initialized. The DDB
is used to store context information about one device, such as:
• Device state
• Control information
• Initialization parameters
• Callback function pointers
Interrupt-Service Routine
The S/UNI-4x622 driver provides an ISR called suni4x622ISR that checks if there is any valid
interrupt condition present for the device. This function can be used by a system-specific
interrupt-handler function to service interrupts raised by the device.
The low-level interrupt-handler function that traps the hardware interrupt and calls
suni4x622ISR is system and RTOS dependent. Therefore, it is outside the scope of the driver.
Example implementations of an interrupt handler and functions that install and remove it are
provided as a reference in section 5.2. You can customize these example implementations to suit
your specific needs.
See section 2.5 for a detailed explanation of the ISR and interrupt-servicing model.
Deferred-Processing Routine
The S/UNI-4x622 driver provides a DPR called suni4x622DPR that processes any interrupt
condition gathered by the ISR for that device. Typically, a system specific function, which runs as
a separate task within the RTOS, will call
suni4x622DPR.
Example implementations of a DPR task and functions that install and remove it are provided as a
reference in section 5.2. You can customize these example implementations to suit your specific
needs.
See section 2.5 for a detailed explanation of the DPR and interrupt-servicing model.
Alarms, Status and Counts
The alarm, status and counts section is responsible for monitoring alarms, tracking devices status
information and retrieving counts for each device registered with (added to) the driver.
Proprietary and Confidential to PMC-Sierra, Inc.17
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Section Overhead
The Section Overhead section provides functions to control and monitor the section overhead
processing. Read / Write access is given to the section trace message (J0). This message is
compared with a configurable reference and mismatches are reported. Section BIP-8 (B1) errors
are accumulated in a counter that can be read. Section overhead alarms are detected and reported.
For diagnostic purposes, errors can be introduced in the section overhead bytes.
Line Overhead
The Line Overhead section provides functions to configure and monitor the line overhead on both
the receive and transmit sides. Read / Write access is given to the APS bytes (K1 and K2) and
most other overhead bytes. Line BIP-8 (B2) errors are accumulated in a counter that can be read.
Line overhead alarms are detected and reported. For diagnostic purposes, errors can be introduced
in the line overhead bytes. Additional functions are provided to automatically insert line RDI and
line AIS.
Path Overhead
The Path Overhead section provides functions to configure and monitor the path overhead on
both the receive and transmit sides. Read / Write access is given to the path trace message (J1)
and the path signal label (C2). Both are compared with a configurable reference and mismatches
are reported. Path BIP-8 (B3) errors and REI are accumulated in a counter that can be read. Path
overhead alarms are detected and reported. For diagnostic purposes, errors can be introduced in
the path overhead bytes. Additional functions are provided to automatically insert path AIS, and
force generation of individual outgoing justification events.
Payload Processor
The Payload Processor section provides functions to configuring the payload for ATM or POS
processing. Function is provided to configure ATM/POS processing.
Interface Configuration
The Interface Configuration section provides functions to configure the FIFO, line and system
side interface for ATM or POS mode. Functions are provided for FIFO management to separate
the line side timing from the higher layer ATM/POS link layer timing. The Line interface is
responsible for receive/transmit line clock configuration. The System interface is responsible for
configuring the system to UTOPIA Level 3 or POS-PHY Level 3 interface for either ATM or POS
application.
APS Configuration
The APS Configuration section provides function to configure the operating mode for the device
to either a protect or working mate in a APS failover condition.
Proprietary and Confidential to PMC-Sierra, Inc.18
Document ID: PMC-2010419, Issue 1
2.3 Software States
Figure 3 shows the software state diagram for the S/UNI-4x622 driver. State transitions occur on
the successful execution of the corresponding transition functions shown. State information helps
maintain the integrity of the MDB and DDB(s) by controlling the set of operations allowed in
each state.
Figure 3: Driver Software States
suni4x622ModuleOpen
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Idle
suni4x622ModuleStart
MODULE STATES
suni4x622ModuleClose
suni4x622ModuleStop
Ready
suni4x622Reset
Start
suni4x622ModuleClose
Start
suni4x622Addsuni4x622Delete
Present
suni4x622Init
suni4x622Activate
Inactive
suni4x622Reset
Active
suni4x622DeActivate
PER-DEVICE STATES
Proprietary and Confidential to PMC-Sierra, Inc.19
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Module States
The following is a description of the S/UNI-4x622 module states. See section 4.1 for a detailed
description of the API functions that are used to change the module state.
Start
The driver module has not been initialized. In this state the driver does not hold any RTOS
resources (memory, timers, etc); has no running tasks, and performs no actions.
Idle
The driver module has been initialized successfully. The Module Initialization Vector (MIV) has
been validated, the Module Data Block (MDB) has been allocated and loaded with current data,
the per-device data structures have been allocated, and the RTOS has responded without error to
all the requests sent to it by the driver.
Ready
This is the normal operating state for the driver module. This means that all RTOS resources have
been allocated and the driver is ready for devices to be added. The driver module remains in this
state while devices are in operation.
Device States
The following is a description of the S/UNI-4x622 per-device states. The state that is mentioned
here is the software state as maintained by the driver, and not as maintained inside the device
itself. See section 4.3 for a detailed description of the API functions that are used to change the
per-device state.
Start
The device has not been initialized. In this state the device is unknown by the driver and performs
no actions. There is a separate flow for each device that can be added, and they all start here.
Present
The device has been successfully added. A Device Data Block (DDB) has been associated to the
device and updated with the user context, and a device handle has been given to the USER. In this
state the device performs no actions.
Inactive
In this state the device is configured but all data functions are de-activated including interrupts
and alarms, as well as status and counts functions.
Active
This is the normal operating state for the device. In this state, interrupt servicing or polling is
enabled.
Proprietary and Confidential to PMC-Sierra, Inc.20
Document ID: PMC-2010419, Issue 1
2.4 Processing Flows
This section describes the main processing flows of the S/UNI-4x622 driver components.
The flow diagrams presented here illustrate the sequence of operations that take place for
different driver functions. The diagrams also serve as a guide to the application programmer by
illustrating the sequence in which the application must invoke the driver API.
Module Management
The following diagram illustrates the typical function call sequences that occur when initializing
or shutting down the S/UNI-4x622 driver module.
Figure 4: Module Management Flow Diagram
START
suni4x622ModuleOpen
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Performs module level initializat ion of the driver. Validates the Module
Initialization Vector (MIV). Allocates memory for the MDB and all its
components (i.e. all the memory needed by the driver) and then initializes
the contents of the MDB with the validated MIV.
suni4x622ModuleStart
suni4x622AddInitProfile
suni4x622DeleteInitProfile
suni4x622ModuleStop
suni4x622ModuleClose
END
Performs module level startup of the dri ver. This involves allocating RTOS
resources such as semaphores and timers and installing the ISR handler
and DPR task.
Register an initialization profile. This allows the user to store pre-defined
parameter vectors that are validated ahead of time. When the deviceinitialization function is in voked only a profile number need t o be passed.
This method simplifies and expedites the above operations.
Perform all device level functions here (add, init, acti vate, de-activate,
reset, delete,...)
De-register an initialization profile previously registered with the driver.
Performs Module level shutdown of the driver. This involves deleting all
devices currently installed and de-allocating all timers and s emaphores as
well as removing the IS R handler and DPR task.
Performs module level shutdown of the driver. De-allocates all the driver's
memory.
Device Management
The following figure shows the typica l func tion ca ll sequ ence s that the dr iv er uses to add,
initialize, re-initialize, and delete the S/UNI-4x622 device.
Proprietary and Confidential to PMC-Sierra, Inc.21
Document ID: PMC-2010419, Issue 1
Figure 5: Device Management Flow Diagram
START
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
suni4x622Add
suni4x622Init
suni4x622Activate
suni4x622Reset
suni4x622DeActivate
suni4x622Reset
Detects the new device in hardware, assigns a DDB to the new device
andstores the user's context for the device. Returns a device handle to
the user
Applies a reset to the device and initializes the device registers
and associated RA Ms based on the DIV passed by the user. The
user may only pass a profile number, which corresponds to a
previously saved & validated set of configurations (by using
suni4x622AddInitProfile
Prepares the device f or normal operation by enabling interrupts and
other global enables. ISR routines are installed when the module is
started using
operational and all other API can be invoked.
In order to re-initi alize the device, reset the device using
suni4x622Reset
again.
De-activates the device and removes it from normal operation.
This involves disabling the device interrupts. ISR routines for this
device are removed
when the module is closed.
Applies a software reset to the device to put it in its def ault startup
state.
sysSuni4x622ISRHandlerInstall
and go through the initialization sequence
usingsysSuni4x622ISRHandlerRemove
)
. The device is now
suni4x622Delete
END
Removes the device from the list of devices being controlled by the
S/UNI-4x622 driver. This function de-allocates the device context
information for the device being deleted.
2.5 Interrupt Servicing
The S/UNI-4x622 driver services device interrupts using an Interrupt-Service Routine (ISR) that
traps interrupts, and a Deferred-Processing Routine (DPR) that actually processes the interrupt
conditions and clears them. This lets the ISR execute quickly and exit. Most of the
time-consuming processing of the interrupt conditions is deferred to the DPR by queuing the
necessary interrupt- c ont ext information to the DPR task. The DPR function runs in the context of
a separate task within the RTOS.
Note: Since the DPR task processes potentially serious interrupt conditions, you should set the
DPR task’s priority higher than the application task interacting with the S/UNI-4x622 driver.
Proprietary and Confidential to PMC-Sierra, Inc.22
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
The driver provides system-independent functions, suni4x622ISR and suni4x622DPR. You
must fill in the corresponding system-specific functions,
sysSuni4x622DPRTask. The system-specific funct ions iso la te the sy stem-specific
sysSuni4x622ISRHandler and
communication mechanism (between the ISR and DPR) from the system-independent functions,
suni4x622ISR and suni4x622DPR.
Figure 6 illustrates the interrupt service model used in the S/UNI-4x622 driver design.
Figure 6: Interrupt Service Mode
sysSuni4x622ISRHandler
suni4x622ISR
Interrupt
Context
Information
sysSuni4x622DPRTask
suni4x622DPR
Indication
Callbacks
Application
Note: Instead of using an interrupt service model, you can use a polling service model in the
S/UNI-4x622 driver to process the device’s event-indication registers (see page 26).
Calling suni4x622ISR
An interrupt handler function, which is system dependent, must call suni4x622ISR. But first,
the low-level interrupt-handler function must trap the device interrupts. You must implement this
function to fit your own system. As a reference, an example implementation of the interrupt
handler (sysSuni4x622ISRHandler) appears on page 110. You can customize this example
implementation to suit your needs.
The interrupt handler that you implement (
interrupt vector table of the system processor. It is called when one or more S/UNI-4x622 devices
interrupt the processor. The interrupt handler then calls
active state that has interrupt processing enabled.
sysSuni4x622ISRHandler) is installed in the
suni4x622ISR for each device in the
The
suni4x622ISR function reads from the master interrupt-status registers and the
miscellaneous interrupt-status registers of the S/UNI-4x622. If at least one valid interrupt
condition is found then
information as well as the current device handle. The
disables all the device’s interrupts detected. The
suni4x622ISR fills an Interrupt-Service Vector (ISV) with this status
suni4x622ISR function also clears and
sysSuni4x622ISRHandler function is then
responsible to send this ISV buffer to the DPR task.
Note: Normally you should save the status information for deferred processing by implementing a
message queue. The interrupt hand le r sends the sta tus information to the queue by the
sysSuni4x622ISRHandler.
Proprietary and Confidential to PMC-Sierra, Inc.23
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Calling suni4x622DPR
The sysSuni4x622DPRTask function is a system specific function that runs as a separate task
within the RTOS. You should set the DPR task’s priority higher than the application task(s)
interacting with the S/UNI-4x622 driver. In the message-queue implementation model, this task
has an associated message queue. The task waits for messages from the ISR on this message
queue. When a message arrives,
the received ISV.
suni4x622DPR processes the status information and takes appropriate action based on the
Then
specific interrupt condition detected. The nature of this processing can differ from system to
system. Therefore,
suni4x622DPR calls different indication callbacks for different interrupt
conditions.
Typically, you should implement these callback functions as simple message posting functions
that post messages to an application task. However, you can implement the indication callback to
perform processing within the DPR task context and return without sending any messages. In this
case, ensure that this callback function does not call any API functions that would change the
driver’s state, such as
suni4x622Delete. Also, ensure that the callback function is
non-blocking because the DPR task executes while S/UNI-4x622 interrupts are disabled. You can
customize these callbacks to suit your system. See page 103 for example implementations of the
callback functions.
sysSuni4x622DPRTask calls the DPR (suni4x622DPR) with
Note: Since the
suni4x622ISR and suni4x622DPR routines themselves do not specify a
communication mechanism, you have full flexibility in choosing a communication mechanism
between the two. A convenient way to implement this communication mechanism is to use a
message queue, which is a service that most RTOSs provide.
You must implement the two system specific functions,
sysSuni4x622DPRTask. When the driver calls sysSuni4x622ISRHandlerInstall, the
application installs
and the
sysSuni4x622ISRHandlerInstall function also creates the communication chann el betwe en
sysSuni4x622ISRHandler and sysSuni4x622DPRTask. This communication channe l is
sysSuni4x622DPRTask function is spawned as a task by the application. The
sysSuni4x622ISRHandler in the interrupt vector table of the processor,
most commonly a message queue associated with the
Similarly, during removal of interrupts, the driver removes
sysSuni4x622ISRHandler and
sysSuni4x622DPRTask.
sysSuni4x622ISRHandler from
the microprocessor’s interrupt vector table and deletes the task associated with
sysSuni4x622DPRTask.
As a reference, this manual provides example implementations of the interrupt installation and
removal functions on pages 109 and 111. You can customize these prototypes to suit your specific
needs.
Calling suni4x622Poll
Instead of using an interrupt service model, you can use a polling service model in the S/UNI4x622 driver to process the device’s event-indication registers.
Figure 7 illustrates the polling service model used in the S/UNI-4x622 driver design.
Proprietary and Confidential to PMC-Sierra, Inc.24
Document ID: PMC-2010419, Issue 1
Figure 7: Polling Service Model
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
suni4x622Poll
Interrupt Context
Information
suni4x622DPRsuni4x622ISR
In polling mode, the application is responsible for calling
service any pending error or alarm conditions. When
Indication
Callbacks
Application
suni4x622Poll often enough to
suni4x622Poll is called, the
suni4x622ISR function is called internally.
The
suni4x622ISR function reads from the master interrupt-status registers and the
miscellaneous interrupt-status registers of the S/UNI-4x622. If at least one valid interrupt
condition is found then
suni4x622ISR fills an Interrupt-Service Vector (ISV) with this status
information as well as the current device handle. In polling mode, this ISV buffer is passed to the
DPR task by calling
suni4x622DPR internally.
Proprietary and Confidential to PMC-Sierra, Inc.25
Document ID: PMC-2010419, Issue 1
3 DATA STRUCTURES
This section describes the elements of the driver that configure or control its behavior, and should
therefore be of interest to the application programmer. Included here are the constants, variables
and structures that the S/UNI-4x622 device driver uses to store initialization, configuration and
counts information. The channel number starts from 0. The structure contains arrays of four
elements, where index 0 corresponds to the first channel and index 3 corresponds to the fourth
channel. For more information on our naming convention, the reader is referred to Appendix A
(page 121).
3.1 Constants
The following Constants are used throughout the driver code:
<S/UNI-4x622 ERROR CODES>: error codes used throughout the driver code, returned by
•
the API functions and used in the global error number field of the MDB and DDB. For a
complete list of error codes, see Appendix B (page 125).
PM5358 S/UNI-4x622 Driver Manual
Data Structures
•
SUNI4x622_MAX_DEVS: defines the maximum number of devices that can be supported by
this driver. This constant must not be changed without a thorough analysis of the
consequences to the driver code
•
SUNI4x622_MOD_START, SUNI4x622_MOD_IDLE, SUNI4x622_MOD_READY: the three
SUNI4x622_INACTIVE: the four possible device states (stored in stateDevice)
stateModule)
3.2 Structures Passed by the Application
These structures are defined for use by the application and are passed as argument to functions
within the driver. These structures are the Module Initialization Vector (MIV), the Device
Initialization Vector (DIV) and the ISR mask.
Module Initialization Vector: MIV
Passed via the suni4x622ModuleOpen call, this structure contains all the in formation needed
by the driver to initialize and connect to the RTOS.
•
maxDevs is used to inform the driver how many devices will be operating concurrently
during this session. The number is used to calculate the amount of memory that will be
allocated to the driver. The maximum value that can be passed is
(see section 3.1).
SUNI4x622_MAX_DEVS
Proprietary and Confidential to PMC-Sierra, Inc.26
Document ID: PMC-2010419, Issue 1
(pointer to) errModule (see descript ion in the MDB)
Maximum number of devices supported during this session
Maximum number of initialization profiles
Device Initialization Vector: DIV
Passed via the suni4x622Init call, this structure contains all the information needed by the
driver to initialize a S/UNI-4x622 device. This structure is also passed via the
suni4x622SetInitProfile call when used as an initialization profile.
•
valid indicates that this initialization profile has been properly initialized and may be used
by the USER. This field should be ignored when the DIV is passed directly.
•
pollISR is a flag that indicates the type of interrupt servicing the driver is to use. The
choices are ‘polling’ (
(
SUNI4x622_ISR_MODE). When configured in polling the interrupt capability of the device
is NOT used, and the USER is responsible for calling
actual processing of the event information is the same for both modes.
will be used by the DPR to inform the application code of pending events. If these fields are
set as NULL, then any events that might cause the DPR to ‘call back’ the application will be
processed during ISR processing but ignored by the DPR.
SUNI4x622_POLL_MODE), and ‘interrupt driven’
suni4x622Poll periodically. The
and cbackAPS are used to pass the address of application functions that
Proprietary and Confidential to PMC-Sierra, Inc.27
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
Data Structures
cbackPYLDsSUNI4x622_CBACK
cbackFIFOsSUNI4x622_CBACK
cbackIntfLinesSUNI4x622_CBACK
cbackIntfSyssSUNI4x622_CBACK
cbackAPSsSUNI4x622_CBACK
cfgGlobalsSUNI4x622_CFG_GLOBAL
cfgChan[4]sSUNI4x622_CFG_CHAN
ISR Enable/Disable Mask
Address for the callback function for
PYLD events
Address for the callback function for FIFO
events
Address for the callback function for Line
Interface events
Address for the callback function for
System Interface events
Address for the callback function for APS
events
Global configuration block
Channel configuration block (4 channels
per device)
Passed via the suni4x622SetMask, suni4x622GetMask and suni4x622ClrMask calls, this
structure contains all the information needed by the driver to enable and disable any of the
interrupts in the S/UNI-4x622.
Proprietary and Confidential to PMC-Sierra, Inc.32
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
Data Structures
lofUINT2
oofUINT2
lotUINT2
doolUINT2
roolUINT2
eseUINT2
pjUINT2
Los of frame
Out of frame
Loss of transition
Recovered data out of lock
Recovered reference out of lock
Elastic store FIFO error
Pointer Justification
3.3 Structures in the Driver’s Allocated Memory
These structures are defined and used by the driver and are part of the context memory allocated
when the driver is opened. These structures are the Module Data Block (MDB), the Device Data
Block (DDB).
Module Data Block: MDB
The MDB is the top-level structure for the module. It contains configuration data about the
module level code and pointers to configuration data about the device level codes.
errModule most of the module API functions return a specific error code directly. When the
•
returned code is
to carry the specified error code back to the application. Under those circumstances, the
proper error code is recorded in this element. The element is the first in the structure so that
the USER can cast the MDB pointer into a INT4 pointer and retrieve the local error (this
eliminates the need to include the MDB tem plate int o th e applica tion code).
•
valid indicates that this structure has been properly initialized and may be read by the
USER.
stateModule contains the current state of the module and could be set to:
•
SUNI4x622_MOD_START, SUNI4x622_MOD_IDLE or SUNI4x622_MOD_READY.
Table 8: S/UNI-4x622 Module Data Block: sSUNI4x622_MDB
Field NameField TypeField Description
errModuleINT4
SUNI4x622_FAILURE, this indicates that the top-lev el funct ion was not able
Global error Indicator for module calls
validUINT2
Proprietary and Confidential to PMC-Sierra, Inc.33
Document ID: PMC-2010419, Issue 1
Indicates that this structure has been
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
initialized
Data Structures
stateModuleeSUNI4x622_MOD_STATE
Module state; can be one of the following
IDLE or READY
maxDevsUINT2
numDevsUINT2
maxInitProfsUINT2
pddbsSUNI4x622_DDB *
Maximum number of devices supported
Number of devices currently registered
Maximum number of initialization profiles
(array of) Device Data Blocks (DDB) in
context memory
pinitProfssSUNI4x622_DIV *
(array of) Initialization profiles in context
memory
Device Data Block: DDB
The DDB is the top-level structure for each device. It contains configuration data about the device
level code and pointers to configuration data about device level sub-blocks.
errDevice most of the device API functions return a specific error code directly. When the
•
returned code is
to carry the specific error code back top the application. In addition, some device functions do
not return an error code. Under those circumstances, the proper error code is recorded in this
element. The element is the fi rs t in the structur e so that the USER can cast the DD B point er
to a INT4 pointer and retrieve the local error (this eliminates the need to include the DDB
template in the application code).
SUNI4x622_FAILURE, this indicates that the top-lev el funct ion was not able
•
valid indicates that this structure has been properly initialized and may be read by the
USER.
•
stateDevice contains the current state of the device and could be set to:
SUNI4x622_START, SUNI4x622_PRESENT, SUNI4x622_ACTIVE or
SUNI4x622_INACTIVE.
usrCtxt is a value that can be used by the USER to identify the device during the execution
•
of the callback functions. It is passed to the driver when
suni4x622Add is called and
returned to the USER in the DPV when a callback function is invoked. The element is unused
by the driver itself and may contain any value.
Table 9: S/UNI-4x622 Device Data Block: sSUNI4x622_DDB
Field NameField TypeField Description
errDeviceINT4
validUINT2
Proprietary and Confidential to PMC-Sierra, Inc.34
Document ID: PMC-2010419, Issue 1
Global error indicator for device calls
Indicates that this structure has been
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
initialized
Data Structures
stateDeviceeSUNI4x622_DEV_STATE
baseAddrvoid *
usrCtxtsSUNI4x622_USR_CTXT
profileNumUINT2
pollISReSUNI4x622_ISR_MODE
cbackSOHsSUNI4x622_CBACK
cbackLOHsSUNI4x622_CBACK
cbackRPOHsSUNI4x622_CBACK
cbackPYLDsSUNI4x622_CBACK
Device State; can be one of the following
PRESENT, ACTIVE or INACTIVE
Base address of the device
Stores the user’s context for the device. It
is passed as an input parameter when the
driver invokes an application callback
Profile number used at initialization
Indicates the current type of ISR / polling
Address for the callback function for SOH
events
Address for the callback function for LOH
events
Address for the callback function for
RPOH events
Address for the callback function for
PYLD events
cbackFIFOsSUNI4x622_CBACK
cbackIntfLinesSUNI4x622_CBACK
cbackIntfSyssSUNI4x622_CBACK
cbackAPSsSUNI4x622_CBACK
cfgGlobalsSUNI4x622_CFG_GLOBAL
cfgChan[4]sSUNI4x622_CFG_CHAN
masksSUNI4x622_MASK_ISR
Address for the callback function for FIFO
events
Address for the callback function for Line
Interface events
Address for the callback function for
System Interface events
Address for the callback function for APS
events
Global configuration block
Channel configuration block ( 4 channels
per device)
Interrupt Enable Mask
Proprietary and Confidential to PMC-Sierra, Inc.35
Document ID: PMC-2010419, Issue 1
Proprietary and Confidential to PMC-Sierra, Inc.49
Document ID: PMC-2010419, Issue 1
Rx corrected HCS error count
Rx uncorrected HCS error count
Rx cell count
Rx idle cell count
Tx cell count
Rx byte count
Rx frame count
Rx aborted frame count
Rx FCS error frame count
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
Data Structures
rxfprminlfUINT2
rxfprmaxlfUINT2
txfptbyteUINT4
txfptframeUINT4
txfptusrabfUINT4
txfptferabfUINT4
Rx minimum length error frame count
Rx maximum length error frame count
Tx byte count
Tx frame count
Tx user aborted frame count
Tx underrun/error aborted frame count
3.4 Structures Passed through RTOS Buffers
Interrupt-Service Vector: ISV
This buffer structure is used to capture the status of the device (during a poll or ISR processing)
for use by the Deferred-Processing Routine (DPR). It is the template for all device registers that
are involved in exception processing. It is the application’s responsibility to create a pool of ISV
buffers (using this template to determine the buffer’s size) when the driver calls the USERsupplied
the driver via
sysSuni4x622ISVBufferRtn.
sysSuni4x622BufferStart function. An indiv idu al IS V buf f er is then obta ine d by
sysSuni4x622ISVBufferGet and returned to the ‘pool’ via
This block is used in two ways. First it is used to determine the size of buffer required by the
RTOS for use in the driver. Second it is the template for data that is assembled by the DPR and
sent to the application code. Note: the application code is responsible for returning this buffer to
the RTOS buffer pool.
The DPR reports events to the application using user-defined callbacks. The DPR uses each
callback to report a functionally-related group of events. Refer to page 104 for a description of
the S/UNI-4x622 callback functions, and Appendix C (page 126) for a list of events.
Proprietary and Confidential to PMC-Sierra, Inc.50
Document ID: PMC-2010419, Issue 1
Although most of the variables within the driver are not meant to be used by the application code,
there is one global variable that can be of great use to the application code.
suni4x622Mdb: A global pointer to the Module Data Block (MDB). The content of this global
variable should be considered read-only by the application.
•
errModule: This structure element is used to store an error code that specifies the reason for
an API function’s failure. The field is only valid for functions that do not return an error code
or when a value of
stateModule: This structure element is used to sto re the module st ate (a s shown in Figure
•
3).
pddb[ ]: An array of pointers to the individual Device Data Blocks. The USER is cautioned
•
that a DDB is only valid if the
particular order.
°
errDevice: This structure element is used to store an erro r code that specifies the reason
for an API function’s failure. The field is only valid for functions that do not return an
error code or when a value of
Event being reported
Reason for the Event
SUNI4x622_FAILURE is returned.
valid flag is set. Note that the array of DDBs is in no
SUNI4x622_FAILURE is returned.
°
stateDevice: This structure element is used to store the dev ice sta te (as shown in
Figure 3).
Proprietary and Confidential to PMC-Sierra, Inc.51
Document ID: PMC-2010419, Issue 1
This section provides a detailed description of each function that is a member of the S/UNI-4x622
driver Application Programming Interface (API).
The API functions typically execute in the context of an application task.
Note: These functions are not re-entrant. This means that two application tasks can not invoke the
same API at the same time. However the driver protects its data structures from concurrent
accesses by the application and the DPR task.
4.1 Module Management
The module management is a set of API functions that are used by the application to open, start,
stop and close the driver module. These functions will take care of initializing the driver,
allocating memory and all RTOS resources needed by the driver. They are also used to change the
module state. For more information on the module states see the state diagram on page 19. For a
typical module management flow diagram see page 21.
Opening the Driver Module: suni4x622ModuleOpen
This function performs module level initialization of the device driver. This involves allocating
all of the memory needed by the driver and initializing the internal structures.
Prototype
Inputs
Outputs
Returns
INT4 suni4x622ModuleOpen(sSUNI4x622_MIV *pmiv)
pmiv: (pointer to) Module Initialization Vector
Places the address of the MDB into the MIV passed by the application
Success =
SUNI4x622_SUCCESS
Failure = SUNI4x622_ERR_INVALID_MODULE_STATE
SUNI4x622_ERR_INVALID_MIV
SUNI4x622_ERR_MEM_ALLOC
Valid States
Side Effects
SUNI4x622_MOD_START
Changes the MODULE state to
SUNI4x622_MOD_IDLE
Closing the Driver Module: suni4x622ModuleClose
This function performs module level shutdown of the driver. This involves deleting all devices
being controlled by the driver (by calling
all the memory allocated by the driver.
suni4x622Delete for each device) and de-allocating
Prototype
Proprietary and Confidential to PMC-Sierra, Inc.52
Document ID: PMC-2010419, Issue 1
This function connects the RTOS resources to the driver. This involves allocating semaphores and
timers, initializing buffers and installing the ISR handler and DPR task. Upon successful return
from this function the driver is ready to add devices.
This function disconnects the RTOS resources from the driver. This involves de-allocating
semaphores and timers, freeing-up buffers and uninstalling the ISR handler and the DPR task. If
there are any registered devices,
This section describes the functions that add, get and clear an initialization profile. Initialization
profiles allow the user to store pre-defined Device Initialization Vectors (DIV) that are validated
ahead of time. When the device initialization function is invoked only a profile number needs to
be passed. This method simplif ie s and expedi tes the in iti al iz at ion proc ess.
Adding an Initialization Profile: suni4x622AddInitProfile
This function creates an initialization profile that is stored by the driver. A device can now be
initialized by simply passing the initialization profile number.
The device management is a set of API functions that are used by the application to control the
device. These functions take care of initializing a device in a specific configuration, enabling the
device general activity as well as enabling interrupt processing for that device. They are also used
to change the software state for that device. For more information on the device states see the
state diagram on page 19. For a typical device management flow diagram see page 22.
Adding a Device: suni4x622Add
This function verifies the presence of a new device in the hardware then returns a handle back to
the user. The device handle is passed as a parameter of most of the device API Functions. It’s
used by the driver to identify the device on which the operation is to be performed.
perrDevice: (pointer to) errDevice (inside the DDB)
Returns
Success = Device Handle (to be used bas an argument to most of the
S/UNI-4x622 APIs)
Failure = NULL (pointer)
Valid States
Side Effects
SUNI4x622_MOD_READY
Changes the DEVICE state to
SUNI4x622_PRESENT
Deleting a Device: suni4x622Delete
This function removes the specified device from the list of devices being controlled by the
S/UNI-4x622 driver. Deleting a device involves invalidating the DDB for that device and
releasing its associated device handle.
This function initializes the Device Data Block (DDB) associated with that device during
suni4x622Add, applies a soft reset to the device and configures it according to the DIV passed
by the application. If the DIV is passed as a NULL the profile number is used. A profile number
of zero indicates that all the register bits are to be left in their default state (after a soft reset).
Note that the profile number is ignored UNLESS the passed DIV is NULL.
Updating the Configuration of a Device: suni4x622Update
This function updates the configuration of the device as well as the Device Data Block (DDB)
associated with that device according to the DIV passed by the application. The only difference
between
device.
Prototype
Inputs
Outputs
Returns
suni4x622Update and suni4x622Init is that no soft reset will be applied to the
This function applies a software reset to the S/UNI-4x622 device. Also resets all the DDB
contents (except for the user context). This function is typically called before re-initializing the
device (via
Proprietary and Confidential to PMC-Sierra, Inc.58
Document ID: PMC-2010419, Issue 1
4.4 Device Read and Write
Reading from Device Registers: suni4x622Read
This function reads a register of a specific S/UNI-4x622 device by providing the register number.
This function derives the actual address location based on the device handle and register number
inputs. It then reads the contents of this address location using the system specific macro,
sysSuni4x622Read. Note that a failure to read returns a zero and any error indication is written
May affect registers that change after a read operation
Writing to Device Registers: suni4x622Write
This function writes to a register of a specific S/UNI-4x622 device by providing the register
number. This function derives the actual address location based on the device handle and register
number inputs. It then writes the contents of this address location using the system specific
macro,
is written to the DDB.
sysSuni4x622Write. Note that a failure to write returns a zero and any error indication
Reading from a block of Device Registers: suni4x622ReadBlock
This function reads a register block of a specific S/UNI-4x622 device by providing the starting
register number, and the size to read. This function derives the actual start address location based
on the device handle and starting register number inputs. It then reads the contents of this data
block using multiple calls to the sy stem specifi c m acro,
indication is written to the DDB. It is the USER’s responsibility to allocate enough memory for
the block read.
deviceHandle: device handle (from suni4x622Add)
startRegNum: starting register number
size: size of the block to read
pblock: (pointer to) the block to read
May affect registers that change after a read operation
Writing to a Block of Device Registers: suni4x622WriteBlock
This function writes to a register block of a specific S/UNI-4x622 device by providing the
starting register number and the block size. This function derives the actual starting address
location based on the device handle and starting register number inputs. It then writes the contents
of this data block using multiple calls to the system specific macro,
from the passed block is only modified in the device’s registers if the corresponding bit is set in
the passed mask. Note that any error indication is written to the DDB
Prototype
Proprietary and Confidential to PMC-Sierra, Inc.60
Document ID: PMC-2010419, Issue 1
The Section Overhead section provides functions to control and monitor the section overhead
processing. Read / Write access is given to the section trace message (J0). This message is
compared with a configurable reference and mismatches are reported. For diagnostic purposes,
errors can be introduced in the section overhead bytes.
Writing the J0 Byte: suni4x622SOHWriteJ0
This function writes the J0 byte into the transmit section overhead.
When the enable flag is set, this function introduces framing errors in the A1 bytes. When the
enable flag is not set, this function resumes normal processing.
Prototype
Inputs
Outputs
Returns
Proprietary and Confidential to PMC-Sierra, Inc.62
Document ID: PMC-2010419, Issue 1
When the enable flag is set, this function forces a loss of signal condition in the data stream.
When the enable flag is not set, this function resumes normal processing.
The Line Overhead section provides functions to configure and monitor the line overhead on both
the receive and transmit sides. Read / Write access is given to the APS bytes (K1 and K2) and
most other overhead bytes. Signal failure and signal degrade can be monitored. For diagnostic
purposes, errors can be introduced in the line overhead bytes. Additional functions are provided to
automatically insert line RDI and line AIS.
Configuring SF Error Monitor: suni4x622LOHSFCfg
This function configures the Signal Failure BERM automatic monitoring of line bit error rate
threshold events.
Prototype
Inputs
Outputs
Returns
Proprietary and Confidential to PMC-Sierra, Inc.64
Document ID: PMC-2010419, Issue 1
The Path Overhead Processor is responsible for pointer interpretation, path overhead processing,
synchronous payload envelope, path level alarm and performance monitoring on both receive and
transmit sides. The Path Overhead section configures and monitors the path overhead on both
receive and transmit sides. Write access is given to the path trace message (J1) and the path signal
label (C2) and other overhead bytes. For diagnostic purposes, errors can be introduced in the path
overhead bytes.Additional functions are provided to automatically insert path AIS, force
generation of outgoing justification events.
Proprietary and Confidential to PMC-Sierra, Inc.68
Document ID: PMC-2010419, Issue 1
Retrieving and Setting the Path Trace Messages: suni4x622POHTraceMsg
This function retrieves and sets the current path trace message in the Sonet/SDH Path Trace
Buffer. Note: It is the USER’s responsibility to make sure that the message pointer points to an
area of memory large enough to hold the returned data.
Inserting a Pointer Value: suni4x622TPOHInsertTxPtr
This function enables the insertion of the pointer value passed in argument into the H1 and H2
bytes of the transmit stream. As a result, the upstream payload mapping circuitry and a valid SPE
can continue functioning and generating normally.
This function enables the insertion of the Path Alarm Indication Signal (PAIS) in the transmit
stream. The synchronous payload envelope and the pointer bytes (H1 – H3) are set to all ones.
The Interface Configuration provides FIFO management to separate the line side timing from the
high layer ATM/POS link layer timing, the line and system interface configuration.
Resetting the Receive/Transmit FIFO: suni4x622FIFOReset
This function resets the rece iv e and/or tr ansmit FIFO.
When enable is set, this function enables the S/UNI-4x622 to operate as an APS working/protect
mate under a failed condition. When enable is not set, this function resumes normal operation.
This function sets the contents of the interrupt mask registers of the S/UNI-4x622 device. Any
bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
Proprietary and Confidential to PMC-Sierra, Inc.81
Document ID: PMC-2010419, Issue 1
This function clears individual in ter rup t bits and reg ister s in the S/UNI- 4x622 device. Any bits
that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function sets the contents of the SOH interrupt mask registers of the S/UNI-4x622 device.
Any bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
This function clears SOH individual interrupt bits and registers in the S/UNI-4x622 device. Any
bits that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function sets the contents of the LOH interrupt mask registers of the S/UNI-4x622 device.
Any bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
This function clears LOH individual interrupt bits and registers in the S/UNI-4x622 device. Any
bits that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function sets the contents of the RPOH interrupt mask registers of the S/UNI-4x622 device.
Any bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
This function clears RPOH individual interrupt bits and registers in the S/UNI-4x622 device. Any
bits that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function sets the contents of the PYLD interrupt mask registers of the S/UNI-4x622 device.
Any bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
This function clears PYLD individual interrupt bits and registers in the S/UNI-4x622 device. Any
bits that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function sets the contents of the FIFO interrupt mask registers of the S/UNI-4x622 device.
Any bits that are set in the passed structure are set in the associated S/UNI-4x622 registers.
This function clears FIFO individual interrupt bits and registers in the S/UNI-4x622 device. Any
bits that are set in the passed structure are cleared in the associated S/UNI-4x622 registers.
This function reads the state of the interrup t reg iste rs in the S/UNI- 4x622 and stores them in an
ISV. Performs whatever functions are needed to clear the interrupt, from simply clearing bits to
complex functions. This routine is called by the application code, from within
sysSuni4x622ISRHandler. If ISR mode is configured all interrupts that were detected are
disabled and the ISV is returned to the application. Note that the application is then responsible
for sending this buffer to the DPR task. If polling mode is selected, no ISV is returned to the
application and the DPR is called directly with the ISV.
Prototype
Inputs
Outputs
Returns
Valid States
Side Effects
Pseudocode
void * suni4x622ISR(sSUNI4x622_HNDL deviceHandle)
deviceHandle: device handle (from suni4x622Add)
None
(pointer to) ISV buffer (to send to the DPR) or NULL (pointer)
SUNI4x622_ACTIVE
None
Begin
get an ISV buffer
update ISV with current interrupt status
if no valid interrupt condition
return NULL
if in ISR mode
disable all detected interrupts
return ISV
else (Polling mode)
suni4x622DPR
call
output NULL
End
Deferred-Processing Routine: suni4x622DPR
This function acts on data contained in the passed ISV, allocates one or more DPV buffers (via
sysSuni4x622DPVBufferGet) and invokes one or more callbacks (if defined and enabled).
This routine is called by the application code, within
callbacks are responsible for releasing the passed DPV. It is recommended that it be done as soon
as possible to avoid running out of DPV buffers.
Prototype
Inputs
Outputs
Returns
Proprietary and Confidential to PMC-Sierra, Inc.95
Document ID: PMC-2010419, Issue 1