Aurora 8b10b Protocol Spec sp002

Aurora 8B/10B
Protocol Specification
SP002 (v2.1) June 24, 2009
R
R
Xilinx is disclosing to you this Specification (hereinafter "the Specification") for use in the development of designs in connection with
semiconductor devices. Xilinx expressly disclaims any liability arising out of your use of the Specification. Xilinx does not convey any license
under its patents, copyrights, or any rights of others in connection with the Specification. You are responsible for obtaining any rights you
may require for your use or implementation of the Specification. Xilinx reserves the right to make changes, at any time, to the Specification
without notice and at the sole discretion of Xilinx. Xilinx assumes no obligation to correct any errors contained in the Specification or to
advise you of any corrections or updates. Xilinx expressly disclaims any liability in connection with technical support or assistance that may
be provided to you in connection with the Specification.
THE SPECIFICATION IS DISCLOSED TO YOU "AS-IS" WITH NO WARRANTY OF ANY KIND. YOU BEAR THE ENTIRE RISK AS TO ITS
IMPLEMENTATION AND USE. YOU ACKNOWLEDGE AND AGREE THAT YOU HAVE NOT RELIED ON ANY ORAL OR WRITTEN
INFORMATION OR ADVICE, WHETHER GIVEN BY XILINX, ITS EMPLOYEES OR CONTRACTORS. XILINX MAKES NO OTHER
WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING THE SPECIFICATION, INCLUDING ANY
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT OF THIRD-PARTY
RIGHTS.
IN NO EVENT WILL XILINX BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, EXEMPLARY, SPECIAL, OR INCIDENTAL DAMAGES,
INCLUDING ANY LOSS OF DATA OR LOST PROFITS, ARISING FROM OR RELATING TO YOUR USE OF THE SPECIFICATION, EVEN
IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
© 2002-2009 Xilinx, Inc. XILINX, the Xilinx logo, Virtex, Spartan, ISE, and other designated brands included herein are trademarks of Xilinx
in the United States and other countries. All other trademarks are the property of their respective owners.
Revision History
The following table shows the revision history for this document.
Date Version Revision

10/16/02 1.0 Initial Xilinx Release.
02/14/03 1.1 Added Flow Control section. Edited text and figures for clarification.
Miscellaneous edits to text and figures throughout.
Clarifications to State Machine Conventions in the preface, and Section 1
Introduction and Overview.
Added Overview to Section 2 Data Transmission and Reception.
Added sections 3.1.2 Native Flow Control Latency, and 3.1.4 User Flow Control
Operation, and added Table 3-2 user flow control SIZE Encoding table to Section 3
10/17/03 1.2
Flow Control.
Corrected Lane Initialization procedure, and Channel Verification in Section 4
Initialization and Error Handling.
Additions to section 5.4.8 Idle Sequence, and section 5.4.11 Multi-Lane Striping and
Transmission Rules in Section 5 PCS and PMA Layers.
Corrections to Section 6 Electrical Specification.
06/21/04 1.3 Added 64B/66B feature.
Removed 64B/66B feature. Clarified Section 4.2.1 “8B/10B Lane Initialization” and
09/19/07 2.0 Figure B-3, page 61 and the Notes section in Figure 5-6, page 37 and Figure 5-8,
page 39.
06/24/09 2.1 Replaced instances of Aurora with Aurora 8B/10B. Corrected Figure 4-2, page 23.
Aurora 8B/10B Protocol Specification www.xilinx.com SP002 (v2.1) June 24, 2009
Table of Contents
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Preface: About This Specification

Open Standard Specification Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Typographical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Online Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Numerical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Values of Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
State Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Section 1: Introduction and Overview

1.1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2: Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Section 2: Data Transmission and Reception

2.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2: 8B/10B Data Transmission and Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1: Symbol-Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2: Data Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3: Transmission Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4: User PDU Transmission Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.5: User PDU Reception Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Section 3: Flow Control

3.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1: Native Flow Control Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2: Native Flow Control Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.3: Native Flow Control PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4: User Flow Control Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.5: User Flow Control PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Section 4: Initialization and Error Handling

4.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2: 8B/10B Initialization and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1: 8B/10B Lane Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2: 8B/10B Channel Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3: 8B/10B Channel Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.4: 8B/10B Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Aurora 8B/10B Protocol Specification www.xilinx.com 3

SP002 (v2.1) June 24, 2009
R
Section 5: PCS and PMA Layers

5.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2: PCS Layer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3: PMA Layer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4: 8B/10B Transmission Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.1: Character and Code Group Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2: Running Disparity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.3: Running Disparity Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.4: 8B/10B Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4.5: Transmission Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4.6: 8B/10B Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.7: Ordered Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.8: Idle Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.9: Clock Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.10: Single-Lane Transmission Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.11: Multi-Lane Striping and Transmission Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Section 6: Electrical Specifications

6.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2: Signal Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3: Equalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4: Transmitter Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5: Receiver Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.6: Receiver Eye Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix A: 8B/10B Coding Reference

A.1: 8B/10B Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Appendix B: Aurora 8B/10B Serial Simplex Operation

B.1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
B.2: Data Transmission and Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.3: Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.4: Initialization and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.5: Serial Simplex vs. Full-Duplex Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B.5.1: Transmit Interface Lane initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B.5.2: Receive Interface Lane Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.5.3: Transmit Interface Channel Bonding Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.5.4: Receive Interface Channel Bonding Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.5.5: Transmit Interface Channel Verification Procedure . . . . . . . . . . . . . . . . . . . . . . 62
B.5.6: Receive Interface Channel Verification Procedure . . . . . . . . . . . . . . . . . . . . . . . 63
B.5.7: Receive Interface Hard Error Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.5.8: Use Models for Aurora 8B/10B Serial Simplex . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Appendix C: References
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 www.xilinx.com Aurora 8B/10B Protocol Specification

SP002 (v2.1) June 24, 2009
R
Preface
About This Specification

The Aurora 8B/10B protocol is a scalable, lightweight, link-layer protocol that can be used
to move data point-to-point across one or more high-speed serial lanes. The Aurora 8B/10B
protocol is an open standard and is available for implementation by anyone without
restriction.
Open Standard Specification Contents

This Specification contains the following sections:
• Section 1, “Introduction and Overview”
• Section 2, “Data Transmission and Reception”
• Section 3, “Flow Control”
• Section 4, “Initialization and Error Handling”
• Section 5, “PCS and PMA Layers”
• Section 6, “Electrical Specifications”
• Appendix A, “8B/10B Coding Reference”
• Appendix B, “Aurora 8B/10B Serial Simplex Operation”
Conventions
This document uses the following conventions.
Typographical
The following typographical conventions are used in this document:
Convention Meaning or Use Example

See the Development System
References to other manuals Reference Guide for more
information.
If a wire is drawn so that it
Italic font
Emphasis in text overlaps the pin of a symbol, the
two nets are not connected.
To emphasize a term the first time The state machine uses one-hot
it is used encoding.

SP002 (v2.1) June 24, 2009
R

Abbreviations or acronyms for
registers are shown in uppercase
REG[FIELD] REG[11:14]
text. Specific bits, fields, or ranges
appear in brackets
Online Document
The following conventions are used in this document:

See the section “Additional
Cross-reference link to a location Resources” for details.
Blue text
in the current document Refer to “Title Formats” in
Section 1 for details.
Cross-reference link to a location See Figure 2-5 in the Virtex-5
Red text
in another document FPGA User Guide.
Go to http://www.xilinx.com
Blue, underlined text Hyperlink to a website (URL)
for the latest speed files.
Numerical
n A decimal value
Used to express a numerical
[n:m]
range from n to m
x Unknown value
z High impedance
Values of Literals
Literals are represented by specifying three of their properties as listed and shown in
Figure P-1 and in Table P-1 and Table P-2, page 7:
1. Width in bits
2. Radix (Base)
3. Value
X-Ref Target - Figure P-1
width in bits ' radix value

SP000_PF_01_031408
Figure P-1: Properties of Literals
Table P-1 shows the Radix specifics:

SP002 (v2.1) June 24, 2009
R
Conventions
Table P-1: Radix Specifics of Literals

Radix Specifier Radix
b Binary
d Decimal
h Hexadecimal
o Octal
All values are extended with zero except those with x or z in the most significant place;
they extend with x or z respectively. A list of examples is shown in Table P-2:
Table P-2: Examples of Extended Values

Number Value Comment
An 8-bit binary number with value of zero.
8’b0 00000000
(Zero extended to get 8 bits.)
An 8-bit binary number with value unknown.
8’bx xxxxxxxx
(x extended to get 8 bits.)
An 8-bit binary number with value of 2 or 3, depending
8’b1x 0000001x
on the value of x.
An 8-bit binary number with value of 0 or 1, depending
8’b0x 0000000x
on the value of x.
An 8-bit hexadecimal number with value unknown.
8’hx xxxxxxxx
(x extended to get 8 bits.)
An 8-bit hexadecimal number with the upper four bits
8’hzx zzzzxxxx
not driven and the lower four bits unknown.
8’b1 00000001 An 8-bit binary number with value of one.
An 8-bit hexadecimal number with the upper four bits
8’hz1 zzzz0001
not driven and the lower four bits having value of one.
8’bx1 xxxxxxx1 An 8-bit binary number that is odd.
8’bx0 xxxxxxx0 An 8-bit binary number that is even.
An 8-bit hexadecimal number with value not driven.
8’hz zzzzzzzz
(z extended to get 8 bits.)
An 8-bit hexadecimal number with upper nibble
8’h0z 0000zzzz
specified and the lower not driven.
11’dn n An 11-bit decimal number with value n.
6’hn n A 6-bit hexadecimal number with value n.
w’b101 ...101 A binary number with value 5 and an unknown width.
State Diagram Conventions

This section describes the conventions used in the state diagrams for this document. The
numbered sections correspond to the call-outs shown in the state machine diagram in
Figure P-2.

SP002 (v2.1) June 24, 2009
R
States
1. A state is represented by a rectangle.
2. The name of the state is indicated in bold.
State Transitions
3. State transition is indicated by an arrow annotated in italics.
State Machine Outputs

Outputs are shown in plain text. Outputs can be shown inside of state rectangles or can be
part of the annotation associated with a transition arrow. If a signal is not listed in a state
rectangle or on a transition arrow, its value at that time is 0 (not asserted). If a registered
output does not appear in the state rectangle or transition arrow annotation, then its value
is unchanged from the previous value.
Output Types
Outputs are divided into three classes as shown in the examples below.
4. Asserting control signals:
♦ go = 1
♦ link reset = 1
5. Register initialization:
♦ XYZ Register = 78
♦ New Counter = 0
♦ xmit = /SP/ (an ordered set)
6. Incrementing or decrementing a register:
♦ XYZ Register = XYZ Register + 1
♦ New Counter = New Counter – 6
X-Ref Target - Figure P-2
2 reset
State ABC 0
1
5 - xmit = /SP/
- New Counter = 0
State ABC 1
6
- New Counter = New Counter + 1
New Counter ≠ 3
- Link Reset = 1
4
New Counter = 3 3 SP000_PF_02_031408
go = 1
Figure P-2: State Machine Diagram Conventions

SP002 (v2.1) June 24, 2009
R
Section 1
Introduction and Overview

1.1 Introduction
The Aurora 8B/10B protocol is a scalable, lightweight, link-layer protocol that can be used
to move data point-to-point across one or more high-speed serial lanes.
The Aurora 8B/10B is protocol independent and can be used to transport industry
standard protocols, such as Ethernet and TCP/IP, or proprietary protocols. This allows
designers of next-generation communication and computing systems to achieve higher
connectivity performance while preserving software infrastructure investment.
While primarily targeted at chip-to-chip and board-to-board applications, the Aurora
8B/10B protocol can be used for box-to-box applications with the addition of standard
optical interface components.
The Aurora 8B/10B protocol is an open standard and is available for implementation by
anyone without restriction.
1.2 Scope
This section outlines what this specification does and does not define.
The Aurora 8B/10B Protocol Specification defines the following:
• Physical layer interface: This includes the electrical levels, the clock encoding, and
symbol coding.
• Initialization and error handling: This defines the steps required to prepare channel
partners for communication across single lane and multi-lane channels. It also
describes how the channel partners should behave in the presence of bit errors in the
channel.
• Data striping: This describes how data is mapped across a channel of multiple serial
lanes.
• Link layer: This describes how the beginning and end of user protocol data units (user
PDUs) are marked during transmission. This also describes how data pauses may be
inserted in data during transmission and how differences in clock rates between the
transmitter and receiver are managed.
• Flow control: the Aurora 8B/10B protocol defines a link layer flow control mechanism
and an expedited mechanism for forwarding higher layer user flow control messages.

