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 2 October 16, 2002
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 Date Comments Number 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 3 October 16, 2002 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]
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 4 October 16, 2002
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
Recommendation
Suggestion
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 5 October 16, 2002 Permission
Observation
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 6 October 16, 2002
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
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 7 October 16, 2002
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 8 October 16, 2002
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.
Serial FPDP Data Serial FPDP OUT IN Data Destination Data With Source Flow FPDP IN With Control FPDP OUT (Optional) FPDP/RM FPDP IN FPDP OUT FPDP/R FPDP/TM FPDP/RM FPDP/TM FPDP/R Host-Bus Interface
Parallel FPDP Parallel FPDP Connection Connection Up to10 kilometer (Serial FPDP)
Figure 4-1 Typical Parallel FPDP to Serial FPDP Application
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 9 October 16, 2002 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 Data & Flow Serial FPDP OUT IN Control
IN OUT
Data & Flow Control
Host-Bus Interface
Figure 4-2 Serial FPDP Bi-directional Example
In addition to Parallel FPDP (ANSI/VITA 17-1998), Serial FPDP is a standard whose implementation takes advantage of elements of other existing current standards. The Serial FPDP speeds of 1.0625 and 2.125 Gbaud correspond to the link speeds defined for Fibre Channel (FC-0). The encoding / decoding method corresponds to that used in Fibre Channel (FC-1), Gigabit Ethernet, and other Serial technologies. These are described in detail in the Fibre Channel Physical and Signaling Interface (FC-PH) standard (ANSI X3.230-1994). Using existing standards, and the technology that supports those standards, facilitates the use of more common and more available components in Serial FPDP designs. Although related at a basic level, Serial FPDP is not meant to be an extension of these existing standards.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 10 October 16, 2002
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 11 October 16, 2002
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 U 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 The PIO signals are programmable I/O lines. They may be configured as inputs or I/O outputs. PSTROBE +PECL Data This signal along with PSTROBE* may be generated by the FPDP/TM as an Strobe 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 This signal is the negative version of the differential PECL data strobe. 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)
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 12 October 16, 2002 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
S Used when the source and the organization of the data is not important. S Used when the Parallel FPDP receivers do not need to be synchronized to the data stream. S 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
S Synchronization must occur prior to data to which it applies. S Synchronization occurs between data blocks. S SYNC* must be asserted before DVALID* is asserted. S 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
S Synchronization must occur prior to data to which it applies. S Synchronization occurs at the same time the last data word in the block is transferred. S SYNC* must be asserted at the end of the data block while DVALID* is still asserted. S Because synchronization occurs at the end of the data block, the first data block will not be synchronized. S Synchronization occurs frequently. S All data frames are the same size.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 13 October 16, 2002 Dynamic size repeating frame data
S Synchronization must occur prior to data to which it applies. S Synchronization occurs at the same time the last data word in the block is transferred. S SYNC* must be asserted at the end of the data block while DVALID* is still asserted. S Because synchronization occurs at the end of the data block, the first data block will not be synchronized. S Synchronization occurs frequently. S 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 14 October 16, 2002
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:
S Basic System S Flow Control S Bi-directional Data Flow S Copy Mode S 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
Data TX RX
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).
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 15 October 16, 2002 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.
Data TX RX RX TX Flow Control
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 16 October 16, 2002 Observation 6.1.2.2:
Disabling flow control allows the protocol to work under the following conditions:
S When there is only a single fiber from the transmitting end point to the receiving end point.
S 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.
Data Data
RX TX 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:
S The length of the cable (both directions) S The amount of time required for the transmitter to actually suspend the data transmission S 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 17 October 16, 2002 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.
Data & Flow Control TX RX RX TX 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 18 October 16, 2002 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.
Data Data
TX RX RX
Copy Mode
Figure 6-5 Serial FPDP Copy Mode
Rule 6.1.4.1:
The transmit node SHALL NOT have its Copy Mode active.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 19 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 20 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 21 October 16, 2002 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.
Data/Flow Control
Data/ Data/ Data Flow Flow Control Control
RX TX RX RX RX
Figure 6-6 Serial FPDP Copy/Loop Mode
Observation 6.1.5.1:
Use of flow control with multiple receivers is limited to loop type configurations.
Rule 6.1.5.1:
The maximum number of receiver nodes in a Copy/Loop Mode chain SHALL be limited to five (5) nodes. This allows for six (6) total nodes in a Serial FPDP system, including the transmitter.
Rule 6.1.5.2:
Each receive node in the Copy/Loop Mode SHALL set the flow control signal based on its own receive FIFO status using an “OR” type function. This allows any of the receive nodes to set this signal for return to the transmit node.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 22 October 16, 2002 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:
S The total length of the cable. (See Observation 6.1.2.3) S 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) S 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)
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 23 October 16, 2002
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.
Fiber Out Transmit Encode Serializer Serial
Host FIFO r Transmitter Bus Optional Copy or Loop/Copy Mode – Optional Copy Mode – Parallel Method 2 (Transmit Method 1 (Transmit FIFO FPDP, FIFO Disabled) Disabled) PCI, ETC. Receive Decode De- Serial FIFO Sili Receiver Fiber In
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 24 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 25 October 16, 2002
Ordered Fibre Channel Serial Serial FPDP Meaning Value Set Meaning FPDP Name IDLE Idle IDLE Idle N-K28.5 D21.4 D21.5 D21.5 R_RDY Receiver_Ready SWDV Start of SYNC Frame, SYNC with N-K28.5 D21.4 D10.2 D10.2 DVALID SOFc1 SOF Connect Class 1 SOF Start of Frame N-K28.5 D21.5 D23.0 D23.0 PIO1, PIO2, DIR = “000” SOFi1 SOF Initiate Class1 SOF Start of Frame N-K28.5 D21.5 D23.2 D23.2 PIO1, PIO2, DIR = “001” SOFn1 SOF Normal Class 1 SOF Start of Frame N-K28.5 D21.5 D23.1 D23.1 PIO1, PIO2, DIR = “010” SOFi2 SOF Initiate Class 2 SOF Start of Frame N-K28.5 D21.5 D21.2 D21.2 PIO1, PIO2, DIR = “011” SOFn2 SOF Normal Class 2 SOF Start of Frame N-K28.5 D21.5 D21.1 D21.1 PIO1, PIO2, DIR = “100” SOFi3 SOF Initiate Class 3 SOF Start of Frame N-K28.5 D21.5 D22.2 D22.2 PIO1, PIO2, DIR = “101” SOFn3 SOF Normal Class 3 SOF Start of Frame N-K28.5 D21.5 D22.1 D22.1 PIO1, PIO2, DIR = “110” SOFf SOF Fabric SOF Start of Frame N-K28.5 D21.5 D24.2 D24.2 PIO1, PIO2, DIR = “111” Data Data Data Data Dnn.n Dnn.n Dnn.n Dnn.n EOFdti EOF Disconnect- FEOF Frame End of Frame N-K28.5 D10.4 D21.4 D21.4 Terminate-Invalid End of a normal data frame P-K28.5 D10.5 D21.4 D21.4 EOFni EOF Normal-Invalid MEOF Mark End of Frame N-K28.5 D10.4 D21.6 D21.6 End of SYNC frame P-K28.5 D10.5 D21.6 D21.6 EOFt EOF terminate SEOF Status End of Frame N-K28.5 D21.4 D21.3 D21.3 TX FIFO Overflow, NRDY = “00” P-K28.5 D21.5 D21.3 D21.3 EOFdt EOF Disconnect- SEOF Status End of Frame N-K28.5 D21.4 D21.4 D21.4 Terminate TX FIFO Overflow, NRDY = “01” P-K28.5 D21.5 D21.4 D21.4 EOFa EOF Abort SEOF Status End of Frame N-K28.5 D21.4 D21.7 D21.7 TX FIFO Overflow, NRDY = “10” P-K28.5 D21.5 D21.7 D21.7 EOFn EOF Normal SEOF Status End of Frame N-K28.5 D21.4 D21.6 D21.6 TX FIFO Overflow, NRDY = “11” 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
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 26 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 27 October 16, 2002 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:
S NRDY* is sent to the Serial FPDP Receiver Logic from the Parallel FPDP Receiver via the Parallel FPDP Host-Bus.
S 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).
S 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 28 October 16, 2002 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:
S 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).
S 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.
S The Serial FPDP receive FIFO will begin to fill and reach a pending Overflow state and will set the Serial FPDP STOP Status signal.
S The Serial FPDP STOP signal is transmitted across the link via the Serial FPDP Receiver’s transmit port.
S 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.
S 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 29 October 16, 2002 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 (W 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 30 October 16, 2002 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).
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 31 October 16, 2002
NORMAL DATA FIBER FRAME (Equivalent to Parallel FPDP /SYNC Not Asserted, /DVALID Asserted**)
GO/ IDLE SOF 0 to 512 DATA WORDS (32 bit or 4 Byte words) CRC FEOF SEOF STOP (Maximum 2048 Bytes) (Optional)
SYNC WITHOUT DATA FIBER FRAME (Equivalent to Parallel FPDP /SYNC Asserted, /DVALID Not Asserted**)
GO/ IDLE SOF NO DATA CRC MEOF SEOF (Optional) STOP
SYNC WITH DATA FIBER FRAME
(Equivalent to Parallel FPDP /SYNC Asserted, /DVALID Asserted**)
CRC SWDV SOF 1 DATA WORD (4 Bytes) associated with SYNC MEOF SEOF GO/ (Optional) (No more – No less) STOP
FEOF: DATA Frame. MEOF: SYNC Frame PIO1,PIO2,DIR
SOFc1 0, 0, 0 FIFO OV, NRDY SOFi1 0, 0, 1 EOFt 0,0 SOFn1 0, 1, 0 EOFdt 0,1
SOFi2 0, 1, 1 EOFa 1,0 SOFn2 1, 0, 0 EOFn 1,1 SOFi3 1, 0, 1 SOFn3 1, 1, 0 SOFf 1, 1, 1 STOP: Suspend. GO: OK to transmit
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)
**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 Frame to generate for transmission across the link.
Figure 7-2 Serial FPDP Fiber Frames
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 32 October 16, 2002 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.
S 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.”
S 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.
S 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
S 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.”
S 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
S 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.”
S 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.”
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 33 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 34 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 35 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 36 October 16, 2002
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 HSSDC 150 shielded quad 30 meters with Gbaud HSSDC-2 equalized cable 25 meters with non-equalized cable Copper 2.5 Gbaud HSSDC 150 shielded quad 15 meters with HSSDC-2 equalized cable Short 1.0625 Duplex SC 50 m multimode fiber 500 meters Wavelength Gbaud Duplex LC Laser Duplex ST Short 2.125 Duplex SC 50 m multimode fiber 300 meters Wavelength Gbaud Duplex LC Laser Short 2.5 Gbaud Duplex SC 50 m multimode fiber 150 meters Wavelength Duplex LC Laser Short 1.0625 Duplex SC 62.5 m multimode 300 meters Wavelength Gbaud Duplex LC fiber Laser Duplex ST Short 2.125 Duplex SC 62.5 m multimode 150 meters Wavelength Gbaud Duplex LC fiber Laser Short 2.5 Gbaud Duplex SC 62.5 m multimode 100 meters Wavelength Duplex LC fiber Laser Long 1.0625 Duplex SC 9 m single mode fiber 10 kilometers Wavelength Gbaud Duplex LC Laser Long 2.125 Duplex SC 9 m single mode fiber 2 kilometers Wavelength Gbaud Duplex LC Laser Long 2.5 Gbaud Duplex SC 9 m single mode fiber 2 kilometers Wavelength Duplex LC Laser
Table 8-1 Media Interfaces
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 37 October 16, 2002 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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 38 October 16, 2002
Units 100-M5-SN-I ** 200-M5-SN-I ** Not defined Nominal bit rate Gbaud 1.0625 2.125 2.500 Tolerance ppm +/-100 +/-100 +/-100
Transmitter Type Laser Laser Laser (1) nm (min.) 770 770 770 nm (max.) 860 860 860 Spectral width (max.) nm RMS 4 4 4 nm FWHM NA NA NA Launched power, max. dBm (ave.) -5 -5 -5 Launch power, min. (3) dBm (ave.) -10 -10 -10 Extinction ratio dBm (min.) 9 9 9 RIN12 (max.) dB/Hz -116 -118 -120 Eye opening (2) % (min.) 57 57 57 Deterministic jitter % (p-p) 20 20 20 Random jitter % (p-p) NA NA NA Optical rise/fall time (4) ns(max.) .45 .22 .20 Receiver Receiver power, min. (3) dBm (ave.) -16 -16 -16 Receiver power, max. dBm (ave.) 0 0 0 Return loss (receiver) dBm (min.) 12 12 12 Deterministic jitter % (p-p) NA NA NA Random jitter % (p-p) NA NA NA Optical rise/fall time ns(max.) .6 .3 .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)
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 39 October 16, 2002
Units 100-SM-LL-IL** 200-SM-LL-I ** Not defined Nominal bit rate Gbaud 1.0625 2.125 2.500 Tolerance ppm +/-100 +/-100 +/-100 Transmitter (S) Type Laser Laser Laser (1) nm (min.) 1285 1270 1270 nm (max.) 1330 1355 1355 Spectral width (max.) nm RMS 3 6 6 Launched power, max. dBm (ave.) -3 -3 -3 Launch power, min. dBm (ave.) -9 -12 -12 Extinction ratio dBm (min.) 9 9 9 RIN12 (max.) dB/Hz -116 -116 -116 Eye opening (2) % (min.) 57 57 57 Deterministic jitter % (p-p) 20 20 20 Receiver (R) Receiver power, min. dBm (ave.) -25 -20 -20 Receiver power, max. dBm (ave.) -3 -3 -3 Optical path penalty dBm (max.) 2 2 2 Return loss (receiver) % (p-p) 12 12 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)
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 40 October 16, 2002
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 41 October 16, 2002 (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)? Always active Not supported Optional (selectable) 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? Always active Not supported Optional (selectable) 7) Does the Transmitter support Copy Master Mode (insertion of additional IDLE ordered sets)? Always active Not supported Optional (selectable) 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
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 42 October 16, 2002
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.
Do not specify or claim conformance to this draft standard
Serial FPDP, VITA 17.1 – 200x/Draft 0.8a 43 October 16, 2002