Your future of PCI Express

PCI-Express may necessarily mean over more rapidly pcs. Because technological innovation builds up, laptop or computer designers may design and style a new motherboard using PCI-Express connectors that will adhere to special cables. This can accommodate absolutely modular laptop or computer technique, comparable to household stereo audio devices. You'd probably have a very smaller field while using motherboard along with brand along with a few PCI-Express connection jacks. The outer harddrive may join via USB 2.0 or PCI-Express. Smaller adventures that contain audio playing cards, online video playing cards, along with modems can also add. As an alternative to one particular significant field, your personal machine may be established however you desire, and yes it would likely merely always be while significant because factors you may need.

PCI-Express is often a totally different beast - it can be geared towards the property laptop or computer market place, and can revolutionize not simply your functionality involving pcs, and also abdominal muscles design along with way of home pc devices. This specific brand-new shuttle it not just more rapidly along with that can deal with additional bandwidth when compared with PCI. PCI-Express  is often a point-to-point system, allowing you pertaining to greater functionality along with might create your making involving motherboards more affordable. PCI-Express slots will likely recognize elderly PCI cards, which supports these people become popular more rapidly when compared with they will in case every one's PCI components ended up out of the blue pointless.
Related：

remote media converters

ftth fiber to the home

http://www.alivenotdead.com/sfptwinax/China-fiber-optical-manufacturer-on-OFC-NFOEC-and-ECOC-profile-2981337.html

The influence of PCI Express

PCI Express  is a high-speed serial connection that operates a lot more like a network than the usual bus. Learn how PCI Express can speed up a computer and replace the AGP.

Peripheral Component Interconnect (PCI) slots are such a fundamental element of a pc's buildings that most people take them for granted. For years, PCI has been a versatile, functional way to connect sound, video and network cards to a motherboard.

But PCI has some disadvantages. As processors, video cards, sound cards and networks have gotten faster and more powerful, PCI has stayed the same. It has a fixed width of 32 bits and can handle only 5 devices at a time. The newer, 64-bit PCI-X bus provides more bandwidth, but its greater width compounds some of PCI's other issues.

A new PCIe eliminates each of these disadvantages, provides more bandwidth and is best with existing os's.
Related:
http://mediaconvertera.wordpress.com/2013/03/27/banish-plc-splitter-inability/
http://10gmodule.wordpress.com/2013/03/27/exclude-plc-splitter-disaster-out-of-quite-a-few-areas/
http://sopto10gmodule.wordpress.com/2013/03/27/celebrate-18th-cpc-national-congress-a-decade-solid-a-new-large-fiber-optical-cable-assembly-land/

Transaction Descriptor Overview

The Transaction Descriptor is a mechanism for carrying Transaction information between the
Requester and the Completer. Transaction Descriptors are composed of three fields:
Transaction ID – identifies outstanding Transactions
Attributes field – specifies characteristics of the Transaction
Traffic Class (TC) field – associates Transaction with type of required service
Figure 2-12 shows the fields of the Transaction Descriptor. Note that these fields are shown
together to highlight their relationship as parts of a single logical entity. The fields are not
contiguous in the packet header.

Figure 2-12: Transaction Descriptor

First/Last DW Byte Enables Rules

Byte Enables are included with Memory, I/O, and Configuration Requests. This section defines the corresponding rules. Byte Enables, when present in the Request header, are located in byte 7 of the header (see Figure 2-11). For Memory Read Requests that have the TH bit Set, the Byte Enable fields are repurposed to carry the ST[7:0] field, and values for the Byte Enables are implied as defined below. Such Requests must only be issued when it is acceptable to complete the Requests as if all bytes for requested payload were enabled.

For Memory Reads that have the TH bit Set, the following values are implied for the Byte
Enables.
• If the Length field for this Request indicates a length of 1 DW, then the value for the 1st DW
Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied
to be 0000b.
• If the Length field for this Request indicates a length of greater than 1 DW, then the value
for the 1st DW Byte Enables and the Last DW Byte Enables is implied to be 1111b.