SP002 (v2.1) June 24, 2009
R
Section 1: Introduction and Overview
The Aurora 8B/10B protocol does not define the following; it is assumed that these features
will be handled by higher-level protocols:
• Error detection and recovery: the Aurora 8B/10B protocol does not define a
mechanism for detecting errors in user PDUs, or mechanisms for recovering from
them beyond that provided by the 8B/10B encoding.
• Data switching: the Aurora 8B/10B protocol does not define an addressing scheme,
therefore cannot support link layer multiplexing or switching.
1.3 Overview
The Aurora 8B/10B protocol describes the transfer of user data across an Aurora 8B/10B
channel. An Aurora 8B/10B channel consists of one or more Aurora 8B/10B lanes. Each
Aurora 8B/10B lane is a full-duplex serial data connection. The devices that communicate
across the channel are called channel partners. Figure 1-1 illustrates this relationship
X-Ref Target - Figure 1-1
Aurora 8B/10B Channel

Partners
Aurora Aurora
8B/10B 8B/10B
Lane 1 Channel
User User
Interface Aurora Aurora Interface
User User
8B/10B 8B/10B
Application Application
Interface Interface
Aurora
8B/10B
Lane N
User PDUs, Channel PDUs, User PDUs,

User Flow Flow Control PDUs User Flow
Control Messages Control Messages
SP002_01_01_050609
Figure 1-1: Aurora 8B/10B Channel Overview
The Aurora 8B/10B protocol interfaces transfer data and control to and from user
applications by way of the user interface. The user interface is not defined in this
specification.
Data flow consists of the transfer of user PDUs and user flow control messages between
the user application and the Aurora 8B/10B interface, and the transfer of channel PDUs,
and flow control PDUs across the Aurora 8B/10B channel. User PDUs can be of any length,
but their format is not defined in this document. The format of the two types of flow
control PDUs are defined in this document.

SP002 (v2.1) June 24, 2009
R
Section 2
Data Transmission and Reception

2.1 Overview
This section describes the procedures for transmitting and receiving data across an Aurora
8B/10B channel. The Aurora 8B/10B protocol uses a symbol-based method.
2.2 8B/10B Data Transmission and Reception
2.2.1 Symbol-Pairs
The minimum unit of information that is transferred across an Aurora 8B/10B channel is
two symbols, called a symbol-pair. The information on an Aurora 8B/10B channel (or lane)
always comprises multiple symbol-pairs.
2.2.2 Data Ordering

Implementations of the Aurora 8B/10B protocol accept a stream of octets from user
applications and transfer them across the Aurora 8B/10B channel as one or more streams
of symbol-pairs. In all cases, the ordering of octet streams is preserved. For
implementations that have user interfaces that are more than one octet wide, the definition
of octet ordering on that interface is implementation specific.
2.2.3 Transmission Scheduling

The following symbol six types of data are transmitted over an Aurora 8B/10B channel:
• Clock Compensation Sequences of control symbols used to prevent overrun of the
Sequences: receiver due to differences in clock rate between channel
partners. Clock compensation sequences are described in
Section 5.4.9 “Clock Compensation,” page 36.
• Initialization Four ordered sets that are used with the idle sequence to
Sequences: prepare an Aurora 8B/10B channel for data transmission
during initialization. These ordered sets and their use are
described in Section “Initialization and Error Handling,”
page 21.
• Native Flow Control Link layer flow control PDUs generated by and interpreted by
PDUs: Aurora 8B/10B interfaces. These PDUs are described in
Section 3.1.3 “Native Flow Control PDU Format,” page 19.

SP002 (v2.1) June 24, 2009
R
• User Flow Control Flow control messages generated by, and interpreted by user
PDUs: applications, and encapsulated for transmission into user flow
control PDUs. These are described in Section 3.1.5 “User Flow
Control PDU Format,” page 20.
• Channel PDUs: User PDUs encapsulated for transmission over the Aurora
8B/10B channel. These are described in Section 2.2.4 “User
PDU Transmission Procedures,” page 13.
• Idle Sequences: Sequences of control symbols that are transmitted whenever
there is no data to send. Idle sequences are described in
Section 5.4.8 “Idle Sequence,” page 34.
In the event that several of the processes that generate these data types are prepared to
transmit data at the same time, they are prioritized as shown in Table 2-1.
Table 2-1: Transmission Priorities
Data Type Priority
Clock Compensation Sequences Highest
Initialization Sequences
Native Flow Control PDUs
User Flow Control PDUs
Channel PDUs
Idle Sequences Lowest

SP002 (v2.1) June 24, 2009
R
8B/10B Data Transmission and Reception
2.2.4 User PDU Transmission Procedures

Transmission of user PDUs requires the following procedures:
• Padding
• Encapsulation with channel PDU delimiters
• 8B/10B encoding of channel PDU payload
• Serialization and clock encoding
Figure 2-1 illustrates how user PDUs are mapped to channel PDUs by these procedures.
Note that this figure illustrates the case where a pad octet is required. The remainder of this
section describes these procedures in more detail.
N Octets
User PDU
Padding
N Octets 1 Octet
User PDU Pad
Link Layer Encapsulation

2 Octets N Octets 1 Octet 2 Octets
SCP User PDU Pad ECP
8B/10B Encoding
1 Symbol Pair N Symbols 1 Symbol 1 Symbol Pair
/SCP/ User PDU /P/ /ECP/

SP002_02_01_101703
Figure 2-1: Transmission Procedures
2.2.4.1 Padding
The Aurora 8B/10B channel requires that all transmissions consist of an even number of
symbols. To meet this requirement, all user PDUs that contain an odd number of octets
must be padded with a single octet. This pad octet has a value of 0x9C and immediately
follows the user PDU.
2.2.4.2 Link Layer Encapsulation

The user PDU is encapsulated with control symbol sequences, called ordered sets, to
produce the complete channel PDU. These ordered sets demarcate the beginning and end
of channel PDUs within the serial data stream. The Aurora 8B/10B protocol uses an /SCP/
(/K28.2/K27.7/) ordered set to mark the start of channel PDUs, and an /ECP/
(/K29.7/K30.7/) ordered set to mark the end of channel PDUs. The details of these ordered
sequences can be found in Section 5.4.7 “Ordered Sets,” page 33.

SP002 (v2.1) June 24, 2009
R
2.2.4.3 8B/10B Encoding

After padding, the resulting data structure is referred to as the link layer payload. Prior to
transmission the link layer payload is 8B/10B encoded by the physical coding sublayer
(PCS). All characters, with the exception of the pad octet, are encoded as data symbols. The
pad octet is encoded as a /P/ (/K28.4/) control symbol to facilitate stripping at the
receiving end. The details of the encoding process are described in Section 5.4.4 “8B/10B
Encoding,” page 32.
2.2.4.4 Serialization and Clock Encoding

After the complete channel PDU has been assembled and encoded, it is serialized for
transmission. The details of this process are described in Section 5.4.5 “Transmission
Order,” page 32. The serialized data stream is transmitted in differential non return to zero
(NRZ) format.
2.2.5 User PDU Reception Procedures

Reception of user PDUs involves the following procedures:
• Deserialization
• 8B/10B decoding of channel PDU payload
• Link layer stripping
• Pad stripping
Figure 2-2 illustrates how user PDUs are mapped to channel PDUs by these procedures.
Note that this figure illustrates the case where a pad octet was added to the user PDU data.
The remainder of this section describes these procedures in more detail.
1 Symbol-Pair A Symbols M Symbols B Symbols 1 Symbol 1 Symbol-Pair
/SCP/ User PDU Embedded Idles User PDU cont. /P/ /ECP/
8B/10B Decoding
2 Octets A Octets M Octets B Octets 1 Octet 2 Octets
SCP User PDU Embedded Idles User PDU cont. Pad ECP
Link Layer Stripping

N Octets 1 Octet
User PDU Pad
Pad Stripping
N Octets
User PDU
Where: A + B = N
N is an odd number
M is an even number SP002_02_03_101703
Figure 2-2: Receive Procedures

SP002 (v2.1) June 24, 2009
R
8B/10B Data Transmission and Reception
2.2.5.1 Deserialization
The serial data stream is received in differential NRZ format. The receive logic deserializes
this data into 10-bit data and control symbols. The details of this process are described in
Section 5.4.5 “Transmission Order,” page 32.
Symbol alignment within the stream is established during the lane initialization procedure
described in Section 4.2.1 “8B/10B Lane Initialization,” page 22 and is not performed
again during normal channel operation.
2.2.5.2 8B/10B Decoding

After deserialization, the link layer payload is decoded into a stream of octets. The details
of the 8B/10B decoding process are described in Section 5.4.6 “8B/10B Decoding,”
page 33. During the decode process, the presence of a /P/ (/K28.4/) control symbol
followed by an/ECP/ (/K29.7/K30.7/) in the data stream must be flagged so that the pad
octet can be stripped during the pad stripping procedure.
2.2.5.3 Link Layer Stripping

The link layer stripping procedure removes channel PDU encapsulation and any
embedded idle ordered sets that may have been inserted during transmission.
Removal of channel PDU encapsulation includes the /SCP/ (/K28.2/K27.7/) ordered set
to mark the start of channel PDUs, and an /ECP/ (/K29.7/K30.7/) ordered set to mark the
end of channel PDUs. The details of these ordered sequences can be found in
Section 5.4.7 “Ordered Sets,” page 33.
Removal of idle ordered sets involves the removal of /K/ (/K28.5/), /R/ (/K28.0/), and
/A/ (/K28.3/) symbols. Any number of these symbols can appear at any point in the
channel PDU with the following restrictions:
• An even number of idle symbols must have been inserted
• The start of the idle sequence must begin after an even number of symbols in the
channel PDU
2.2.5.4 Pad Stripping

If a /P/ (/K28.4/) control symbol followed by /ECP/ (/K29.7/K30.7/) was detected
during the 8B/10B decoding process, a pad octet was post-pended to the user PDU by the
transmission process in order to meet channel alignment requirements. This octet, which
has a value 0x9C after decoding, shall be stripped from the end of the data stream before
passing it to the user application.

SP002 (v2.1) June 24, 2009
R

SP002 (v2.1) June 24, 2009
R
Section 3
Flow Control
3.1 Overview
This chapter describes the optional flow control mechanisms supported by the Aurora
8B/10B protocol. These mechanisms provide low-latency flow control to prevent data loss
due to differences between the rate at which data is sourced and sunk between channel
partners. Latency is minimized because flow control PDUs can be embedded within channel
PDUs (see Section 2.2.3 “Transmission Scheduling,” page 11).
The Aurora 8B/10B protocol supports the following two flow control mechanisms:
• Native Flow Control: This is a link-layer flow control mechanism. Native flow control
PDUs are generated by, and interpreted by the Aurora 8B/10B
interface.
• User Flow Control: This mechanism can be used to implement user-defined flow
control schemes at any layer. User flow control messages are
generated by, and interpreted by the user application. The
Aurora 8B/10B interface encapsulates these messages into user
flow control PDUs, and provides a low latency mechanism for
their transport across the channel.
Figure 3-1, page 18 illustrates how these flow control schemes interrelate.
Native flow control PDUs are typically generated when elasticity storage at the receiver side
is being depleted. Note that these PDUs must be generated early enough that the latency
between the time that they are issued and when traffic stops does not result in an overflow
of elasticity storage.
User flow control messages are forwarded from one user application to the other through
the Aurora 8B/10B channel and are not interpreted by either Aurora 8B/10B interface.
Some things to note about the flow control mechanisms:
• Assertion of native flow control does not block the forwarding of user flow control
PDUs
• User flow control PDUs, once their transmission has started, cannot be interrupted by
any other sequence

SP002 (v2.1) June 24, 2009
R
Channel Partner A Aurora 8B/10B Channel Channel Partner B User Flow

User Flow
Control Control
Messages Messages
D User
User PDUs M E User PDUs
U RX
Native Flow Control M Native Flow Control
X FIFO
U
Idle Sequences Idle Sequences
X
RX Native TX Native FIFO
Flow Control Flow Control Status
State Machine State Machine
FIFO TX Native RX Native

Status Flow Control Flow Control
State Machine Idle Sequences Idle Sequences State Machine
Native Flow Control D Native Flow Control

User E M
RX M U
User PDUs X User PDUs
FIFO U
X
User Flow User Flow
Control Control
Messages Messages
SP002_06_01_050609
Figure 3-1: Flow Control Overview
3.1.1 Native Flow Control Operation

