serial front panel data port (fpdp) draft standard vita 17

Serial Front Panel Data Port (FPDP)

Draft Standard VITA 17.1 – 200x

Draft 0.8a

October 16, 2002

This draft standard is being prepared by the VITA Standards Organization (VSO) and is unapproved.

Do not specify or claim conformance to this draft standard.

VSO is the Public Domain Administrator of this draft standard and guards the contents from change except by sanctioned

meetings of the task group under due process.

VITA Standards Organization PO Box 19658

Fountain Hills, AZ 85269 Ph: 480-837-7486

URL: http://www.vita.com

Table of Contents Chapter 1- Introduction................................................................................................................................5

1.1 Standard Terminology ..................................................................................................................5 Chapter 2 - Scope and Purpose..................................................................................................................7

2.1 Scope.............................................................................................................................................7 2.2 Purpose .........................................................................................................................................7 2.3 References ....................................................................................................................................7

Chapter 3.....................................................................................................................................................8 Chapter 4 - Overview ..................................................................................................................................9

4.1 General ..........................................................................................................................................9 Chapter 5 - Background ............................................................................................................................11

5.1 Parallel FPDP Signals .................................................................................................................11 5.2 Parallel FPDP Frame Structure ...................................................................................................13

Chapter 6 - System Specifications ............................................................................................................15 6.1 Serial FPDP System Configurations............................................................................................15

6.1.1 Basic Serial FPDP Configuration ..........................................................................................15 6.1.2 Flow Control (Optional) .........................................................................................................16 6.1.3 Bi-directional Data Flow (Optional) .......................................................................................18 6.1.4 Copy Mode (Optional) ...........................................................................................................19 6.1.5 Copy/Loop Mode (Optional) ..................................................................................................22

Chapter 7 - Link Specifications .................................................................................................................24 7.1 Overview......................................................................................................................................24 7.2 Link Bandwidth ............................................................................................................................24 7.3 Serial FPDP Transmission Frames .............................................................................................25

7.3.1 8B/10B Encoding / Decoding ................................................................................................25 7.3.2 Serial FPDP Control Signals .................................................................................................27 7.3.3 Fiber Frames.........................................................................................................................30

Chapter 8 - Physical Specifications...........................................................................................................37 8.1 Link Interface ...............................................................................................................................37

Appendix A - Interoperability Issues..........................................................................................................41 Appendix B – Implementation Considerations ..........................................................................................43

List of Figures Figure 4-1 Typical Parallel FPDP to Serial FPDP Application....................................................................9 Figure 4-2 Serial FPDP Bi-directional Example .......................................................................................10 Figure 6-1 Basic Serial FPDP system configuration ................................................................................15 Figure 6-2 Serial FPDP with Flow Control................................................................................................16 Figure 6-3 Transmit & Receive Fibers having different end points ..........................................................17 Figure 6-4 Bi-directional Serial FPDP Link...............................................................................................18 Figure 6-5 Serial FPDP Copy Mode.........................................................................................................19 Figure 6-6 Serial FPDP Copy/Loop Mode................................................................................................22 Figure 7-1 Typical Serial FPDP Process...................................................................................................24 Figure 7-2 Serial FPDP Fiber Frames......................................................................................................32

List of Tables Table 5-1 Parallel FPDP Signals.............................................................................................................. 12 Table 7-1 Fibre Channel to Serial FPDP Ordered Sets ........................................................................... 26 Table 8-1 Media Interfaces ...................................................................................................................... 37 Table 8-2 Short-Wave Laser Media Characteristics (Example)...............................................................39 Table 8-3 Long-Wave Laser Media Characteristics (Example) ...............................................................40 Table A-1 Serial FPDP Interoperability Checklist.....................................................................................42

Do not specify or claim conformance to this draft standard

Serial FPDP, VITA 17.1 – 200x/Draft 0.8a October 16, 2002 2

Abstract

This standard defines “Serial FPDP”, a high-speed low-latency serial communications protocol for use in high-speed data transfer applications, typically using a fiber optic link. As the name implies, it is directly related to Standard Front Panel Data Port (FPDP), deriving its serial protocol from the defined protocol and control signals of FPDP. This Serial FPDP standard supports three link speeds: 1.0625 Gbaud, 2.125 Gbaud, and 2.5 Gbaud. These three link speeds can support data transfer rates in excess of 105 MBps, 210 MBps, and 247 MBps respectively.

Comments, Corrections, Additions Currently, all comments, corrections, or additions should be addressed to:

Ron Taulton Systran Corporation 4126 Linden Ave. Dayton, OH 45432-3068 Ph: 937-252-5601 x231 Fax: 937-258-2729 email: [email protected]

Draft History

Draft Number

Date Comments

D0.1 July 21, 1999 Preliminary Draft. D0.2 September 22, 1999 Total Revision. D0.3 February 24, 2000 Minor modifications. Changed designation from VITA 33 to VITA

17.1. Provided to VITA web site. D0.4 November 10, 2000 Detailed Update (not Published on VITA Website). D0.5 February 26,2001 Detailed Update to include submitted comments. D0.6 January 28,2002 Inclusion of comments and changes suggested by task group.

Expanded copy and copy/loop sections to include a requirement for a copy or copy/loop master mode – adding idles to allow for receive and re-transmit clock differences.

D0.7 June 10, 2002 Included comments from task group. Expanded link speeds to include 2.125 Gbaud. First draft released for a task group ballot.

D0.8 September 30, 2002 Included all comments / changes from the initial task group ballot. Official draft for task group ballot #2.

D0.8a October 16, 2002 Added minor formatting changes to reflect comments from task group ballot #2. No content changes.



mailto:[email protected]

Task Group Members The VITA-17.1 Task Group consists of the following members: First Last Company Email address Status Steve Belvin IBSi [email protected] Observer Tom Bohman VMETRO [email protected] Sponsor Danny Cohen Sun [email protected] Participant Richard Jaenicke Mercury Computer Systems, Inc. [email protected] Participant Jonathan Jones Interactive Circuits & Systems [email protected] Sponsor Jim LaLone Mercury Computer Systems, Inc. [email protected] Observer Tony Lavely Mercury Computer Systems, Inc. [email protected] Participant Mike Macpherson MITRE [email protected] Observer Stephen Paavola SKY Computers, Inc. [email protected] Participant Elwood Parsons AMP [email protected] Observer Doug Patterson VISTA Controls Corporation [email protected] Observer Greg Rocco Mercury Computer Systems, Inc. [email protected] Observer John Rynearson VITA [email protected] Participant Ron Seese Chrislin Industries, Inc. [email protected] Observer Hermann Strass Technology Consulting [email protected] Participant Ron Taulton Systran Corporation [email protected] Sponsor Larry Thompson Naval Surface Warfare Center [email protected] Observer Mark Trepanier Mercury Computer Systems, Inc. [email protected] Observer Istvan Vadasz Force Computers [email protected] Observer Tom Woodword Communication Automation Corp. [email protected] Observer

Task Group Ballot Participants

First Last Company Email address Steve Belvin IBSi [email protected] Tom Bohman VMETRO [email protected] Jonathan Jones Interactive Circuits & Systems [email protected] Jim LaLone Mercury Computer Systems, Inc. [email protected] Tony Lavely Mercury Computer Systems, Inc. [email protected] Stephen Paavola SKY Computers, Inc. [email protected] Elwood Parsons AMP [email protected] Greg Rocco Mercury Computer Systems, Inc. [email protected] John Rynearson VITA [email protected] Ron Seese Chrislin Industries, Inc. [email protected] Hermann Strass Technology Consulting [email protected] Ron Taulton Systran Corporation [email protected] Tom Woodword Communication Automation Corp. [email protected]



Chapter 1- Introduction

Serial FPDP is a high-speed low-latency data-streaming serial communications protocol for use in high-speed real-time data transfer applications. It currently is defined to operate at three distinct link speeds, 1.0625 Gbaud, 2.125 Gbaud, and 2.5 Gbaud – with sustained data rates in excess of 105, 210, and 247 Mbytes/sec. respectively. Serial FPDP can also operate over long distances (up to 10 kilometers) using fiber optic cable. 1.1 Standard Terminology To avoid confusion and to make very clear what the requirements for compliance are, many of the para-graphs in this standard are labeled with keywords that indicate the type of information they contain. The keywords are listed below: Rule Recommendation Suggestion Permission Observation These key words are used as follows: Rule <chapter>.<number>: Rules form the basic framework of this draft standard. They are sometimes expressed in text form and sometimes in the form of figures, tables or drawings. All rules shall be followed to ensure compatibility between board and backplane designs. All rules use the "SHALL" or "SHALL NOT" words to emphasize the importance of the rule. The upper-case "SHALL" or "SHALL NOT" words are reserved exclusively for stating rules in this standard and are not used for any other purpose. Recommendation <chapter>.<number>: Wherever a recommendation appears, designers would be wise to take the advice given. Doing other-wise might result in some awkward problems or poor performance. While the Serial FPDP architecture has been designed to support high-performance systems, it is possible to design a system that complies with all the rules but has poor performance. In many cases, a designer needs a certain level of experience in order to design boards that deliver top performance. Recommendations found in this standard are based on this kind of experience and are provided to designers to speed their traversal of the learning curve. All recommendations use the "SHOULD" or "SHOULD NOT" words to emphasize the importance of the recommendation. The upper-case "SHOULD" or "SHOULD NOT" words are reserved exclusively for stating recommendations in this draft standard and are not used for any other purpose. Suggestion <chapter>.<number>: A suggestion contains advice that is helpful but not vital. The reader is encouraged to consider the advice before discarding it. Some design decisions that need to be made in designing boards are difficult until experience has been gained. Suggestions are included to help a designer who has not yet gained this experience. Some suggestions have to do with designing boards that can be easily reconfigured for compatibility with other boards, or with designing the board to make the job of system debugging easier.



Permission <chapter>.<number>: In some cases, a rule does not specifically prohibit a certain design approach, but the reader might be left wondering whether that approach might violate the spirit of the rule or whether it might lead to some subtle problem. Permissions reassure the reader that a certain approach is acceptable and will cause no problems. All permissions use the "MAY" words to emphasize the importance of the permission. The upper-case word "MAY" words are reserved exclusively for stating permissions in this draft standard and are not used for any other purpose. Observation <chapter>.<number>: Observations do not offer any specific advice. They usually follow naturally from what has just been discussed. They spell out the implications of certain rules and bring attention to things that might other-wise be overlooked. They also give the rationale behind certain rules so that the reader understands why the rule shall be followed.



