Table of Contents NMS Glossary Previous Page Next Page Version

Chapter 6

Packet Protocol

6.1 Introduction
6.2 Initializing the Virtual Port Library
6.2.1 Packet Headers
6.3 Attaching to Virtual Ports
6.3.1 Full Packets
6.4 Enabling Virtual Ports
6.4.1 Full Packets
6.5 Disabling Virtual Ports
6.5.1 Full Packets
6.6 Detaching from Virtual Ports
6.6.1 Full Packets
6.7 Transmitting Data over Virtual Ports
6.7.1 Full Packets
6.8 Receiving Data over Virtual Port
6.8.1 Full Packet
6.9 Terminating the Virtual Port Library

6.1 IntroductionTop of Page

This chapter describes the packet protocol that exists between the host application and the communications processor. API functions are provided to assist in the building/issuing of request packets, but there is no requirement that these API functions be used. All virtual port requests can be issued as dual port RAM packet send requests (no interaction with the API). For a description of the function associated with a given packet definition, see the corresponding section in the Virtual Port Data Transfer API function descriptions.

6.2 Initializing the Virtual Port LibraryTop of Page

Initialization is identical to that described in the API functions.

6.2.1 Packet HeadersTop of Page

All dual port RAM packets begin with a common header structure. This structure is defined in txcpi.h:

TX_DPR_HDR:

srcchan

 Source channel number

Requests: channel used for cpi_open

Responses: TXVPD_DPRCHAN (in all responses/receive notifications)

srcboard

 Source board number (0 = PC)

dstchan

 Destination channel number

Requests: TXVPD_DPRCHAN

Responses: channel used for cpi_open (in all responses/receive notifications)

dstboard

 Destination board number (0 = PC)

len

 Byte length of this header and following data

For the virtual port packets, the dual port RAM header is immediately followed by a dual port RAM message request | response header. These structures allow matching of requests and responses. The only difference between a request header and response header is the presence of a status field (and a future expansion field) in the response. The structures are defined in txcpi.h:

TX_DPR_MSGHDR:

msgdir

 Indicator of message direction

TXMSG_TOCP: '>' Message being passed from HOST to TX board communication processor

TXMSG_TOHOST: '<' Message being passed from TX board communication processor to HOST

msgtype

 General type of message. The following set is used for virtual ports:

TXMSG_COMMAND: 'C' Command request (future response expected)

TXMSG_RESULT: 'R' Result (response to command request)

TXMSG_NOTIF: 'N' Notification (receive indication)

msgnum

 Message number identifying specific function. These values are defined in vpdtype.h and are listed in the following specific packet descriptions.

msgtrc

 Message trace level. The $vpd task on the communication processor creates an on-board log entry for messages sent/received with a non-zero trace level. The trace level used in the attach request is used for all receive notifications. Tracing on the host system is the responsibility of the given host application.

msgid

 Specific request (and associated response) identifier. This field allows matching of responses to requests. If the Virtual Port Data Transfer API is used, this number is incremented (single global for all virtual port API requests) for each request. If an application is using the packet protocol, this field is controlled by the application.

msgkey

 Key associated with request (and its response). This field is completely controlled by the host application. For receive notifications, this will be the vpdatchkey used by the application in the attach request.

future

 Reserved for future use.

 TX_DPR_REQHDR: (used for all requests)

hdr

 Dual port RAM header [TX_DPR_HDR]

msg

 Message header [TX_DPR_MSGHDR]

 TX_DPR_RSPHDR: (used for all responses)

hdr

 Dual port RAM header [TX_DPR_HDR]

msg

 Message header [TX_DPR_MSGHDR]

status

 Status of response

future

 Area reserved for future extension of TX responses

All requests (except the attach) and all responses include a virtual port identification structure (defined in vpdtype.h) that identifies the specific virtual port conversation that the message applies to:

TXVPD_P_VPID:

vpdatchkey

 Application's attach key (specified in attach request)

vpdcpctl

 Communication processor's virtual port control key (first returned in attach response)

Any data specific to the given request/response immediately follows the 2 (or 3) headers (see the following specific definitions).

6.3 Attaching to Virtual PortsTop of Page

Description

Attach to the indicated virtual port (registering the application as sole owner of virtual port).

Prototype

msgnum: TXVPD_DPR_ATTACH