Operation of native flow control is governed by the two state machines shown in
Figure 3-1.
The RX native flow control state machine monitors the state of the RX FIFO, and generates
native flow control PDUs when there is a risk of RX FIFO overflow. These PDUs request
that the channel partner pause the transmission of user PDUs for a specified number of
symbol times. The format of these native flow control PDUs is described in
Section 3.1.3 Native Flow Control PDU Format. The algorithm used to map the state of the
FIFO to a specific native flow control PDU is implementation dependent, and is not
defined in this specification.
The TX native flow control state machine responds to native flow control PDUs from the
channel partner by pausing the transmission of user PDUs for the requested interval. Note
that in addition to idle sequences, a pause can include the transmission of native flow control
PDUs or user flow control PDUs since neither of these PDUs are stored in the RX FIFO.
If the Aurora 8B/10B interface is in the process of transmitting a user PDU, the TX native
flow control state machine can respond in one of two ways to native flow control PDUs.
• Completion Mode: The user PDU is completed before transmission is paused.

• Immediate Mode: The transmission of the user PDU is interrupted by the pause.
All Aurora 8B/10B protocol implementations must be capable of supporting either

behavior if they support flow control. The operating mode must be programmable, but this
specification does not define how the operating mode is chosen.

SP002 (v2.1) June 24, 2009
R
Overview
3.1.2 Native Flow Control Latency

When operating in immediate mode, the maximum round trip delay contribution from the
channel partners is defined, in order to bound the depth of the User RX FIFO. The
contribution to latency introduced by the channel is not included in this definition, but
must also be taken into account when designing the User RX FIFO for a particular channel.
The round trip delay through the Aurora 8B/10B interfaces between the native flow
control PDU request and the first pause arriving at the originating channel partner must
not exceed 256 symbol times.
3.1.3 Native Flow Control PDU Format

Native flow control PDUs are two octets in length. The first octet is an SNF (start of native
flow control) character and the second octet is a data character called the command octet.
The command octet contains the PAUSE field, which specifies the number of idle characters
the channel partner must send in response to the PDU. Figure 3-2 shows the command
octet format, and Table 3-1 shows the encoding of the PAUSE field.
8 bits 4 bits 4 bits
SNF PAUSE 0000
Reserved UG002_06_02_020603
Figure 3-2: Native Flow Control Command Octet Format
Table 3-1: Native Flow Control PAUSE Field Encoding

PAUSE Field Contents PAUSE Interval (Symbols)
0000 0 (XON)
0001 2
0010 4
0011 8
0100 16
0101 32
0110 64
0111 128
1000 256
1001 to 1110 Reserved
1111 Infinite (XOFF)

SP002 (v2.1) June 24, 2009
R
3.1.4 User Flow Control Operation

User flow control PDUs are not interruptible by clock compensation sequences, native
flow control PDUs, or idle sequences once their transmission has begun. The Aurora
8B/10B protocol implementations may need to buffer user flow control PDUs to ensure
that they are not interrupted, and that the clock compensation rules are met. Any buffering
scheme is implementation dependent and is not defined in this specification.
3.1.5 User Flow Control PDU Format

User flow control PDUs are 4 to 18 octets in length. The first octet is an SUF (start of user flow
control) character, which is followed by a data character called the command octet. This
command octet is immediately followed by 2 to 16 octets of the flow control message from
the user application.
Note: The /K28.4/ symbol is used for both an SUF character and a pad character for channel PDUs.
However the pad character can only be followed by a control character, and can never be followed by
a data character. This discriminates between a /K28.4/ used as a pad character and a /K28.4/
used to mark the start of a user flow control PDU.
Figure 3-3 shows the format of the user flow control PDU. The length of the user flow
control message is specified in the SIZE field. The user flow control message size can be
any even number of octets from 2 to 16 as shown in Table 3-2.
Command Octet 2 to 16 octets of

User Flow Control
8 bits 3 bits 5 bits Message
SUF SIZE 00000
Reserved UG002_06_03_101403
Figure 3-3: User Flow Control PDU Format
Table 3-2: SIZE Encoding

SIZE Field User Flow Control
Contents Message Size
000 2 octets
001 4 octets
010 6 octets
011 8 octets
100 10 octets
101 12 octets
110 14 octets
111 16 octets

SP002 (v2.1) June 24, 2009
R
Section 4
Initialization and Error Handling

4.1 Overview
This chapter describes the initialization procedures needed to prepare an Aurora 8B/10B
channel for data transmission and reception. Initialization of an Aurora 8B/10B channel is
a three-stage process. These stages are:
• Lane Initialization: This procedure is performed individually on each lane to activate the
link and align the received data to the proper boundaries.
• Channel Bonding: This procedure bonds the individual lanes into a single data channel.
If the function implemented only uses a single link, channel bonding
is not required and will be bypassed. Channel bonding eliminates
skew introduced from various sources including the trace lengths,
connectors and IC variations.
• Channel Verification: This procedure performs any alignment needed to map received data
to the user interface and verifies the ability of the channel to transfer
valid data.
Figure 4-1 illustrates how these procedures interrelate. During channel verification, all lanes
must become ready to receive data across the channel. When an Aurora 8B/10B interface
completes channel verification, it can immediately start to transmit data.
Power-Up, Reset, Channel Failure
Lane Initialization
Initialize Lane Hardware
and Symbol Alignment
Single-Lane Multi-Lane
Channel Channel Channel Bonding
Channel Timeout
Bonding
Verification
Timeout Bond Lanes
Channel
Verification
Check Channel Integrity
and Data Alignment
Verification Complete
Channel Ready
SP006_04_01_060607
Figure 4-1: Initialization Overview

SP002 (v2.1) June 24, 2009
R
4.2 8B/10B Initialization and Error Handling
4.2.1 8B/10B Lane Initialization

The individual lane initialization procedure synchronizes each lane transceiver with its
lane partner upon reset or channel failure. A channel failure is defined as any one of the
following conditions:
• Excessive channel data errors, as defined in Section 4.2.4 “8B/10B Error Handling”
• Excessive protocol violations, implementation defined
A state diagram of the lane initialization procedure is shown in Figure 4-2, page 23. See
Table 5-1, page 33 for the definition of /SP/, /K/, and /SPA/.
Note: /D21.5/ is the inverse of /D10.2/, and /D19.6/ is the inverse of /D12.1/.

SP002 (v2.1) June 24, 2009
R
8B/10B Initialization and Error Handling
Power-Up, Reset, Channel Failure
RESET0
- xmit = /SP/
- Reset internal state
- Lane Reset Counter = 0
RESET1
- xmit = /SP/
- Reset internal state Lane Reset Counter < N1
- Lane Reset Counter = Lane Reset Counter + 1
Lane Reset Counter = N1

INIT0
- xmit = /SP/
Else
- K Counter = 0
- Enable comma alignment = 1
Else
RX = /K/
INIT1
RX = /K/
- xmit = /SP/
& valid code group
- K Counter = K Counter + 1
RX = [valid code group RX = /K/

& (not /K/)] & valid code group
INIT1A
Else - xmit = /SP/ RX = [valid code group
- K Counter = K Counter & (not /K/)]
INIT2
- xmit = /SP/ RX = valid code group
RX =
- RX Ack Counter = 0 & K Counter >= 3
/D21.5/ or /D19.6/
- TX Ack Counter = 0
Toggle - Start error detection circuitry
Lane Polarity - Start Error Counter
RX = /D10.2/ or /D12.1/
INIT3
- xmit = /SPA/
- TX Ack Counter = TX Ack Counter + 1 RX Ack Counter < 4
- If RX = ack, then: or TX Ack Counter < 8
RX Ack Counter = RX Ack Counter + 1
Multi-Lane Channel
& RX Ack Counter >= 4
& TX Ack Counter >= 8 Single-Lane Channel
INIT4 & RX Ack Counter >= 4
& TX Ack Counter >= 8
- xmit = /SPA/
- Lane up register = 1
All Lanes up = 1
To Channel Verification Procedure
To Channel Bonding Procedure SP002_04_02_052009
Figure 4-2: Lane Initialization Procedure
Note: See “State Diagram Conventions,” page 7 for conventions used in this diagram.

SP002 (v2.1) June 24, 2009
R
4.2.2 8B/10B Channel Bonding

The channel bonding procedure aligns all data being received by each lane. Channel
bonding cannot begin until each lane has completed the lane initialization procedure.
Figure 4-3 shows a state diagram of the channel bonding procedure. See Table 5-1, page 33
for the definition of /I/ and /A/.
From Lane Initialization

CB0
- xmit = /I/ on all lanes
Transceiver channel
- CB_CTR = 0
bonding in progress
/A/ on - Enable channel bonding = 1
some lanes
but CB1 All lanes indicate channel bonding is completed
not on all
- xmit = /I/ on all lanes /A/ on all lanes
- If /A/ on all lanes, then: or
CB_CTR = CB_CTR + 1 no /A/ on any lane
CB_CTR = 4
To Channel Verification Procedure SP002_04_03_061604
Figure 4-3: Channel Bonding Procedure
Channel bonding occurs in two phases. This first phase, which corresponds to State CB0 in
Figure 4-3, consists of transceiver specific data alignment. The second phase, which
corresponds to State CB1, verifies that the transceivers have aligned correctly and are
delivering the /A/ ordered sets within the /I/ ordered set at the same time.
4.2.3 8B/10B Channel Verification

The channel verification procedure is used to align data across the user interface, and verify
channel integrity. It essentially consists of sending the channel verification sequence across
all lanes in each direction. Using this known data pattern, the receiving channel partners
can correctly align data across the user interface, and verify channel integrity. A diagram of
the procedure is shown in Figure 4-4. See Table 5-1, page 33 for the definition of /V/.
From Lane Initialization Procedure From Channel Bonding Procedure

If Single-Lane Channel If Multi-Lane Channel
CV0
- xmit = verification sequence1 across channel
- RX CV Counter = 0
- TX CV Counter = 0
CV1
- xmit = verification sequence1 across channel
- If TX = /V/ then:
TX CV Counter = TX CV Counter + 1 Else
- If RX = /V/ then:
RX CV Counter = RX CV Counter + 12
RX CV Counter = at least 4
Bad /V/
& TX CV Counter = at least 8
Go to
Initialization Complete, Channel Ready Lane Initialization Procedure
State RESET0
Note: 1) The verification sequence consists of the following pattern:
60 /I/ symbols followed by the four-symbol /V/ ordered set
2) When all of the lane receivers have received the third /V/ ordered set
from their lane partners, the channel receiver portion of the receiver,
if not already enabled, must be enabled to prevent loss of data.
SP002_04_04_101603
Figure 4-4: Channel Verification Procedure

SP002 (v2.1) June 24, 2009
R
8B/10B Initialization and Error Handling
4.2.4 8B/10B Error Handling

During the normal transmission of data, it is possible for the channel to fail. All lanes must
be individually monitored for errors. Before the serial transceiver properly byte aligns the
data, many errors will be seen on the outputs. Because of this, it is important that none of
the error detection circuits is activated until the lane is stable. This stable point is achieved
when the K counter reaches 3, as shown in Figure 4-2, page 23. Once the K counter has
reached 3, all error detection circuits should be activated.
There are two types of errors: hard and soft.
A hard error occurs when:
• There is an overflow/underflow in either the transmit or receive elastic buffers
• There are too many soft errors, refer to Figure 4-5, page 26
• The channel partner undergoes a reset, indicated by receipt of initialization sequences
• The physical connection between channel partners is broken
Hard errors are considered catastrophic errors, after which the channel should immediately
be re-initialized. Any data unit being received when a hard error occurs is corrupt and
should be discarded.
Soft errors are typically due to transient bit errors on the lane. Soft errors do not necessarily
require the channel to be reset. The Aurora 8B/10B protocol does no explicit data error
checking; data errors induced by soft errors should be detected and corrected by the user's
error handling capability. Examples of soft errors include:
• Disparity errors
• Symbol errors
In multi-Gbps systems, a bit error can occur in a range between minutes, for a system with
poor channel integrity, to days or years for a system with good channel integrity. As a
result, Aurora 8B/10B interfaces must implement soft error monitoring logic to verify
ongoing channel integrity. This logic consists of a soft error counter and associated control
logic for each lane. Figure 4-5, page 26 illustrates the required behavior of the soft error
monitoring logic.

SP002 (v2.1) June 24, 2009
R
From Lane initialization
err_cnt = 0
Soft error
Four good code
groups in a row
err_cnt = err_cnt + 1
Soft error Soft error

Four good code
groups in a row
Four good code
groups in a row
err_cnt = err_cnt + 1 err_cnt = err_cnt - 1
Soft error
Soft error
Four good code
groups in a row
Four good code
groups in a row
err_cnt = err_cnt + 1 err_cnt = err_cnt - 1
Soft error
err_cnt = 0
Go to
Lane Initialization Procedure
State RESET0 SP002_04_05_110402
Figure 4-5: Soft Error Handling

SP002 (v2.1) June 24, 2009
R
Section 5
PCS and PMA Layers