Chapter 2 - Scope and Purpose

2.1 Scope This document defines “Serial FPDP”, a serial communications interface. Included in this definition are the data frame structure, the link layer protocol, and the physical media requirements. 2.2 Purpose The purpose of this standard is to allow products to be designed to work with other Serial FPDP products. The degree of interoperability will depend on the specific options implemented. Although all options are supported by this standard, not all products are required to support all options. 2.3 References ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface (FC-PH) ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2 (FC-PH-2) ANSI X3.272-1996, Fibre Channel Arbitrated Loop (FC-AL) ANSI/VITA 17-1998, Front Panel Data Port Specifications



Chapter 3 - Definitions

Parallel FPDP The industry standard Front Panel Data Port (FPDP) as specified

in the standard document ANSI/VITA 17-1998, Front Panel Data Port Specifications.

Host-Bus The interface side of a Serial FPDP device that provides data to

a Serial FPDP transmitter or receives data from a Serial FPDP receiver.

Serial FPDP Transmitter A Serial FPDP interface that has the ability to receive data from a

Host-Bus and transmit it as serial data using the Serial FPDP protocol.

Serial FPDP Receiver A Serial FPDP interface that has the ability to receive serial data

from a Serial FPDP link using Serial FPDP protocol and transmit that data to the Host-Bus.

Serial FPDP Transmission Frame The Serial FPDP data and control word frames that are sent

across the serial link. It is also referred to as a Fiber Frame in this document.

Fiber Frame The Serial FPDP data and control word frames that are sent

across the serial link. Although fiber optics is considered the most common media, Fiber Frames can be sent across other media types (i.e. copper).

Flow Control The ability of the Serial FPDP receiver to communicate to the

transmitter a pending Receive FIFO overflow condition, allowing the transmitter to temporarily stop sending data.

Copy Mode A Serial FPDP option that permits a receiving node to re-transmit

the incoming control words and data stream to another receiving node. This provides for a limited broadcast of the data.

Copy/Loop Mode A Serial FPDP option that allows a receiving node to not only re-

transmit the incoming control words and data to another receiving node, but it also allows any receiving node to set the flow control signal. This setting of the flow control signal provides any of the receiving nodes the capability to stop the transmitter.

Copy Master Mode An optional mode for a Serial FPDP transmitter which supports

the Copy and Copy/Loop modes. This mode adds additional IDLE ordered sets to the beginning of each transmission frame.

MByte / MB It is customary to have MB equal to 1,048,576 when referring to

the size of memory and equal to 1,000,000 bytes when used in reference to data rates. This standard is using it to refer to data rates and so an MB is equal to 1,000,000 bytes in this standard.



Chapter 4 - Overview

4.1 General The purpose of this standard is to define “Serial FPDP”, a high-speed low-latency serial communications link for use in high-speed data transfer applications. As the name implies, it is directly related to standard Front Panel Data Port (FPDP), deriving its serial protocol from the defined protocol and control signals of FPDP. In order to avoid confusion with the subject of this standard (Serial FPDP), this document will refer to this standard FPDP as “Parallel FPDP.” Parallel Front Panel Data Port (FPDP) is a 32-bit parallel synchronous bus intended to provide high-speed data transfer between FPDP connections at speeds up to 160MB/s. Parallel FPDP is an existing ANSI/VITA standard (ANSI/VITA 17-1998, Front Panel Data Port Specifications). Although widely used for high-speed communications within a single chassis or rack of equipment, one of the limitations of Parallel FPDP is that link connections are limited to relatively short distances – not more than 5 meters. One of the direct advantages and common applications of Serial FPDP is the extension of a Parallel FPDP connection over much greater distances – in some cases up to 10 kilometers (assuming the selection of appropriate optical transceiver and fiber optic cable). Figure 4-1 provides a conceptual example of this typical Serial FPDP implementation. It demonstrates a possible application in which Serial FPDP is used as a direct link between two Parallel FPDP connections. It shows the conversion from Parallel FPDP to Serial FPDP on the source side, transmission across the link, and the reverse conversion, Serial FPDP to Parallel FPDP on the destination side. This figure represents one very basic configuration of Serial FPDP and is provided only as a conceptual reference to show the relationship between Parallel FPDP and Serial FPDP. The area delineated by the triple dashed line in figure 4-1 conceptually defines the scope of this standard. The interface represented by the heavy solid line represents what this document refers to as the Host-Bus Interface. The concept of the Host-Bus is used throughout this standard to describe the interface that provides data to, or receives data from, the serial link. The Host-Bus Interface provides the data to the Serial FPDP OUT (Transmitter) and receives the data from the Serial FPDP IN (Receiver). In the particular case shown in Figure 4-1, the Host-Bus would be Parallel FPDP.

Figure 4-1 Typical Parallel FP

Flow Control

(Optional)

Serial FPDP

FPDP IN FPDP/RM FPDP/R

Parallel FPDP Connection

Serial FPDP OUT

Data

Source With

FPDP OUT

FPDP/TM

Up to10 k(Serial

Host-Bus

Do not specify or claim confo


Data

DP to Serial FPDP Application

Parallel FPDP Connection

FPDP OUT FPDP/TM

IN Data Destination

With FPDP IN

FPDP/RM FPDP/R

ilometer FPDP)

Interface

rmance to this draft standard

Data and Flow Control can be mixed over the same Serial FPDP link. Figure 4-1 shows only data going in one direction, with flow control being returned by the receiving end. Serial FPDP also supports bi-directional data flow, where both data and flow control are transmitted in both directions across the connection as shown in Figure 4-2.

Serial FPDP IN

OUT

Serial FPDP OUT

IN

Figure 4-2 Se In addition to Parallel FPDP (ANSI/VITA 17advantage of elements of other existing cuGbaud correspond to the link speeds defincorresponds to that used in Fibre Channelare described in detail in the Fibre ChanneX3.230-1994). Using existing standards, ause of more common and more available cbasic level, Serial FPDP is not meant to be

Do not specify or cl

Serial FPDP, VITA 17.1 – 200x/Draft 0.8a October 16, 2002

Data & Flow Control

Host-Bus I

rial FPDP

-1998), Srrent standed for Fibr (FC-1), Gl Physical nd the tecomponen an extens

aim confo

1

Data & Flow Control

nterface

Bi-directional Example

