Sunday, April 15, 2012

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.

No comments:

Post a Comment