5.1 Overview
This chapter specifies the functions provided by the physical coding sublayer (PCS) and
physical medium attachment (PMA) sublayer (the PCS and PMA terminology is adopted
from IEEE Std 802.3 [Ref 1]). While the Aurora 8B/10B protocol does not explicitly
implement these sublayers, the physical layer functions that are part of the Aurora 8B/10B
protocol are described using this conceptual model.
The topics include:
• 8B/10B coding
• Character representation
• Data stream serialization
• Code groups
• Columns
• Channel transmission rules
• Idle sequences
• Channel initialization
This section also describes how data is striped across lanes when the channel is made up of
more than one lane. An Aurora 8B/10B channel is made up of one or more Aurora 8B/10B
lanes, each of which is a full-duplex serial connection (see Section 1.3 “Overview,” page 10
for details).
5.2 PCS Layer Functions

The physical coding sublayer (PCS) function is responsible for idle sequence generation,
lane striping, and encoding for transmission. Upon reception, the PCS is responsible for
decoding, lane alignment, and destriping. The PCS in a standard implementation uses an
8B/10B encoding for transmission over the channel. See BYTE ORIENTED DC BALANCED
(0,4) 8B/10B PARTITIONED BLOCK TRANSMISSION CODE [Ref 2], for the source of the
8B/10B encoding scheme.
The PCS layer also provides mechanisms to detect lane states. It provides for clock
difference tolerance between the sender and receiver without requiring flow control. The
The Aurora 8B/10B protocol does not include mechanisms for determining the number of
lanes that make up the channel. Each channel partner must be configured for operation over
the same number of lanes.
The PCS layer performs the following list of transmit functions:

SP002 (v2.1) June 24, 2009
R
• Dequeues channel PDUs, native flow control PDUs, user flow control PDUs and
delimited control symbols awaiting transmission as a character stream
• Stripes the transmit character stream across the available lanes
• Generates the idle sequence and inserts it into the transmit character stream for each
lane when no PDUs or delimited control symbols are available for transmission
• Encodes the character stream of each lane independently into 10-bit parallel code
groups
• Passes the resulting 10-bit parallel code groups to the PMA
The PCS layer performs the following receive functions:
• Decodes the received stream of 10-bit parallel code groups for each lane
independently into characters
• Marks characters decoded from invalid code groups as invalid
• Aligns the character streams to eliminate the skew between the lanes and reassembles
(destripes) the character stream from each lane into a single character stream, if the
channel is using more than one lane
• Delivers the decoded character stream of PDUs and delimited control symbols to the
higher layers
5.3 PMA Layer Functions

The physical medium attachment (PMA) function is responsible for serializing 10-bit
parallel code groups to/from a serial bitstream on a lane-by-lane basis. Upon receiving
data, the PMA function aligns the received bitstream into 10-bit code group boundaries,
independently on a lane-by-lane basis. It then provides a continuous stream of 10-bit code
groups to the PCS, one stream for each lane. The 10-bit code groups are not observable by
layers higher than the PCS.

SP002 (v2.1) June 24, 2009
R
8B/10B Transmission Code
5.4 8B/10B Transmission Code

The 8B/10B transmission code used by the PCS encodes 9-bit characters (eight bits of
information and one control bit) into 10-bit code groups for transmission, and reverses the
process on reception. Encodings are defined for 256 data characters and 12 special (control)
characters.
The code groups used by the transmission code are either balanced or unbalanced. A
balanced code group has an equal number of ones and zeros and an unbalanced code
group has an unequal number of zeros. This selection of code groups guarantees a
minimum of three transitions, 0 to 1 or 1 to 0, within each code group, while maintaining
DC balance.
The 8B/10B code uses disparity to keep track of the number of ones and zeros it has sent
and received. A code group that has two more ones than zeros is assigned a positive
disparity. A code group that has two more zeros than ones is assigned a negative disparity.
A code group that has an equal number of ones and zeros is assigned a zero disparity. The
encoder maintains DC balance by never transmitting a second code group of the same
disparity without first transmitting a code group of the opposite disparity. This rule does
not apply to code groups with zero disparity. The complete definition is in
Section 5.4.3 “Running Disparity Rules,” page 31.
The 8B/10B code has the following properties:
• Sufficient bit transition density (three to eight transitions per code group) to allow
clock recovery by the receiver
• Special code groups that are used for establishing the receiver synchronization to the
10-bit code group boundaries, delimiting control symbols, and maintaining receiver
bit and code group boundary synchronization
• DC balanced
• Detection of single and some multiple-bit errors

SP002 (v2.1) June 24, 2009
R
5.4.1 Character and Code Group Notation

This section describes the notation for characters, code groups, and their bits used in
8B/10B encoding and decoding.
The information bits [0-7] of an unencoded character are denoted with the letters A
through H where the letter H denotes the most significant information bit (bit 0) and the
letter A denotes the least significant information bit (bit 7). This is shown in Figure 5-1.
Each data character has a representation of the form Dx.y where x is the decimal value of
the least significant five information bits EDCBA, and y is the decimal value of the most
significant three information bits HGF, as shown in Figure 5-1. Each control character has
a similar representation using the form Kx.y.
HGF EDCBA
D25.3
011 11001
y=3 x = 25
sp002_03_01_081302
Figure 5-1: Character Notation Example (D25.3)
The output of the 8B/10B encoding process is a 10-bit code group. The bits of a code group
are denoted with the letters a through j. The bits of a code group are all of equal
significance, there is no most significant or least significant bit. The ordering of the code
group bits is shown in Figure 5-2.
The code groups corresponding to the data character Dx.y is denoted by /Dx.y/. The code
groups corresponding to the special character Kx.y are denoted by /Kx.y/
abcdei fghj
/D25.3/
100110 1100
from x term from y term
sp002_03_02_082102
Figure 5-2: Code Group Notation Example (/D25.3/)

SP002 (v2.1) June 24, 2009
R
5.4.2 Running Disparity

The 8B/10B encoding and decoding functions use a binary variable called running
disparity. The variable can have a value of either positive (RD+) or negative (RD-). The
encoder and decoder each have a running disparity variable for each lane, which are all
independent of each other.
The primary use of running disparity in the encoding process is to keep track of whether
the encoder has output either more ones or more zeros. The current running disparity
value is used to select which unbalanced code group will be used when the encoding for a
character requires a choice between two unbalanced code groups.
The primary use of running disparity in the decoding process is to detect errors. Bit error(s)
will transform a 10-bit code group into either an invalid code group or a different valid
code group. For those code groups that were transformed into another valid code group,
running disparity will catch all instances caused by a single bit error and some instances
caused by multiple bit errors. When a running disparity error is flagged, the error can be
either in that code group or in an earlier code group.
5.4.3 Running Disparity Rules

After power-up and before the channel is operational, both the transmitter (encoder) and
receiver (decoder) must establish current values of running disparity. The transmitter shall
use a negative value as the initial value for the running disparity for each lane.
The receiver may use either a negative or positive initial value of running disparity for
each lane.
The following algorithm shall be used for calculating the running disparity for each lane.
In the encoder, the algorithm operates on the code group that has just been generated by
the encoder. In the receiver, the algorithm operates on the received code group that has just
been decoded by the decoder.
Each code group is divided to two sub-blocks as shown in Figure 5-2, page 30, where the
first six bits abcdei form one 6-bit sub-block and the second four bits fghj form a second
4-bit sub-block. The running disparity value at the beginning of the 6-bit sub-block is the
value determined at the end of the previous code group. Running disparity at the
beginning of the 4-bit sub-block is the running disparity at the end of the 6-bit sub-block.
The running disparity value at the end of the code group is the value determined at the end
of the 4-bit sub-block.
The sub-block running disparity shall be calculated as follows:
1. The running disparity is positive if at the end of any sub-block the sub-block contains
more ones than zeros. It is also positive if at the end of a 4-bit sub-block the sub-block
has the value 4’b0011, and if at the end of a 6-bit sub-block the sub-block has the value
6’b000111.
2. The running disparity is negative if at the end of any sub-block, the sub-block contains
more zeros than ones. It is also negative if at the end of a 4-bit sub-block, the sub-block
has the value 4’b1100, and if at the end of a 6-bit sub-block, the sub-block has the value
6’b111000.
3. In all other cases, the value of the running disparity at the end of the sub-block is the
same as the value at the beginning of the sub-block (the running disparity is
unchanged).

SP002 (v2.1) June 24, 2009
R
5.4.4 8B/10B Encoding

The 8B/10B encoding function encodes 9-bit characters into 10-bit code groups. The
encodings for the 256 data characters (Dx.y) are specified in Table A-1, page 47. The
encodings or the 12 control characters (Kx.y) are specified in Table A-2, page 56. Both tables
have two columns of encodings, one marked RD- and one marked RD+. When encoding a
character, the code group in the RD- column is selected if the current value of encoder
running disparity is negative. The code group in the RD+ column is selected if the current
value of encoder running disparity is positive.
Data characters (Dx.y) shall be encoded according to Table A-1, page 47 and the current
value of encoder running disparity. Special characters (Kx.y) shall be encoded according to
Table A-1, page 47 and the current value of encoder running disparity. After each character
is encoded, the resulting code group shall be used by the encoder to update the running
disparity according to Section 5.4.3 “Running Disparity Rules,” page 31.
5.4.5 Transmission Order

The 10-bit parallel output of the encoder shall be serialized and transmitted with bit a
transmitted first and a bit ordering of abcdei fghj as shown in Figure 5-3.
Figure 5-3 gives an overview of a character passing through the encoding, serializing,
transmission, deserializing, and decoding processes. The left side of the figure shows the
transmit process of encoding a character stream using 8B/10B encoding and the 10-bit
serialization. The right side shows the reverse process of the receiver deserializing and
using 8B/10B decoding on the received code groups.
The dashed line shows the functional separation between the PCS layer, that provides 10-
bit code groups, and the PMA layer.
The drawing also shows, on the receive side, the bits of a special character containing the
comma pattern that is used by the receiver to establish 10-bit code-boundary
synchronization.
MSB LSB MSB LSB

01234567 01234567
8 + control 8 + control
Input to the Output of the
ENCODE function HG F E DC B A HG F E DC B A DECODE function
8B/10B PCS Layer 8B/10B

Encoder Encoder
Output of the Input to the
10 10
ENCODE function DECODE function
abcde i f gh j abcde i f gh j
0011111xxx Aligned comma code group
Lane bitstream 0123456789 0123456789 Lane bitstream

Bit 0 transmitted first Bit 0 received first
PMA Layer
SP002_03_03_100702
Figure 5-3: Lane Encoding, Serialization, Deserialization, and Decoding Process

SP002 (v2.1) June 24, 2009
R
5.4.6 8B/10B Decoding

The 8B/10B decoding function decodes received 10-bit code groups into 9-bit characters. It
also detects received code groups that have no defined decoding and marks the resulting
characters in the output stream invalid.
The decoding function uses Table A-1, page 47, Table A-2, page 56, and the current value of
the decoder running disparity. To decode a received code group, the decoder shall select
the RD- column of Table A-1, page 47 and Table A-2, page 56 if the current value of the
decoder running disparity is negative or the RD+ column if the value is positive. The
decoder shall then compare the received code group with the code groups in the selected
column of both tables. If a match is found, the code group is decoded to the associated
character. If no match is found, the code group is decoded to a character that is flagged as
invalid. After each code group is decoded, it shall be used by the decoder to update the
decoder running disparity according to the rules in Section 5.4.3 “Running Disparity
Rules.”
5.4.7 Ordered Sets

Table 5-1 defines the ordered sets of special characters used by Aurora 8B/10B channel
partners. These ordered sets are used for the following functions:
• Alignment to code group (10-bit) boundaries on lane-by-lane basis
• Alignment of the receive data stream across a channel
• Synchronization between channel partners
• Polarity checking
• Clock rate compensation between receiver and transmitter
• PDU delineation
Table 5-1: Aurora 8B/10B Ordered Sets

Ordered Set Designator Encoding
Idle /I/ /K/, /R/, /A/ sequence
Sync and Polarity /SP/ /K28.5/D10.2/D10.2/D10.2/
Sync and Polarity Acknowledge /SPA/ /K28.5/D12.1/D12.1/D12.1/
Verification /V/ /K28.5/D8.7 /D8.7/D8.7/
Start of Channel PDU /SCP/ /K28.2/K27.7/
End of Channel PDU /ECP/ /K29.7/K30.7/
Pad or Start of User Flow Control /P/ or /SUF/ /K28.4/
PDU
Comma /K/ /K28.5/
Skip /R/ /K28.0/
Channel Bonding /A/ /K28.3/
Clock Compensation /CC/ /K23.7/K23.7/
Start of Native Flow Control PDU /SNF/ /K28.6/