erial FPDP is a standard whose implementation takes ards. The Serial FPDP speeds of 1.0625 and 2.125 e Channel (FC-0). The encoding / decoding method igabit Ethernet, and other Serial technologies. These and Signaling Interface (FC-PH) standard (ANSI hnology that supports those standards, facilitates the ts in Serial FPDP designs. Although related at a ion of these existing standards.

rmance to this draft standard

0

Chapter 5 - Background

5.1 Parallel FPDP Signals Serial FPDP is conceptually based on the control signals and data structure currently used by Parallel FPDP, and consequentially, allows a straightforward implementation from Parallel FPDP to Serial FPDP. In designs with a Parallel FPDP Host-Bus, the protocol defined in this specification is a mapping of these signals into a serial format for transmission across the serial link. The frame structure used by Parallel FPDP can also be duplicated in a serial format with Serial FPDP. In non-Parallel FPDP Host-Bus designs, such as PCI, these parallel signals need to be simulated or replicated. Table 5-1 lists these Parallel FPDP signals and provides a brief description as defined in the Parallel FPDP specification. For more detailed information on these signals, refer to the Front Panel Data Port Specifications document, ANSI/VITA 17-1998. Permission 5.1.1:

Although Serial FPDP is based on the data and signal structure of Parallel FPDP, Serial FPDP does not require Parallel FPDP to be the Host-Bus or connection as the front-end (input) to a Serial FPDP “Transmitter” design – and it does not require Parallel FPDP to be the Host-Bus or connection as the back-end (output) of a Serial FPDP “Receiver” design. The Host-Bus section of a Serial FPDP design is not considered part of this standard. Designers MAY design either a standard Host-Bus (such as Parallel FPDP or PCI) or a custom Host-Bus interface.

Observation 5.1.1: Although the Parallel FPDP clock signals STROB, PSTROBE, and PSTROBE* would need to be considered if implementing a Parallel FPDP Host-Bus front or back-end to a Serial FPDP design, they are not used by Serial FPDP. They are listed in Table 5-1 for reference only.

Observation 5.1.2: Although not required for Serial FPDP, a Serial FPDP Receiver design with a Parallel FPDP Host-Bus must generate the necessary Parallel FPDP clock signals to clock the FPDP signals out of the Host-Bus interface.

Observation 5.1.3: The Parallel FPDP signals DVALID* and SYNC* that are received by a Parallel FPDP Host-Bus are not directly mapped into the Serial FPDP Fiber Frames, but instead are used to determine which type of Serial FPDP Fiber frame is sent across the link. Likewise, since the state of these signals (DVALID* and SYNC*) are not directly received from the serial link by the Serial FPDP Receiver, the type of Serial FPDP Fiber Frame that is received is used to determine the state of these signals, which are then transmitted by a Parallel FPDP Host-Bus.



Recommendation 5.1.1:

The Parallel FPDP SUSPEND* signal, which is used for Parallel FPDP flow control SHOULD NOT be confused with the Serial FPDP flow control signal (STOP), although they are related. In a Serial FPDP Transmitter which has a Parallel FPDP Host-Bus design, a Serial FPDP “STOP” signal SHOULD result in the Parallel FPDP SUSPEND* signal being asserted, but this SHOULD NOT be implemented as a direct mapping of the STOP signal (Serial FPDP STOP � Parallel FPDP SUSPEND*). It SHOULD be an indirect relationship, with a typical example as follows:

(1) The Serial FPDP STOP signal stops transmissions from the Serial FPDP transmit FIFO. (2) This creates a pending overflow condition in the Serial FPDP transmit FIFO. (3) This Serial FPDP transmit FIFO pending overflow condition asserts the Parallel FPDP

SUSPEND* signal (4) The Parallel FPDP SUSPEND* stops the FPDP source.

SIGNAL NAME COMMENTS D<31:00> Data Bus 32-bit data bus driven by FPDP/TM Interfaces. DIR* Data Direction The FPDP/TM asserts DIR* low. DVALID* Data Valid When asserted, DVALID* indicates that the data bus has valid data. This signal is

generated by the FPDP/TM. STROB Data Strobe STROB is a free running clock supplied by the FPDP/TM. FPDP/R and FPDP/RM

interfaces should sample the data with the rising edge of STROB when DVALID* is asserted.

NRDY* Not Ready NRDY* should be asserted by FPDP/R or FPDP/RM interfaces, when they are not ready to receive data. The FPDP/TM should sample this signal until the FPDP/R or FPDP/RM brings it high, at which time the transfer should commence. Since NRDY* is asynchronous to STROB, the FPDP/TM should double synchronize to it before sampling its state; this avoids metastability problems.

PIO1, PIO2 Programmable I/O

The PIO signals are programmable I/O lines. They may be configured as inputs or outputs.

PSTROBE +PECL Data Strobe

This signal along with PSTROBE* may be generated by the FPDP/TM as an optional differential ±PECL data strobe. PSTROBE is the positive version of the differential clock and has the same polarity as STROB. For high data rate applications, the differential ±PECL data strobe should be used instead of STROB.

PSTROBE* -PECL Data Strobe

This signal is the negative version of the differential PECL data strobe.

Reserved No connection should be made to reserved signals. SUSPEND* Suspend Data SUSPEND* should be generated by FPDP/R or FPDP/RM interfaces to inform the

data source of a pending FIFO overflow condition. The FPDP/TM may delay for no more than 16 cycles in total before suspending the transfer by negating DVALID*. Since SUSPEND* is asynchronous to STROB, the FPDP/TM should double-synchronize to it before sampling its state; this avoids metastability problems.

SYNC* Sync Pulse The FPDP/TM must provide a Sync pulse to FPDP/R and FPDP/RM interfaces to synchronize data transfers when transmitting Single Frame data, Fixed Size Repeating Frame data or Dynamic Size Repeating Frame data. FPDP/R and FPDP/RM interfaces should wait for the Sync pulse before accepting data. FPDP/R and FPDP/RM interfaces should start to accept data on the first Data Valid period following the Sync pulse.

Table 5-1 Parallel FPDP Signals

(This table is not part of this standard but is provided for information only)



5.2 Parallel FPDP Frame Structure This section is not part of this standard, but is provided for information only. Designers should refer to the FPDP Specification (ANSI/VITA 17-1998, Front Panel Data Port Specification). Parallel FPDP defines four different types of data frames: (1) Unframed Data, (2) Single Frame Data, (3) Fixed Size Repeating Frame Data, and (4) Dynamic Size Repeating Frame Data. A brief description of each frame type is provided here. It is important for the Serial FPDP designer to understand the frame structure of Parallel FPDP, because the Serial FPDP Frame structure is based on these Parallel FPDP concepts. Serial FPDP supports all four Parallel FPDP frame types.

Unframed data

�� Used when the source and the organization of the data is not important. �� Used when the Parallel FPDP receivers do not need to be synchronized to the data

stream. �� SYNC* is not used.

When unframed data is transmitted onto the Parallel FPDP bus, no synchronization is required. Thus, the Parallel FPDP/TM must not generate SYNC*, and the Parallel FPDP/RM and Parallel FPDP/R devices must not require a SYNC* pulse in order to correctly receive data. Single frame data

�� Synchronization must occur prior to data to which it applies. �� Synchronization occurs between data blocks. �� SYNC* must be asserted before DVALID* is asserted. �� Synchronization occurs infrequently, perhaps only once.

When single frame data is transmitted onto the Parallel FPDP bus, the Parallel FPDP/TM must assert a SYNC* pulse before valid data starts being transmitted. Valid data is transmitted when the data valid signal DVALID* is asserted. Thus, a SYNC* pulse must be asserted before DVALID* is asserted when transmitting single frame data. After a SYNC* pulse is asserted, the Parallel FPDP/RM and Parallel FPDP/R devices should not accept data until the first STROBE period after DVALID* is asserted. The SYNC* pulse does not have to be asserted again until before the start of the next data transmission. Fixed size repeating frame data

�� Synchronization must occur prior to data to which it applies. �� Synchronization occurs at the same time the last data word in the block is transferred. �� SYNC* must be asserted at the end of the data block while DVALID* is still asserted. �� Because synchronization occurs at the end of the data block, the first data block will not

be synchronized. �� Synchronization occurs frequently. �� All data frames are the same size.



Dynamic size repeating frame data

�� Synchronization must occur prior to data to which it applies. �� Synchronization occurs at the same time the last data word in the block is transferred. �� SYNC* must be asserted at the end of the data block while DVALID* is still asserted. �� Because synchronization occurs at the end of the data block, the first data block will not

be synchronized. �� Synchronization occurs frequently. �� Data frames may vary in size.

When fixed or dynamic size repeating frame data is transmitted onto the Parallel FPDP bus, the Parallel FPDP/TM must assert a SYNC pulse while DVALID* is already asserted. The SYNC* pulse must be asserted at the same time as the last data item of every frame. The Parallel FPDP/RM and Parallel FPDP/R devices must recognize that the current data is the last data item in current frame when both SYNC* and DVALID* are asserted. Since SYNC* is asserted at the end of a frame, the first data frame transmitted will not be synchronized. As a result, the system designer may wish to discard this first unsynchronized data frame. All data frames are the same size when fixed size repeating frame data is transmitted.



Chapter 6 - System Specifications

6.1 Serial FPDP System Configurations This section discusses some of the standard and optional system configurations that are supported by Serial FPDP. A Serial FPDP “system” is considered two or more Serial FPDP interfaces and the appropriate interconnecting cabling. The configurations / features discussed in this section include:

�� Basic System �� Flow Control �� Bi-directional Data Flow �� Copy Mode �� Copy/Loop Mode

Serial FPDP is a data streaming protocol, rather than a network protocol. The protocol header does not provide for node identification or addressing. A Serial FPDP connection provides a link from the source interface to its destination(s). A return link can also optionally be provided. 6.1.1 Basic Serial FPDP Configuration A basic Serial FPDP system consists of a single transmitter, a single receiver, and an inter-connecting cable/link. This configuration does not provide for any feedback or flow control. Figure 6-1 shows this basic configuration

RXTX Data

Figure 6-1 Basic Serial FPDP system configuration Rule 6.1.1.1:

A Serial FPDP link SHALL have only one transmitter.

Rule 6.1.1.2: The average variance of the transmit clock (or re-transmit clock in the case of Copy or Copy/Loop Mode) SHALL not exceed +/-100 Parts per Million (PPM).



Observation 6.1.1.1: The single transmitter, single receiver configuration assumes that the receiving end of the system is capable of receiving and processing the incoming data at a rate sufficient to remain ahead of the transmitter. Failure to assure this transmitter / receiver data rate relationship can result in receiver FIFO overflow and loss of data.

6.1.2 Flow Control (Optional) Serial FPDP supports flow control as an option. The flow control signal is transmitted as part of the Serial FPDP frame structure. Flow control is set by the receiver and returned to the transmitter by a separate cable/link. Figure 6-2 shows the basic Serial FPDP configuration with flow control.

TXRX

Data

Flow Control

RXTX

Figure 6-2 Serial FPDP with Flow Control Rule 6.1.2.1:

A Serial FPDP Link that uses the Flow Control option SHALL consist of a data source or transmit node, a data destination or receive node, and two independent unidirectional interconnecting cables/links with signals flowing in opposite directions. This requires that the receive node have a transmit capability and the transmit node have receive capability.

Rule 6.1.2.2: When flow control is implemented (without bi-directional data flow) and the return cable is connected, the receive node SHALL continuously send empty data frames back to the transmitter. This is to insure that the transmitter is notified of any pending receiver overflow condition.

Rule 6.1.2.3: Flow control may be disabled at the Serial FPDP transmitter. In this condition, (1) the receiving node SHALL still transmit the ordered set for flow control (if it has a transmitter available), and (2) the transmitter SHALL transmit data regardless of any flow control it is receiving.

Observation 6.1.2.1: When a Serial FPDP receiver is designed to accept a continuous stream without the need for flow control, it is OK to always transmit flow control indicating it is ready for data regardless of the state of the input FIFO.



Observation 6.1.2.2: Disabling flow control allows the protocol to work under the following conditions:

�� When there is only a single fiber from the transmitting end point to the receiving end point.

�� The transmit and receive fibers do not go to the same end point. An example of this is a single Serial FPDP Interface operating in the bi-directional mode (see Section 6.1.3) – sending data to one interface and receiving data from a completely independent interface. Figure 6-3 shows a conceptual diagram of this configuration.

TXRX

DataData

RX TX

Figure 6-3 Transmit & Receive Fibers having different end points Flow control is set by the receiver when the receive FIFO is about to go into an overflow condition, which would result in the loss of data. Since the transmission of data does not cease instantaneously, this signal must be set to leave enough space in the receive FIFO to compensate for the receipt of data based on any delays. Designers must consider the delay between when the receiver actually sets the flow control suspend signal, when the transmit node actually stops the transmission of data, and when the data flow actually stops at the receive node. Some variables that impact these delays and thus impact the amount of space that must be allocated in the received FIFO are:

�� The length of the cable (both directions) �� The amount of time required for the transmitter to actually suspend the data transmission �� The baud rate (The higher the baud rate, the more words of data that are on the fiber)

Rule 6.1.2.4:

When flow control is enabled, the flow control suspend signal SHALL be asserted by the receiver at a point which provides sufficient additional capacity in the receive FIFO to store the data that may be received during the time interval between the assertion of the flow control suspend signal (STOP) and the actual stoppage of data at the receiver.

Rule 6.1.2.5: The maximum delay between receipt of the flow control suspend signal (STOP) at the Serial FPDP Transmitter and the actual stoppage of the data transmission SHALL be within thirty-two (32) cycles of the 32-bit transmit clock. This maximum time interval equates to approximately 1.2 �sec. for a 1.0625 Gbaud link, approximately 600 ns for a 2.125 Gbaud link, and approximately 500 ns for a 2.5 Gbaud link.



Rule 6.1.2.6: On receipt of the flow control suspend signal (STOP) at the Serial FPDP Transmitter, the current Fiber Frame being transmitted SHALL be terminated immediately, even if in mid-frame. This is necessary to insure compliance with Rule 6.1.2.5.

Observation 6.1.2.3: The amount of additional capacity needed in the receive FIFO due to cable delay varies depending on the length of the cable and the link rate (either 1.0625 Gbaud, 2.125.Gbaud or 2.5 Gbaud). Assuming five ns/m for the speed of light, a 100 m cable length (50m from transmitter to receiver and return), provides 500 ns of delay due to the cable. Each byte in a 1.0625 Gbaud link takes 9.41 ns (1 sec. / 1,062,500,000 cycles per sec. x 10 bits per byte [8B/10B]) – and each 32-bit word takes 37.64 ns. A 100-meter cable would hold approximately 13-14 words (500 / 37.64). A 2.125 Gbaud link would hold 26-27 words and a 2.5 Gbaud link of the same cable length would hold 31-32 words.

6.1.3 Bi-directional Data Flow (Optional) Serial FPDP supports optional bi-directional data flow. Since flow control is sent across the return cable using standard Serial FPDP frames, this cable can also be used to transmit data. Figure 6-4 shows a bi-directional Serial FPDP configuration with flow control.

TXRX

Data & Flow Control

RXTX

Data & Flow Control

Figure 6-4 Bi-directional Serial FPDP Link Rule 6.1.3.1:

When implementing a bi-directional data flow, each Serial FPDP Transmitter SHALL be implemented independent of each other (except for flow control). A bi-directional Serial FPDP link is actually two separate links.

Observation 6.1.3.1: The “single transmitter” rule is not violated in a bi-directional Serial FPDP configuration. If a bi-directional Serial FPDP link is implemented, each direction is treated as a separate independent link, each one with a single transmitter.



Rule 6.1.3.2: The only relationship between the transmit side and the receive side of a bi-directional Serial FPDP interface SHALL be flow control. The flow control signal that is generated by the receiver of data in one direction is embedded in the Serial FPDP frame trailer of the data flowing in the opposite direction.

Rule 6.1.3.3: Any dependency between opposite flowing data streams in a bi-directional link SHALL be implemented at the application level. The exception to this is flow control (See Rule 6.1.3.2).

Rule 6.1.3.4: The flow control signals for each data transmitter in a bi-directional configuration SHALL be embedded in the data frames of the opposite flowing data streams.

Observation 6.1.3.2: The same rules that apply to flow control for a single direction data link apply to a bi-directional link.

Observation 6.1.3.3: The difference between a single direction Serial FPDP link with flow control and a bi-directional Serial FPDP is that the single directional link transmits empty data frames back to the transmitter, while the bi-directional link transmits data frames containing data.

6.1.4 Copy Mode (Optional) Serial FPDP supports an optional Copy Mode. A Serial FPDP receiver designed with Copy Mode allows the data and control signals sent by the original Serial FPDP transmitter to be received, and then re-transmitted using the transmit section of the receiver. This can be used to send the same bit stream to multiple end points and is very useful for data recording. Figure 6-5 shows the Serial FPDP Copy Mode.

DataData

RXRX TX

Copy Mode

Figure 6-5 Serial FPDP Copy Mode Rule 6.1.4.1:

The transmit node SHALL NOT have its Copy Mode active.



Permission 6.1.4.1: Although a Serial FPDP link is limited to a single Transmitter, a Serial FPDP link MAY have more than one receiver.

Rule 6.1.4.2: If implemented, the optional Serial FPDP Copy Mode SHALL re-transmit all data and control signals generated by the originating transmitter. The only exception to this would be IDLE ordered sets, which may be added or deleted in the process (See Observation 6.1.4.4).

Rule 6.1.4.3: In Copy Mode, the maximum amount of time between the receipt of data by a Serial FPDP receiver and the re-transmission of the data on the next segment of the link SHALL not exceed the time to transmit sixty-four (64) words – which is equal to sixty-four (64) 32-bit clock cycles. This maximum time interval equates to approximately 2.4 �sec. for a 1.0625 Gbaud link, approximately 1.2 �sec. for a 2.125 Gbaud link, and approximately 1.0 �sec. for a 2.5 Gbaud link.

Observation 6.1.4.1: In Copy Mode, flow control is not supported. There is no return line to the transmitter. Since this broadcast approach does not support flow control, each receiver must be capable of receiving and processing the incoming data at a rate sufficient to remain ahead of the transmitter. Failure to assure this transmitter / receiver data rate relationship for all Receivers can result in Receiver FIFO overflow and loss of data.

Observation 6.1.4.2: In Copy Mode, the Serial FPDP receiver is not required to de-serialize and decode the incoming data prior to re-transmitting (copy). Flow control is not used in Copy Mode. Refer to section 6.1.5 (Copy/Loop Mode) on the use of flow control with multiple receivers.

Observation 6.1.4.3: The optional Serial FPDP Copy Mode is not limited to a single receiver. Chaining together a series of receivers with the Copy Mode active allows the original data and control signals to be broadcast to multiple receiver nodes.

Permission 6.1.4.2: If a Serial FPDP Receiver supports Copy Mode, this specification allows the option of bypassing the Receive FIFO (not receiving the data) and only copying or re-transmitting the data to the next node. Therefore, a Serial FPDP Receiver with the Copy Mode Option active MAY (1) receive the data and re-transmit it, or (2) ignore the data and simply re-transmit it.



Observation 6.1.4.4: When implementing Copy or Copy/Loop Mode, there are two possible methods for generating the re-transmit clock: (1) mapping the receive clock directly to the re-transmit path without any decoding of the data; or (2) using the local transmit clock to re-transmit the data independent of the receive clock. In the first method, additional jitter is typically introduced into the circuit while in the second method, the variance or skew between receive and transmit clocks must be taken into account. Both methods will support Copy Mode, while Method 2 is required to support Copy/Loop Mode. The terms “Method 1” and “Method 2” will be used as references in this document to distinguish the two approaches.

Recommendation 6.1.4.1: Because of jitter buildup, the number of receiver nodes in the Copy Mode chain using Method 1 SHOULD be limited to two (2) nodes. This allows for three (3) total nodes in a Serial FPDP system, including the transmitter. Copy Mode implemented using Method 2 does not suffer from this jitter buildup problem, so the maximum number of nodes in the Copy Mode chain can be increased. The number of receiver nodes in a “Method 2” system SHOULD be limited to five (5) nodes. This allows for six (6) total nodes in a Serial FPDP system, including the transmitter.

Recommendation 6.1.4.2: Although not required by this standard, designers SHOULD strongly consider applying Method 2 when implementing the Serial FPDP Copy Mode.

Observation 6.1.4.5: Designers are advised to refer to the referenced document, ANSI X3.272-1996, Fibre Channel Arbitrated Loop (FC-AL) specification, Annex G, for a detailed discussion and example of the clock skew smoothing function, the recommended technique for implementing Method 2 of the Serial FPDP Copy Mode.

Rule 6.1.4.4: If receivers supporting Serial FPDP Copy Mode Method 2 (see Observation 6.1.4.4) are to be supported, the designer SHALL provide for a selectable Copy Master Mode. This Copy Master Mode SHALL provide the transmitter with the ability to add a minimum of three (3) additional IDLE ordered sets to each Fiber Frame type. This translates to at least four (4) IDLEs in the Normal Data and Sync with Data Fiber frames, and at least three (3) IDLEs and a SWDV ordered set in a Sync without Data Fiber frame. (Refer to section 7.3 for a discussion of the various Fiber frames). These extra IDLEs are necessary to support the addition/deletion of IDLEs method of handling the clock variations required in Method 2.

Recommendation 6.1.4.3: Since adding additional IDLEs to the Serial FPDP Fiber frames has the effect of adding overhead to each Fiber frame and reducing the throughput, the Copy Master Mode SHOULD be designed as an optional mode of operation, selectable by either a jumper or control register.



Observation 6.1.4.6: In addition to the direct implementation of the Copy Mode on a Serial FPDP interface, copying or broadcasting the data from a Serial FPDP transmitter can be accomplished using a transparent switch that supports the Serial FPDP link baud rates. However, this broadcast approach does not support flow control (single Transmitter – multiple Receivers), therefore each Receiver must be capable of receiving and processing the incoming data at a rate sufficient to remain ahead of the transmitter. Failure to assure this transmitter / receiver data rate relationship for all Receivers can result in Receiver FIFO overflow and loss of data.

6.1.5 Copy/Loop Mode (Optional) Serial FPDP supports Copy/Loop mode as an option. Copy/loop mode is implemented using the Copy Mode with a return cable from the last receiver back to the transmitter. Receivers in the Copy/Loop Mode must also have the ability to set the flow control signal to tell the transmitter to temporarily back off in the event of a pending Receive FIFO overflow condition. This allows any of the receive nodes to back off the transmitter. Figure 6-6 shows the Serial FPDP Copy/Loop Mode. All discussion, references, rules, recommendations, etc. provided in the Serial FPDP Copy Mode section (Section 6.1.4) apply to the Copy/Loop mode.

RX RX

Data

TX

Figure 6-6 Se Observation 6.1.5.1:

Use of flow control with multiple receiv

Rule 6.1.5.1: The maximum number of receiver nodnodes. This allows for six (6) total nod

Rule 6.1.5.2: Each receive node in the Copy/Loop Mreceive FIFO status using an “OR” typsignal for return to the transmit node.

Do not specify or claim

Serial FPDP, VITA 17.1 – 200x/Draft 0.8a October 16, 2002

Data/Flow Control

Data/ Flow

Control

Data/ Flow

Control

RX RX

rial FPDP Copy/Loop Mode

ers is limited to loop type configurations.

es in a Copy/Loop Mode chain SHALL be limited to five (5) es in a Serial FPDP system, including the transmitter.

ode SHALL set the flow control signal based on its own e function. This allows any of the receive nodes to set this

conformance to this draft standard

22

Permission 6.1.5.1: The Copy/Loop configuration (Figure 6-6) MAY include nodes that are in the Copy Mode as opposed to the Copy/Loop Mode. The nodes in Copy Mode cannot participate in flow control and so must be able to handle the data rate without the need to throttle it. This “Copy Mode Only” condition may be a result of (1) receivers using a Method 1 implementation of Copy Mode or (2) receivers using a Method 2 implementation of Copy Mode but have their flow control disabled.

Rule 6.1.5.3: The transmit node SHALL NOT have its Copy Mode or Copy/Loop Mode active.

Rule 6.1.5.4: In order for the Copy/Loop Mode to operate, a return link to the transmitter must be provided.

Observation 6.1.5.2: In order to assure that data is not lost at the Serial FPDP receiver, it is recommended that the Serial FPDP STOP signal be asserted when enough receive capacity is left in the receive FIFO to accommodate the data that will be received in the time interval between when the STOP signal is set and the actual data flow into the receive FIFO ceases. This requires that the designer consider:

�� The total length of the cable. (See Observation 6.1.2.3) �� Delays attributed to the process of re-transmitting the data and control signals at each

receive node. (See Rule 6.1.4.3 for maximum time interval) �� The delay between the receipt of the flow control signal by the transmit node and the

actual disabling of the transmitter. (See Rule 6.1.2.5 for maximum time interval)



Chapter 7 - Link Specifications

7.1 Overview The theory behind Serial FPDP (on the transmit side) is that the Host-Bus, such as Parallel FPDP, supplies data to a Transmit FIFO and the Serial FPDP logic removes this data from this FIFO, encodes it, serializes it, and transmits it across the link using the framing protocol defined by this specification. The receive side performs in a similar, but reverse manner. Figure 7-1 show a typical Serial FPDP process approach, with the double dashed lines indicating the separation between the Host-Bus side and the Serial FPDP side. The single dashed lines indicate the flow for the optional Copy and Copy/Loop Modes. There are two suggested logical implementation points for Method 2 of Loop and Loop/Copy: (1) at the output of the De-Serializer circuit and, (2) at the output of the Decoder circuit.

Optional Copy Mode – Method 1 (Transmit FIFO Disabled)

Optional Copy or Loop/Copy Mode – Method 2 (Transmit FIFO Disabled)

Receive FIFO

Serial Receiver

De-S i li

DecodeFiber In

Host Bus

Parallel FPDP, PCI, ETC.

Serial Transmitter

Serializer Encoder

Transmit FIFO

Fiber Out

Figure 7-1 Typical Serial FPDP Process Throughout this specification, there will be many references to the existing Parallel FPDP. These references are necessary to explain both the signals generated by the Host-Bus and the Frame structure used by Serial FPDP. These continuous references to Parallel FPDP are not meant to limit the use of FPDP to Parallel FPDP Host-Bus only. For example, products meeting this specification are available with a PCI bus as the Host-Bus. 7.2 Link Bandwidth This standard defines and supports three different link speeds (or link bandwidths): (1) 1.0625 Gbaud – which corresponds to one of the link speeds currently defined by Fibre Channel, (2) 2.125 Gbaud – which corresponds to another of the link speeds currently defined by Fibre Channel, and (3) 2.5 Gbaud. Rule 7.2.1:

A Serial FPDP interface SHALL be capable of operating at 1.0625 Gbaud, 2.125 Gbaud or 2.5 Gbaud across the link.

Permission 7.2.1: Although not required, a single Serial FPDP interface MAY be capable of operating at 1.0625, 2.125 Gbaud, and 2.5 Gbaud, or any combination of the three supported rates.



Observation 7.2.1: An interface operating at one supported link rate and an interface operating at different supported link rate are not intended to inter-operate across the same link. In cases where an interface is capable of operating at multiple rates, a methodology such as a jumper or control bit can be used to configure the interface for operation at the desired rate.

Suggestion 7.2.1: Designers should carefully consider the speed differential (including burst speed) between the Host-Bus and the Serial FPDP link in determining the appropriate Transmit FIFO size. For example, a Host-Bus speed (including possible data burst) that is guaranteed to always operate slower than the effective Serial FPDP link speed will require only a small transmit FIFO. Host-Bus interfaces that allow for high data burst rates will require a larger transmit FIFO in order to avoid possible data losses (disregarding any flow control mechanism that may be in place).

7.3 Serial FPDP Transmission Frames Parallel FPDP defines four different types of data frames: Unframed Data, Single Frame Data, Fixed Size Repeating Data, and Dynamic Size Repeating Frame Data. The characteristics of these Parallel FPDP Frames are generally described in chapter 5 of this document and are described in detail in the Front Panel Data Port Specifications (ANSI/VITA 17-1998) Standard. Serial FPDP supports all four of these Parallel FPDP frames, using a serialized frame structure defined by this standard. The data frame concept is important in many applications to delineate “real life” frame separation, such as a video frame, a radar signal frame, etc. Serial FPDP also uses a serial frame structure in order to send information and maintain synchronization across the link. In order to avoid confusion, this document will refer to a Parallel FPDP frame as a “Parallel FPDP Data Frame” or just “Data Frame” – and will refer to a Serial FPDP Frame as a “Serial FPDP Fiber Frame” or just “Fiber Frame.” For clarification, although “Fiber Frame” references the most common media used for Serial FPDP, Fiber Optic media is not the only media option allowed by this standard. 7.3.1 8B/10B Encoding / Decoding The Serial FPDP uses a transmission protocol based on the standard 8B/10B encoding method, which is commonly used for other standard communication schemes, including Fibre Channel and Gigabit Ethernet. Designers may implement this 8B/10B process by using commercially available components that perform this function, or they may choose to implement the logic directly in some type of programmable device. A complete discussion of this 8B/10B encoding scheme is beyond the scope of this standard. It is a proven serial transmission method and is well documented in readily available technical literature. Serial FPDP uses the 8B/10B process in a manner similar to that used by Fibre Channel. Fibre Channel denotes a certain mapping of the transmission words in the 8B/10B protocol to be ordered sets, which denote special control information for Fibre Channel. Serial FPDP has adopted and uses a subset of the total available ordered sets used by Fibre Channel – as defined in the Fibre Channel Specifications ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface (FC-PH) and ANSI X3.272-1996, Fibre Channel Arbitrated Loop (FC-AL) – to denote control information. Serial FPDP assigns a different meaning to these ordered sets. Table 7-1 shows the ordered sets used by Serial FPDP. The Fibre Channel and the Serial FPDP connotations are also included in this table. These ordered sets make up the Serial FPDP framing protocol.



Ordered

Set Fibre Channel

Meaning Serial FPDP Name

Serial FPDP Meaning Value

IDLE Idle IDLE Idle N-K28.5 D21.4 D21.5 D21.5 R_RDY Receiver_Ready SWDV Start of SYNC Frame, SYNC with

DVALID N-K28.5 D21.4 D10.2 D10.2

SOFc1 SOF Connect Class 1 SOF Start of Frame PIO1, PIO2, DIR = “000”

N-K28.5 D21.5 D23.0 D23.0

SOFi1 SOF Initiate Class1 SOF Start of Frame PIO1, PIO2, DIR = “001”

N-K28.5 D21.5 D23.2 D23.2

SOFn1 SOF Normal Class 1 SOF Start of Frame PIO1, PIO2, DIR = “010”

N-K28.5 D21.5 D23.1 D23.1

SOFi2 SOF Initiate Class 2 SOF Start of Frame PIO1, PIO2, DIR = “011”

N-K28.5 D21.5 D21.2 D21.2


N-K28.5 D21.5 D21.1 D21.1

SOFi3 SOF Initiate Class 3 SOF Start of Frame PIO1, PIO2, DIR = “101”

N-K28.5 D21.5 D22.2 D22.2


N-K28.5 D21.5 D22.1 D22.1

SOFf SOF Fabric SOF Start of Frame PIO1, PIO2, DIR = “111”

N-K28.5 D21.5 D24.2 D24.2

Data Data Data Data Dnn.n Dnn.n Dnn.n Dnn.n EOFdti EOF Disconnect-

Terminate-Invalid FEOF Frame End of Frame

End of a normal data frame N-K28.5 D10.4 D21.4 D21.4 P-K28.5 D10.5 D21.4 D21.4

EOFni EOF Normal-Invalid MEOF Mark End of Frame End of SYNC frame

N-K28.5 D10.4 D21.6 D21.6 P-K28.5 D10.5 D21.6 D21.6

EOFt EOF terminate SEOF Status End of Frame TX FIFO Overflow, NRDY = “00”

N-K28.5 D21.4 D21.3 D21.3 P-K28.5 D21.5 D21.3 D21.3

EOFdt EOF Disconnect-Terminate

SEOF Status End of Frame TX FIFO Overflow, NRDY = “01”

N-K28.5 D21.4 D21.4 D21.4 P-K28.5 D21.5 D21.4 D21.4

EOFa EOF Abort SEOF Status End of Frame TX FIFO Overflow, NRDY = “10”

N-K28.5 D21.4 D21.7 D21.7 P-K28.5 D21.5 D21.7 D21.7

EOFn EOF Normal SEOF Status End of Frame TX FIFO Overflow, NRDY = “11”

N-K28.5 D21.4 D21.6 D21.6 P-K28.5 D21.5 D21.6 D21.6

CLS Close Port GO Suspend = 0 (Flow Control) N-K28.5 D05.4 D21.5 D21.5 NOS Not Operational STOP Suspend = 1 (Flow Control) N-K28.5 D21.2 D31.5 D05.2

Table 7-1 Fibre Channel to Serial FPDP Ordered Sets



7.3.2 Serial FPDP Control Signals Serial FPDP uses a minimal set of status and control signals and encodes them for transmission across the serial link using the ordered sets defined in Table 7-1. There are six status and control signals transmitted across the Serial FPDP Link. These are DIR, PIO1, PIO2, NRDY, TX FIFO Overflow and STOP/GO. The origin of these signals is as follows:

(1) The embedded Serial FPDP signals DIR, PIO1, PIO2, and NRDY are derived from the Parallel FPDP signals DIR*, PIO1, PIO2, and NRDY* in an interface with a Parallel FPDP Host-Bus. These signals must be generated (simulated) by a non-Parallel FPDP Host-Bus. Serial FPDP does not directly use these four signals, but simply transmits them from Host-Bus to Host-Bus.

(2) Serial FPDP directly generates the other two embedded signals, TX FIFO Overflow and the

STOP/GO (Flow Control) signals. The TX FIFO Overflow is asserted to indicate an overflow condition in the Transmit FIFO – indicating a loss of data. The STOP/GO signal is used for Flow Control.

Of the eighteen ordered sets used by Serial FPDP, the eight “Start-of-Frame (SOF)” ordered sets are used to embed the three signals – PIO1, PIO2, and DIR. The four “Status End-of-Frame (SEOF)” ordered sets are used to embed the Serial FPDP signals NRDY and TX FIFO Overflow. The ordered sets GO and STOP are the ordered sets used for Serial FPDP flow control. The other four ordered sets are IDLE, SYNC with Data Valid (SWDV), Frame End-of-Frame (FEOF) and Mark End-of-Frame (MEOF). Rule 7.3.2.1:

The Serial FPDP signal DIR SHALL be generated by the Host-Bus interface of the Serial FPDP Transmitter for embedding in the appropriate ordered set. DIR is a direct translation of the DIR* signal for a Parallel FPDP Host-Bus. DIR SHALL be provided via a status register or similar means in a non-Parallel FPDP Host-Bus interface.

Observation 7.3.2.1: The use of the DIR* signal in Parallel FPDP is not specifically defined and is not directly used by Serial FPDP, therefore, the Serial FPDP signal DIR is available as a user defined signal, if the host bus is not Parallel FPDP at either end of the link.

Rule 7.3.2.2: The Serial FPDP bi-directional signals PIO1 and PIO2 SHALL be generated by the Host-Bus interface of either the Serial FPDP Transmitter or Serial FPDP Receiver for embedding in the appropriate ordered set. The Serial FPDP PIO1 and PIO2 signals are a direct translation of the Parallel FPDP PIO1 and PIO2 signals for a Parallel FPDP Host-Bus. PIO1 and PIO2 SHALL be provided via a status register or similar means in a non-Parallel FPDP Host-Bus interface.

Rule 7.3.2.3: The Serial FPDP signal NRDY SHALL be generated by the Host-Bus interface of the Serial FPDP Receiver for embedding in the appropriate ordered set. NRDY is a direct translation of the NRDY* signal for a Parallel FPDP Host-Bus. NRDY SHALL be provided via a status register or similar means in a non-Parallel FPDP Host-Bus interface.



Observation 7.3.2.2: In a Parallel FPDP Host-Bus system, the NRDY* signal in Parallel FPDP is generated by the Parallel FPDP Receiver and is asserted to indicate that the Receiver is not ready to receive data. It appears from the FPDP specification that NRDY* is typically used during a startup or reset sequence (no specific requirement to check status of NRDY* while in an operational mode). NRDY* has the direct effect of preventing the transmission of data from the Parallel FPDP Transmitter until the Receiver is ready. The Serial FPDP status signal NRDY, which is a direct translation of Parallel FPDP NRDY* is not used directly by the Serial FPDP. A typical sequence between the Parallel FPDP NRDY* and the Serial FPDP status signal NRDY is as follows:

�� NRDY* is sent to the Serial FPDP Receiver Logic from the Parallel FPDP Receiver via the Parallel FPDP Host-Bus.

�� The Serial FPDP Receiver Logic sets the state of the Serial FPDP status signal NRDY

based on the condition of NRDY*, encodes it, and transmits it via the transmit port of the Serial FPDP Receiver to the receive port of the Serial FPDP Transmitter (assuming a two cable system).

�� Upon receipt, the Serial FPDP Transmitter decodes the Serial FPDP NRDY status signal

and sends the NRDY* signal to Parallel FPDP Transmitter via the Parallel FPDP Host-Bus.

There is no requirement for the Serial FPDP Transmitter to take any action on receipt of an asserted NRDY signal from the Serial FPDP Receiver. However, this specification does not prohibit action by the Serial FPDP Logic – such as immediately stopping data from the Serial FPDP Transmitter upon receipt of the NRDY signal by the Serial FPDP Transmitter (similar to the STOP condition).

Rule 7.3.2.4: In a Serial FPDP design with a Parallel FPDP Host-Bus, the embedded Serial FPDP signals DIR, PIO1, PIO2, and NRDY (shown in Table 7-1) SHALL correspond exactly to the Parallel FPDP signals DIR*, PIO1, PIO2 and NRDY* (shown in Table 5-1).

Rule 7.3.2.5: For compatibility with Serial FPDP designs with a Parallel FPDP Host-Bus, designers of non-Parallel FPDP Host-Bus interfaces SHALL simulate or replicate DIR, PIO1, PIO2, and NRDY using a status/control register or similar means.

Observation 7.3.2.3: All five signals (PIO1, PIO2, DIR, NRDY, TX FIFO Overflow) embedded in the SOF and SEOF ordered sets and the GO/STOP ordered sets are transmitted as part of a Fiber Frame rather than within the actual data. Therefore, these signals are asynchronous with regard to the data.



Rule 7.3.2.6: The TX FIFO Overflow signal SHALL be generated by the Serial FPDP Transmitter to communicate that an overflow condition has occurred within the transmit FIFO – causing a potential loss of data.

Observation 7.3.2.4: Although the TX FIFO Overflow signal generated by the Serial FPDP Transmitter is provided to the Serial FPDP Receiver as an embedded signal in the SEOF ordered set, there is no defined action required by the Serial FPDP Receiver based on assertion of the signal by the Transmitter. Careful implementation of the flow control process in a system utilizing flow control should insure that this signal is never asserted.

Observation 7.3.2.5: The Serial FPDP STOP signal is used for flow control and is not intended to be a direct translation of the Parallel FPDP SUSPEND* signal (see Recommendation 5.1.1). The Serial FPDP STOP signal will usually be set as a result of the Parallel FPDP SUSPEND* being asserted, but in some cases this may not be true. If the time interval in which the SUSPEND* is asserted is very short and the Serial FPDP receive FIFO has enough capacity, the Serial FPDP logic may not need to invoke the Serial FPDP STOP. A typical flow of the relationship between a FPDP SUSPEND* signal being asserted and the Serial FPDP status signal STOP being set is as follows:

�� The Parallel FPDP SUSPEND* signal is asserted indicating a pending condition that it will no longer be able to accept data (refer to the FPDP spec. for exact timing requirements).

�� When this SUSPEND* signal is received by the Parallel FPDP Host-Bus logic, it

immediately stops sending data from the Serial FPDP Logic to the Parallel FPDP Receiver.

�� The Serial FPDP receive FIFO will begin to fill and reach a pending Overflow state and

will set the Serial FPDP STOP Status signal.

�� The Serial FPDP STOP signal is transmitted across the link via the Serial FPDP Receiver’s transmit port.

�� The STOP signal is received via the receive port of the Serial FPDP Transmitter and the

Serial FPDP Transmitter immediately halts the transmission of data.

�� The Serial FPDP Transmit FIFO begins to fill up and reaches a pending Overflow state, which then causes the assertion of the Parallel FPDP SUSPEND* signal, which is sent by the Parallel FPDP Host-Bus logic to the Parallel FPDP Transmitter.



Observation 7.3.2.6: In addition to the relationship where the Parallel FPDP SUSPEND* causes the Serial FPDP STOP to be set, it is also possible to have the condition where the Serial FPDP STOP is set without the Parallel FPDP SUSPEND* initiating the action. An obvious example would be a situation where a 2.5 Gbaud link is receiving data at its maximum bandwidth (� 247 MB/sec) and the Parallel FPDP Host-Bus is transmitting it to a Parallel FPDP device using a standard FPDP clock of 40 MHz (160 MB/sec).

7.3.3 Fiber Frames There are three Fiber Frame types defined by Serial FPDP – Normal Data Fiber Frame, SYNC without Data Fiber Frame, and SYNC with Data Fiber Frame. These three Fiber Data Frames support all four types of Parallel FPDP Data frames. Figure 7-2 shows the three types of Fiber Frames. In addition to the four Status End-of-Frame (SEOF) ordered sets discussed in section 7.3.2, there are two additional End-Of-Frame (EOF) ordered sets used by Serial FPDP. These two ordered sets are used to distinguish between a frame that only contains data and a frame that contains SYNC. The Frame End-of-Frame (FEOF) denotes the end of a Normal Data Fiber Frame and the Mark End-of-Frame (MEOF) denotes a Fiber Frame that has SYNC associated with it. Rule 7.3.3.1:

All Serial FPDP Fiber Frames SHALL consist of:

1) at least one IDLE or exactly one Sync with Data Valid (SWDV) ordered set (frame may contain IDLEs preceding the SWDV);