The 1st DW BE[3:0] field contains Byte Enables for the first (or only) DW referenced by a
Request.
• If the Length field for a Request indicates a length of greater than 1 DW, this field must not
equal 0000b.
􀂉 The Last DW BE[3:0] field contains Byte Enables for the last DW of a Request.
• If the Length field for a Request indicates a length of 1 DW, this field must equal 0000b.
• If the Length field for a Request indicates a length of greater than 1 DW, this field must not
equal 0000b.
􀂉 For each bit of the Byte Enables fields:
 • a value of 0b indicates that the corresponding byte of data must not be written or, if nonprefetchable, must not be read at the Completer.
• a value of 1b indicates that the corresponding byte of data must be written or read at the
Completer.
􀂉 Non-contiguous Byte Enables (enabled bytes separated by non-enabled bytes) are permitted in the 1st DW BE field for all Requests with length of 1 DW.
• Non-contiguous Byte Enable examples: 1010b, 0101b, 1001b, 1011b, 1101b
􀂉 Non-contiguous Byte Enables are permitted in both Byte Enables fields for QW aligned
Memory Requests with length of 2 DW (1 QW).
􀂉 All non-QW aligned Memory Requests with length of 2 DW (1 QW) and Memory Requests with
length of 3 DW or more must enable only bytes that are contiguous with the data between the first and last DW of the Request.
• Contiguous Byte Enables examples:
1st DW BE: 1100b, Last DW BE: 0011b
1st DW BE: 1000b, Last DW BE: 0111b
􀂉 Table 2-9 shows the correspondence between the bits of the Byte Enables fields, their location in the Request header, and the corresponding bytes of the referenced data.

A Write Request with a length of 1 DW with no bytes enabled is permitted, and has no effect at the Completer.
􀂉 If a Read Request of 1 DW specifies that no bytes are enabled to be read (1st DW BE[3:0] field = 0000b), the corresponding Completion must specify a Length of 1 DW, and include a data payload of 1 DW
• The contents of the data payload within the Completion packet is unspecified and may be
any value
􀂉 Receiver/Completer behavior is undefined for a TLP violating the Byte Enables rules specified in this section.
􀂉 Receivers may optionally check for violations of the Byte Enables rules specified in this section. If a Receiver implementing such checks determines that a TLP violates one or more Byte Enables rules, the TLP is a Malformed TLP
• If Byte Enables rules are checked, a violation is a reported error associated with the
Receiving Port (see Section 6.2)

The flush semantic has wide application, and all Completers must implement the functionality associated with this semantic. Because a Requester may use the flush semantic without comprehending the characteristics of the Completer, Completers must ensure that zero-length reads do not have side-effects. This is really just a specific case of the rule that in a non-prefetchable space, non-enabled bytes must not be read at the Completer. Note that the flush applies only to traffic in the same Traffic Class as the zero-length Read.

Routing and Addressing Rules

There are three principal mechanisms for TLP routing: address, ID, and implicit. This section defines the rules for the address and ID routing mechanisms. Implicit routing is used only with Message Requests, and is covered in Section 2.2.8.

Address Based Routing Rules

Address routing is used with Memory and I/O Requests.
Two address formats are specified, a 64-bit format used with a 4 DW header (see Figure 2-7) and a 32-bit format used with a 3 DW header (see Figure 2-8).

Figure 2-8: 32-bit Address Routing

For Memory Read, Memory Write, and AtomicOp Requests, the Address Type (AT) field is encoded as shown in Table 2-5, with full descriptions contained in the Address Translation Services Specification, Revision 1.0. For all other Requests, the AT field is reserved.

Table 2-5: Address Type (AT) Field Encodings

 

Address mapping to the TLP header is shown in Table 2-6.

Table 2-6: Address Field Mapping

Memory Read, Memory Write, and AtomicOp Requests can use either format.
• For Addresses below 4 GB, Requesters must use the 32-bit format. The behavior of the receiver is not specified if a 64-bit format request addressing below 4 GB (i.e., with the upper 32 bits of address all 0) is received.
I/O Read Requests and I/O Write Requests use the 32-bit format.
All agents must decode all address bits in the header - address aliasing is not allowed.

ID Based Routing Rules

ID routing is used with Configuration Requests,with ID Routed Messages, and with
Completions. This specification defines Vendor_Defined Messages that are ID Routed (Section 2.2.8.6). Other specifications define additional ID Routed Messages.