SP002 (v2.1) June 24, 2009
R
5.4.8 Idle Sequence

The idle ordered set (idle), shown in Table 5-1, page 33, is used to perform word-boundary
alignment and channel bonding during initialization. During operation, idles are used to
indicate that there is no data. Idle insertion occurs during wait-states and in between
channel PDUs. The idle ordered set consists of three code groups: /A/, /K/, and /R/. The
/K/ and /R/ code groups must be applied in a pseudo-random sequence (between /A/
code groups) to reduce EMI, by not producing a discrete spectrum. The following
conditions apply:
• /A/ spacing is randomized with a minimum of 16 code groups but no more than 32
code groups between any two /A/ code groups.
• /K/s and /R/s are placed between the /A/s in a random fashion.
• The minimum transmit pattern is one symbol-pair. Any of the three characters can be
sent, as long as the preceding two rules are obeyed. If the /A/ is sent, the spacing rule
must still be obeyed.
• For multi-lane channels, the same idle symbol-pair must be transmitted
simultaneously on all lanes that require an idle at that time.
• No discrete spectrum is created.
The example in Figure 5-4 shows an /A/ code group having a separation of 31 code
groups. It also shows the current running disparity after the character has been applied.
Note: /A/ and /K/ will change the current running disparity. /R/ will keep the disparity the same.
-A +K +R -K -R -R +K -K -R +K +R -K -R -R +K -K -R -R +K +R +R -K -R -R +K +R +R -K +K +R -K +K -A
SP002_03_04_082202
Figure 5-4: Example of an Idle Sequence

SP002 (v2.1) June 24, 2009
R
Figure 5-5 shows an example implementation of idle generation logic which meets the
requirements.
pseudo_random_integer_generator pseudo_random_bit
clock
Q Q Q Q Q Q Q
1
msb lsb
D D D D D
down_counter
LOAD
Q Q Q Q Q
Acntr_eq_zero
send_idle_dlyd
D Q
send_idle send_idle
send_K = send_i dl e & (!send_idle_dlyd | send_i dl e_dlyd & ! A cntr_eq_zero & pseudo_random_bit)
send_A = send_i dl e & send_idle_dlyd & A cntr_eq_zero
send_R = send_i dl e & send_idle_dlyd & ! A cntr_eq_zero & !pseudo_random_bit
SP002_03_04_082102
Figure 5-5: Example of a Pseudo-Random Idle Code Group Generator

SP002 (v2.1) June 24, 2009
R
5.4.9 Clock Compensation

The Aurora 8B/10B protocol provides a compensating mechanism for clock rate
differences between the transmitter and receiver. This mechanism, called clock
compensation, can accommodate up to a 200 ppm clock rate differential between the
transmitter and the receiver. The Aurora 8B/10B protocol implements clock compensation
by periodically inserting clock compensation sequences into idle patterns or user data.
Clock compensation sequences should not be inserted into user flow control PDUs, see
Section 3.1.4 “User Flow Control Operation,” page 20.
The clock compensation sequence consists of six copies of the clock compensation ordered
set, /CC/. The clock compensation sequence shall be transmitted at least every 10,000 code
groups even when there are PDUs or other code groups available for transmission. For
multi-lane channels, the complete clock compensation sequence is transmitted
simultaneously over each lane that makes up the channel.
5.4.10 Single-Lane Transmission Rules

A single-lane channel has a single differential pair in each direction. A single-lane channel
shall be encoded and shall transmit the character stream of control ordered sets and PDUs
received from the upper layers over the differential pair in the order the characters were
received from the upper layers.
When neither control ordered sets nor PDUs are available from the upper layers for
transmission, the idle sequence shall be fed to the input of the encoder for encoding and
transmission.
On reception, the code group stream is decoded and passed to the upper layers. Figure 5-6,
page 37 shows the encoding and transmission order for a channel PDU transmitted over a
single-lane channel. The data stream shown in Figure 5-6, page 37 illustrates many of the
cases defined in the protocol. The key features to note in the figure are:
• The first example shows how a channel PDU with an odd number of payload octets is
padded to maintain alignment of the /ECP/ symbol
• The third example shows a channel PDU interrupted by a clock compensation
sequence, and idles

SP002 (v2.1) June 24, 2009
R
/I/ 0 /SCP/1 20 /CC/1 40 D12 60

/I/ 1 /SCP/2 21 /CC/2 41 /P/ 61
/I/ 2 D0 22 /CC/1 42 /I/ 62
/I/ 3 D1 23 /CC/2 43 /I/ 63
/SCP/1 4 D2 24 /CC/1 44 /I/ 64
/SCP/2 5 D3 25 /CC/2 45 /I/ 65
D0 6 D4 26 /CC/1 46 /I/ 66
Time
D1 7 D5 27 /CC/2 47 /I/ 67
D2 8 /ECP/1 28 D4 48 /I/ 68
D3 9 /ECP/2 29 D5 49 /I/ 69
D4 10 /SCP/1 30 D6 50 /I/ 70
D5 11 /SCP/2 31 D7 51 /I/ 71
D6 12 D0 32 /I/ 52 /I/ 72
/P/ 13 D1 33 /I/ 53 /I/ 73
/ECP/1 14 D2 34 /I/ 54 /I/ 74
/ECP/2 15 D3 35 /I/ 55 /I/ 75
/I/ 16 /CC/1 36 D8 56 /I/ 76
/I/ 17 /CC/2 37 D9 57 /I/ 77
/I/ 18 /CC/1 38 D10 58 /I/ 78
/I/ 19 /CC/2 39 D11 59 /I/ 79
Note:
/SCP/1 = /K28.2/ /ECP/1 = /K29.7/ /CC/1 = /K23.7/
/SCP/2 = /K27.7/ /ECP/2 = /K30.7/ /CC/2 = /K23.7/
The sequence shown is for illustrative purposes only, SP002_03_05_062507
Figure 5-6: Single-Lane Channel Typical Data Flow

SP002 (v2.1) June 24, 2009
R
5.4.11 Multi-Lane Striping and Transmission Rules

The Aurora 8B/10B protocol defines the striping of user data and control ordered sets
across channels consisting of an arbitrary number of lanes. The striping scheme balances
lane efficiency and implementation simplicity. Figure 5-7 is an overview of the striping
scheme.
Lane 0
D3 D2 /SCP/2 /SCP/1
Transmitting Data Receiving Data

D5 D4 D3 D2 D1 D0 /SCP/2 /SCP/1 D5 D4 D3 D2 D1 D0 /SCP/2 /SCP/1
D5 D4 D1 D0
Lane 1 sp002_03_06_110402
Figure 5-7: Channel Striping Overview
Striping allocates symbol-pairs across multiple lanes. Striping is the method used to send
data simultaneously across all n lanes of a multi-lane channel. The symbol stream is striped
across the lanes on a symbol-pair by symbol-pair basis. Striping may begin in any lane and
proceeds lane by lane. For example, the first symbol-pair is striped onto lane 0, the second
symbol-pair onto lane 1, and the nth symbol-pair onto lane n-1. The nth+1 symbol-pair is
striped onto lane 0.
The only special requirements are as follows:
• The individual symbols in the symbol pairs /SCP/, /ECP/, /SNF/, /SUF/ must not
be split between lanes, but can be transmitted and received on any lane
• When /I/ sequences are transmitted, the same data pattern must be transmitted over
each lane in the channel that requires an /I/ sequence
Figure 5-8, page 39 shows how the same channel sequence shown in Figure 5-6, page 37
would be transmitted over a channel consisting of three lanes.

SP002 (v2.1) June 24, 2009
R
Lane 0 Lane 1 Lane 2
/I/ 0 /I/ 0 /SCP/1 0

/I/ 1 /I/ 1 /SCP/2 1
D0 2 D2 2 D4 2
D1 3 D3 3 D5 3
D6 4 /ECP/1 4 /I/ 4
/P/ 5 /ECP/2 5 /I/ 5
/I/ 6 /SCP/1 6 D0 6
/I/ 7 /SCP/2 7 D1 7
D2 8 D4 8 /ECP/1 8
D3 9 D5 9 /ECP/2 9
/SCP/1 10 D0 10 D2 10
/SCP/2 11 D1 11 D3 11
/CC/1 12 /CC/1 12 /CC/1 12
/CC/2 13 /CC/2 13 /CC/2 13
/CC/1 14 /CC/1 14 /CC/1 14
Time /CC/2 15 /CC/2 15 /CC/2 15
/CC/1 16 /CC/1 16 /CC/1 16
/CC/2 17 /CC/2 17 /CC/2 17
/CC/1 18 /CC/1 18 /CC/1 18
/CC/2 19 /CC/2 19 /CC/2 19
/CC/1 20 /CC/1 20 /CC/1 20
/CC/2 21 /CC/2 21 /CC/2 21
/CC/1 22 /CC/1 22 /CC/1 22
/CC/2 23 /CC/2 23 /CC/2 23
D4 24 D6 24 /I/ 24
D5 25 D7 25 /I/ 25
/I/ 26 D8 26 D10 26
/I/ 27 D9 27 D11 27
D12 28 /ECP/1 28 /I/ 28
/P/ 29 /ECP/2 29 /I/ 29
/I/ 30 /I/ 30 /I/ 30
/I/ 31 /I/ 31 /I/ 31
/I/ 32 /I/ 32 /I/ 32
/I/ 33 /I/ 33 /I/ 33
/I/ 34 /I/ 34 /I/ 34
/I/ 35 /I/ 35 /I/ 35
Note:
/SCP/1 = /K28.2/ /ECP/1 = /K29.7/ /CC/1 = /K23.7/
/SCP/2 = /K27.7/ /ECP/2 = /K30.7/ /CC/2 = /K23.7/ SP002_03_07_062507
Figure 5-8: Typical Data Flow for a Triple-Lane Channel

SP002 (v2.1) June 24, 2009
R

SP002 (v2.1) June 24, 2009
R
Section 6
Electrical Specifications
6.1 Overview
The AC specifications cover both single-lane and multi-lane implementations. The
specifications define two types of transmitters and one type of receiver with baud rates of
1.25, 2.5, and 3.125 Gbps. The Aurora 8B/10B protocol does not preclude the use of other
baud rates, but only defines timing for these by way of example.
This chapter specifies differential signaling in quantities that represent the voltage
difference between the true and complement signals. This is known as the peak-to-peak
voltage. The peak-to-peak voltage is twice that of the peak voltage of either the true or the
complement signal. Specific definitions are given Table 6-2, page 43.
To ensure interoperability between drivers and receivers of different vendors and
technologies, AC coupling at the receiver input is required.
6.2 Signal Definition

The Aurora 8B/10B protocol uses differential signaling between ports. This section
specifies signals using peak-to-peak differential voltages. Figure 6-1 shows how the signals
are defined. The figure shows waveforms for either a transmitter (TD and TD) or a receiver
(RD and RD). Each signal swings between A volts and B volts. Using these waveforms, the
definitions are as follows:
1. The transmitter or receiver has a peak-to-peak range of A - B
2. The differential signal ranges from +|A−B| to -|A-B|
3. The differential peak-to-peak signal is 2 * (A−B)
Peak-to-peak is the difference between the most positive and the most negative
readings of a particular signal. In this case (A−B) −(−(A−B)) = 2*(A−B).
A Volts TD or RD
B Volts TD or RD
Single-Ended Voltage Swing SP002_05_01_101703
Figure 6-1: Differential Peak-To-Peak Voltage of Transmitter or Receiver

SP002 (v2.1) June 24, 2009
R
To illustrate this concept using real values, consider the case where a current mode logic
(CML) transmitter has a termination voltage of 2.5V and has a swing between 2.5V and
2.0V. Using these values, the peak-to-peak range is 500 mV. The differential signal ranges
between 500 mV and -500 mV. The peak differential signal is 500 mV. The differential peak-
to-peak signal is 1000 mV.
6.3 Equalization
With the use of high-speed serial transceivers, the interconnect media causes degradation
of the signal at the receiver. Effects such as inter-symbol interference (ISI) or
data-dependent jitter are produced. This loss can be large enough to degrade the eye
opening at the receiver beyond that which is allowed in this specification. To negate a
portion of these effects, equalization techniques can be used, such as:
• Pre-emphasis: Applied to the transmitter

• Passive equalization: A passive high pass filter network placed at the receiver
• Adaptive equalization: The use of active circuits in the receiver
6.4 Transmitter Specifications