2) a Start of Frame (SOF) ordered set; 3) Data Words (0-512 words); 4) Optional CRC; 5) a Frame End-of-Frame (FEOF) or Mark End-of-Frame (MEOF) ordered set; 6) a Status End-of-Frame (SEOF) ordered set; and 7) a GO/STOP ordered set.

CRC is an optional data word (not a control character or ordered set) that is generated if the CRC function is active. If the data contained in a single frame is maximum length (512 words), CRC represents an additional (# 513) data word.

Observation 7.3.3.1: The maximum size of a Serial FPDP Fiber Frame (excluding optional additional IDLEs preceding the frame) is 518 thirty-two bit words – consisting of an IDLE, SOF, 512 data words, CRC, FEOF, SEOF and GO/STOP. The minimum size of a Serial FPDP Fiber Frame is 5 thirty-two bit words – consisting of an IDLE, SOF, FEOF, SEOF and GO/STOP.

Observation 7.3.3.2: If the Copy Master Mode (see Rule 6.1.4.4) is selected, a minimum of three (3) additional IDLE ordered sets are added to each Fiber Frame type. This translates to four (4) IDLEs in the Normal Data Fiber Frame and the Sync without Data Fiber Frame, and three (3) IDLEs and a SWDV ordered set in the SYNC with Data Fiber Frame.



Rule 7.3.3.2: Serial FPDP Receiver interfaces SHALL be designed to receive all three Serial FPDP Fiber Frame types – Normal Data Fiber Frame, Sync without Data Fiber Frame, and Sync with Data Fiber Frame.

Rule 7.3.3.3: Serial FPDP Transmit interfaces SHALL be designed to transmit Serial FPDP Normal Data Fiber Frames.

Permission 7.3.3.1: Serial FPDP Transmitter designs are not required to support all Serial FPDP Frame types, therefore, in addition to Normal Data Fiber Frames; Serial FPDP Transmitters MAY be designed to transmit either Sync without Data Fiber Frames or Sync with Data Fiber Frames or both.

Recommendation 7.3.3.1: Since SYNC is the primary method of delineating and synchronizing the data at the application level, it is strongly recommended that Serial FPDP Transmitter designs SHOULD support at least one type of SYNC Fiber Frame.

Rule 7.3.3.4: All Serial FPDP Normal Data Fiber Frames and Sync without Data Fiber Frames SHALL be preceded by one or more IDLE ordered sets.

Rule 7.3.3.5: Serial FPDP Sync with Data Fiber Frames SHALL be preceded by exactly one Sync with Data Valid (SWDV) ordered set.

Rule 7.3.3.6: The maximum amount of data that can be sent in a single Serial FPDP Normal Data Fiber Frame is 512 32-bit words (2048 bytes).



SYNC WITH DATA FIBER FRAME (Equivalent to Parallel FPDP /SYNC Asserted, /DVALID Asserted**)

NORMAL DATA FIBER FRAME (Equivalent to Parallel FPDP /SYNC Not Asserted, /DVALID Asserted**)

SOF SWDV

CRC (Optional)

SOF IDLE

CRC (Optional)

NO DATA

SOF IDLE CRC (Optional)

SEOF GO/STOP

MEOF

MEOF SEOF GO/STOP

FEOF SEOF GO/STOP0 to 512 DATA WORDS (32 bit or 4 Byte words)

(Maximum 2048 Bytes)

SYNC WITHOUT DATA FIBER FRAME (Equivalent to Parallel FPDP /SYNC Asserted, /DVALID Not Asserted**)

SOSOSOSOSOSOSOSO

FIFO OV, NRDY EOFt 0,0 EOFdt 0,1 EOFa 1,0 EOFn 1,1

Serial FOctobe

IDLE: An ordered set used to start a DATA or Sync without DATA Frame. (At least one is required)SWDV: An ordered set used to start a SYNC with DATA Frame. (One and only one is required)

PDP, VITA 17r 16, 2002

1 DATA WORD (4 Bytes) associated with SYNC(No more – No less)

PIO1,PIO2,DIR

Fc1 0, 0, 0 Fi1 0, 0, 1 Fn1 0, 1, 0 Fi2 0, 1, 1 Fn2 1, 0, 0 Fi3 1, 0, 1 Fn3 1, 1, 0 Ff 1, 1, 1

Figure 7-2 Serial FPDP Fiber Frames

Do not specify or claim conformance to this draft st

.1 – 200x/Draft 0.8a 32

STOP: Suspend. GO: OK to transmit

FEOF: DATA Frame. MEOF: SYNC Frame
**SYNC* and DVALID* are Parallel FPDP signals used to define Parallel FPDP Data Frames. They are used directly by a serial FPDP design with a Parallel FPDP Host-Bus to determine which type of Fiber Frameto generate for transmission across the link.
andard

Observation 7.3.3.3: In order to provide support for all four types of Parallel FPDP Frames, these Parallel FPDP frames types are mapped into the Serial FPDP Fiber Frame types. The method used to map between the four Parallel FPDP Frames and the three Serial FPDP Frames is as follows.

�� The Parallel FPDP “Unframed Data” frame type requires no frame formatting and does not use SYNC*. This is mapped into Serial FPDP as one or more Serial FPDP “Normal Data Fiber Frames.”

�� The Parallel FPDP “Single Frame Data” frame type requires that a SYNC* be asserted

prior to the data being sent. This is mapped into Serial FPDP as a Serial FPDP Sync without Data Fiber Frame, followed by one or more Serial FPDP Normal Data Frames. The next and following frames of data are handled in the same manner – a Serial FPDP Sync without Data Fiber Frame followed by one or more Serial FPDP Normal Data Frames.

�� The Parallel FPDP “Fixed Size Repeating Frame Data” and “Dynamic Size Repeating

Frame Data” frame types are mapped into Serial FPDP Frames in an identical manner. The size or amount of data that is in the frame does not matter to Serial FPDP. Both of these Parallel FPDP Frames require that the SYNC* be asserted coincident with the last word of the data frame. This is mapped into Serial FPDP as one or more Serial FPDP “Normal Data Frames” followed by a Serial FPDP “Sync with Data Fiber Frame” (containing the last data word) followed by one or more Serial FPDP “Normal Data Frames” followed by a Serial FPDP “Sync with Data Fiber Frame” etc. As is true with Parallel FPDP, the first “Data Frame” is sent prior to the Synchronization signal, and therefore the integrity of the data is questionable.

Observation 7.3.3.4:

Two possible implementations for a Serial FPDP Receiver to identify SYNC without DVALID and SYNC with DVALID frames are: SWDV Method

�� When a MEOF is received and the Serial FPDP Fiber Frame being terminated is not preceded by an SWDV, then the Serial FPDP Fiber Frame is a “SYNC without Data Fiber Frame.”

�� When an MEOF is received and the Serial FPDP Fiber Frame being terminated is

preceded by an SWDV, then the Serial FPDP Fiber Frame is a “SYNC with Data Fiber Frame.”

Ignore SWDV Method

�� When an MEOF is received and the Serial FPDP Fiber Frame being terminated has no data, the Fiber Frame is a Serial FPDP “SYNC without Data Fiber Frame.”

�� When an MEOF is received and the Serial FPDP Fiber Frame being terminated has data,

then the Fiber Frame is a Serial FPDP “SYNC with Data Fiber Frame.”



Rule 7.3.3.7: Although there are multiple methods to detect the Serial FPDP Fiber Frames, the frames SHALL always look like those given in Figure 7-2. The SWDV SHALL always immediately precede the SOF of a “SYNC with Data Fiber Frame.” Additionally, the “SYNC with Data Fiber Frame” SHALL always have exactly one (1) 32-bit data word.

Serial FPDP is designed to be an active link, regardless of the presence of data. Since the status and control bits (part of the Fiber Frame header) may be required to be updated regardless of the availability of actual data, the steady state condition for a transmitter should be to send empty Serial FPDP Normal Data Fiber Frames. In addition, due to the speed of the Serial FPDP Link (especially the 2.5 Gbaud link), there may be occasions when, even during a data transmission sequence (i.e. a Parallel FPDP Data Frame), the transmitter may not see data available for transmission. In this condition, the transmitter should send either IDLE ordered sets or empty Serial FPDP Normal Data Fiber Frames. It should be noted that when the Serial FPDP device detects that no more data is available (even though it occurs in the middle of a data transmission sequence), it must complete the Fiber Frame (CRC if required, FEOF, SEOF, etc.) and start a new Fiber Frame when data is available. Rule 7.3.3.8:

If no data is available at the Serial FPDP Transmitter, the Transmitter SHALL send either empty Serial FPDP Normal Data Fiber Frames or IDLE ordered sets.

Recommendation 7.3.3.2: Since the status and control signals are sent as part of the Serial FPDP Frame, the Serial FPDP device SHOULD send Normal Data Fiber Frames when no data is available at the Serial FPDP Transmitter.

Permission 7.3.3.2: Designers MAY choose to send IDLE ordered sets between Serial FPDP Fiber Frames, especially in the cases where the “no data available” condition at the Serial FPDP Transmitter occurs within a data transmission sequence (i.e. a Parallel FPDP Data Frame).

Suggestion 7.3.3.1: If a transmitter sends IDLE ordered sets rather than empty Serial FPDP Normal Data Fiber Frames when no data is available, it may want to periodically insert an empty Normal Data Fiber Frame. This will guarantee that the control bits are updated at the receive side of the link.

Rule 7.3.3.9: Only IDLE and SWDV (in the very limited situation of directly preceding a Serial FPDP Sync with Data Fiber Frame) ordered sets SHALL be used as padding between Serial FPDP Fiber Frames.

Rule 7.3.3.10: Ordered sets, including IDLE ordered sets, SHALL NOT occur in the data payload portion of a Serial FPDP Fiber Frame.



Observation 7.3.3.5: The control bits are not checked by the CRC. An error on any of them may be detected by an 8B/10B decoding error. If this occurs, the state of that control bit should be ignored. For this reason, sending periodic empty Serial FPDP Normal Data Fiber Frames will guarantee that the control information is kept current, even if link errors should occur.

Observation 7.3.3.6: The calculation of CRC is optional in a Serial FPDP design. Although operating with CRC is preferred, this standard supports three different implementations of this feature: (1) designs that support only CRC (CRC mode only); (2) designs that do not support CRC (No-CRC mode only); and (3) designs that support both CRC and No-CRC. Designers are encouraged to consider interoperability issues when implementing this optional feature. A serial FPDP interface, which only supports CRC SHALL, only interoperate with other Serial FPDP interfaces which support CRC (either CRC only designs or designs which support both CRC and No-CRC). A Serial FPDP interface which only supports No-CRC SHALL only interoperate with other Serial FPDP interfaces which support No-CRC (either No-CRC only designs or designs which support both CRC and No-CRC).

Rule 7.3.3.11: If CRC is implemented, it SHALL be based on the standard CRC-32 commonly used in other common networking technologies, including Ethernet, FDDI, and FibreChannel. It is based on the following generating polynomial:

X32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1.

Permission 7.3.3.3: A Serial FPDP interface MAY support CRC only, No-CRC only, or both CRC and No-CRC.

Observation 7.3.3.7: The No-CRC mode effectively reduces the overhead in the Fiber Frame structure (header/footer) by one 32-bit word (from 6 words to 5 words), effectively increasing the efficiency of the protocol slightly.

Rule 7.3.3.12: If both the CRC and No-CRC feature is supported in a single interface design, selection of the mode (CRC or No-CRC) SHALL be via jumper or control bit.

Rule 7.3.3.13: CRC SHALL be calculated on the actual data stream only, and SHALL NOT include any of the Fiber Frame header words (ordered sets).

Observation 7.3.3.8: The CRC does not provide any error check on any of the control words used to convey control information, such as the SOF; therefore, it does not validate the control words. This means that errors in PIO1, PIO2, DIR, FIFO OV, and NRDY are not detected by the CRC.



Recommendation 7.3.3.3: CRC is sent across the link as a data word and is indistinguishable from the actual data itself. The Serial FPDP Receiver SHOULD check whether the CRC function is enabled in order to determine if the last word received is the CRC or an actual data word.



Chapter 8 - Physical Specifications

8.1 Link Interface Serial FPDP is designed to operate over a variety of serial media. A representative sample of the available media interfaces is shown in Table 8.1. This table is not meant to be all-inclusive, but should be used only as a reference.

Media Type Data Rate Connector Cable Maximum Cable Length

Copper 1.0625 Gbaud

HSSDC HSSDC-2

150 � shielded quad 30 meters with equalized cable 25 meters with non-equalized cable

Copper 2.5 Gbaud HSSDC HSSDC-2

150 � shielded quad 15 meters with equalized cable

Short Wavelength Laser

1.0625 Gbaud

Duplex SC Duplex LC Duplex ST

50 �m multimode fiber 500 meters


2.125 Gbaud

Duplex SC Duplex LC



2.5 Gbaud Duplex SC Duplex LC



1.0625 Gbaud

Duplex SC Duplex LC Duplex ST

62.5 �m multimode fiber

300 meters


2.125 Gbaud

Duplex SC Duplex LC


150 meters




100 meters

Long Wavelength Laser

1.0625 Gbaud

Duplex SC Duplex LC

9 �m single mode fiber 10 kilometers


2.125 Gbaud

Duplex SC Duplex LC





Table 8-1 Media Interfaces



Observation 8.1.1: One of the objectives of this specification is to allow the use of existing components in the development of Serial FPDP interface devices. In addition, this specification does not limit the type of media that may be selected and used between Serial FPDP interfaces. Therefore, designers should consider the intended application and interoperability requirements when selecting a particular media type. Serial FPDP has adopted some common guidelines to aid in this design process. For the 1.0625 Gbaud and 2.125 Gbaud Short Wavelength Laser links, Serial FPDP has adopted, as a guideline, the optical characteristics specified in the FibreChannel specification FC-PH-2 (ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2), section 6.2 Table 9B. A subset of these characteristics is also provided in Table 8-2. For the 1.0625 Gbaud Long Wavelength Laser links, Serial FPDP has adopted, as a guideline, the characteristics specified in the FibreChannel specification FC-PH (ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface), section 6.1 Table 6. Similarly, the 2.125 Gbaud Long Wavelength Laser links follow the characteristics specified in the FibreChannel specification FC-PH-2 (ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2), section 6.1 Table 6. A subset of these characteristics is also provided in Table 8-3 of this document. The suggested guidelines for 2.5 Gbaud laser link characteristic for Serial FPDP devices are also specified in Tables 8-2 and 8-3.



Units 100-M5-SN-I ** 200-M5-SN-I ** Not defined Nominal bit rate Tolerance

Gbaud ppm

1.0625 +/-100

2.125 +/-100

2.500 +/-100

Transmitter Type � (1) Spectral width (max.) Launched power, max. Launch power, min. (3) Extinction ratio RIN12 (max.) Eye opening (2) Deterministic jitter Random jitter Optical rise/fall time (4)

nm (min.) nm (max.) nm RMS nm FWHM dBm (ave.) dBm (ave.) dBm (min.) dB/Hz % (min.) % (p-p) % (p-p) ns(max.)

Laser 770 860 4 NA -5 -10 9 -116 57 20 NA .45

Laser 770 860 4 NA -5 -10 9 -118 57 20 NA .22

Laser 770 860 4 NA -5 -10 9 -120 57 20 NA .20

Receiver Receiver power, min. (3) Receiver power, max. Return loss (receiver) Deterministic jitter Random jitter Optical rise/fall time

dBm (ave.) dBm (ave.) dBm (min.) % (p-p) % (p-p) ns(max.)

-16 0 12 NA NA .6

-16 0 12 NA NA .3

-16 0 12 NA NA .2

(1) Spectral center wavelength (2) @BER�10-12

(3) A 6 dB system budget is specified for both 50 um fiber and 61.2 um fiber. Of this 6 dB budget, 4 dB is allocated for cable plant losses and 2 dB is allocated for a system power penalty as described in clause 6.2.4 of the reference document -- FibreChannel specification FC-PH-2 (ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2). (4) The optical tr and tf for lasers are specified from 20% to 80%. (5) Maximum launched power may exceed –5 dBm as long as launched power does not exceed 0 dBm and complies with applicable laser safety standards. ** This is a nomenclature adopted from FibreChannel – reference section 5.7 of the FibreChannel specifications (FC-PH ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface) or FC-PH-2 (ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2).

Table 8-2 Short-Wave Laser Media Characteristics (Example)



Units 100-SM-LL-IL** 200-SM-LL-I ** Not defined Nominal bit rate Tolerance

Gbaud ppm

1.0625 +/-100

2.125 +/-100

2.500 +/-100

Transmitter (S) Type � (1) Spectral width (max.) Launched power, max. Launch power, min. Extinction ratio RIN12 (max.) Eye opening (2) Deterministic jitter

nm (min.) nm (max.) nm RMS dBm (ave.) dBm (ave.) dBm (min.) dB/Hz % (min.) % (p-p)

Laser 1285 1330 3 -3 -9 9 -116 57 20

Laser 1270 1355 6 -3 -12 9 -116 57 20

Laser 1270 1355 6 -3 -12 9 -116 57 20

Receiver (R) Receiver power, min. Receiver power, max. Optical path penalty Return loss (receiver)

dBm (ave.) dBm (ave.) dBm (max.) % (p-p)

-25 -3 2 12

-20 -3 2 12

-20 -3 2 12

(1) Spectral center wavelength (2) @BER�10-12

** This is a nomenclature adopted from FibreChannel – reference section 5.7 of the FibreChannel specifications (FC-PH ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface) or FC-PH-2 (ANSI X3.297-1997, Fibre Channel Physical and Signaling Interface - 2).

Table 8-3 Long-Wave Laser Media Characteristics (Example)



Appendix A - Interoperability Issues

One of the key issues underlying this standard is to permit interoperability between products developed by different companies. Due to the variety of optional features in a Serial FPDP design, designers and operators must be aware of potential incompatibility issues. Presented here is a checklist (Table A-1) of features that should be considered when designing and operating Serial FPDP products. In order to reduce confusion when connecting Serial FPDP interfaces from different companies, suppliers are encouraged to copy the attached checklist and provide this information to the users of their devices as part of their vendor documentation.



(Check all that apply)

1) What Link Rates does the interface support?