TXVPD_P_ATTACH:

vpdvpnum

 Virtual port number to attach to

vpdatchkey

 Application's attach key (identifies this virtual port conversation)

Request/response structure: TXVPD_P_VPID (see Section 6.2.1, Packet Headers).

The response structure should be used as the second header for all other requests related to this virtual port attachment. This structure includes both a key field set by the application (used to reference a control structure specific to the given attachment), and a key field required by the communication processor KERNEL (also identifying the particular attachment).

6.3.1 Full Packets
REQUEST:

 Attach to Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.attach

 Attach parameters [TXVPD_P_ATTACH]

Top of Page

RESPONSE:

 Attach to Virtual Port

rsp

 Common response header [TX_DPR_RSPHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

6.4 Enabling Virtual PortsTop of Page

Description

Enable virtual port, allowing data transmission (TX and RX). This brings up the physical resource that the virtual port is attached to if it is the first enable for the given resource.

Prototype

msgnum: TXVPD_DPR_ENABLE

Request/response structure: TXVPD_P_VPID (see Section 6.2.1, Packet Headers).

6.4.1 Full PacketsTop of Page

REQUEST:

 Enable Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]
RESPONSE:

 Enable Virtual Port

rsp

 Common response header [TX_DPR_RSPHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

6.5 Disabling Virtual PortsTop of Page

Description

Disable the virtual port. Once the disable response is received, no further dual port RAM packets are received for the given virtual port. If this is the last enabled virtual port for the associated physical resource, the disable also brings down the physical resource.

Prototype

msgnum: TXVPD_DPR_DISABLE

Request/response structure: TXVPD_P_VPID (see Section 6.2.1, Packet Headers).

6.5.1 Full PacketsTop of Page

REQUEST:

 Disable Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]
RESPONSE:

 Disable Virtual Port

rsp

 Common response header [TX_DPR_RSPHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

6.6 Detaching from Virtual PortsTop of Page

Description

Release ownership of the given virtual port. Virtual port must be disabled for this request to succeed. Once a virtual port has been detached, another application (local to the communication processor or residing on the host) can attach to the virtual port.

Prototype

msgnum: TXVPD_DPR_DETACH

Request/response structure: TXVPD_P_VPID (see Section 6.2.1, Packet Headers).

6.6.1 Full Packets
REQUEST:

 Detach from Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

Top of Page

RESPONSE:

 Detach from Virtual Port

rsp

 Common response header [TX_DPR_RSPHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

6.7 Transmitting Data over Virtual PortsTop of Page

Description

Send a data frame through the virtual port and out the physical resource associated with the virtual port.

Prototype

msgnum: TXVPD_DPR_TX

 TXVPD_P_DATA:

vpdid

 Structure identifying the specific virtual port conversation

vpddata

 From 1..MAXVPDDATA bytes to be transmitter over virtual port

Response structure: TXVPD_P_VPID (see Section 6.2.1, Packet Headers).

6.7.1 Full PacketsTop of Page

REQUEST:

 Transmit Data over Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.data

 Attach identification and TX data [TXVPD_P_DATA]
RESPONSE:

 Transmit Data over Virtual Port

rsp

 Common response header [TX_DPR_RSPHDR]

data.u.vpid

 Attach identification [TXVPD_P_VPID]

6.8 Receiving Data over Virtual PortTop of Page

Description

Receive a data frame from the physical resource associated with a virtual port (for an address indicated by the virtual port definition).

Prototype

msgnum: TXVPD_DPR_RX

TXVPD_P_DATA:

vpdid

 Identifies the specific virtual port conversation

vpddata

 From 1..MAXVPDDATA bytes received over virtual port

This message has no associated request structure and requires no response from the host application.

6.8.1 Full Packet
NOTIFICATION:

 Receive Data over Virtual Port

req

 Common request header [TX_DPR_REQHDR]

data.u.data

 Attach identification and RX data [TXVPD_P_DATA]

Top of Page

6.9 Terminating the Virtual Port LibraryTop of Page

Termination concerns are identical to those described for use of the API functions.


Table of Contents NMS Glossary Previous Page Next Page Version

Want to send us feedback on our documentation? Email: Tech_Pubs@nmss.com
Copyright © 2000, Natural MicroSystems, Inc. All rights reserved.