Driver AC timing specifications are displayed in the tables below.
Table 6-1: Transmitter AC Timing Specifications - 1.25 Gbps Baud Rate
Range
Characteristic Symbol Unit Notes
Min Max
Differential output voltage VDIFF 800 1600 mV Peak-to-peak differential
Rise/fall time TMRF 60 ps At driver output
Deterministic jitter JD 0.17 UI
Total jitter JT 0.35 UI
Output skew SO 25 ps Skew at a transmitter output between the two
signals comprising a differential pair
Multiple output skew SMO 1000 ps Skew at the transmitter output between lanes
of a multi-lane channel
Unit interval UI 800 800 ps +/- 100 ppm
Note: AC coupling is required to guarantee interoperability between vendors.

SP002 (v2.1) June 24, 2009
R
Receiver Specifications

Range
Min Max

Range
Min Max
6.5 Receiver Specifications

Receiver AC timing specifications are displayed in the tables below.
Table 6-4: Receiver AC Timing Specifications - 1.25 Gbps Baud Rate
Range
Min Max
Differential input voltage VIN 200 1600 mV Peak-to-peak differential input voltage
Deterministic jitter JD 0.37 UI Measured at receiver.
Total jitter JT 0.65 UI Measured at receiver

SP002 (v2.1) June 24, 2009
R

Range
Min Max
Input skew SI 75 ps Skew at a receiver input between the two
Multiple input skew SMI 24 ns Skew at the receiver input between lanes of a
multi-lane channel
Bit error rate BER 10-12

Range
Min Max
multi-lane channel

SP002 (v2.1) June 24, 2009
R
Receiver Eye Diagrams

Range
Min Max

multi-lane channel
6.6 Receiver Eye Diagrams

The following receiver eye openings are required to ensure proper operation.
800 mV
Minimum Eye
Differential Voltage
100 mV
-100 mV
Maximum Eye
-800 mV
0 .325 .42 .58 .675 1
Time (UI) SP002_05_02_081503
Figure 6-2: 1.25 Gbps Baud Rate Receiver Eye Diagram

SP002 (v2.1) June 24, 2009
R
800 mV
Minimum Eye
100 mV
-100 mV
Maximum Eye
-800 mV
0 .325 .42 .58 .675 1
Time (UI) SP002_05_03_120402
800 mV
Minimum Eye
100 mV
-100 mV
Maximum Eye
-800 mV
0 .325 .42 .58 .675 1
Time (UI) SP002_05_04_030403

SP002 (v2.1) June 24, 2009
R
Appendix A
8B/10B Coding Reference

A.1 8B/10B Encoding
The Aurora 8B/10B protocol uses 8B/10B line coding, which includes Data characters and
K characters. The 8-bit values are coded into 10-bit values, keeping the serial line DC
balanced and providing sufficient line transitions for reliable clock recovery. K characters
are special Data characters used to construct the ordered sets defined in Table 5-1, page 33.
Table A-1, and Table A-2, page 56 show the tables of valid Data and K characters.
Table A-1: Valid Data Characters

Data Byte Bits Current RD – Current RD +
Name HGF EDCBA abcdei fghj abcdei fghj
D0.0 000 00000 100111 0100 011000 1011
D1.0 000 00001 011101 0100 100010 1011
D2.0 000 00010 101101 0100 010010 1011
D3.0 000 00011 110001 1011 110001 0100
D4.0 000 00100 110101 0100 001010 1011
D5.0 000 00101 101001 1011 101011 0100
D6.0 000 00110 011001 1011 011001 0100
D7.0 000 00111 111000 1011 000111 0100
D8.0 000 01000 111001 0100 000110 1011
D9.0 000 01001 100101 1011 011010 0100
D10.0 000 01010 010101 1011 010101 0100
D11.0 000 01011 110100 1011 110100 0100
D12.0 000 01100 001101 1011 001101 0100
D13.0 000 01101 101100 1011 101100 0100
D14.0 000 01110 011100 1011 011100 0100
D15.0 000 01111 010111 0100 101000 1011
D16.0 000 10000 011011 0100 100100 1011
D17.0 000 10001 100011 1011 100011 0100
D18.0 000 10010 010011 1011 010011 0100

SP002 (v2.1) June 24, 2009
R
Table A-1: Valid Data Characters (Cont’d)

D19.0 000 10011 110010 1011 110010 0100
D20.0 000 10100 001011 1011 001011 0100
D21.0 000 10101 101010 1011 101010 0100
D22.0 000 10110 011010 1011 011010 0100
D23.0 000 10111 111010 0100 000101 1011
D24.0 000 11000 110011 0100 001100 1011
D25.0 000 11001 100110 1011 100110 0100
D26.0 000 11010 010110 1011 010110 0100
D27.0 000 11011 110110 0100 001001 1011
D28.0 000 11100 001110 1011 001110 0100
D29.0 000 11101 101110 0100 010001 1011
D30.0 000 11110 011110 0100 100001 1011
D31.0 000 11111 101011 0100 010100 1011
D0.1 001 00000 100111 1001 011000 1001
D1.1 001 00001 011101 1001 100010 1001
D2.1 001 00010 101101 1001 010010 1001
D3.1 001 00011 110001 1001 110001 1001
D4.1 001 00100 110101 1001 001010 1001
D5.1 001 00101 101001 1001 101011 1001
D6.1 001 00110 011001 1001 011001 1001
D7.1 001 00111 111000 1001 000111 1001
D8.1 001 01000 111001 1001 000110 1001
D9.1 001 01001 100101 1001 011010 1001
D10.1 001 01010 010101 1001 010101 1001
D11.1 001 01011 110100 1001 110100 1001
D12.1 001 01100 001101 1001 001101 1001
D13.1 001 01101 101100 1001 101100 1001
D14.1 001 01110 011100 1001 011100 1001
D15.1 001 01111 010111 1001 101000 1001
D16.1 001 10000 011011 1001 100100 1001
D17.1 001 10001 100011 1001 100011 1001
D18.1 001 10010 010011 1001 010011 1001

SP002 (v2.1) June 24, 2009
R
8B/10B Encoding

D19.1 001 10011 110010 1001 110010 1001
D20.1 001 10100 001011 1001 001011 1001
D21.1 001 10101 101010 1001 101010 1001
D22.1 001 10110 011010 1001 011010 1001
D23.1 001 10111 111010 1001 000101 1001
D24.1 001 11000 110011 1001 001100 1001
D25.1 001 11001 100110 1001 100110 1001
D26.1 001 11010 010010 1001 010110 1001
D27.1 001 11011 110110 1001 001001 1001
D28.1 001 11100 001110 1001 001110 1001
D29.1 001 11101 101110 1001 010001 1001
D30.1 001 11110 011110 1001 100001 1001
D31.1 001 11111 101011 1001 010100 1001
D0.2 010 00000 100111 0101 011000 0101
D1.2 010 00001 011101 0101 100010 0101
D2.2 010 00010 101101 0101 010010 0101
D3.2 010 00011 110001 0101 110001 0101
D4.2 010 00100 110101 0101 001010 0101
D5.2 010 00101 101001 0101 101011 0101
D6.2 010 00110 011001 0101 011001 0101
D7.2 010 00111 111000 0101 000111 0101
D8.2 010 01000 111001 0101 000110 0101
D9.2 010 01001 100101 0101 011010 0101
D10.2 010 01010 010101 0101 010101 0101
D11.2 010 01011 110100 0101 110100 0101
D12.2 010 01100 001101 0101 001101 0101
D13.2 010 01101 101100 0101 101100 0101
D14.2 010 01110 011100 0101 011100 0101
D15.2 010 01111 010111 0101 101000 0101
D16.2 010 10000 011011 0101 100100 0101
D17.2 010 10001 100011 0101 100011 0101
D18.2 010 01010 010011 0101 010011 0101

SP002 (v2.1) June 24, 2009
R

D19.2 010 10011 110010 0101 110010 0101
D20.2 010 10100 001011 0101 001011 0101
D21.2 010 10101 101010 0101 101010 0101
D22.2 010 10110 011010 0101 011010 0101
D23.2 010 10111 111010 0101 000101 0101
D24.2 010 11000 110011 0101 001100 0101
D25.2 010 11001 100110 0101 100110 0101
D26.2 010 11010 010010 0101 010110 0101
D27.2 010 11011 110110 0101 001001 0101
D28.2 010 11100 001110 0101 001110 0101
D29.2 010 11101 101110 0101 010001 0101
D30.2 010 11110 011110 0101 100001 0101
D31.2 010 11111 101011 0101 010100 0101
D0.3 000 00000 100111 0011 011000 1100
D1.3 011 00001 011101 0011 100010 1100
D2.3 011 00010 101101 0011 010010 1100
D3.3 011 00011 110001 1100 110001 0011
D4.3 011 00100 110101 0011 001010 1100
D5.3 011 00101 101001 1100 101011 0011
D6.3 011 00110 011001 1100 011001 0011
D7.3 011 00111 111000 1100 000111 0011
D8.3 011 01000 111001 0011 000110 1100
D9.3 011 01001 100101 1100 011010 0011
D10.3 011 01010 010101 1100 010101 0011
D11.3 011 01011 110100 1100 110100 0011
D12.3 011 01100 001101 1100 001101 0011
D13.3 011 01101 101100 1100 101100 0011
D14.3 011 01110 011100 1100 011100 0011
D15.3 011 01111 010111 0011 101000 1100
D16.3 011 10000 011011 0011 100100 1100
D17.3 011 10001 100011 1100 100011 0011
D18.3 011 10010 010011 1100 010011 0011

SP002 (v2.1) June 24, 2009
R
8B/10B Encoding

D19.3 011 10011 110010 1100 110010 0011
D20.3 011 10100 001011 1100 001011 0011
D21.3 011 10101 101010 1100 101010 0011
D22.3 011 10110 011010 1100 011010 0011
D23.3 011 10111 111010 0011 000101 1100
D24.3 011 11000 110011 0011 001100 1100
D25.3 011 11001 100110 1100 100110 0011
D26.3 011 11010 010110 1100 010110 0011
D27.3 011 11011 110110 0011 001001 1100
D28.3 011 11100 001110 1100 001110 0011
D29.3 011 11101 101110 0011 010001 1100
D30.3 011 11110 011110 0011 100001 1100
D31.3 011 11111 101011 0011 010100 1100
D0.4 100 00000 100111 0010 011000 1101
D1.4 100 00001 011101 0010 100010 1101
D2.4 100 00010 101101 0010 010010 1101
D3.4 100 00011 110001 1101 110001 0010
D4.4 100 00100 110101 0010 001010 1101
D5.4 100 00101 101001 1101 101011 0010
D6.4 100 00110 011001 1101 011001 0010
D7.4 100 00111 111000 1101 000111 0010
D8.4 100 01000 111001 0010 000110 1101
D9.4 100 01001 100101 1101 011010 0010
D10.4 100 01010 010101 1101 010101 0010
D11.4 100 01011 110100 1101 110100 0010
D12.4 100 01100 001101 1101 001101 0010
D13.4 100 01101 101100 1101 101100 0010
D14.4 100 01110 011100 1101 011100 0010
D15.4 100 01111 010111 0010 101000 1101
D16.4 100 10000 011011 0010 100100 1101
D17.4 100 10001 100011 1101 100011 0010
D18.4 100 10010 010011 1101 010011 0010

SP002 (v2.1) June 24, 2009
R

D19.4 100 10011 110010 1101 110010 0010
D20.4 100 10100 001011 1101 001011 0010
D21.4 100 10101 101010 1101 101010 0010
D22.4 100 10110 011010 1101 011010 0010
D23.4 100 10111 111010 0010 000101 1101
D24.4 100 11000 110011 0010 001100 1101
D25.4 100 11001 100110 1101 100110 0010
D26.4 100 11010 010010 1101 010110 0010
D27.4 100 11011 110110 0010 001001 1101
D28.4 100 11100 001110 1101 001110 0010
D29.4 100 11101 101110 0010 010001 1101
D30.4 100 11110 011110 0010 100001 1101
D31.4 100 11111 101011 0010 010100 1101
D0.5 101 00000 100111 1010 011000 1010
D1.5 101 00001 011101 1010 100010 1010
D2.5 101 00010 101101 1010 010010 1010
D3.5 101 00011 110001 1010 110001 1010
D4.5 101 00100 110101 1010 001010 1010
D5.5 101 00101 101001 1010 101001 1010
D6.5 101 00110 011001 1010 011001 1010
D7.5 101 00111 111000 1010 000111 1010
D8.5 101 01000 111001 1010 000110 1010
D9.5 101 01001 100101 1010 011010 1010
D10.5 101 01010 010101 1010 010101 1010
D11.5 101 01011 110100 1010 110100 1010
D12.5 101 01100 001101 1010 001101 1010
D13.5 101 01101 101100 1010 101100 1010
D14.5 101 01110 011100 1010 011100 1010
D15.5 101 01111 010111 1010 101000 1010
D16.5 101 10000 011011 1010 100100 1010
D17.5 101 10001 100011 1010 100011 1010
D18.5 101 01010 010011 1010 010011 1010