� 1.0625 Gbaud � 2.125 Gbaud � 2.5 Gbaud

2) What Serial FPDP function does the interface support?

� Transmitter only � Receiver only � Transmitter and Receiver

3) Does the Receiver support Flow Control (setting the STOP signal)?

� Always active � Not supported � Optional (selectable)

4) Does the Transmitter support Flow Control (stopping data transmission on receipt of a STOP signal)?


5) If the Transmitter supports Flow Control, after transmitting a STOP signal, how many 32-bit words can be received before a Receive FIFO overflow occurs.

____________ 32-bit words

6) Does the interface support CRC?


7) Does the Transmitter support Copy Master Mode (insertion of additional IDLE ordered sets)?


8) Does the Receiver support Copy Mode (re-transmission of data)?

� Yes � No

9) If Copy Mode is supported, what method is used for implementation (see Observation 6.1.4.4)?

� Method 1 � Method 2

10) Does the Receiver Support Copy/Loop Mode (re-transmission of data and setting Flow Control)?

� Yes � No

11) What type of media is supported?

� Short Wave Laser � Long Wave Laser � Copper � Other

12) What type of media connectors?

� LC � SC � ST � HSSDC/ HSSDC-2 � Other

13) Which fiber transmit data frames are supported in addition to Normal Data Fiber Frames (see Permission 7.3.3.1)?