ID routing uses the Bus, Device, and Function Numbers (as applicable) to specify the destination for the TLP:
• For non-ARI Routing IDs, Bus, Device, and (3-bit) Function Number to TLP header
mapping is shown in Table 2-7.
• For ARI Routing IDs, the Bus and (8-bit) Function Number to TLP header mapping is shown in Table 2-8.

Two ID routing formats are specified, one used with a 4 DW header (see Figure 2-9) and one used with a 3 DW header (see Figure 2-10).
• Header field locations are the same for both formats, and are given in Table 2-7

Table 2-7: Header Field Locations for non-ARI ID Routing

Table 2-8: Header Field Locations for ARI ID Routing

Figure 2-9: ID Routing with 4 DW Header

Figure 2-10: ID Routing with 3 DW Header

TLP Digest Rules

For any TLP, a value of 1b in the TD field indicates the presence of the TLP Digest field including an ECRC value at the end of the TLP
• A TLP where the TD field value does not correspond with the observed size (accounting for the data payload, if present) is a Malformed TLP
♦ This is a reported error associated with the Receiving Port (see Section 6.2)
If an intermediate or ultimate PCI Express Receiver of the TLP does not support ECRC checking, the Receiver must ignore the TLP Digest4
• If the Receiver of the TLP supports ECRC checking, the Receiver interprets the value in the TLP Digest field as an ECRC value, according to the rules in Section 2.7.1

Common Packet Header Fields

