req | ||
LPID | Logical Processor ID. Used in conjunction with the SrcID field to uniquely identify the logical processor that generated the request. |
|
和srcid一起,唯一确定一个处理器源头; | ||
This field is used when a single Requester contains more than one logically separate processing agent. |
||
txnid | It is required that the TxnID must be unique for a given Requester | |
An 8-bit field is defined for the TxnID to accommodate up to 256 outstanding transactions | ||
A transaction that is retried is not required to use the same TxnID | ||
ReturnNID | ||
A transaction request from Home to Slave includes a ReturnNID that is used to determine the TgtID for the Data response from the Slave. | ||
Its value must be either the Node ID of Home or the Node ID of the original Requester | ||
ReturnNID only applicable in a ReadNoSnp request from Home to Slave. The field is inapplicable in all other requests from Home to Slave and must be set to zero | ||
ReturnNID is inapplicable from Requester to Home and must be set to zero in all requests. | ||
ReturnTxnID | ||
A transaction request from Home to Slave also includes a ReturnTxnID field to convey the value of TxnID in the data response from the Slave | ||
Its value, when applicable, must be either: | ||
• The TxnID generated by Home, when the ReturnNID is the Node ID of the Home. | ||
• The TxnID of the original Requester, when the ReturnNID is the Node ID of the original Requester. | ||
ReturnTxnID is only applicable in a ReadNoSnp request from Home to Slave. The field is inapplicable in all other requests from Home to Slave and must be set to zero. | ||
ReturnTxnID is inapplicable from Requester to Home and Requester to Slave, and must be set to zero in all requests. | ||
StashNID | ||
Stash Node ID. The node ID of the Stash target | ||
StashNIDValid | ||
Stash Node ID Valid. Indicates that the StashNID field has a valid Stash target value. | ||
StashLPIDValid | ||
Stash Logical Processor ID Valid. Indicates that the StashLPID field value must be considered as the Stash target. | ||
PCrdType | ||
Protocol Credit Type. Indicates the type of Protocol Credit being used by a request that has the AllowRetry field deasserted | ||
• For a Request transaction: | ||
— If the AllowRetry field is asserted, the PCrdType field must be set to 0b00 | ||
— If the AllowRetry field is deasserted, the PCrdType field must be set to the value that was returned in the RetryAck response from the Completer when the transaction was first attempted |
||
• For destinations that have a single credit class, or do not implement credit type classification, this specification recommends that the PCrdType field is set to 0b00. | ||
Figure 2-34 Transaction Retry flow | ||
ExpCompAck | ||
Indicates that the transaction will include a Completion Acknowledge message | ||
Figure 2-6 ReadNoSnp and ReadOnce* structure without Direct Data Transfer | ||
MemAttr | ||
Determines the memory attributes associated with the transaction | ||
The Memory Attributes (MemAttr) consist of Early Write Acknowledgement (EWA), Device, Cacheable, and Allocate | ||
EWA | ||
If EWA is asserted, the write completion response for the transaction can come from an intermediate point or from the endpoint. | ||
If EWA is deasserted, the write completion response for the transaction must come from the endpoint. | ||
Device | ||
Device attribute indicates if the memory type is either Device or Normal | ||
Device memory type must be used for locations that exhibit side-effects | ||
• A Read transaction must not read more data than requested. | ||
• Prefetching from a Device memory location is not permitted. | ||
• A read must get its data from the endpoint. | ||
• Combining requests to different locations into one request, or combining different requests to the same location into one request, is not permitted. | ||
• Writes must not be merged. | ||
• Writes to Device memory that obtain completion from an intermediate point must make the write data visible to the endpoint in a timely manner. | ||
Normal memory type | ||
Normal memory type is appropriate for memory locations that do not exhibit side-effects | ||
Accesses to Normal memory do not have the same restrictions regarding prefetching or forwarding as Device type memory | ||
Cacheable | ||
The Cacheable attribute indicates if a transaction must perform a cache lookup | ||
Cacheable=1,先进行cache查找,如果没有找到再去访问最终节点;Cacheable=0,必须访问最终节点。 | ||
Allocate | ||
The Allocate attribute is a an allocation hint. It indicates the recommended allocation policy for a transaction | ||
• If Allocate is asserted, it is recommended that the transaction is allocated into the cache for performance reasons. However, it is permitted to not allocate the transaction. |
||
• If Allocate is deasserted, it is recommended that the transaction is not allocated into the cache for performance reasons. However, it is permitted to allocate the transaction. | ||
SnpAttr | ||
Specifies the snoop attributes associated with the transaction. | ||
An access to a Snoopable memory region can result in the interconnect generating a snoop to the Request Node in the transaction specified snoop domain | ||
The Snoop Attribute (SnpAttr) indicates if a transaction requires snooping | ||
LikelyShared | ||
The LikelyShared attribute is a cache allocation hint | ||
When asserted this attribute indicates that the requested data is likely to be shared by other Request Nodes within the system |
||
This acts as a hint to shared system level caches that the allocation of the cache line is recommended for performance reasons |
||
SnoopMe | ||
Indicates that Home must determine whether to send a snoop to the Requester | ||
This specification permits self-snooping of the Requester in Atomic transactions. | ||
Self-snooping is controlled by the SnoopMe bit value in the Atomic request. | ||
The Request-Response rules for self-snooping in Atomic transactions are | ||
• An RN that does not invalidate its own cached copy of the cache line before sending an Atomic request must rely on self-snooping to | ||
— Invalidate its own cached copy of the cache line. | ||
— Obtain a copy of the cache line if Dirty. | ||
Excl | ||
Indicates that the corresponding transaction is an Exclusive access transaction. | ||
Order | ||
Order requirement. Determines the ordering requirement for this request with respect to other transactions from the same agent. | ||
Endian | ||
Endianness. Indicates the endianness of Data in the Data packet | ||
Indicates the endianness of Data in an Atomic transaction. | ||
Applicable in Atomic requests, inapplicable in all other requests | ||
Little Endian, Big Endian | ||
TraceTag | ||
Provides additional support for the debugging, tracing, and performance measurement of systems. | ||
Trace Tag. A bit in a packet used to tag the packets associated with a transaction for tracing purposes. | ||
snp | ||
FwdNID | ||
A Snoop request from Home to RN-F includes a FwdNID that is used to determine the TgtID for the Data response from the RN-F. Its value must be the NodeID of the original Requester. | ||
FwdTxnID | ||
The transaction ID used in the Request by the original Requester. | ||
StashLPID | ||
StashLPID | ||
StashLPIDValid | ||
VMIDExt | ||
Virtual Machine ID Extension | ||
DVM操作无非就是无效化某些缓存,分支预测和TLB项 | ||
DoNotGoToSD | ||
Do Not Go To SD state. Controls Snoopee use of SD state. | ||
DoNotDataPull | ||
Instructs the Snoopee that it is not permitted to use the Data Pull feature associated with Stash requests | ||
data | ||
HomeNID | ||
The Node ID of the target of the CompAck response to be sent from the Requester | ||
RespErr | ||
Response Error status. Indicates the error status associated with a data transfer | ||
OK | ||
EXOK | ||
Data Error | ||
Non-data Error. | ||
Resp | ||
Response status. Indicates the cache line state associated with a data transfer. | ||
e.g: CompData_UC | ||
FwdState | ||
Forward State. Indicates the cache line state associated with a data transfer to the Requester from the receiver of the snoop | ||
DataPull | ||
Indicates the inclusion of an implied Read request in the Data response | ||
DataSource | ||
The value indicates the source of the data in a read Data response. | ||
Fixed values are used for DataSource when Data comes from memory and are used to indicate the following:xxx | ||
For a response not from memory, that is, from a cache, the DataSource value is IMPLEMENTATION DEFINED. | ||
CCID | ||
Critical Chunk Identifier. Replicates the address offset of the original transaction request | ||
DataID | ||
Data Identifier. Provides the address offset of the data provided in the packet. | ||
BE | ||
Byte Enable. For a data write, or data provided in response to a snoop, indicates which bytes are valid. | ||
DataCheck | ||
Data Check. Detects data errors in the DAT packet | ||
The Data_Check property is used to indicate if Data Check is supported | ||
When Data Check is supported: | ||
• The DAT packet carries eight Data Check bits per 64 bits of data. | ||
• The Data Check bit is a parity bit that generates Odd Byte parity. | ||
Poison | ||
Indicates that a set of data bytes has previously been corrupted | ||
Passing the Poison bit alongside the data in the DAT packet permits any future user of the data to be notified that the data might be corrupt. | ||
When Poison is supported: | ||
• The DAT packet includes one Poison bit per 64 bits of data. | ||
• Data marked as poisoned: | ||
— Must not be utilized by any master. | ||
— Is permitted to be stored in caches and memory if marked as poisoned. | ||
• The Poison value, once set, must be propagated along with the data. | ||
• When a Poison error is detected, it is permitted to over poison the data | ||
Poison must be accurate if there are any valid bytes in the 64-bit chunk, which is Poison granularity |