� Sync without Data Fiber Frames � Sync with Data Fiber Frames

14) Does the Serial FPDP Transmitter stop in response to the Serial FPDP Receiver sending NRDY True (see Observation 7.3.2.2)?

� Always � Never � Optional (selectable)

15) Are status bits kept up to date when there is no data to transmit – by sending empty Serial FPDP Normal Data Fiber (see Rule 7.3.3.8, Recommendation 7.3.3.2 and Suggestion 7.3.3.1)?

� Yes, empty frames transmitted � No, status is not updated when no data is transmitted

Table A-1 Serial FPDP Interoperability Checklist



Appendix B – Implementation Considerations

(Information Only – Not intended to be a direct part of this Standard)

�� The information in this appendix is meant to provide general guidance regarding the characteristics and intended usage of Serial FPDP. It is not intended to add to or modify this specification.

�� The link is intended to be very simple and provide low-latency, and contains very limited error

correcting capability. In most instances, it is left to the application code to decide what to do in order to recover from link errors.

�� It is strongly recommended that the FPDP data frame type "Unframed Data" be avoided. With

Unframed Data, if data is lost due to a link error it is very difficult for the receiving application to re-synchronize to the data stream.

�� Due to the need for re-synchronization of the data in the event of a link error, designers are

encouraged to provide the capability to generate at least one type of SYNC frame.

�� When link problems cause data to be lost, one option for recovery is to throw out data until the next FPDP data frame starts. This technique can also be used when the link is first started up, where data is thrown way until the start of an FPDP data frame.

�� User should be aware that there might be some garbage in receive and transmit FIFOs during

startup and in response to link errors. Error flags can be used to identify when data should be discarded, but the handling these error conditions must we done at the application level.

�� It is recommended that CRCs be used in order to help identify data that is erroneous.

�� PIO bits are not protected by a CRC.

�� Use of flow control is highly recommended, especially if the Receiver Host-Bus is a non real-time

interface (i.e. PCI on a Solaris or Windows systems). In addition to the potential loss of data, the impact on the ability of the operating system to recover from an overflow condition is uncertain.



serial front panel data port (fpdp) draft standard vita 17

Documents