All Transaction Layer Packet (TLP) prefixes and headers contain the following fields (see
Figure 2-4):
􀂉 Fmt[2:0] – Format of TLP (see Table 2-2) – bits 7:5 of byte 0
􀂉 Type[4:0] – Type of TLP – bits 4:0 of byte 0
A-0784
Byte 0 > Fmt Type {Fields in bytes 1 through 3 depend on Fmt and Type Fields
+0 +1 +2 +3
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Figure 2-4: Fields Present in All TLPs
The Fmt field(s) indicate the presence of one or more TLP Prefixes and the Type field(s) indicates
the associated TLP Prefix type(s).
The Fmt and Type fields of the TLP Header provide the information required to determine the size
of the remaining part of the TLP Header, and if the packet contains a data payload following the
header.
The Fmt, Type, TD, and Length fields of the TLP Header contain all information necessary to
determine the overall size of the non-prefix portion of the TLP. The Type field, in addition to
defining the type of the TLP also determines how the TLP is routed by a Switch. Different types of
TLPs are discussed in more detail in the following sections.
􀂉 Permitted Fmt[2:0] and Type[4:0] field values are shown in Table 2-3.
• All other encodings are reserved (see Section 2.3).
􀂉 TC[2:0] – Traffic Class (see Section 2.4.2) – bits [6:4] of byte 1
􀂉 TH – 1b indicates the presence of TLP Processing Hints (TPH) in the TLP header and optional
TPH TLP Prefix (if present) – bit 0 of byte 1 (see Section 2.2.7.1)
􀂉 Attr[1:0] – Attributes (see Section 2.2.6.3) – bits [5:4] of byte 2
􀂉 Attr[2] – Attribute (see Section 2.2.6.3) – bit 2 of byte 1
􀂉 TD – 1b indicates presence of TLP digest in the form of a single DW at the end of the TLP (see Section 2.2.3) – bit 7 of byte 2
􀂉 EP – indicates the TLP is poisoned (see Section 2.7) – bit 6 of byte 2
􀂉 Length[9:0] – Length of data payload in DW (see Table 2-4) – bits 1:0 of byte 2 concatenated
with bits 7:0 of byte 3
• TLP data must be 4-byte naturally aligned and in increments of 4-byte Double Words (DW).
• Reserved for TLPs that do not contain or refer to data payloads, including Cpl, CplLk, and
Messages (except as specified)
OM14540B
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Attr TD
EP
Type R TC AT Length
+0 +1 +2 +3
Byte 0 > TH
Fmt R R
Figure 2-5: Fields Present in All TLP Headers
Table 2-2: Fmt[1:0] Field Values
Fmt[1:0] Corresponding TLP Format
000b 3 DW header, no data
001b 4 DW header, no data
010b 3 DW header, with data
011b 4 DW header, with data
100b TLP Prefix
All encodings not shown above are
reserved (see Section 2.3).
Table 2-3: Fmt[1:0] and Type[4:0] Field Encodings
TLP Type Fmt
[2:0]2
(b)
Type
[4:0]
(b)
Description
MRd 000
001
0 0000 Memory Read Request
MRdLk 000
001
0 0001 Memory Read Request-Locked
MWr 010
011
0 0000 Memory Write Request
IORd 000 0 0010 I/O Read Request
IOWr 010 0 0010 I/O Write Request
CfgRd0 000 0 0100 Configuration Read Type 0
CfgWr0 010 0 0100 Configuration Write Type 0
CfgRd1 000 0 0101 Configuration Read Type 1
CfgWr1 010 0 0101 Configuration Write Type 1
TCfgRd 000 1 1011 Deprecated TLP Type3
TCfgWr 010 1 1011 Deprecated TLP Type3
Msg 001
1 0r2r1r0 Message Request – The sub-field r[2:0]
specifies the Message routing mechanism
(see Table 2-18).
MsgD 011
1 0r2r1r0 Message Request with data payload – The
sub-field r[2:0] specifies the Message
routing mechanism (see Table 2-18).
Cpl 000 0 1010 Completion without Data – Used for I/O and
Configuration Write Completions with any
Completion Status. Also used for AtomicOp
Completions and Read Completions (I/O,
Configuration, or Memory) with Completion
Status other than Successful Completion.
CplD 010 0 1010 Completion with Data – Used for Memory,
I/O, and Configuration Read Completions.
Also used for AtomicOp Completions.
CplLk 000 0 1011 Completion for Locked Memory Read
without Data – Used only in error case.
CplDLk 010 0 1011 Completion for Locked Memory Read –
otherwise like CplD.
2 Requests with two Fmt[2:0] values shown can use either 32 bits (the first value) or 64 bits (the second value)
Addressing Packet formats.
3 Deprecated TLP Types: previously used for TCS, which is no longer supported by this specification. If a Receiver
does not implement TCS, the Receiver must treat such Requests as Malformed Packets.
TLP Type Fmt
[2:0]2
(b)
Type
[4:0]
(b)
Description
FetchAdd 010
011
0 1100 Fetch and Add AtomicOp Request
Swap 010
011
0 1101 Unconditional Swap AtomicOp Request
CAS 010
011
0 1110 Compare and Swap AtomicOp Request
LPrfx 100 0L3L2L1L0 Local TLP Prefix – The sub-field L[3:0]
specifies the Local TLP Prefix type (see
Table 2-29).
EPrfx 100 1E3E2E1E0 End-End TLP Prefix – The sub-field E[3:0]
specifies the End-End TLP Prefix type (see
Table 2-30).
All encodings not shown above are
reserved (see Section 2.3).
Table 2-4: Length[9:0] Field Encoding
Length[9:0] Corresponding TLP Data Payload Size
00 0000 0001b 1 DW
00 0000 0010b 2 DW
... ...
11 1111 1111b 1023 DW
00 0000 0000b 1024 DW

Transaction Layer Protocol - Packet Definition

PCI Express uses a packet based protocol to exchange information between the Transaction Layers
of the two components communicating with each other over the Link. PCI Express supports the
following basic transaction types: Memory, I/O, Configuration, and Messages. Two addressing
formats for Memory Requests are supported: 32 bit and 64 bit.Transactions are carried using Requests and Completions. Completions are used only where
required, for example, to return read data, or to acknowledge Completion of I/O and Configuration
Write Transactions. Completions are associated with their corresponding Requests by the value in
the Transaction ID field of the Packet header.
All TLP fields marked Reserved (sometimes abbreviated as R) must be filled with all 0’s when a TLP is formed. Values in such fields must be ignored by Receivers and forwarded unmodified by
Switches. Note that for certain fields there are both specified and reserved values – the handling of
reserved values in these cases is specified separately for each case.

Packet Format Overview

Transactions consist of Requests and Completions, which are communicated using packets. Figure 2-2 shows a high level serialized view of a Transaction Layer Packet (TLP), consisting of one or more optional TLP Prefixes, a TLP header, a data payload (for some types of packets), and an optional TLP digest. Figure 2-3 shows a more detailed view of the TLP. The following sections of this chapter define the detailed structure of the packet headers and digest.

Serial View of a TLP

PCI Express conceptually transfers information as a serialized stream of bytes as shown in Figure 2-2. Note that at the byte level, information is transmitted/received over the interconnect with the leftmost byte of the TLP as shown in Figure 2-2 being transmitted/received first (byte 0 if one or more optional TLP Prefixes are present else byte H). Refer to Section 4.2 for details on how individual bytes of the packet are encoded and transmitted over the physical media.

Detailed layouts of the TLP Prefix, TLP Header and TLP Digest (presented in generic form in Figure 2-3) are drawn with the lower numbered bytes on the left rather than on the right as has traditionally been depicted in other PCI specifications. The header layout is optimized for performance on a serialized interconnect, driven by the requirement that the most time critical information be transferred first. For example, within the TLP header, the most significant byte of the address field is transferred first so that it may be used for early address decode.

Generic TLP Format

Payload data within a TLP is depicted with the lowest addressed byte (byte J in Figure 2-3) shown to the upper left. Detailed layouts depicting data structure organization (such as the Configuration Space depictions in Chapter 7) retain the traditional PCI byte layout with the lowest addressed byte shown on the right. Regardless of depiction, all bytes are conceptually transmitted over the Link in increasing byte number order.
Depending on the type of a packet, the header for that packet will include some of the following types of fields:

• Format of the packet
• Type of the packet
• Length for any associated data
• Transaction Descriptor, including:
  1. Transaction ID
  2. Attributes
  3. Traffic Class

• Address/routing information
• Byte Enables
• Message encoding
• Completion status

Address Spaces, Transaction Types, and Usage

Transactions form the basis for information transfer between a Requester and Completer. Four address spaces are defined, and different Transaction types are defined, each with its own unique intended usage, as shown in Table 2-1.

Transaction Types for Different Address Spaces

Address Space	Transaction Types	Basic Usage
Memory	Read Write	Transfer data to/from a memory-mapped location.
I/O	Read Write	Transfer data to/from an I/O-mapped location
Configuration	Read Write	Device Function configuration/setup
Message	Baseline(including Vendor–defined)	From event signaling mechanism to general purpose messaging

Details about the rules associated with usage of these address formats and the associated TLP formats are described later in this chapter.

Memory Transactions

Memory Transactions include the following types:
􀂉 Read Request/Completion
􀂉 Write Request
􀂉 AtomicOp Request/Completion
Memory Transactions use two different address formats:
􀂉 Short Address Format: 32-bit address
􀂉 Long Address Format: 64-bit address

I/O Transactions

PCI Express supports I/O Space for compatability with legacy devices which require their use.
Future revisions of this specification are expected to deprecate the use of I/O Space. I/O
Transactions include the following types:
􀂉 Read Request/Completion
􀂉 Write Request/Completion
I/O Transactions use a single address format:
􀂉 Short Address Format: 32-bit address

Configuration Transactions

Configuration Transactions are used to access configuration registers of Functions within devices.
Configuration Transactions include the following types:
􀂉 Read Request/Completion
􀂉 Write Request/Completion

Message Transactions

The Message Transactions, or simply Messages, are used to support in-band communication of events between devices.
In addition to the specified Messages, PCI Express provides support for vendor-defined Messages using specified Message codes. The definition of specific vendor-defined Messages is outside the scope of this document.
This specification establishes a standard framework within which vendors can specify their own vendor-defined Messages tailored to fit the specific requirements of their platforms (see Sections 2.2.8.5 and 2.2.8.7).
Note that these vendor-defined Messages are not guaranteed to be interoperable with components from different vendors.

Transaction Layer Overview

Layering Diagram Highlighting the Transaction Layer

At a high level, the key aspects of the Transaction Layer are:

• A pipelined full split-transaction protocol
• Mechanisms for differentiating the ordering and processing requirements of Transaction Layer Packets (TLPs)
• Credit-based flow control
• Optional support for data poisoning and end-to-end data integrity detection.

The Transaction Layer comprehends the following:
TLP construction and processing
Association of transaction-level mechanisms with device resources including:
• Flow Control
• Virtual Channel management
Rules for ordering and management of TLPs
• PCI/PCI-X compatible ordering
• Including Traffic Class differentiation
This chapter specifies the behaviors associated with the Transaction Layer.

Inter-Layer Interfaces

Transaction/Data Link Interface

The Transaction to Data Link interface provides:
Byte or multi-byte data to be sent across the Link
• Local TLP-transfer handshake mechanism
• TLP boundary information
Requested power state for the Link
PCI EXPRESS BASE SPECIFICATION, REV. 2.1
The Data Link to Transaction interface provides:
Byte or multi-byte data received from the PCI Express Link
TLP framing information for the received byte
Actual power state for the Link
Link status information

Data Link/Physical Interface

The Data Link to Physical interface provides:
Byte or multi-byte wide data to be sent across the Link
• Data transfer handshake mechanism
• TLP and DLLP boundary information for bytes
Requested power state for the Link
The Physical to Data Link interface provides:
Byte or multi-byte wide data received from the PCI Express Link
TLP and DLLP framing information for data
Indication of errors detected by the Physical Layer
Actual power state for the Link
Connection status information

Physical Layer Services

Interface initialization, maintenance control, and status tracking:

• Reset/Hot-Plug control/status
• Interconnect power management
• Width and Lane mapping negotiation
• Polarity reversal

Symbol and special Ordered Set generation:

• 8b/10b encoding/decoding
• Embedded clock tuning and alignment

Symbol transmission and alignment:

• Transmission circuits
• Reception circuits
• Elastic buffer at receiving side
• Multi-Lane de-skew (for widths > x1) at receiving side

System DFT support features

Data Link Layer Services

The Data Link Layer is responsible for reliably exchanging information with its counterpart on the opposite side of the Link.
Initialization and power management services:

• Accept power state Requests from the Transaction Layer and convey to the Physical Layer
• Convey active/reset/disconnected/power managed state to the Transaction Layer

Data protection, error checking, and retry services:

• CRC generation
• Transmitted TLP storage for Data Link level retry
• Error checking
• TLP acknowledgment and retry Messages
• Error indication for error reporting and logging

PCI Express cards

Transaction Layer Services

The Transaction Layer, in the process of generating and receiving TLPs, exchanges Flow Control information with its complementary Transaction Layer on the other side of the Link. It is also responsible for supporting both software and hardware-initiated power management.
Initialization and configuration functions require the Transaction Layer to:

• Store Link configuration information generated by the processor or management device
• Store Link capabilities generated by Physical Layer hardware negotiation of width and operational frequency

A Transaction Layer’s Packet generation and processing services require it to:

• Generate TLPs from device core Requests
• Convert received Request TLPs into Requests for the device core
• Convert received Completion Packets into a payload, or status information, deliverable to the core
• Detect unsupported TLPs and invoke appropriate mechanisms for handling them
• If end-to-end data integrity is supported, generate the end-to-end data integrity CRC and update the TLP header accordingly.

Flow control services:

• The Transaction Layer tracks flow control credits for TLPs across the Link.
• Transaction credit status is periodically transmitted to the remote Transaction Layer using transport services of the Data Link Layer.
• Remote Flow Control information is used to throttle TLP transmission.

Ordering rules:

• PCI/PCI-X compliant producer consumer ordering model
• Extensions to support Relaxed Ordering
• Extensions to support ID-Based Ordering

Power management services:

• ACPI/PCI power management, as dictated by system software.
• Hardware-controlled autonomous power management minimizes power during full-on power states.

Virtual Channels and Traffic Class:

• The combination of Virtual Channel mechanism and Traffic Class identification is provided to support differentiated services and QoS support for certain classes of applications.
• Virtual Channels: Virtual Channels provide a means to support multiple independent logical data flows over given common physical resources of the Link. Conceptually this involves multiplexing different data flows onto a single physical Link.
• Traffic Class: The Traffic Class is a Transaction Layer Packet label that is transmitted unmodified end-to-end through the fabric. At every service point (e.g., Switch) within the fabric, Traffic Class labels are used to apply appropriate servicing policies. Each Traffic Class label defines a unique ordering domain - no ordering guarantees are provided for packets that contain different Traffic Class labels.

PCI Express Cards

PCI Express Physical Layer

The Physical Layer includes all circuitry for interface operation, including driver and input buffers, parallel-to-serial and serial-to-parallel conversion, PLL(s), and impedance matching circuitry. It includes also logical functions related to interface initialization and maintenance. The Physical Layer exchanges information with the Data Link Layer in an implementation-specific format. This Layer is responsible for converting information received from the Data Link Layer into an appropriate serialized format and transmitting it across the PCI Express Link at a frequency and width compatible with the device connected to the other side of the Link.
The PCI Express architecture has “hooks” to support future performance enhancements via speed upgrades and advanced encoding techniques. The future speeds, encoding techniques or media may only impact the Physical Layer definition.

PCI Express Data Link Layer

The middle Layer in the stack, the Data Link Layer, serves as an intermediate stage between the Transaction Layer and the Physical Layer. The primary responsibilities of the Data Link Layer include Link management and data integrity, including error detection and error correction.
The transmission side of the Data Link Layer accepts TLPs assembled by the Transaction Layer, calculates and applies a data protection code and TLP sequence number, and submits them to Physical Layer for transmission across the Link. The receiving Data Link Layer is responsible for checking the integrity of received TLPs and for submitting them to the Transaction Layer for further processing. On detection of TLP error(s), this Layer is responsible for requesting retransmission of TLPs until information is correctly received, or the Link is determined to have
failed.
The Data Link Layer also generates and consumes packets that are used for Link management functions. To differentiate these packets from those used by the Transaction Layer (TLP), the term Data Link Layer Packet (DLLP) will be used when referring to packets that are generated and consumed at the Data Link Layer.

PCI Express products:
http://www.sopto.com/category_category_59/PCI-E_Cards.shtml

PCI Express Transaction Layer

The upper Layer of the architecture is the Transaction Layer. The Transaction Layer’s primary responsibility is the assembly and disassembly of Transaction Layer Packets (TLPs). TLPs are used to communicate transactions, such as read and write, as well as certain types of events. The Transaction Layer is also responsible for managing credit-based flow control for TLPs.
Every request packet requiring a response packet is implemented as a split transaction. Each packet has a unique identifier that enables response packets to be directed to the correct originator. The packet format supports different forms of addressing depending on the type of the transaction (Memory, I/O, Configuration, and Message). The Packets may also have attributes such as No Snoop, Relaxed Ordering, and ID-Based Ordering (IDO).
The transaction Layer supports four address spaces: it includes the three PCI address spaces (memory, I/O, and configuration) and adds Message Space. This specification uses Message Space to support all prior sideband signals, such as interrupts, power-management requests, and so on, as in-band Message transactions. You could think of PCI Express Message transactions as “virtual wires” since their effect is to eliminate the wide array of sideband signals currently used in a platform implementation.

PCI Express Layering Overview

This document specifies the architecture in terms of three discrete logical layers: the Transaction Layer, the Data Link Layer, and the Physical Layer. Each of these layers is divided into two sections: one that processes outbound (to be transmitted) information and one that processes inbound (received) information, as shown in Figure 1-4.
The fundamental goal of this layering definition is to facilitate the reader’s understanding of the specification. Note that this layering does not imply a particular PCI Express implementation.

High-Level Layering Diagram

PCI Express uses packets to communicate information between components. Packets are formed in the Transaction and Data Link Layers to carry the information from the transmitting component to the receiving component. As the transmitted packets flow through the other layers, they are extended with additional information necessary to handle packets at those layers. At the receiving side the reverse process occurs and packets get transformed from their Physical Layer representation to the Data Link Layer representation and finally (for Transaction Layer Packets) to the form that can be processed by the Transaction Layer of the receiving device. Figure 1-5 shows the conceptual flow of transaction level packet information through the layers.

Packet Flow Through the Layers

Note that a simpler form of packet communication is supported between two Data Link Layers (connected to the same Link) for the purpose of Link management.

PCI Express Fabric Topology Configuration

The PCI Express Configuration model supports two mechanisms:

• PCI compatible configuration mechanism: The PCI compatible mechanism supports 100% binary compatibility with PCI 3.0 or later operating systems and their corresponding bus enumeration and configuration software.
• PCI Express enhanced configuration mechanism: The enhanced mechanism is provided to increase the size of available Configuration Space and to optimize access mechanisms.

Each PCI Express Link is mapped through a virtual PCI-to-PCI Bridge structure and has a logical PCI bus associated with it. The virtual PCI-to-PCI Bridge structure may be part of a PCI Express Root Complex Port, a Switch Upstream Port, or a Switch Downstream Port. A Root Port is a virtual PCI-to-PCI Bridge structure that originates a PCI Express hierarchy domain from a PCI Express Root Complex. Devices are mapped into Configuration Space such that each will respond to a particular Device Number.