SP002 (v2.1) June 24, 2009
R
8B/10B Encoding

D19.5 101 10011 110010 1010 110010 1010
D20.5 101 10100 001011 1010 001011 1010
D21.5 101 10101 101010 1010 101010 1010
D22.5 101 10110 011010 1010 011010 1010
D23.5 101 10111 111010 1010 000101 1010
D24.5 101 11000 110011 1010 001100 1010
D25.5 101 11001 100110 1010 100110 1010
D26.5 101 11010 010010 1010 010110 1010
D27.5 101 11011 110110 1010 001001 1010
D28.5 101 11100 001110 1010 001110 1010
D29.5 101 11101 101110 1010 010001 1010
D30.5 101 11110 011110 1010 100001 1010
D31.5 101 11111 101011 1010 010100 1010
D0.6 110 00000 100111 0110 011000 0110
D1.6 110 00001 011101 0110 100010 0110
D2.6 110 00010 101101 0110 010010 0110
D3.6 110 00011 110001 0110 110001 0110
D4.6 110 00100 110101 0110 001010 0110
D5.6 110 00101 101001 0110 101011 0110
D6.6 110 00110 011001 0110 011001 0110
D7.6 110 00111 111000 0110 000111 0110
D8.6 110 01000 111001 0110 000110 0110
D9.6 110 01001 100101 0110 011010 0110
D10.6 110 01010 010101 0110 010101 0110
D11.6 110 01011 110100 0110 110100 0110
D12.6 110 01100 001101 0110 001101 0110
D13.6 110 01101 101100 0110 101100 0110
D14.6 110 01110 011100 0110 011100 0110
D15.6 110 01111 010111 0110 101000 0110
D16.6 110 10000 011011 0110 100100 0110
D17.6 110 10001 100011 0110 100011 0110
D18.6 110 01010 010011 0110 010011 0110

SP002 (v2.1) June 24, 2009
R

D19.6 110 10011 110010 0110 110010 0110
D20.6 110 10100 001011 0110 001011 0110
D21.6 110 10101 101010 0110 101010 0110
D22.6 110 10110 011010 0110 011010 0110
D23.6 110 10111 111010 0110 000101 0110
D24.6 110 11000 110011 0110 001100 0110
D25.6 110 11001 100110 0110 100110 0110
D26.6 110 11010 010010 0110 010110 0110
D27.6 110 11011 110110 0110 001001 0110
D28.6 110 11100 001110 0110 001110 0110
D29.6 110 11101 101110 0110 010001 0110
D30.6 110 11110 011110 0110 100001 0110
D31.6 110 11111 101011 0110 010100 0110
D0.7 111 00000 100111 0001 011000 1110
D1.7 111 00001 011101 0001 100010 1110
D2.7 111 00010 101101 0001 010010 1110
D3.7 111 00011 110001 1110 110001 0001
D4.7 111 00100 110101 0001 001010 1110
D5.7 111 00101 101001 1110 101011 0001
D6.7 111 00110 011001 1110 011001 0001
D7.7 111 00111 111000 1110 000111 0001
D8.7 111 01000 111001 0001 000110 1110
D9.7 111 01001 100101 1110 011010 0001
D10.7 111 01010 010101 1110 010101 0001
D11.7 111 01011 110100 1110 110100 1000
D12.7 111 01100 001101 1110 001101 0001
D13.7 111 01101 101100 1110 101100 1000
D14.7 111 01110 011100 1110 011100 1000
D15.7 111 01111 010111 0001 101000 1110
D16.7 111 10000 011011 0001 100100 1110
D17.7 111 10001 100011 0111 100011 0001
D18.7 111 10010 010011 0111 010011 0001

SP002 (v2.1) June 24, 2009
R
8B/10B Encoding

D19.7 111 10011 110010 1110 110010 0001
D20.7 111 10100 001011 0111 001011 0001
D21.7 111 10101 101010 1110 101010 0001
D22.7 111 10110 011010 1110 011010 0001
D23.7 111 10111 111010 0001 000101 1110
D24.7 111 11000 110011 0001 001100 1110
D25.7 111 11001 100110 1110 100110 0001
D26.7 111 11010 010110 1110 010110 0001
D27.7 111 11011 110110 0001 001001 1110
D28.7 111 11100 001110 1110 001110 0001
D29.7 111 11101 101110 0001 010001 1110
D30.7 111 11110 011110 0001 100001 1110
D31.7 111 11111 101011 0001 010100 1110

SP002 (v2.1) June 24, 2009
R
Table A-2: Valid K (Control) Characters

Special Bits Current RD – Current RD +
Code Name HGF EDCBA abcdei fghj abcdei fghj
K23.7 111 10111 111010 1000 000101 0111
K27.7 111 11011 110110 1000 001001 0111
K28.0 000 11100 001111 0100 110000 1011
K28.2 010 11100 001111 0101 110000 1010
K28.3 011 11100 001111 0011 110000 1100
K28.4 100 11100 001111 0010 110000 1101
K28.5 101 11100 001111 1010 110000 0101
K28.6 110 11100 001111 0110 110000 1001
K29.7 111 11101 101110 1000 010001 0111
K30.7 111 11110 011110 1000 100001 0111

SP002 (v2.1) June 24, 2009
R
Appendix B
Aurora 8B/10B Serial Simplex Operation

B.1 Overview
This appendix provides an addendum to the Aurora 8B/10B protocol that specifies the use
of the protocol in Aurora 8B/10B serial simplex (1) operation, or simplex operation. Except where
indicated otherwise in this appendix, simplex operation is wholly defined by the Aurora
8B/10B Protocol Specification.
Simplex operation preserves all of the Aurora 8B/10B protocol features for channel
initialization, data transmission, flow control, and error handling across a single
unidirectional channel, called the Aurora 8B/10B simplex channel. An Aurora 8B/10B
simplex channel comprises one or more serial lanes carrying data from the transmit
partner to the receive partner, as shown in Figure B-1. Channel PDUs and user flow control
(UFC) PDUs are transferred across the Aurora 8B/10B simplex channel.
X-Ref Target - Figure B-1
Aurora 8B/10B Simplex

Channel Partners
Aurora
8B/10B
Simplex
Lane 0 Channel
User Aurora Aurora User

Interface 8B/10B 8B/10B Interface
User Simplex Simplex User
Application Transmit Receive Application
Interface Interface
Lane N-1
User PDUs, Channel PDUs, User PDUs,

UFC Messages UFC PDUs UFC Messages
SP002_B_01_050609
Figure B-1: Aurora 8B/10B Simplex Channel Overview
1. Simplex is used in the technical sense, defined as communication across a channel in a single direction. Full-
duplex Aurora 8B/10B is used in this appendix to differentiate between Aurora 8B/10B and Aurora 8B/10B
Simplex.

SP002 (v2.1) June 24, 2009
R
B.2 Data Transmission and Reception

The transmit user interface passes user PDUs and user flow control messages to the Aurora
8B/10B transmit interface for encapsulation and transmission across the Aurora 8B/10B
simplex channel, as defined by the Aurora 8B/10B Protocol Specification. At the Aurora
8B/10B receive interface, the channel PDUs and user flow control PDUs are passed to the
receiving user application as user PDUs and user flow control messages.
The rules governing data transmission from the transmit partner and reception at the
receive partner are completely defined in Section 2, “Data Transmission and Reception”
with the exception of the transmission of native flow control PDUs. Native flow control
PDUs have no relevance when transferred across the Aurora 8B/10B simplex channel.
B.3 Flow Control

User flow control messages can be sent from the transmit partner to the receive partner, as
defined in Section 3.1 “Overview,” Section 3.1.4 “User Flow Control Operation,” and
Section 3.1.5 “User Flow Control PDU Format” of the Aurora 8B/10B Protocol Specification.
The transmission of user flow control PDUs from the receive partner to the transmit
partner is not specified by the Aurora 8B/10B serial simplex definition.
B.4 Initialization and Error Handling

Lane initialization, channel bonding for multi-lane channels, and lane verification are
performed between the Aurora 8B/10B simplex channel partners using a modification of
the procedures specified in Section 4, “Initialization and Error Handling.” These modified
procedures are illustrated in Figures B-2 through B-8, which show initialization state
machines for the transmit and receive partners. The state machines include new inputs and
outputs to support simplex operation.

SP002 (v2.1) June 24, 2009
R
Serial Simplex vs. Full-Duplex Operation
B.5 Serial Simplex vs. Full-Duplex Operation

This section details the differences between Aurora 8B/10B simplex operation and Aurora
8B/10B full-duplex operation. Refer to the State Diagram Conventions, page 7 for
Figures B-2 through B-8 in the following sections.
B.5.1 Transmit Interface Lane initialization

Each lane, whether in Aurora 8B/10B full-duplex operation or in simplex operation, first
undergoes lane initialization. However, simplex operation requires different state
machines than full-duplex operation in the transmit and receive interfaces.Table B-1 shows
the inputs and outputs that are necessary for simplex operation. These signals are shown
in uppercase in the state diagrams that follow.
Table B-1: Signals for Simplex Operation
Signal Direction Description
TX_ALIGNED Input Transmit Lane Initialization state machine input. Moves the
transmit interface past the alignment procedure.
RX_ALIGNED Output Receive Lane Initialization output. Asserted when
alignment is reached at the receiver.
TX_BONDED Input Transmit Channel Bonding state machine input. Moves the
transmit interface past the channel bonding procedure.
RX_BONDED Output Receive Channel Bonding state machine output. Asserted
when channel bonding condition is met.
TX_VERIFIED Input Transmit Channel Verification state machine input. Moves
the transmit interface past the channel verification
procedure.
RX_VERIFIED Output Receive Channel Verification state machine output.
Asserted when the channel verification criteria are met.
TX_RESET Input Transmit Lane Initialization, Channel Bonding, and
Channel Verification Procedures state machine input.
Returns transmit interface to TXRESET0.
RX_RESET Output Receive Lane Initialization, Channel Bonding, Channel
Verification, and Hard Error Procedures state machine
input. Asserted when an error condition occurs causing the
receive interface to return to RXRESET0.

SP002 (v2.1) June 24, 2009
R
Figure B-2 shows the state diagram for the lane initialization procedure of the transmit
interface. If the RESET input is asserted at any point in the initialization procedure, then
the state of the transmit interface must return to TXRESET0, as indicated in Figure B-2.
Power-up, Reset, Channel Failure
TXRESET0
- xmit = /SP/
TXRESET1
- xmit = /SP/
- Reset internal state else
- Lane Reset Counter = Lane Reset Counter + 1
TXINIT0 Lane Reset Counter = N*
- xmit = /SP/
else
Multi-Lane Channel Single-Lane Channel

& TX_ALIGNED = 1 & TX_ALIGNED = 1
To Channel Bonding Procedure To Channel Verification Procedure
* The value of N is implementation specific SP002_B_02_061704
Figure B-2: Transmit Interface Lane Initialization Procedure

SP002 (v2.1) June 24, 2009
R
B.5.2 Receive Interface Lane Initialization

Figures B-3 shows the state diagram for the lane initialization procedure of the transmit
interface.
Power-up, Reset, Channel Failure
TXRESET0

TXRESET1
- Lane Reset Counter = Lane Reset Counter + 1 Lane Reset Counter < N*
Lane Reset Counter = N*

RXINIT0
- K Counter = 0 Else
Else
RX = /K/
RXINIT1
RX = /K/
- K Counter = K Counter + 1 & valid code group
- Enable comma alignment = 1 & K Counter 1 3
RX = [valid code group RX = /K/

& (not /K/)] & valid code group
RXINIT1A
Else - K Counter = K Counter RX 1 [valid code group

- Enable comma alignment = 1 & (not /K/)]
RX = RXINIT2
RX = valid code group
/D21.5/ or /D19.6/ & K Counter >= 3
- Start error detection circuitry
Toggle - Start Error Counter
Lane Polarity
Multi-Lane Channel Single-Lane Channel
RXINIT3
Lane
RX_ALIGNED = 1 All Lanes up 1 1
All Lanes up = 1
RXINIT4 RXINIT5
RX_ALIGNED = 1 RX_ALIGNED = 1
To Channel Bonding Procedure To Channel Verification Procedure
* The value of N is implementation specific SP002_B_03_062507
Figure B-3: Receive Interface Lane Initialization

SP002 (v2.1) June 24, 2009
R
B.5.3 Transmit Interface Channel Bonding Procedure

Figure B-4 shows the transmit interface procedure for channel bonding.

TXCB0
- xmit = /I/
TX_BONDED ≠ 1
TX_BONDED = 1
SP002_B_04_061704
Figure B-4: Transmit Interface Channel Bonding Procedure
B.5.4 Receive Interface Channel Bonding Procedure

Figure B-5 shows the state diagram for the receive interface channel bonding procedure.

RXCB0
- CB_CTR = 0
Transceiver channel
- Enable channel bonding = 1
bonding in progress
Else RXCB1 All lanes indicate channel bonding is completed
- Enable channel bonding = 1 /A/ on all lanes

- If /A/ on all lanes, then: or
CB_CTR = CB_CTR + 1 no /A/ on any lane
RXCB2 CB_CTR = 4
- Set RX_BONDED = 1

SP002_B_05_061704
Figure B-5: Receive Interface Channel Bonding Procedure
B.5.5 Transmit Interface Channel Verification Procedure

Figure B-6 shows the transmit interface procedure for channel verification.

TXCB0
- xmit = verification sequence
TX_VERIFY ≠ 1
TX_VERIFY = 1
Initialization Complete, Channel Ready

SP002_B_06_061704
Figure B-6: Transmit Interface Channel Verification Procedure

SP002 (v2.1) June 24, 2009
R
B.5.6 Receive Interface Channel Verification Procedure

Figure B-7 shows the receive interface procedure for channel verification.
From Lane Initialization Procedure

If Single-Lane Channel
From Channel Bonding Procedure
If Multi-Lane Channel
RXCV0
- RX CV Counter = 0
RXCV1
- If RX = /V/ then: Go to RXRESET0
RX CV Counter = CV Counter + 1 Else
RXCV4
Bad /V/ Set RX_RESET = 1
RX CV Counter = 4
RXCV2
- Lane RX_VERIFIED = 1
Else
RXCV3 All lanes verified
RX_VERIFIED = 1
Initialization Complete, Channel Ready

SP002_B_07_061704
Figure B-7: Receive Interface Channel Verification Procedure
B.5.7 Receive Interface Hard Error Procedure

If a hard error is encountered in the receiver at any point during the initialization or data
transmission procedures, then the RX_RESET output is asserted at the receive interface,
and the receiver returns to the reset state RXRESET0. Figure B-8 shows the receive interface
hard error procedure.
Go to RXRESET0
RXERR0
Hard Error RX_RESET = 1
SP002_B_08_061704
Figure B-8: Receiver Interface Hard Error Procedure

SP002 (v2.1) June 24, 2009
R
B.5.8 Use Models for Aurora 8B/10B Serial Simplex

Two use models are envisaged for Aurora 8B/10B serial simplex.
The first use model includes a user-defined back channel that conveys the receive interface
status, as represented by the receive interface outputs defined in this appendix, back to the
transmit interface. The details of the back channel implementation is highly application
specific and is outside of the scope of this specification.
The second use-model does not include a back channel. In this second case, the control of
the additional inputs to the receive interface as defined in this appendix is user-defined.
The interface designer must ensure that this control guarantees the Aurora 8B/10B simplex
channel operation during normal operation.

SP002 (v2.1) June 24, 2009
R
Appendix C
References
1. IEEE Std 802.3
2. BYTE ORIENTED DC BALANCED (0,4) 8B/10B PARTITIONED BLOCK TRANSMISSION
CODE (Patent Number: 4,486,739). Inventors: Peter A. Franaszek and Albert X. Widmer
(IBM)

SP002 (v2.1) June 24, 2009
R

SP002 (v2.1) June 24, 2009
R
Glossary
Click on a letter, or scroll down to view the entire glossary.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
A
Aurora 8B/10B Interface
An implementation of the Aurora 8B/10B protocol.
C
Channel
The communication link between two Aurora 8B/10B interfaces,
comprising one or more lanes.
Character
A 9-bit entity comprised of an information octet and a control bit that
indicates whether the information octet contains data or control
information. The control bit has the value D or K indicating that the
information octet contains data or control information respectively.
Clock Compensation
A compensating mechanism provided by the Aurora 8B/10B protocol
for clock rate differences between the transmitter and receiver.
Clock Encoding
A method used to transmit a clock in band with data.

SP002 (v2.1) June 24, 2009
R
Code group
A 10-bit entity that is the result of 8B/10B encoding a character. A code
group is also called a symbol.
Column
A group of characters that are transmitted simultaneously on a multi-
lane channel.
Comma
A seven-bit encoded 8B/10B sequence that is either 1100000 or 0011111
which is used for alignment. The seven-bits are the most significant
bits of a 10-bit code group. A comma is contained in the 8B/10B
symbol designated as /K28.5/.
Control Character
A character whose control bit has the value K.
Current Mode Logic

Current Mode Logic (CML) is a differential logic operation using
devices that are commonly grounded through a current source.
D
Data Character
A character whose control bit has the value D.
Data Striping
This describes how data is mapped across a channel consisting of
multiple lanes.
Destriping
The opposite of striping; reverse of striping.
Deterministic Jitter
Deterministic jitter (DJ) is a jitter with a non-Gaussian probability
density function. Deterministic jitter is always bounded in amplitude
and has specific causes. If a sufficient amount of data is taken over a
complete cycle of each periodic element, the total amount of DJ will
remain constant.
Disparity
The difference between the number of ones and zeros in a symbol.
Disparity Error
A received code group whose value is inconsistent with the current
running disparity.

SP002 (v2.1) June 24, 2009
R
I
Idle Sequence
The sequence of characters (code groups after encoding) that is
transmitted when a PDU is not being transmitted. The idle sequence
allows the receiver to maintain bit synchronization and code group
alignment.
K
K Character
A character whose control bit has the value K. Also referred to as a
special character.
L
Lane
A full duplex physical serial connection.
Lane Alignment
The process of eliminating the skew between the lanes of a multi-lane
Aurora 8B/10B channel such that the characters transmitted as a
column by the sender are output as a column by the alignment process
of the receiver. Without lane alignment, the characters transmitted as
a column might be scattered across several columns output by the
receiver. During initialization, all lanes continuously transmit
columns of the idle sequence. The alignment process in the receiver
uses the /A/ ordered sets to realign the columns of received data.

SP002 (v2.1) June 24, 2009
R
Link Layer
This describes how the beginning and end of user protocol data units
(user PDUs) are marked during transmission. It also describes how
data pauses may be inserted in data during transmission and how
differences in clock rates between the transmitter and receiver are
managed. Equivalent to the OSI Link Layer.
Link Layer Flow Control

A mechanism for throttling the flow of user PDU in the link layer.
Link Layer Payload

The resulting data structure after padding.
N
Not-in-table Error
A received code group that does not exist in the 8B/10B table. Same as
a symbol error.
O
Octet
An 8-bit unit of information. Each bit of a octet has the value 0 or 1.
P
PCS
See Physical Coding Sublayer.
Physical Coding Sublayer (PCS)

The physical coding sublayer (PCS) function is responsible for idle
sequence generation, lane striping, and encoding for transmission. It
is also responsible for decoding, lane alignment, and destriping upon
reception. The PCS uses an 8B/10B encoding for transmission over the
channel. The PCS layer also provides mechanisms to detect lane states.
It provides for clock difference tolerance between the sender and
receiver without requiring flow control.

SP002 (v2.1) June 24, 2009
R
Physical Layer Interface

This consists of the electrical levels, the clock encoding, and symbol
coding.
Physical Medium Attachment (PMA)

The physical medium attachment (PMA) function is responsible for
serializing 10-bit parallel code groups to/from a serial bitstream on a
lane-by-lane basis.
PMA
See Physical Medium Attachment.
R
Running Disparity
The cumulative disparity of a sequence of symbols. The binary
variable used by the 8B/10B encoding and decoding functions.
S
SNF
See Start of Native Flow control.
Start of Native Flow Control (SNF)

The /SNF/ ordered set is used in the protocol to mark the start of a
native flow control PDU. A native flow control PDU is sent in
response to a channel partner's request. A native flow control PDU is
always comprised of exactly two symbols.
Start of User Flow Control (SUF)

The SUF ordered set is used in the protocol to mark the start of a user
flow control PDU. A user flow control PDU is comprised of the /SUF/
ordered set plus a data symbol that defines the length of the PDU,
followed by up to 16 symbols of user data.
Striping
Striping allocates byte-pairs across multiple lanes. The method used
on multi-lane channels to send data simultaneously across all n lanes
that make up the channel . The byte stream is striped across the lanes,
on a byte-pair by byte-pair basis, starting with the first byte-pair on
lane 0, to the second byte-pair on lane 1, to the third byte-pair on lane

SP002 (v2.1) June 24, 2009
R
2, to the nth byte-pair on lane n-1, and wrapping back with the nth+1
byte-pair on lane 0.
Stripping
The method to remove data from a PDU.
SUF
See Start of User Flow control.
Symbol
A 10-bit entity that is the result of 8B/10B encoding a character. A
symbol is also called a code group.
Symbol Error
A received code group that does not exist in the 8B/10B table. Same as
a not-in-table error.
Symbol Time
Equivalent to 10 unit times.
T
Total Jitter
The total deviation from the ideal timing of a clock or data signal as a
result of noise, patterns, or other causes.
U
User Application
An implementation of a higher level function that transports data
across an Aurora 8B/10B channel.
User Interface
An implementation-specific interface provided to the user application
by an Aurora 8B/10B interface.
User PDUs
User protocol data units.
Unit Interval
The unit interval (UI) is the total time of one ideal clock cycle. For
example, an Aurora 8B/10B channel operating at a data rate of 3.125
Gbps has a UI of 320 ps.

SP002 (v2.1) June 24, 2009
R
V
Valid Code Group
A received code group that when decoded has neither a disparity error
nor a not-in-table error. A disparity error is defined as a received code
group whose value is inconsistent with the current running disparity.
A not-in-table error is defined as a received code group that does not
exist in the 8B/10B table.
X
XON
A command that resumes transmission in a single direction used by
native flow control
XOFF
A command that suspends transmission in a single direction used by
native flow control

SP002 (v2.1) June 24, 2009

Aurora 8b10b Protocol Spec sp002

Uploaded by

Copyright:

Available Formats

Aurora 8b10b Protocol Spec sp002

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aurora 8b10b Protocol Spec sp002

Uploaded by

Copyright:

Available Formats

What is the purpose of the document?

What is the purpose of the document?

What is the 8B/10B encoding scheme?

What is the 8B/10B encoding scheme?

Aurora 8B/10B

SP002 (v2.1) June 24, 2009

Date Version Revision

Preface: About This Specification

Section 1: Introduction and Overview

Section 2: Data Transmission and Reception

Section 3: Flow Control

Section 4: Initialization and Error Handling

Aurora 8B/10B Protocol Specification www.xilinx.com 3

Section 5: PCS and PMA Layers

Section 6: Electrical Specifications

Appendix A: 8B/10B Coding Reference

Appendix B: Aurora 8B/10B Serial Simplex Operation

4 www.xilinx.com Aurora 8B/10B Protocol Specification

About This Specification

Open Standard Specification Contents

Convention Meaning or Use Example

Aurora 8B/10B Protocol Specification www.xilinx.com 5

Preface: About This Specification

Convention Meaning or Use Example

Convention Meaning or Use Example

width in bits ' radix value

Figure P-1: Properties of Literals

Table P-1 shows the Radix specifics:

6 www.xilinx.com Aurora 8B/10B Protocol Specification

Table P-1: Radix Specifics of Literals

Table P-2: Examples of Extended Values

State Diagram Conventions

Aurora 8B/10B Protocol Specification www.xilinx.com 7

Preface: About This Specification

State Machine Outputs

Figure P-2: State Machine Diagram Conventions

8 www.xilinx.com Aurora 8B/10B Protocol Specification

Introduction and Overview

Aurora 8B/10B Protocol Specification www.xilinx.com 9

Section 1: Introduction and Overview

X-Ref Target - Figure 1-1

Aurora 8B/10B Channel

User PDUs, Channel PDUs, User PDUs,

Figure 1-1: Aurora 8B/10B Channel Overview

10 www.xilinx.com Aurora 8B/10B Protocol Specification

Data Transmission and Reception

2.2 8B/10B Data Transmission and Reception

2.2.2 Data Ordering

2.2.3 Transmission Scheduling

Aurora 8B/10B Protocol Specification www.xilinx.com 11

Section 2: Data Transmission and Reception

12 www.xilinx.com Aurora 8B/10B Protocol Specification

8B/10B Data Transmission and Reception

2.2.4 User PDU Transmission Procedures

X-Ref Target - Figure 2-1

Link Layer Encapsulation

/SCP/ User PDU /P/ /ECP/

Figure 2-1: Transmission Procedures

2.2.4.2 Link Layer Encapsulation