In the last article i write about the Data Link Layer, in this article i’ll write about the Transaction Layer.
This layer’s primary responsibility is to create PCI Express request and completion transactions. It has both transmit functions for outgoing transactions, and receive functions for incoming transactions.
The Transaction Layer uses TLPs to communicate request and completion data with other PCI Express devices. TLPs may address several address spaces and have a variety of purposes. Each TLP has a header associated with it to identify the type of transaction.
I’ll explain two main things, the Transaction Layer Packet (TLP) and the TLP Handling
Transaction Layer Packet
An generic TLP is show in the figure below:
A TLP consists of a header, an optional data payload, and an optional TLP digest. The Transaction Layer generates outgoing TLPs based on the information it receives from its device core. The Transaction Layer then passes the TLP on to its Data Link Layer for further processing. The Transaction Layer also accepts incoming TLPs from its Data Link Layer.
All TLPs consist of a header that contains the basic identifying information for the transaction. The TLP header may be either 3 or 4 DWords in length, depending on the type of transaction.
The format of first DWord is shown in the figure below
To the article don’t get much extensive, i’ll not cover each bit, but if you like, leave a comment with this request and then i’ll cover bit by bit
TLP Data Payload
Whether or not a TLP contains a data payload depends on the type of packet. If present, the data payload is DWord-aligned for both the first and last DWord of data.
The data payload for a TLP must not exceed the maximum allowable payload size, as defined in the device’s control register (and more specifically, the Max_Payload_Size field of that register).
The Data Link Layer provides the basic data reliability mechanism within PCI Express via the use of a 32-bit LCRC. This LCRC code can detect errors in TLPs on a link-by-link basis and allows for a retransmit mechanism for error recovery.
To ensure end-to-end data integrity, the TLP may contain a digest that has an end-to-end CRC. This optional field protects the contents of the TLP through the entire system, and can be used in systems that require high data reliability. The Transaction Layer of the source component generates the 32-bit ECRC.
A TLP that makes it through the Data Link Layer has been verified to have traversed the link properly, but that does not necessarily mean that the TLP is correct. A TLP may make it across the link intact, but may have been improperly formed by its originator. As such, the receiver side of the Transaction Layer performs some checks on the TLP to make sure it has followed the rules. If the incoming TLP does not check out properly, it is considered a malformed packet, is discarded (without updating receiver flow control information) and generates an error condition. If the TLP is legitimate, the Transaction Layer updates its flow control tracking and continues to process the packet
An flowchart is shown below
If the TLP is a request packet, the Transaction Layer first checks to make sure that the request type is supported. If it is not supported, it generates a non-fatal error and notifies the root complex.
I’ll not get into details, but an flowchart is show below of this process.
If a device receives a completion that does not correspond to any outstanding request, that completion is referred to as an unexpected completion. Receipt of an unexpected completion causes the completion to be discarded and results in an error-condition (nonfatal).
The receipt of unsuccessful completion packets generates an error condition that is dependent on the completion status. The details for how successful completions are handled and impact flow control logic i’ll not cover because this article is getting too big.
But as always, if you want me to cover, leave a comment.
Remember that this series was suggested by a reader.Share this post via: