AMBA CHI Chip-to-Chip Architecture Specication

AMBA CHI Chip-to-Chip (C2C) Architecture Specification

1. Introduction

This specification is a Chip-to-Chip (C2C) extension of the AMBA CHI Architecture Specification.

1.1. Overview

The C2C extension enables building a system with multiple CPUs, accelerators, or other devices. CHI C2C focuses on the Packetization of CHI messages, making them suitable to be transported over a chip-to-chip link. The Packetization format is optimized for link utilization and latency, while avoiding complex packing and unpacking schemes.

C2C 扩展允许构建具有多个 CPU、加速器或其他设备的系统。 CHI C2C 专注于 CHI 消息的打包，使其适合通过芯片到芯片链路进行传输。打包格式针对链路利用率和延迟进行了优化，同时避免了复杂的打包和解包方案。

The two primary use cases are:

• Multi-chip Symmetric Multi-Processor (SMP)
• Multi-chip coherent accelerator attach

两个主要用例是：

• 多芯片对称多处理器 (SMP)
• 多芯片相干加速器附加

The C2C extension can also be referred to as Chip(let)-to-Chip(let), as it covers both the board-level connection of multiple chips and the package level connection of multiple dies or chiplets.

C2C 扩展也可以称为 chiplet 到 chiplet，因为它涵盖多个芯片的板级连接以及多个芯片或 chiplet 的封装级连接。

1.1.1. Multi-chip Symmetric Multi-Processor (SMP)

The SMP congurations of interest are a small number of chips that are similar in their functionality and tightly connected together. Each chip includes System-on-Chip (SoC) components with a large number of processing cores. Each chip is expected to have attached memory that is coherently shared by processing cores on all the chips.

我们感兴趣的 SMP 配置是指功能相似且紧密连接在一起的少量芯片。每个芯片包括系统芯片（SoC）组件与大量的处理核心。每个芯片都有附加的内存，这些内存被所有芯片上的处理核心一致地共享。

Figure 1.1 shows an example of a two-chip topology.

Figure 1.2 shows an example of four chips in a fully connected topology. The attached memories will exist but are not shown in the figure.

1.1.2. Multi-chip coherent accelerator attach

The accelerator attach congurations of interest are one or more coherent accelerators connected to a host chip.

感兴趣的加速器连接配置是连接到主机芯片的一个或多个相干加速器。

The accelerators can be fully coherent or IO coherent.

加速器可以是完全一致性的或 IO 一致性的。

Figure 1.3 shows an example of a topology of coherent accelerators.

1.2. Terminology

The following terms have a specific meaning within this specication:

• DN
  • DVM Node (DN) is a node located within the chip that processes DVM operations to and from remote chips.
  • DVM 节点 (DN) 是位于芯片内的节点，用于处理往返于远程芯片的 DVM 操作。
• RP
  • Resource Planes are link buffer resources enabling groups of messages within the same Message Class to be independently transported over the link.
  • 资源计划是链路缓冲区资源，使同一消息类别内的消息组能够通过链路独立传输
• Transmitter
  • An interface component that forwards messages to the Link layer.
  • 向链路层转发消息的接口组件。
• Receiver
  • An interface component that receives messages from the Link layer.
  • 从链路层接收消息的接口组件。
• Container
  • A container is the smallest fixed size unit in which messages are transferred across an interface.
  • Container 是通过接口传输消息的最小固定大小单元。

2. Interface structures

This chapter describes the structure of the C2C interface.

本章介绍 C2C 接口的结构。

2.1. Interface layers

The functional logic between on-chip CHI interface and the chip pins that a message traverses through is divided into multiple functional layers. These layers are referred to as:

• Protocol layer
• Packetization layer
• Link layer
• Physical layer

片上 CHI 接口和消息所经过的芯片引脚之间的功能逻辑分为多个功能层。这些层被称为：

• 协议层
• 打包层
• 链路层
• 物理层

Link layer and Physical layer presence is expected, but not required, for connecting two chips together.

链路层和物理层的存在是预期的，但不是必需的，用于将两个芯片连接在一起。

Figure 2.1 shows the C2C interface structure.

2.1.1. Protocol layer

The Protocol layer handles protocol conversion between on-chip CHI and CHI C2C.

协议层处理片上 CHI 和 CHI C2C 之间的协议转换。

The logic required for the conversion is minimal.

转换所需的逻辑很少。

2.1.2. Packetization layer

When the Link layer is present, the Packetization layer is between the Protocol layer and the Link layer.

当存在链路层时，打包层位于协议层和链路层之间。

If the Link layer is not present, the Packetization layer connects directly to the external signals. If required, the Packetization layer packs outgoing messages into a fixed size container and unpacks incoming containers into individual messages. The incoming messages are forwarded to the Protocol layer or other functional blocks within the Packetization layer.

如果不存在链路层，则打包层直接连接到外部信号。如果需要，打包层会将传出消息打包到固定大小的容器中，并将传入容器解包到单独的消息中。传入消息被转发到协议层或打包层内的其他功能块。

2.1.3. Link layer

The Link layer is responsible for handling message transport at a FLow control unIT (Flit) granularity.

链路层负责以流量控制单元（Flit）粒度处理消息传输。

The Link layer is also responsible for optional data integrity and transport error detection and recovery. Typically, this is done by adding a generated Cyclic Redundancy Check (CRC) checksum to a flit being transmitted and checking the CRC checksum on the received flit.

链路层还负责可选的数据完整性以及传输错误检测和恢复。通常，这是通过将生成的循环冗余校验 (CRC) 校验和添加到正在传输的 flit 并检查接收到的 flit 上的 CRC 校验和来完成的。

When an error occurs, the Link layer can use a flit retry mechanism to recover from the error.

当发生错误时，链路层可以使用 flit 重试机制从错误中恢复。

2.1.4. Physical layer

The Physical layer is responsible for providing reliable electrical connectivity between the two chips.

物理层负责在两个芯片之间提供可靠的电气连接。

Some of the capabilities of the Physical layer include the logic to overcome latency skew among different signals and link retraining to maintain signal integrity.

物理层的一些功能包括克服不同信号之间的延迟偏差的逻辑以及保持信号完整性的链路重新训练。

There must be a space in a container for the Link layer to fill the following transport information:

• Flit header
• Link reliability

容器中必须留有空间，以便链路层填充以下传输信息：

• Flit 包头
• 链路可靠性

The detail of the Link layer and Physical layer is outside the scope of this specication.

链路层和物理层的细节不在本规范范围之内。

2.2. Message classes

This specication defines a message class as the group of messages of a single CHI message type. Message classes are similar to on-chip CHI physical channels.

该规范将消息类别定义为单个 CHI 消息类型的消息组。消息类别与片上 CHI 物理通道类似。

Messages are grouped into the following five message classes:

• Request, REQ
• Response, RSP. Does not include data.
• Snoop, SNP
• Data, DAT
• Miscellaneous, MISC

消息分为以下五个消息类别：

• 请求，REQ
• 回应，RSP。不包括数据。
• 窥探，SNP
• 数据，DAT
• 杂项、MISC

MISC, a C2C-specific message class, is defined to group all messages that do not directly relate to on-chip CHI protocol messages. Example use of MISC messages are interface initialization and message credit grant.

MISC 是一种 C2C 特定消息类别，定义为对与片上 CHI 协议消息不直接相关的所有消息进行分组。 MISC 消息的使用示例是接口初始化和消息 credit 授予。

For further MISC message details, see 4.2.7. Uncredited Miscellaneous message fields.

2.3. Channel connection

There are two different approaches to connect the different message class channels between chips:

1. Shared channel connect
2. Independent channel connect

有两种不同的方法来连接芯片之间的不同消息类别通道：

• 共享通道连接
• 独立通道连接

The common usage for a C2C interface is expected to be a shared channel connection. All on-chip channels share the same connection between chips.

C2C 接口的常见用途预计是共享通道连接。所有片上通道在芯片之间共享相同的连接 。

A fixed size container is used as the unit of exchange across the C2C interface. The messages to be sent are placed in a container. The container can include multiple messages from the same message class as well as messages from different message classes.

固定大小的容器用作 C2C 接口上的交换单元。要发送的消息放置在容器中。容器可以包含来自同一消息类别的多个消息以及来自不同消息类别的消息。

The use of a container with messages included from any message class instead of using independent physical channels for each message class typically results in a better link efficiency.

使用包含来自任何消息类别的消息的容器，而不是为每个消息类别使用独立的物理通道，通常会带来更好的链路效率。

Figure 2.2 shows a shared channel connection.

Alternatively, an independent channel connect can be used, where a separate physical set of wires is used for each message class. This type of connection provides implementation ease due to not requiring Packetization logic. However, this is at the cost of potential under utilization of the physical channels due to lack of messages to fully utilize all available channels.

或者，可以使用独立的通道连接，其中针对每个消息类别使用一组单独的物理线路。由于不需要分组逻辑，这种类型的连接提供了实现的便利性。然而，这是以由于缺乏充分利用所有可用信道的消息而导致物理信道的潜在利用率不足为代价的。

2.4. Multiple interfaces

It is expected that a single C2C interface is used to connect two chips.

期望使用单个 C2C 接口来连接两个芯片。

It is permitted that multiple C2C interfaces are used between two chips to meet greater throughput requirements.

两个芯片之间允许使用多个 C2C 接口，以满足更大的吞吐量要求。

When using multiple interfaces, both the chips must follow message association requirements.

当使用多个接口时，两个芯片都必须遵循消息关联要求。

• Within transaction

  • For a Request or Snoop, all associated Data or Response messages must use the same interface.

• Between transaction

  • All requests and snoops to the same address must use the same interface. All endpoint ordered requests must use the same interface. DVMReq and DVMSync transactions from a given source must use the same interface. See 6.3. DVM transaction flows. MISC messages to the same target must use the same interface.

• Transaction 内：

  • 对于请求或监听，所有关联的数据或响应消息必须使用相同的接口

• Transaction 间：

  • 发送到同一地址的所有请求和侦听必须使用同一接口。所有端点有序的请求必须使用同一接口。来自给定源的 DVMReq 和 DVMSync 事务必须使用同一接口。发送到同一目标的 MISC 消息必须使用同一接口。

A Completer can ensure that a response is sent on the same interface as the corresponding memory or snoop request by tracking the interface used by the request.

通过跟踪请求所使用的接口，Completer 可以确保响应是在与相应的内存或窥探请求相同的接口上发送的。

A Home can ensure snoop requests are sent on the same interface as requests to that address by either tracking the interface the request was received on or by using a common address hash.

通过跟踪接收请求的接口或使用公共地址哈希，Home 可以确保在与发送到该地址的请求相同的接口上发送窥探请求。

When using an address hash:

• A chip is required to use a single address hash for requests to a given target chip.
• Requests to different target chips can use different address hash functions.
• It is permitted to use an approach where both the request and snoop sides are able to be programmed with a hash function. An example hash function is provided in 2.4.1. Hash function example.

使用地址哈希时：

• 芯片需要使用单个地址散列来请求给定的目标芯片。
• 对不同目标芯片的请求可以使用不同的地址哈希函数。
• 允许使用请求端和探听端都能够用散列函数进行编程的方法。

The number of interfaces permitted for aggregating traffic between two components is 1 to 16.

允许聚合两个组件之间的流量的接口数量为 1 到 16。

2.4.1. Hash function example

Figure 2.3 shows how the interface number is determined from an address hash.

• The following steps are used to determine the interface on which to send a request or a snoop:

  1. The cache line aligned input address is first filtered through a Hash Mask. The most significant address bits that are not used must be 0 before filtering the address. In this example, the result of the filtering is labeled as Masked_Addr.
  2. The individual bits of the Masked_Addr are XORed to obtain the target interface in a manner defined by the number of interfaces between the two chips.

• 以下步骤用于确定发送请求或监听的接口：

  1. 缓存行对齐的输入地址首先通过哈希掩码进行过滤。在过滤地址之前，未使用的最高有效地址位必须为 0。在此示例中，过滤结果标记为 Masked_Addr。
  2. Masked_Addr 的各个位进行异或运算，以获得目标接口，其方式由两个芯片之间的接口数量定义。

The following are examples of determining the interface number for a given address when the number of interfaces is:

• A power-of-two

  • For 2 interfaces
    • Interface Num[0] = Masked_Addr[n-1] XOR Masked_Addr[n-2]…Masked_Addr[7] XOR Masked_Addr[6]}
  • For 4 interfaces
    • Interface Num[1:0] = Masked Addr[n-1:n-2] XOR Masked Addr[n-3:n-4]…Masked Addr[9:8] XOR Masked Addr[7:6]
  • For 8 interfaces
    • Interface Num[2:0] = Masked Addr[n-1:n-3] XOR Masked Addr[n-4:n-6]…Masked Addr[11:9] XOR Masked Addr[8:6]

• Non power-of-two.

The first step is to perform the hash using a power-of-two number of interfaces which is larger than the available number of interfaces. The obtained intermediate interface number is mapped to the interface number by using a table or by some other implementation means. The table is heuristic ally set up to distribute, as evenly as possible, the hashed numbers across the available number of interfaces. The larger the intermediate interface number relative to the actual number of interfaces, the greater than the uniformity of message distribution across the interfaces.

第一步是使用大于可用接口数量的二次方数量的接口来执行哈希。将得到的中间接口号通过表格或者其他实现手段映射到接口号。该表是启发式设置的，以便尽可能均匀地在可用数量的接口上分布散列数。中间接口数量相对于实际接口数量越大，接口间消息分布的均匀性就越大。

3. Packetization

This chapter describes the process of packetization within the C2C interface.

本章描述了 C2C 接口内的打包过程。

3.1. Containers

A container is 256 bytes and comprises Link header bytes, Protocol header bytes and message bytes organized in granules.

容器为 256 字节，包括按颗粒组织的链路头字节、协议头字节和消息字节。

The following two container formats are defined:

定义了以下两种容器格式：

1. Format X, comprising of:
   • 240 bytes of payload, split into twelve 20-byte granules
   • 6 bytes of Link header
   • 10 bytes of Protocol header
   • This format is compatible with UCIe 256-byte Latency Optimized Mode with optional bytes.

• 格式 X，包括：
  • 240 字节的有效负载，分为 12 个 20 字节的颗粒
  • 6 字节链接头
  • 10 字节协议头
  • 此格式与具有可选字节的 UCIe 256 字节延迟优化模式兼容。

2. Format Y, comprising of:
   • 226 bytes of payload, split into:
     • Ten 20-byte granules
     • One 16-byte granule
     • One 10-byte granule
   • 20 bytes of Link header
   • 10 bytes of Protocol header
   • This format is compatible with CXL 256-byte latency optimized flit format.

• 格式 Y，包括：
  • 226 字节的有效负载，分为：
    • 十个 20 字节颗粒
    • 1 个 16 字节颗粒
    • 1 个 10 字节颗粒
  • 20 字节的链接头
  • 10 字节协议头
  • 此格式与 CXL 256 字节延迟优化 flit 格式兼容。

Figure 3.1 shows the container byte layouts for Format X and Format Y. The granules are distributed so they are aligned across 64-byte and 128-byte parts of the container.

For information on ProtHdr bits, see 3.2. Protocol header.

3.2. Protocol header

The bytes which are not used for message granules are either the Link header or the Protocol header.

不用于消息颗粒的字节是链路标头或协议标头。

The description of Link header bytes are outside the scope of this specication. Typical usage for these bits are for adding a flit header, a CRC, and an FEC.

链接头字节的描述超出了本规范的范围。这些位的典型用途是添加 flit 标头、CRC 和 FEC。

The Protocol layer header bits are allocated as shown in Figure 3.2.

Table 3.1 shows the encoding of the Protocol Header fields present in Figure 3.2.

3.3. Message packing

Messages are packed into a container using granules. Messages are only permitted to begin at the start of a granule. This limits the number of positions each message type can occupy within a container to minimize decode logic.

使用颗粒将消息打包到容器中。消息只允许在颗粒的开头开始。这限制了每种消息类型在容器内可以占据的位置数量，以最小化解码逻辑。

The MsgStart vector in the Protocol Header determines if a new message starts at a particular granule. Each message begins with a MsgType field that defines the type of the message.

协议头中的 MsgStart 向量确定新消息是否从特定颗粒开始。每条消息都以定义消息类型的 MsgType 字段开头。

3.3.1. Rules and restrictions

The restrictions on message placement within a container are:

• In Format X container, a message can be placed in any granule.
• In Format Y container:
  • A message, except Resp and Misc type, can be placed in any granule except G5 and G11.
  • A Resp can be placed in any granule.
  • A Misc message of:
    • A total message size of 10 bytes or less can be placed in any granule.
    • A total message size of 16 bytes or less can be placed in any granule except G11.
    • A total message size greater than 16 bytes can be placed in any granule except G5 and G11.
• Multi-granule messages
  • Can start in any granule, except G5 and G11 in Format Y.
  • Must be contiguous, except when spanning G5 or G11 in Format Y. Multi-granule messages in Format Y skip over G5 and G11.
  • Can span across consecutive containers. When spanning multiple containers, the message must continue in G0 of the next container.

容器内消息放置的限制是：

• 在 Format X 容器中，消息可以放置在任何颗粒中。
• 在格式 Y 容器中：
  • 除 Resp 和 Misc 类型外，消息可以放置在除 G5 和 G11 之外的任何颗粒中。
  • Resp 可以放置在任何颗粒中。
  • 杂项消息：
    • 10 字节或更小的总消息大小可以放置在任何颗粒中。
    • 总消息大小为 16 字节或更小可以放置在除 G11 之外的任何颗粒中。
    • 总消息大小大于 16 字节可以放置在除 G5 和 G11 之外的任何颗粒中。
• 多粒度消息
  • 可以从任何颗粒开始，格式 Y 中的 G5 和 G11 除外。
  • 必须是连续的，但格式 Y 中跨越 G5 或 G11 时除外。格式 Y 中的多颗粒消息会跳过 G5 和 G11。
  • 可以跨越连续的容器。当跨越多个容器时，消息必须在下一个容器的 G0 中继续。

Additionally, the container packing rules are:

• Inclusion of a message in a granule is optional. A container with no messages is permitted.
• The LSB of a message is placed in the LSB of the granule.
• Unused bits must be 0, including:
  • Granules that do not include a message.
  • Any bits between the end of a message and the end of the granule.
  • 32-byte data is placed in the half of the 64-byte Data field, corresponding to the request address bit[5] value.
  • Granules are organized into groups: G0-G2, G3-G5, G6-G8, G9-G11.
    • Each group can have:
      • No granules populated.
      • The lowest numbered granule populated.
      • The two lowest numbered granules populated.
      • All granules populated.
      • A maximum of one MiscU message.
      • A maximum of four response messages, where Resp2 counts as two response messages.
    • For example, if G6 is not populated, then G7 and G8 must also be empty.

此外，容器打包规则为：

• 在颗粒中包含消息是可选的。允许使用没有消息的容器。
• 消息的 LSB 放置在颗粒的 LSB 中。
• 未使用的位必须为 0，包括：
  • 不包含消息的颗粒。
  • 消息末尾和颗粒末尾之间的任何位。
  • 32 字节数据放置在 64 字节数据字段的一半中，对应于请求地址位 [5] 的值。
  • 颗粒分为几组：G0-G2、G3-G5、G6-G8、G9-G11。
    •  每个组可以有：
      • 没有填充颗粒。
      • 填充编号最低的颗粒。
      • 编号最低的两个颗粒已填充。
      • 所有颗粒均已填充。
      • 最多一条 MiscU 消息。
      • 最多四个响应消息，其中 Resp2 算作两个响应消息。
    • 例如，如果 G6 未填充，则 G7 和 G8 也必须为空。
  • A MiscU.LinkStatus message can only use G0.
  • MiscU.LinkStatus 消息只能使用 G0。

Figure 3.3 illustrates an example of Format X container packing. The two containers in Figure 3.3 include:

• Two ReqS and two ReqL messages, where one ReqL message spans over two containers.
• One Resp and one Resp2 message.
• One Snoop message.
• One DataS message.
• Empty granules in Container B.

图 3.3 展示了 Format X 容器打包的示例。图 3.3 中的两个容器包括：

• 两条 ReqS 和两条 ReqL 消息，其中一条 ReqL 消息跨越两个容器。
• 一条 Resp 消息和一条 Resp2 消息。
• 一条 DataS 消息。
• 容器 B 中的空颗粒。

Figure 3.4 illustrates an example of Format Y container packing. The four containers in Figure 3.4 include:

• Two ReqS messages and one ReqL.
• Six Resp messages.
• One Snoop message.
• One DataS message and one DataL message.
  • The DataS message in Container A spans over G5.
  • The DataL message starts in Container A, skips over G11, and rolls over to the beginning of Container B.
• Six WrReqDataS messages.
  • One WrReqDataS message in Container B, spans over G5.
  • One WrReqDataS message starts in Container C G9, skips over G11, and rolls over to the beginning of Container D.
• Empty granules in Container B.

图 3.4 展示了 Y 型容器打包的示例。图 3.4 中的四个容器包括：

• 两条 ReqS 消息和一条 ReqL。
• 六个 Resp 消息。
• 一条窥探消息。
• 一条 DataS 消息和一条 DataL 消息。
  • 容器 A 中的 DataS 消息跨越 G5。
  • DataL 消息从容器 A 开始，跳过 G11，然后滚动到容器 B 的开头。
• 六个 WrReqDataS 消息。
  • 容器 B 中的一条 WrReqDataS 消息跨越 G5。
  • 一条 WrReqDataS 消息从容器 C 的 G9 开始，跳过 G11，并滚动到容器 D 的开头。
• 容器 B 中的空颗粒。

4. Message structures

This chapter describes the extent of support for on-chip CHI transaction flows, the on-chip CHI fields in messages that are optimized out as they are not required and resulting message formats with list of fields in each message class.

本章描述了对片上 CHI 事务流的支持范围、消息中因不需要而被优化的片上 CHI 字段以及结果消息格式以及每个消息类别中的字段列表。

4.1. Transactions and transaction flows

This section describes the mapping of fields in a request received by a Subordinate Node to on-chip CHI fields, and also lists the CHI transactions that are not supported.

本节描述了从属节点接收到的请求中的字段到片上 CHI 字段的映射，并列出了不支持的 CHI 事务。

4.1.1. Field mapping in requests to Subordinate Nodes

An interface receiving requests targeting Subordinate Node must map the fields in the received request to the on-chip CHI request message in the following manner:

• Duplicate SrcID onto ReturnNID
• Duplicate TxnID onto Return TxnID
• Set DoDWT to 0

接收针对从属节点的请求的接口必须按以下方式将接收到的请求中的字段映射到片上 CHI 请求消息：

• 将 SrcID 复制到 ReturnNID
• 将 TxnID 重复到返回 TxnID
• 将 DoDWT 设置为 0

4.1.2. Unsupported transactions

The following transactions are not supported:

• Forwarding snoops
• Exclusive access to Non-cacheable and Device memory
• Request Retry flows
• Direct Memory Transfer (DMT). The ReturnNID and ReturnTxnID fields used for DMT are not included in a Request message.
• Direct Cache Transfer (DCT). The FwdNID and FwdTxnID fields used exclusively for DCT are not included in a Snoop message.
• Direct Write Transfer (DWT). The ReturnNID field used for DWT is not included in a Request message.
• When TagMatch is enabled, direct TagMatch response to Request Node from Subordinate Node is not supported.
• In Persist Cache Maintenance Operation (CMO) transaction flow, direct Persist response to Request Node from Subordinate Node is not supported.

不支持以下交易：

• 转发窥探
• 对不可缓存（Non-cacheable）和设备内存（Device memory）的独占访问（Exclusive access）
• 请求重试流程
• 直接内存传输 (DMT)。用于 DMT 的 ReturnNID 和 ReturnTxnID 字段不包含在请求消息中。
• 直接高速缓存传输 (DCT)。专用于 DCT 的 FwdNID 和 FwdTxnID 字段不包含在 Snoop 消息中。
• 直接写传输 (DWT)。用于 DWT 的 ReturnNID 字段不包含在请求消息中。
• 启用 TagMatch 后，不支持从下级​​节点直接 TagMatch 响应请求节点。
• 在持久缓存维护操作 (CMO) 事务流中，不支持从下级​​节点直接对请求节点进行持久响应。

Note

For a Read transaction, the chip which includes the Home Node and Subordinate Node can use DMT internally to that chip. This allows data to be forwarded directly to the C2C port from the Subordinate Node.

注意 对于读取事务，包含主节点和从属节点的芯片可以在该芯片内部使用 DMT。这允许数据从下级节点直接转发到 C2C 端口。

However, because DMT is not supported across the C2C interface, the data response only has a single SrcID field, rather than having both SrcID and HomeNID fields. At the C2C port, the SrcID field in the data response must be populated with the Node ID of the Home. This ensures that any subsequent message in the transaction, such as CompAck, is correctly sent to the Home.

但是，由于 C2C 接口不支持 DMT，因此数据响应仅具有单个 SrcID 字段，而不是同时具有 SrcID 和 HomeNID 字段。在 C2C 端口，数据响应中的 SrcID 字段必须填充 Home 的节点 ID。这确保了事务中的任何后续消息（例如 CompAck）都正确发送到 Home。

For Write transactions and Snoop transactions, the SrcID field of the data response will contain the correct Node ID and does not need to be replaced with the Home ID.

对于写入事务和监听事务，数据响应的 SrcID 字段将包含正确的节点 ID，不需要替换为 Home ID。

At the Requester chip interface, the SrcID and HomeNID in the responses to the Requester must be populated by duplicating the common field value.

在请求者芯片接口处，必须通过复制公共字段值来填充对请求者的响应中的 SrcID 和 HomeNID。

DCT support can be partially supported at the Home chip egress by keeping track of the snoop type before converting the Forwarding snoop into a Non-forwarding snoop. When the snoop response with data is received, the interface logic can split the response where one is sent to the Requester and the other is sent to the Home.

通过在将转发侦听转换为非转发侦听之前跟踪侦听类型，可以在主芯片出口部分支持 DCT 支持。当接收到带有数据的探听响应时，接口逻辑可以分割响应，其中一个被发送到请求方，另一个被发送到归属地。

4.2. Message fields

This section describes the fields in each message class.

本节描述每个消息类别中的字段。

Fields that are present for C2C, but not in on-chip CHI messages, are described in 4.2.1. C2C specific message fields. On-chip CHI messages that are removed in C2C messages are described in 4.2.8. Redundant fields.

4.2.1. C2C specific message fields

The following fields are added to C2C messages and are not present in on-chip CHI messages:

• MsgType
• ResPlane
• SharedCrdt
• ChunkValid
• RsvdZero

4.2.1.1. Message type, MsgType

This field identifies the message type in terms of message class and size, where:

• Request, Data, WrReqData messages can be one of two types, dependent upon message length. See 4.2.2. Request message fields, 4.2.4. Data message fields, and 4.2.5. WritePush message for more details.
• Response messages can be one or two per granule of 20 bytes. See 4.2.3. Response message fields.
• Miscellaneous messages can be credited or uncredited.
  • See 4.2.7. Uncredited Miscellaneous message fields for details on uncredited MISC messages.
  • This specication does not yet define any credited MISC messages.

该字段根据消息类别和大小来标识消息类型，其中：

• Request、Data、WrReqData 消息可以是两种类型之一，具体取决于消息长度。
• 每个 20 字节的颗粒可以有一个或两个响应消息。
• 杂项消息可以被 credited 或不被 credited。
  • 该规范尚未定义任何记入 MISC 消息

Table 4.1 shows the encoding of the MsgType field.

4.2.1.2. Resource plane, ResPlane

This field is used to support multiple resource planes in Request and WritePush messages. See 5.3. Resource Planes and 5.4. Data credit pools.

该字段用于支持 Request 和 WritePush 消息中的多个资源计划。

4.2.1.3. Shared credit, SharedCrdt

This field is used to support multiple resource planes and data credit pools in Request and Data message class messages. See 5.3. Resource Planes and 5.4. Data credit pools.

该字段用于支持请求和数据消息类消息中的多个资源计划和数据 credit 池。

4.2.1.4. Chunk valid, ChunkValid

This field is present in DataS, DataL, WrReqDataS, and WrReqDataL messages. Its value indicates if one or both of the 32 byte data chunks have valid data.

该字段存在于 DataS、DataL、WrReqDataS 和 WrReqDataL 消息中。其值指示一个或两个 32 字节数据块是否具有有效数据。

Table 4.2 shows the ChunkValid field encodings.

4.2.1.5. RsvdZero

This field indicates that the use of the bits is Reserved and a Transmitter must set the field value to zero, a Receiver must ignore the field and an intermediate agent must forward them unchanged. The inclusion of RsvdZero field in a message may be for starting the subsequent field at a byte or granule boundary or to fill the bits beyond useful information in the last granule.

该字段指示位的使用是保留的，并且发送器必须将该字段值设置为零，接收器必须忽略该字段，并且中间代理必须将它们原封不动地转发。在消息中包含 RsvdZero 字段可能是为了在字节或颗粒边界处开始后续字段，或者填充最后颗粒中有用信息之外的位。

4.2.2. Request message fields

The fields in the Request message types are described in this section:

• ReqS, for short-sized formats
• ReqL, for long-sized formats

本节描述请求消息类型中的字段：

• ReqS，适用于短尺寸格式
• ReqL，适用于长尺寸格式

A Request message uses a ReqL message format when any of the following fields are present in the request and have a non-zero value:

• Addr[3:0] in any request. Addr[5:0] bits in Dataless requests of 64 bytes size to normal memory are permitted to be zeroed.
• LPID in an exclusive transaction.
• GroupID in a Persist CMO, a Stash Once Sep, or a Write with TagOp value of Match.
• StashNID[10:1]
• StashLPID Valid
• PBHA
• Likely Shared
• DataTarget[6:1]
• RSVDC[N-1:16]

当请求中存在以下任何字段且具有非零值时，请求消息将使用 ReqL 消息格式：

• 任何请求中的 Addr[3:0]。允许将 64 字节大小的无数据请求中的 Addr[5:0] 位清零。
• 独占（Exclusive）事务中的 LPID。
• Persist CMO、Stash Once Sep 或 TagOp 值为 Match 的 Write 中的 GroupID。
• StashNID[10:1]
• StashLPID 有效
• PBHA
• Likely Shared
• DataTarget[6:1]
• RSVDC[N-1:16]

When the the use of ReqS is allowed, a Transmitter is permitted to use ReqL messages in place of ReqS. The use of ReqL instead of ReqS may lead to reduced container packing efficiency.

当允许使用 ReqS 时，传输器被允许使用 ReqL 消息来代替 ReqS。使用 ReqL 代替 ReqS 可能会导致容器打包率降低。

Table 4.3 lists Request message fields and their placement into ReqS and ReqL.

The columns in the table are defined as follows:

• Common
  • Fields marked with the same ’x’ in ’Cx’ share a common position in the message.
• ReqS
  • The request includes all mandatory fields and most commonly used optional fields.
• ReqL
  • Request size is extended to include all supported Request fields.

表中的列定义如下：

• 公共字段
  • 在“Cx”中标有相同“x”的字段在消息中共享公共位置。
• ReqS
  • 该请求包括所有必填字段和最常用的可选字段。
• ReqL
  • 请求大小已扩展以包含所有支持的请求字段。

4.2.3. Response message fields

The fields in the Response message types are described in this section:

• Resp
• Resp2

4.2.3.1. Resp message type

Table 4.4 shows the fields in a Resp message type, where one response is packed into a single granule.

4.2.3.2. Resp2 message type

Table 4.5 shows the fields in a Resp2 message type, where two responses are packed into a single granule.

4.2.4. Data message fields

DataS and DataL message formats are used for read data, snoop response data, and non-WritePush data messages.

DataS 和 DataL 消息格式用于读取数据、监听响应数据和非 WritePush 数据消息。

The characteristics of DataS and DataL message format include:

• SrcID and HomeNID share a single 11-bit field. This field is used by:
  • HomeNID in CompData and DataSepResp
  • SrcID in SnpRespData and WriteData
• Data poison is a single bit per data transfer and is indicated by a RespErr value of DERR.
• The ChunkValid field is used to indicate if the corresponding 32 bytes includes valid data. See Table 4.2.
• The Data field starts at a byte boundary. This requires a RsvdZero bit padding before the Data field.
• Fields exclusively in DataL message start at a granule boundary.
• Invalid bytes in the Data field in any data message, indicated by ChunkValid, and BE in write data and snoop response data, must be zeroed.

DataS 和 DataL 消息格式的特点包括：

• SrcID 和 HomeNID 共享一个 11 位字段。该字段由以下使用：
  • CompData 和 DataSepResp 中的 HomeNID
  • SnpRespData 和 WriteData 中的 SrcID
• 数据 poison 是每次数据传输的一位，并由 DERR 的 RespErr 值指示。
• ChunkValid 字段用于指示相应的 32 字节是否包含有效数据。
• 数据字段从字节边界开始。这需要在数据字段之前进行 RsvdZero 位填充。
• DataL 消息中专有的字段从颗粒边界开始。
• 任何数据消息中数据字段中的无效字节（由 ChunkValid 指示）以及写入数据和探听响应数据中的 BE 必须为零。

The DataL message format must be used instead of DataS when any of the following conditions are true:

• The BE field in a data response to a partial write request has one or more bits with zero value.

• The following fields are present in the message and have a non-zero value:

  • QoS
  • PBHA
  • RSVDC[N-1:16]

• 当满足以下任一条件时，必须使用 DataL 消息格式而不是 DataS：

  • 对部分写入请求的数据响应中的 BE 字段具有一个或多个零值位。
  • 消息中存在以下字段且具有非零值：
    • QoS
    • PBHA
    • RSVDC[N-1:16]

When the use of DataS is allowed, a Transmitter is permitted to use DataL message in place of DataS. The use of DataL instead of DataS may lead to reduced container packing efficiency.

当允许使用 DataS 时，传输器被允许使用 DataL 消息来代替 DataS。使用 DataL 代替 DataS 可能会导致容器的打包率降低。

Table 4.6 shows the message fields for DataS and DataL.

4.2.5. WritePush message

Immediate Writes, Atomics and DVMReq transactions with NonCopyBackWriteData data, are permitted, but not required, to optimize their transaction flow by using write push semantics. A Write push flow combines the request and data sent from the Transmitter to Receiver into a single message, thus eliminating the need for a DBIDResp response.

使用 NonCopyBackWriteData 数据的即时写入（Immediate Writes）、原子（Atomics）和 DVMReq 事务允许（但不要求）通过使用写入推送语义来优化其事务流程。WritePush 流程将从发送方发送到接收方的请求和数据合并为一条消息，因此无需 DBIDResp 响应。

This two-step write push over the three-step write pull transaction allows the following advantages:

• Reduced number of messages, therefore improving link utilization.
• Fields that are present in both Request and Data only need to be sent once.
• Reduced request buffer occupancy time.

与三步写拉取事务相比，两步 WritePush 具有以下优点：

• 减少消息数量，从而提高链路利用率。
• 请求和数据中都存在的字段只需发送一次。
• 减少请求缓冲区占用时间。

The following interface properties are defined to support WritePush transactions:

• WritePush_Support
  • This property indicates if the interface supports the use of WritePush for Immediate Writes and Atomic transactions. See 10.4.2. Receiver and Transmitter properties.
• DVMPush_Support
  • This property indicates if the interface supports the use of WritePush for DVM transactions. See 10.4.2. Receiver and Transmitter properties.

定义以下接口属性来支持 WritePush 事务：

• WritePush_Support
  • 此属性指示接口是否支持使用 WritePush 进行立即写入和原子事务。
• DVMPush_Support
  • 此属性指示接口是否支持使用 WritePush 进行 DVM 事务​​。

See 4.2.5.2. Message fields Message fields for message format details.

4.2.5.1. Transaction flow

Figure 4.1 shows the transaction flow for an Immediate Write transaction using write push semantics.

The sequence for the WritePush transaction is:

• The transaction starts with the Requester issuing a WrReqDataS or WrReqDataL message.
• The Completer sends a Comp response.

WritePush 事务的顺序是：

• 事务从请求者发出 WrReqDataS 或 WrReqDataL 消息开始。
• Completer 发送 Comp 响应。

4.2.5.2. Message fields

Table 4.7 lists the request opcodes that are permitted to use a WrReqDataS message. In these requests, the BE field values must all be 1. All other push transactions, including those that require fields which are not included in a WrReqDataS message, must use a WrReqDataL message format.

表 4.7 列出了允许使用 WrReqDataS 消息的请求操作码。在这些请求中，BE 字段值必须全部为 1。所有其他推送事务（包括那些需要 WrReqDataS 消息中未包含的字段的事务）必须使用 WrReqDataL 消息格式。

In WrReqDataS and WrReqDataL, invalid bytes in the Data field must be zeroed.

在 WrReqDataS 和 WrReqDataL 中，数据字段中的无效字节必须清零。

Note

The interface can use ChunkValid to determine which bytes to be zeroed.

该接口可以使用 ChunkValid 来确定哪些字节要清零。

The OWO field in Table 4.7 indicates if the write is part of a group of writes that require Ordered Write Observation (OWO) guarantees.

表 4.7 中的 OWO 字段表示写操作是否是需要有序写观察（Ordered write Observation， OWO）保证的一组写操作的一部分。

• When OWO = 0
  • OWO guarantees are not required.
• When OWO = 1
  • OWO guarantees are required.

When the rules permit the use of WrReqDataS, a write push message is permitted to use WrReqDataL instead of WrReqDataS. The use of WrReqDataL may lead to reduced container packing efficiency.

当规则允许使用 WrReqDataS 时，允许 WritePush 消息使用 WrReqDataL 而不是 WrReqDataS。使用 WrReqDataL 可能会导致容器打包效率降低。

Table 4.8 shows the Opcode2 field in a WrReqDataS message

Figure 4.2 illustrates the sharing of the Union1 field among MPAM, MECID, and RSVDC fields.

The lower order bits of the Union1 field determine how the other bits of the field are used for MPAM, MECID, and RSVDC values.

Union1 字段的低位确定该字段的其他位如何用于 MPAM、MECID 和 RSVDC 值。

4.2.6. Snoop message fields

Table 4.9 shows the fields in a Snoop message.

表 4.9 显示了 Snoop 消息中的字段。

4.2.7. Uncredited Miscellaneous message fields

The fields in a MiscU message are shown in Table 4.10.

MiscU 消息中的字段如表 4.10 所示。

The number of Payload bits used by a MiscU message is dependent on the MISC message type.

MiscU 消息使用的有效负载位数取决于 MISC 消息类型。

The following key is used:

使用以下字段：

X Variable field width, where the precise value is dependent on the MiscOp field value.

X 可变字段宽度，其中精确值取决于 MiscOp 字段值。

MiscOp describes the message subtypes supported by Miscellaneous message class.

MiscOp 描述杂项消息类支持的消息子类型。

The encoding of MiscOp field in a MiscU message is shown in Table 4.11.

MiscU 消息中 MiscOp 字段的编码如表 4.11 所示。

4.2.8. Redundant fields

Certain CHI fields are not required in C2C messages because of one or more of the following reasons:

• The transaction flow that uses the field is not supported.
• The field is used in messages in the Home Node to Subordinate Node interface only to support flow optimizations not supported in C2C.
• Routing of messages of that message class is based on address decode rather than ID.

由于以下一个或多个原因，C2C 消息中不需要某些 CHI 字段：

• 不支持使用该字段的事务流。
• 该字段用于主节点到从属节点接口的消息中，仅用于支持 C2C 中不支持的流优化。
• 该消息类别的消息路由基于地址解码而不是 ID。

Table 4.12 shows the CHI fields not required in C2C messages.

5. Flow control

This chapter describes the message flow control for a C2C interface

本章介绍 C2C 接口的消息流控制

5.1. Introduction

Messages are required to adhere to the following conditions:

• A message must not be dropped or lost in transport, that is, every message that is sent by a Transmitter must be received and processed by the Receiver.
• Incoming packets from the Link layer or Physical layer must be accepted without applying back pressure, in accordance with industry wide physical design standards. See UCIe for more information.
• Response and Data channel messages must be accepted without dependency on forward progress of any Request or Snoop messages.
• Snoop channel message must progress without dependency on forward progress of Request channel messages.
• Write push requests must not block forward progress of any data that is not associated with a write push.

消息必须遵守以下条件：

• 消息在传输过程中不得丢失或丢失，即发送器发送的每条消息都必须由接收器接收和处理。
• 根据行业范围的物理设计标准，来自链路层或物理层的传入数据包必须在不施加反压的情况下被接受。
• 响应和数据通道消息必须被接受，而不依赖于任何请求或窥探消息的转发进度。
• 窥探通道消息必须在不依赖于请求通道消息的转发进度的情况下进行。
• 写推送请求不得阻止与写推送无关的任何数据的转发进程。

The following mechanisms are used to support the flow control requirements:

• Separate credits per message class are provided to ensure messages from an individual message class can progress, while other Message Class messages are back pressured.
• Multiple Resource Planes and DAT credit pools are supported within REQ and DAT Message Classes to support forward progress guarantees for different message groups within each message class.
• Ordering of messages within a message class and an RP is also supported.

以下机制用于支持流量控制要求：

• 为每个消息类别提供单独的信用，以确保来自单个消息类别的消息可以继续进行，而其他消息类别消息则受到反压。
• REQ 和 DAT 消息类中支持多个资源计划和 DAT 信用池，以支持每个消息类中不同消息组的转发进度保证。
• 支持消息类和 RP 内的消息排序。

5.2. Message credits

To support flow control requirements, it is required that:

• Messages from each message class must be flow controlled independently.
• For each message class, the Receiver must provide message credits to the Transmitter. This ensures a Transmitter has the appropriate credits before sending a message.
  • Uncredited MISC messages do not require a message credit and the Receiver must guarantee to accept such a message.
  • To send a WrReqDataS or WrReqDataL message, the Transmitter needs to have one REQ and one DAT message credit. See 5.4. Data credit pools.

为了支持流量控制要求，需要：

• 来自每个消息类别的消息必须独立地进行流控制。
• 对于每个消息类别，接收方必须向发送方提供消息信用。这确保发送者在发送消息之前拥有适当的信用。
  • 未信用的 MISC 消息不需要消息信用，并且接收方必须保证接受此类消息。
  • 为了发送 WrReqDataS 或 WrReqDataL 消息，发送器需要具有 1 个 REQ 和 1 个 DAT 消息信用。

See Table 4.1 to determine which credit is required for each message type.

Credits can be granted using either the Protocol header or using a MiscU message.

信用可通过协议标头或 MiscU 报文授予。

5.2.1. Credit grant using a Protocol header

Credits can be granted to the Transmitter using the message credit grant field, MsgCredit, in the Protocol Header. The subfields of the MsgCredit field are shown in Figure 5.1. The MsgCredit field can be used to grant credits for all message classes, except MISC.

可以使用协议头中的消息信用授予字段 MsgCredit 向发送方授予信用。 MsgCredit 字段的子字段如图 5.1 所示。 MsgCredit 字段可用于为除 MISC 之外的所有消息类别授予信用。

A container with Activation messages cannot be used to grant credits using the Protocol header. See 8.2. Interface Activation and Deactivation for details on Activation messages.

带有激活消息的容器不能用于使用协议标头授予信用。

SharedCrdt (ShC) and RP fields are included to be used when multiple RP are supported in either REQ or DAT message classes. ShC and RP field values are applicable in both REQCredit and DATCredit fields, but are not applicable to RSPCredit or SNPCredit fields.

SharedCrdt (ShC) 和 RP fields 包含在 REQ 或 DAT 报文类中支持多个 RP 时使用。ShC 和 RP field 值适用于 REQCredit 和 DATCredit fields，但不适用于 RSPCredit 或 SNPCredit fields。

• When ShC=0

  • The REQCredit and DATCredit both correspond to credit pools indicated by the RP field value and:
    • When WritePush_Support and DVMPush_Support are both False, DATCredit must be 0.
    • When either WritePush_Support or DVMPush_Support, or both, are True, DATCredit must be 0 when the RP value is greater than 1.
    • An RP value of greater than or equal value to the maximum REQ RP is not permitted.

• When ShC=1

  • The REQCredit and DATCredit both correspond to shared credit pool. The RP field is inapplicable and must be zero.

• 当 ShC=0 时

  • REQCredit 和 DATCredit 都对应于 RP 字段值指示的信用池，并且：
    • 当 WritePush_Support 和 DVMPush_Support 都为 False 时，DATCredit 必须为 0。
    • 不允许 RP 值大于或等于最大 REQ RP。

• 当ShC=1时

  • REQCredit 和 DATCredit 都对应于共享信用池。 RP 字段不适用并且必须为零。

See 5.3. Resource Planes and 5.4. Data credit pools for details of the shared credit and dedicated credit pool usage.

5.2.2. Credit grant using a MiscU message

Credits for all message channels can be granted using a MISC channel message by sending an explicit credit grant message on the MISC channel. 5.2.3. Credit grant message format.

通过在 MISC 通道上发送显式信用授予消息，可以使用 MISC 通道消息来授予所有消息通道的信用。

Granted credits are used when a message in the associated message class is sent. Table 5.1 shows the encoding of the message credit field.

当发送关联消息类别中的消息时，将使用授予的信用。

5.2.3. Credit grant message format

The MiscU.CrdtGrant is used for granting credits for messages. Table 5.2 shows the CrdtGrant MiscU message fields.

MiscU.CrdtGrant 用于授予消息信用。

5.3. Resource Planes

Multiple resource planes are typically used to enable:

• Forward progress guarantees against different requests. For example, to ensure the forward progress of PCIe posted writes is not dependent on the progress of other write transactions.
• Service time guarantees. For example, messages that are part of real-time traffic which need to be serviced within required latency bounds.
• Simplication of the protocol. For example, eliminating Request retry without creating a transport deadlock, even when two phases of a transaction use the same transport.

多个资源计划通常用于使能：

• 向前进度保证了不同的请求。例如，确保 PCIe posted writes 的转发进度不依赖于其他写入事务的进度。
• 服务时间保证。例如，属于实时流量一部分的消息需要在所需的延迟范围内提供服务。
• 协议的简化。例如，即使事务的两个阶段使用相同的传输，也可以消除请求重试而不会造成传输死锁。

This specication supports request Resource Planes (RP) to provide transport independence between requests. When using Resource Planes:

• Messages using different Resource Planes must not block one another from the local Protocol layer to the remote Protocol layer.
• The following types of credits can be issued:
  • Dedicated credits are for a specific RP and can only be used for messages belonging to that RP.
  • Shared credits do not specify an RP and can be used for messages assigned to any RP.
• Messages using the same RP must remain in-order, even if they are using shared credits.
• Any RP for which the Transmitter has credits can be used to send messages.
• It is recommended, but not required, that a Transmitter uses shared credits before dedicated credits.

该规范支持请求资源计划（RP）以提供请求之间的传输独立性。使用资源计划时：

• 使用不同资源计划的消息不得从本地协议层到远程协议层相互阻塞。
• 可以发射以下类型的信用：
  • 专用信用用于特定 RP，并且只能用于属于该 RP 的消息。
  • 共享信用不指定 RP，可用于分配给任何 RP 的消息。
• 使用相同 RP 的消息必须保持有序，即使它们使用共享信用。
• 发送者有信用的任何 RP 都可以用来发送消息。
• 建议但不要求发送者在专用信​​用之前使用共享信用。

There can be up to eight Resource Planes for Request messages.

请求消息最多可以有八个 RP。

A Receiver can divide its buffers between shared and dedicated credit pools. The number of message credits for each dedicated credit pool is permitted to be different.

接收方可以将其缓冲区划分为共享信用池和专用信用池。每个专用信用池的消息信用数允许不同。

The Receiver must have available at least one dedicated credit per request RP supported and at least one credit for shared credit pool.

接收方必须为每个受支持的 RP 请求提供至少 1 个可用的专用信用，并且至少为共享信用池提供 1 个信用。

A Request message must:

• Indicate if it is using shared pool credit.
• Include the RP to which it belongs to, even when using shared pool credit.

请求消息必须：

• 指示它是否正在使用共享池信用。
• 包括它所属的 RP，即使在使用共享池信用时也是如此。

SharedCrdt and ResPlane fields are included in request messages to support Resource Planes:

• SharedCrdt. Indicates if a request is using a shared credit.
  • When SharedCrdt = 0
    • The request is using dedicated RP credit. The RP number is indicated by the ResPlane field value.
  • When SharedCrdt =1
    • The request is using shared pool credit. The RP to which the message belongs must be indicated by the ResPlane field value, even though shared credits are being used.
• ResPlane[2:0]. Indicates the RP to which the request belongs.

SharedCrdt 和 ResPlane 字段包含在请求消息中以支持资源计划：

• SharedCrdt。指示请求是否使用共享信用。
  • 当 SharedCrdt = 0 时
    • 该请求使用专用 RP 信用。 RP 编号由 ResPlane 字段值指示。
  • 当 SharedCrdt = 1 时
    • 该请求使用共享池信用。即使正在使用共享信用，消息所属的 RP 也必须由 ResPlane 字段值指示。
• ResPlane[2:0]。请求所属的 RP。

The field value can be 0 to Num_RP_REQ. The Num_RP_REQ property defines the maximum number of dedicated RP supported by the Request message class. See Table 10.7 and Table 10.8 for the Num_RP_REQ encoding.

该字段值可以是 0 到 Num_RP_REQ。 Num_RP_REQ 属性定义请求消息类支持的专用 RP 的最大数量。 Num_RP_REQ 编码参见表 10.7 和表 10.8。

See 4.2.2. Request message fields for the ReqS and ReqL message format.

5.4. Data credit pools

Credits that are used to transfer messages with data, DAT credits, are split into the following credit pools:

• DAT0Credit, a dedicated credit used to transfer Data messages that need progress to be guaranteed over any blocked WritePush message. The sending of a message using DAT0Credit must not be dependent on the progress of messages using credits from the other data credit pools.
• DAT1Credit, a dedicated credit used to transfer WrReqData messages that need guaranteed forward progress. The sending of a message using DAT1Credit must not be dependent on progress of messages using credits from the other data credit pools
• DATShCredit, a shared credit that can be used to transfer any data message. The use of DATShCredit by messages relating to one request RP must not block or be blocked by messages relating to another request RP.

用于传输带有数据的消息的信用（DAT credits）分为以下信用池：

• DAT0Credit，一种专用信用，用于传输需要保证任何被阻止的 WritePush 消息的进度的数据消息。使用 DAT0Credit 发送消息不得依赖于使用来自其他数据信用池的信用的消息的进度。
• DAT1Credit，用于传输需要保证转发进度的 WrReqData 消息的专用信用。使用 DAT1Credit 发送消息不得依赖于使用其他数据信用池中的信用消息的进度
• DATShCredit，一种可用于传输任何数据消息的共享信用。与一个请求 RP 相关的消息对 DATShCredit 的使用不得阻塞或被与另一请求 RP 相关的消息阻塞。

Table 5.3 shows which message types are permitted to use which credit types.

The choice of using a dedicated or shared credit can depend on the required progress of the transfer. For example:

• A PCIe write which must make forward progress, and is using the WrReqData message, is expected to use a dedicated credit when no shared credits are available.
• A DVM message which can be stalled by other messages can wait for a shared credit to be available and does not need dedicated credit support.

使用专用或共享信用的选择可以取决于所需的传输进度。例如：

• 当没有共享信用可用时，必须向前推进并使用 WrReqData 消息的 PCIe 写入预计将使用专用信用。
• 可以被其他消息阻塞的 DVM 消息可以等待共享信用可用，并且不需要专用信用支持。

If either WritePush_Support or DVMPush_Support are True, at least one credit of each dedicated DAT credit type must be made available.

如果 WritePush_Support 或 DVMPush_Support 为 True，则必须使每种专用 DAT credit 类型中的至少一个信用可用。

If both WritePush_Support and DVMPush_Support are False, DAT0Credit and DAT1Credit are not required and credits for them must not be sent.

如果 WritePush_Support 和 DVMPush_Support 均为 False，则不需要 DAT0Credit 和 DAT1Credit，并且不得发送它们的积分。

5.4.1. Credits for DataS and DataL messages

The DataS and DataL fields include a SharedCrdt field with the following encoding:

• When SharedCrdt = 0
  • The data message is using a DAT0Credit.
• When SharedCrdt = 1
  • The data message is using a DATShCredit.

DataS 和 DataL 字段包括具有以下编码的 SharedCrdt 字段：

• 当 SharedCrdt = 0 时
  • 数据消息使用 DAT0Credit。
• 当 SharedCrdt = 1 时
  • 数据消息使用 DATShCredit

See 4.2.4. Data message fields for the DataS and DataL message format.

5.4.2. Credits for WrReqData messages

A WrReqData message includes a request and write data, so needs one REQ message credit and one DAT message credit.

WrReqData 消息包括请求和写入数据，因此需要 1 个 REQ 消息信用和 1 个 DAT 消息信用。

The request part of a WrReqData message can be allocated an RP in the same way as other request messages.

WrReqData 消息的请求部分可以与其他请求消息相同的方式分配 RP。

Any WrReqData message that:

• Requires forward progress guarantees is permitted to use either DATShCredit or DAT1Credit. It is recommended, but not required, to use DATShCredit before DAT1Credit.
• Does not require forward progress guarantees must use DATShCredit.

任何 WrReqData 消息：

• 需要向前进度保证才允许使用 DATShCredit 或 DAT1Credit。建议（但不要求）在 DAT1Credit 之前使用 DATShCredit。
• 不要求前进进度保证的必须使用 DATShCredit。

The credit and RP options for WrReqData messages are encoded in SharedCrdt and ResPlane fields as follows:

• SharedCrdt
  • When SharedCrdt = 0
    • The request is using a REQxCredit. The data is using a DAT1Credit.
  • When SharedCrdt = 1
    • The request is using a REQShCredit. The data is using a DATShCredit.
• ResPlane[2:0]
  • Indicates the RP to which the request is assigned.

WrReqData 消息的信用和 RP 选项在 SharedCrdt 和 ResPlane 字段中编码，如下所示：

• SharedCrdt
  • 当 SharedCrdt = 0 时
    • 该请求使用 REQxCredit。数据使用 DAT1Credit。
  • 当 SharedCrdt = 1 时
    • 该请求使用 REQShCredit。数据使用 DATShCredit。
• ResPlane[2:0]
  • 指示请求被分配到的 RP。

See 4.2.5.2. Message fields for the WrReqData message format.

Note A write message that needs both Request and Data shared credits to progress using WritePush semantics may change to using Write pull to progress on the transaction, when simultaneous availability of both shared credits is not provided in a timely manner.

注意：当未及时提供两个共享信用的同时可用性时，需要请求和数据共享信用来使用 WritePush 语义进行处理的写入消息可能会更改为使用 Write Pull 来处理事务。

5.5. Ordered interface

It is required that the C2C interface must be ordered.

要求 C2C 接口必须有一定的序。

Containers must be received at the C2C interface in the same order that they were sent by the C2C interface on the far side of the link.

C2C 接口接收容器的顺序必须与链路远端 C2C 接口发送容器的顺序相同。

It is required that:

• At the Transmitter:

  • Messages from the same message class and same RP where that applies, must be placed in the container in the same order that they are received from the Protocol layer, that is in granules starting from the lowest number first to higher numbers.
  • Messages from different message class do not have such ordered placement restrictions.

• At the Receiver:

  • The Packetization layer must maintain the order of placement of messages of a given message class within the received container as well as order in which containers are received.
  • The messages within a message class of the same RP value must be forwarded to the Protocol layer in the same order as they are received.

要求：

• 在发射处
  • 来自相同消息类和相同 RP 的消息必须按照从协议层接收的顺序放置在容器中，即按照从最低编号开始到更高编号的顺序排列。
  • 来自不同消息类别的消息没有这种顺序放置限制。
• 在接收处：
  • 打包层必须维护给定消息类的消息在接收到的容器内的放置顺序以及接收容器的顺序。
  • 具有相同 RP 值的消息类别中的消息必须按照接收顺序转发到协议层。

See 2.4. Multiple interfaces for ordering requirements when using multiple interfaces between two components.

The ordered interface is a required feature and hence an interface property to control its presence is not included.

有序接口是必需的功能，因此不包括控制其存在的接口属性。

6. DVM transactions

6.1. Introduction

All CHI DVM transactions are supported over the C2C interface. A new node type, DVM Node (DN), is defined which is responsible for propagating local DVM transactions to remote chips and performing the required local in validations as requested by remote DVM requests.

所有 CHI DVM 事物均通过 C2C 接口支持。定义了一种新的节点类型，DVM 节点 (DN)，它负责将本地 DVM 事务​​传播到远程芯片，并根据远程 DVM 请求的要求执行所需的本地验证。

DVM Nodes also manage flow control to guarantee DVM transaction forward progress. DVM message flows are optimized by introducing new response types and reducing the number of messages.

DVM 节点还管理流量控制以保证 DVM 事务​​的转发进度。通过引入新的响应类型和减少消息数量来优化 DVM 消息流。

6.2. DVM Node, DN

A DN processes DVM operations to and from remote chips. A DN performs the following functions:

• Sends DVM requests to remote DVM Nodes for local DVM transactions. When sending the request to multiple nodes, it may use unicasting DVM requests to each remote DN or a hierarchical tree communication pattern to send to a subset of remote DN which further forward the request to another subset and thus spanning the DVM request to all DVM nodes in the system.
• Collects responses for DVM requests it sent to remote DN.
• Performs locally required in validations for remote DVM requests.
• Coordinates interaction between local and remote DVM transactions.

DN 处理往返于远程芯片的 DVM 操作。 DN 执行以下功能：

• 将 DVM 请求发送到远程 DVM 节点以进行本地 DVM 事务​​。当将请求发送到多个节点时，它可以使用到每个远程 DN 的单播 DVM 请求或分层树通信模式来发送到远程 DN 的子集，该子集进一步将请求转发到另一个子集，从而将 DVM 请求跨越到所有 DVM 节点在系统中。
• 收集发送到远程 DN 的 DVM 请求的响应。
• 在本地执行远程 DVM 请求验证所需的操作。
• 协调本地和远程 DVM 事务​​之间的交互。

Each chip is permitted to have one DN only.

每个芯片只允许有一个 DN。

The number of DVM Nodes in the system is limited to 64.

系统中的 DVM 节点数量限制为 64 个。

6.2.1. DVM Node assignment

A DN is permitted to share ID name space with Request Nodes and Home Nodes on the same chip.

允许 DN 与同一芯片上的请求节点和主节点共享 ID 名称空间。

This requires DVM responses which are targeting a DN to be identified separately from responses targeting Request Nodes.

这需要将针对 DN 的 DVM 响应与针对请求节点的响应分开识别。

Note

The ability to share Node ID name space minimizes the total unique ID required in the system.

共享节点 ID 名称空间的能力最大限度地减少了系统中所需的唯一 ID 总数。

6.3. DVM transaction flows

The two DVM transactions over C2C are:

• DVMReq
• DVMSync

C2C 上的两个 DVM 事物是：

• DVMReq
• DVMSync

In this specication, DVMReq refers to DVMOp(NonSync) and DVMSync refers to DVMOp(Sync).

在本规范中，DVMReq 指的是 DVMOp(NonSync)，DVMSync 指的是 DVMOp(Sync)。

6.3.1. DVMReq

The DVMReq transaction flow is illustrated in Figure 6.1. The flow is similar to a 32-byte write partial transaction flow. The DVMReq transaction can use write push or write pull semantics.

DVMReq 交易流程如图 6.1 所示。该流程类似于 32 字节写入部分事务流程。 DVMReq 事务可以使用写推送或写拉语义。

The DVMReq is permitted to use write push semantics only when DVMPush_Support property is True.

仅当 DVMPush_Support 属性为 True 时，才允许 DVMReq 使用写推送语义。

The Completer responses are:

• When a write push flow is used: CompDVM.
• When a write pull flow is used: CompDVM, DBIDResp DVM, or a combined CompDBIDResp DVM.

完成者的回应是：

• 当使用写推送时：CompDVM。
• 使用写拉时：CompDVM、DBIDResp DVM 或组合的 CompDBIDResp DVM。

See 6.4. DVM transaction responses for response message details. FIXME

DVM transaction payload is distributed across the Addr and Data fields of the request, like on-chip CHI. Comp and DVMData are differentiated from Comp and Data responses for non-DVM transactions by using different opcodes.

DVM 事务​​有效负载分布在请求的 Addr 和 Data 字段中，就像片上 CHI 一样。 Comp 和 DVMData 通过使用不同的操作码来区别于非 DVM 事务​​的 Comp 和 Data 响应。

Note On-chip CHI is used to pass DVM transactions from a local DN or ingress port to the C2C Requester. After being sent across the C2C interface, the C2C Completer uses on-chip CHI to pass the transaction to the local DN or an egress port.

片上 CHI 用于将 DVM 事务​​从本地 DN 或入口端口传递到 C2C 请求方。通过 C2C 接口发送后，C2C Completer 使用片上 CHI 将事务传递到本地 DN 或出口端口。

6.3.2. DVMSync

The DVMSync transaction flow is illustrated in Figure 6.2. The flow is similar to a Dataless request transaction flow with a single response.

DVMSync 事务流程如图 6.2 所示。该流程类似于具有单个响应的无数据请求事务流程。

The complete response is Comp Sync DVM.

完整的响应是 Comp Sync DVM。

All required payload is in the request address fields and thus the DVM transaction data response is eliminated.

所有必需的有效负载都在请求地址字段中，因此消除了 DVM 事务​​数据响应。

DVMSync is used when the on-chip Opcode field indicates DVMOp and the DVMType subfield indicates Synchronization.

当片上操作码字段指示 DVMOp 并且 DVMType 子字段指示同步时，使用 DVMSync。

Request is tracked by SrcID alone. There can be only one DVMSync transaction outstanding from each source. Thus, the TgtID in the response is used to match the response to its corresponding request.

请求仅通过 SrcID 进行跟踪。每个源只能有一个未完成的 DVMSync 事务。因此，响应中的 TgtID 用于将响应与其相应的请求进行匹配。

In the request, the TxnID is inapplicable and must be zero.

请求中，TxnID 不适用，必须为零。

In the response, the TxnID field is inapplicable and must be zero.

在响应中，TxnID 字段不适用，必须为零。

6.4. DVM transaction responses

The response messages for DVMReq and DVMSync messages are:

• For DVMReq: CompDVM, DBIDResp DVM, CompDBIDResp DVM, and DVMData
• For DVMSync: Comp Sync DVM.

DVMReq 和 DVMSync 消息的响应消息是：

• 对于 DVMReq：CompDVM、DBIDResp DVM、CompDBIDResp DVM 和 DVMData
• 对于 DVMSync：Comp 同步 DVM。

See Table 6.1 and Table 6.2 for opcodes for DVM transaction responses, both data and non-data responses.

有关 DVM 事务​​响应（数据和非数据响应）的操作码，请参阅表 6.1 和表 6.2。

6.5. Flow control

The following rules must be followed by the Requester and the Completer of DVM transactions to guarantee transaction forward progress is made.

DVM 交易的 Requester 和 Completer 必须遵循以下规则，以保证交易的进展。

A DN:

• Must have only one DVMSync request outstanding to remote DVM nodes.
• Permitted to have any number of DVMReq requests outstanding to remote DVM nodes.
• Must accept one DVMSync from each remote DN.

DN:

• 远程 DVM 节点必须只有一个未完成的 DVMSync 请求。
• 允许向远程 DVM 节点发出任意数量的未完成的 DVMReq 请求。
• 必须接受来自每个远程 DN 的一个 DVMSync。

This requirement of all DVMSync requests must be sunk at the destination DN is placed to avoid request path being blocked at the C2C.

此要求所有 DVMSync 请求必须在目标 DN 处进行下沉，以避免请求路径在 C2C 处被阻塞。

A DVMSync at DN must not block forward progress of DVMReq transactions. That is, must guarantee forward progress of DVMReq transactions received from remote nodes. This guarantee can be obtained by reserving a buffer for received DVMReq transactions.

DN 处的 DVMSync 不得阻止 DVMReq 事务的转发进程。也就是说，必须保证从远程节点接收到的 DVMReq 事务的向前进展。可以通过为接收到的 DVMReq 事务保留缓冲区来获得此保证。

DVMReq transactions forward progress at the C2C interface must not depend on forward progress of DVMSync transactions.

C2C 接口处的 DVMReq 事务转发进度不得依赖于 DVMSync 事务的转发进度。

7. RME-DA and RME-CDA support

This chapter describes the C2C support for RME Device Assignment (DA) and RME Coherent Device Assignment (CDA). which are part of Arm Condential Compute Architecture.

本章介绍对 RME 设备分配 (DA) 和 RME 一致设备分配 (CDA) 的 C2C 支持。它们是 Arm Condential 计算架构的一部分。

7.1. Introduction

RME-DA is part of the Realm Management Extension architecture that enables the secure assignment of assignable device interfaces. A Device Permission Table (DPT) contains the permission attributes associated with physical addresses and specifies a corresponding set of DPT checks that apply to incoming accesses from devices.

RME-DA 是领域管理扩展架构的一部分，可实现可分配设备接口的安全分配。设备权限表 (DPT) 包含与物理地址关联的权限属性，并指定一组相应的 DPT 检查，这些检查适用于来自设备的传入访问。

In this section, the term RME-DA refers to a device that is IO coherent and the term RME-CDA refers to a device that has the capability of being fully coherent.

在本节中，术语 RME-DA 指的是 IO 相干的设备，术语 RME-CDA 指的是具有完全相干能力的设备。

This specication supports RME-DA and RME-CDA in multiple accelerator device topologies, where the accelerators are connected to a host. See Figure 7.1.

该规范支持多加速器设备拓扑中的 RME-DA 和 RME-CDA，其中加速器连接到主机。参见图 7.1。

A host, made from a single or multiple SoC dies, forms a Trusted Computing Base (TCB): A host:

• Is responsible for enforcing the security policies required by the system.
• Can be connected to multiple devices.
• Can have memory termed as Host Coherent Memory (HCM) directly attached to it. The HCM can be coherently accessed by the host, or by any fully coherent or IO coherent devices.
• Must not send a Stash Snoop to a device, unless the line is already legally permitted to be cached by the device.
• Is permitted to send DVMOp requests or SnpDVMOp snoops towards a device.

由单个或多个 SoC 芯片组成的主机形成可信计算基础 (TCB)： 主机：

• 负责执行系统所需的安全策略。
• 可以连接到多个设备。
• 可以直接连接称为主机一致性内存 (HCM) 的内存。 HCM 可以由主机或任何完全相干或 IO 相干设备进行相干访问。
• 不得向设备发送 Stash Snoop，除非设备已经合法地允许缓存该行。
• 允许向设备发送 DVMOp 请求或 SnpDVMOp 监听。

A device is a single physical chip(let) and is treated as a single unit from a trust perspective and individually attested. A device:

• Is trusted in its entirety for a set of Realms only and trusted to maintain Realm separation where required.
• Can have private memory-mapped resources.
• Can have one or more interfaces.
• Can have memory termed as device coherent memory (DCM) directly attached to it. The DCM can be coherently accessed by the host, the device, and by other coherent devices.
• Can access the DCM of another coherent device only where that access is channeled through a host compute node.
• Only operates in the Realm and Non-secure PAS.
• Is expected, but not required, to include the following fields in all requests to the host:
  • Security State (SecSID1) field
  • Stream ID (StreamID) field
• Only receives snoop requests for regions of memory owned by Realms that trust the device.
• Cannot be directly connected to another device.
• Is not permitted to send DVMReq or DVMSync requests to a host.

设备是单个物理 Chiplet，从信任的角度来看被视为单个单元并经过单独证明。一个设备：

• 仅对一组领域完全受信任，并受信任在需要时维持领域分离。
• 可以拥有私有内存映射资源。
• 可以有一个或多个接口。
• 可以直接连接称为设备相干内存 (DCM) 的内存。 DCM 可以由主机、设备以及其他相干设备进行相干访问。
• 仅当访问通过主机计算节点进行时，才能访问另一个相干设备的 DCM。
• 仅在领域和非安全 PAS 中运行。
• 预计但不要求在向主机发出的所有请求中包含以下字段：
  • 安全状态 (SecSID1) 字段
  • 流 ID（StreamID）字段
• 仅接收对信任设备的领域拥有的内存区域的探听请求。
• 无法直接连接到其他设备。
• 不允许向主机发送 DVMReq 或 DVMSync 请求。

The host and the devices can have multiple Request Nodes and Home Nodes.

主机和设备可以有多个请求节点和主节点。

It is expected that the host will perform additional checks on certain messages from or to a device. These checks can ensure that:

• Requests coming from the device to HCM are permitted to access that memory. This means the device cannot issue a request with a random PA and expect to get access to that location.
• Snoops coming from the device are only for DCM. This means the device cannot issue a request with arbitrary PA to gain access to a location.
• Snoops going to the device for cached HCM locations only expose accesses that the device is permitted to observe. This means the device cannot build up a picture of all trusted system activity for more targeted attacks.

预计主机将对来自或发送至设备的某些消息执行额外的检查。这些检查可以确保：

• 允许从设备发送到 HCM 的请求访问该内存。这意味着设备无法向随机 PA 发出请求并期望访问该位置。
• 来自设备的窥探仅适用于 DCM。这意味着设备无法向任意 PA 发出请求来访问某个位置。
• 探听设备以获取缓存的 HCM 位置仅公开允许设备观察的访问。这意味着设备无法构建所有可信系统活动的图像以进行更有针对性的攻击。

7.2. Fields supporting RME-DA and RME-CDA

The fields used to enable support for RME-DA and RME-CDA include:

• StreamID
  • Stream Identifier. StreamID is a unique identifier of request streams originating from one or a set of Requesters associated with the same System MMU context. The StreamID field in messages at an interface is applicable as defined by the DevAs sign Support properties.

Note When interfacing to PCIe, StreamID is the Requester ID associated with a single PCIe endpoint.

• SecSID1
  • Secure Stream Identifier. SecSID1 qualifies the Security state of StreamID. The SecSID1 field in messages at an interface is applicable as defined by the DevAs sign Support properties.
• MECID
  • Memory Encryption Context Identifier. MECID is an identifier assigned to memory accesses, associating each access with a memory encryption context. The MECID value is unique to each Realm. The MECID field in messages at an interface is applicable as defined by the MEC Support properties.

用于支持 RME-DA 和 RME-CDA 的字段包括：

• StreamID
  • 流标识符。 StreamID 是源自与同一系统 MMU 上下文关联的一个或一组请求者的请求流的唯一标识符。接口消息中的 StreamID 字段适用于 DevAs 标志支持属性的定义。
• SecSID1
  • 安全流标识符。 SecSID1 限定 StreamID 的安全状态。接口消息中的 SecSID1 字段适用于 DevAs 标志支持属性的定义。
• MECID
  • 内存加密上下文标识符。 MECID 是分配给内存访问的标识符，将每次访问与内存加密上下文相关联。每个领域的 MECID 值都是唯一的。接口消息中的 MECID 字段适用于 MEC 支持属性的定义。

7.3. Host and device responsibilities

7.4. Request Nodes per device

In an accelerator-attached configuration when the DevAssign_Support_Tx property indicates an interface is represented as a device:

• At the interface, the maximum number of Request Nodes permitted is 16. From this, a maximum of 8 nodes can be RN-F. The remaining can be IO coherent Request Nodes. The RN-F nodes must be assigned node ID values within the range 0 to 7.
• The interface must precisely track device caching to determine if an RN-F on that device has cached a copy of the line.

在加速器连接的配置中，当 DevAssign_Support_Tx 属性指示接口表示为设备时：

• 在接口处，允许的最大请求节点数为 16。由此，最多 8 个节点可以是 RN-F。剩下的可以是 IO 相干的请求节点。必须为 RN-F 节点分配 0 到 7 范围内的节点 ID 值。
• 该接口必须精确跟踪设备缓存，以确定该设备上的 RN-F 是否缓存了该线路的副本。

Note:

The manner in which memory caching is tracked at a Home determines the efficiency of snoop filter implementation.

主节点中跟踪内存缓存的方式决定了监听过滤器实现的效率。

Precisely knowing where a line is cached results in a Home sending targeted snoops to that cache. With coarse grain tracking, a Home needs to resort to multi-casting the snoop to a subset of caches or broadcasting the snoops to all the caches except the Requester. Both multi casting and broadcasting of snoops involves a Home sending multiple unicast snoops.

准确地知道行被缓存的位置会导致主向该缓存发送目标监听。通过粗粒度跟踪，主节点需要将监听多播到缓存的子集，或者将监听广播到除请求者之外的所有缓存。监听的多播和广播都涉及家庭发送多个单播监听。

A fine grain tracker at Home, typically a snoop filter or a directory, increases in size with respect to the increase in the number of caches to be tracked precisely.

主节点的细粒度跟踪器（通常是窥探过滤器或目录）的大小随着要精确跟踪的缓存数量的增加而增加。

To manage the increase in the size of a fine grain tracking snoop filter, an architectural upper limit on the number of caching agents per interface is placed. A host that supports RME-CDA can preemptively size its cache tracking structure to that limit.

为了管理细粒度跟踪探听过滤器大小的增加，对每个接口的缓存代理数量设置了架构上限。支持 RME-CDA 的主机可以预先将其缓存跟踪结构调整到该限制。

8. Interface state management

This chapter describes the C2C interface state management.

本章介绍 C2C 接口状态管理。

8.1. Introduction

Hardware flows manage the connectivity state of the interface and thus the link.

硬件流管理接口的连接状态，从而管理链路。

The three different connect and disconnect set of flows affect either the fully coherent traffic, DVM messages or all protocol messages.

三种不同的连接和断开流集会影响完全一致的流量、DVM 消息或所有协议消息。

8.2. Interface Activation and Deactivation

Interface activation and deactivation is used to enable or disable transport of all protocol traffic across the interface. Activation messages within MiscU message type support interface activation and deactivation. See 8.2.2. Messages for details of these messages.

接口激活和停用用于启用或禁用跨接口的所有协议流量的传输。 MiscU 消息类型中的激活消息支持接口激活和停用。

8.2.1. Activity states

The interface can be in one of four activity states.

• STOP
  • The interface is disconnected from all protocol activity.
• ACTIVATE
  • The interface is preparing to enable protocol activity.
• RUN
  • The interface is enabled for protocol activity.
• DEACTIVATE
  • The interface is preparing to disconnect from all protocol activity.

该接口可以处于四种活动状态之一：

• STOP
  • 该接口与所有协议活动断开。
• ACTIVATE
  • 该接口正在准备启用协议活动。
• RUN
  • 该接口已启用以进行协议活动。
• DEACTIVATE
  • 该接口正准备断开与所有协议活动的连接。

See 8.2.4. Activation and Deactivation flow flow for details of the interface behavior in each state.

The permitted state transitions are:

• STOP to ACTIVATE
• ACTIVATE to RUN
• RUN to DEACTIVATE
• DEACTIVATE to STOP

允许的状态转换是：

• STOP 到 ACTIVATE
• ACTIVATE 到 RUN
• RUN 到 DEACTIVATE
• DEACTIVATE 到 STOP

Figure 8.1 shows the permitted state transitions.

The remote credits are implicitly returned when the interface moves into the STOP state. That is, all Transmitter message credit counts are zeroed and Receiver message credits are reset to the values they were at the interface initialization.

当接口进入 STOP 状态时，远程信用会隐式返回。也就是说，所有发送方消息信用计数均归零，并且接收方消息信用计数重置为接口初始化时的值。

8.2.2. Messages

The following five messages are defined to support interface activation flow:

• ActivateReq
• ActivateAck
• DeactivateReq
• DeactivateAck
• DeactivateHint

定义了以下五个消息来支持接口激活流程：

• ActivateReq
• ActivateAck
• DeactivateReq
• DeactivateAck
• DeactivateHint

See Table 8.2 for their message format and Table 8.1 for Activation Op encoding.

8.2.2.1. ActivateReq and ActivateAck

ActivateReq and ActivateAck message pair is used to move the interface from a STOP state to the RUN state. See STOP and ACTIVATE state entries in 8.2.4. Activation and Deactivation flow for when ActivateReq and ActivateAck messages are sent and the interface response on receiving them.

ActivateReq 和 ActivateAck 消息对用于将接口从 STOP 状态移至 RUN 状态。

8.2.2.2. DeactivateReq and DeactivateAck

DeactivateReq and DeactivateAck message pair is used to bring the interface from the RUN state to the STOP state.

DeactivateReq 和 DeactivateAck 消息对用于使接口从 RUN 状态进入 STOP 状态。

8.2.2.3. DeactivateHint

DeactivateHint is a message informing the remote interface about the readiness of the Transmitter to deactivate the interface. The characteristics of this message include:

• It is a MiscU.Activation message. See Table 8.1.
• An interface is only permitted to send this message in the RUN activation state.
• An interface is permitted to send a DeactivateHint and then resume activity on the link.
• An interface is permitted to send multiple DeactivateHint messages, either with or without link activity between them.
• An interface is permitted to send a DeactivateReq without first sending a DeactivateHint message.
• If an interface has sent a DeactivateHint it is permitted to send a DeactivateReq without waiting for any response to the DeactivateHint.

DeactivateHint 是一条消息，通知远程接口发送器已准备好停用接口。该消息的特点包括：

• 这是一条 MiscU.Activation 消息。
• 仅允许接口在 RUN 激活状态下发送该消息。
• 允许接口发送 DeactivateHint，然后恢复链路上的活动。
• 接口可以发送多个 DeactivateHint 消息，无论它们之间有或没有链路活动。
• 允许接口在不先发送 DeactivateHint 消息的情况下发送 DeactivateReq。
• 如果接口已发送 DeactivateHint，则允许发送 DeactivateReq，而无需等待对 DeactivateHint 的任何响应。

Note The sender may use heuristics to decide on when to send the DeactivateHint message. For example, the heuristics might use the length of time the link has been inactive, that is, the time period for which no message is sent or received across the link. 注意 发送方可以使用试探法来决定何时发送 DeactivateHint 消息。例如，启发法可以使用链路处于非活动状态的时间长度，即没有通过链路发送或接收消息的时间段。

• The Receiver is permitted to respond to the DeactivateHint message in the following manner:

  • Can drop the hint without any state change.
  • Accept the hint and respond with DeactivateReq when the conditions for sending the message are met.

• 接收方可以通过以下方式响应 DeactivateHint 消息：

  • 可以在不改变任何状态的情况下删除提示。
  • 接受提示并在满足发送消息的条件时以 DeactivateReq 进行响应。

8.2.3. Activation message format

Table 8.1 shows the encoding of Activation Op field in the Activation message.

Table 8.2 shows the Activation message fields.

8.2.3.1. PropertyReq

This field value determines if a property exchange is required at the completion of interface activation.

• When PropertyReq = 0
  • Properties must not be exchanged.
• When PropertyReq = 1
  • Properties messages must be sent after ActivateAck is sent and received.

该字段值确定接口激活完成后是否需要进行属性交换。

• 当 PropertyReq = 0 时
  • Property 不得交换。
• 当 PropertyReq = 0 时
  • Properties 消息必须在发送和接收 ActivateAck 之后发送。

This field is applicable when ActivationOp is ActivateReq.

当 ActivationOp 为 ActivateReq 时，该字段适用。

This field is inapplicable and must be zero for other Activate message types.

该字段不适用，对于其他激活消息类型必须为零。

See 10.1. Introduction

8.2.4. Activation and Deactivation flow

This section describes the behavior of the interface in each activation state. There are two options for conditions under which the interface deactivation can be initiated. The two deactivation conditions, defined by Deactivation Support property, are:

1. Protocol agnostic: DeactivateReq is permitted to be sent from the RUN state at any time and does not need to check protocol message flows. Additionally, the protocol messages must not be sent after DeactivateReq is sent until the interface comes back to RUN state.
2. Protocol aware: DeactivateReq is permitted to be sent only when interfaces are in the RUN state and are completely quiesced in both directions. A reason for quiescing the interface may be for powering down the interface or the chip. Quiesce condition requires both sides must not have any protocol traffic to send. That is, all outstanding requests must have completed, no response messages must be sent, and no new request or snoop messages must be sent across the link.

本节描述每种激活状态下接口的行为。可以启动接口停用的条件有两个选项。由 Deactivation Support property 定义的两个停用条件是：

• 协议无关：允许在任何时候从 RUN 状态发送 DeactivateReq，并且不需要检查协议消息流。此外，在发送 DeactivateReq 后，直到接口返回到 RUN 状态之前，不得发送协议消息。
• 协议感知：仅当接口处于 RUN 状态且双向完全静止时才允许发送 DeactivateReq。使接口停顿的原因可能是为了使接口或芯片断电。静默条件要求双方不得有任何协议流量要发送。也就是说，所有未完成的请求必须已完成，不得发送任何响应消息，并且不得通过链路发送新的请求或探听消息。

The interface behavior for each activation and deactivation state includes:

• STOP

  • The credits are reset in this state.
  • The Receiver has all the credits but must not send any credits.
  • The Transmitter has no credits and is only permitted to send LinkStatus or ActivateReq messages.
  • If an interface wants to start sending other messages, it must send an ActivateReq message.
  • When an interface has sent or received an ActivateReq message, it must move into the ACTIVATE state.

• ACTIVATE

  • If not already sent, send an ActivateReq message.
  • If not already received, wait for an ActivateReq message.
  • After receiving the ActivateReq message, ActivateAck must be sent in a timely manner in response to the request.
  • After ActivateAck is sent, it is permitted, but not required, to send credits.
  • After ActivateAck is received, credits may be received.
  • When an interface has sent and received an ActivateAck message, it must move into the RUN state.

• RUN

  • Interface properties are sent, if requested.
  • Credits, appropriate to the negotiated interface properties, must be sent.
  • Credited messages can be sent.
  • If an interface might want to stop, it can send a DeactivateHint message. This message can be ignored by the remote or can cause it to send a DeactivateReq message.
  • If an interface wants to move to the STOP state, it can send a DeactivateReq message.
  • When an interface has sent or received a DeactivateReq message, it must move into the DEACTIVATE state.

• DEACTIVATE

  • If not already sent, when required activity is completed, send a DeactivateReq message.
  • Credits must be sent, until DeactivateReq is received.
  • Credited messages must not be sent, after the DeactivateReq message is sent.
  • DeactivateAck must be sent in a timely manner after a DeactivateReq is received.
  • Credits must not be sent after the DeactivateAck message is sent.
  • When an interface has sent and received a DeactivateAck message, it must move into the STOP state.

• STOP

  • 在此状态下信用将被重置。
  • 接收者拥有所有信用，但不得发送任何信用。
  • 发送器没有信用，只允许发送 LinkStatus 或 ActivateReq 消息。
  • 如果接口想要开始发送其他消息，则必须发送 ActivateReq 消息。
  • 当接口发送或接收到 ActivateReq 消息时，它必须进入 ACTIVATE 状态。

• ACTIVATE

  • 如果尚未发送，请发送 ActivateReq 消息。
  • 如果尚未收到，请等待 ActivateReq 消息。
  • 收到ActivateReq消息后，必须及时发送ActivateAck响应请求。
  • 发送ActivateAck后，允许但不要求发送信用。
  • 收到ActivateAck后，必须接收到信用。
  • 当接口发送并接收到ActivateAck消息时，它必须进入RUN状态。

• RUN

  • 如果需要，将发送接口属性。
  • 必须发送适合于协商的接口属性的信用。
  • 可以发送信用消息。
  • 如果接口可能想要停止，它可以发送 DeactivateHint 消息。远程设备可以忽略此消息，或者可以导致其发送 DeactivateReq 消息。
  • 如果接口想要转至 STOP 状态，它可以发送 DeactivateReq 消息。
  • 当接口发送或接收 DeactivateReq 消息时，它必须进入 DEACTIVATE 状态。

• DEACTIVATE

  • 如果尚未发送，则当所需活动完成时，发送 DeactivateReq 消息。
  • 必须发送信用，直到收到 DeactivateReq。
  • 发送 DeactivateReq 消息后，不得发送已记入的消息。
  • 收到DeactivateReq后，必须及时发送DeactivateAck。
  • 发送 DeactivateAck 消息后不得发送 Credits。
  • 当接口发送并接收到 DeactivateAck 消息时，它必须进入 STOP 状态。

8.2.4.1. Activation trigger, ActTrigger

A software visible 2-bit activation control field, ActTrigger, is defined to enable the hardware to initiate an Activate or Deactivate flow.

软件可见的 2 位激活控制字段 ActTrigger 被定义为使硬件能够启动激活或停用流程。

Table 8.3 shows the encoding of the ActTrigger field.

It is sufficient to set the trigger bits on one side to start the activation or deactivation sequence.

只需设置一侧的触发位即可启动激活或停用序列。

For example, if an Accelerator is attached to a host using the C2C link, the triggers can be implemented only on the host side.

例如，如果加速器使用C2C链路连接到主机，则触发器只能在主机侧实现。

8.3. Connect Miscellaneous messages

The MiscU.Connect messages are used in connecting and disconnecting an interface from the Snoop and DVM domains. See 8.4. Coherency connect and disconnect and 8.5.2. Messages on how these messages are used.

MiscU.Connect 消息用于连接和断开接口与 Snoop 和 DVM 域的连接。

Table 8.4 shows the Connect message fields.

Table 8.5 shows the encoding of ConnectOp field in Connect messages.

8.4. Coherency connect and disconnect

Interface coherency connect and disconnect messages are used to connect or disconnect the interface from coherency management requirements.

接口一致性连接和断开消息用于根据一致性管理要求连接或断开接口。

8.4.1. Coherency connect states

Each direction of C2C interface can be in one of the four coherency states. See Table 8.6 for details of each state.

• CohDisabled
  • The Requester caches on the interface do not include coherent data.
• CohConnect
  • An interface is requesting to be permitted to cache coherent data.
• CohEnabled
  • The Requesters on the interface participate in coherent data exchange.
• CohDisconnect
  • The Requesters on the interface are requesting to be removed from participating in coherent data exchange.

C2C 接口的每个方向都可以处于四种一致性状态之一。各状态的详细信息请参见表 8.6。

• CohDisabled
  • 接口上的请求者缓存不包含一致的数据。
• CohConnect
  • 接口正在请求允许缓存一致数据。
• CohEnabled
  • 接口上的请求者参与一致的数据交换。
• CohDisconnect
  • 接口上的请求者请求不再参与一致数据交换。

The Requesters on a chip participating in coherency domain are independent of the Home Nodes on that interface sending snoops to the remote nodes. Thus, the coherency connect and disconnect is per direction. The coherency state of an interconnect effects all Requesters on that interface.

参与一致性域的芯片上的请求者独立于该接口上向远程节点发送监听的主节点。因此，一致性连接和断开是每个方向的。互连的一致性状态影响该接口上的所有请求者。

The permitted state transitions are:

• CohDisabled to CohConnect
• CohConnect to CohEnabled
• CohEnabled to CohDisconnect
• CohDisconnect to CohDisabled

允许的状态转换是：

• CohDisabled 到 CohConnect
• CohConnect 到 CohEnabled
• CohEnabled 到 CohDisconnect
• CohDisconnect 到 CohDisabled

The interface moving from CohDisconnect to CohDisabled state must retain and not zero out the SNP credits held from the remote side.

从 CohDisconnect 状态转变为 CohDisabled 状态的接口必须保留而不是清零从远程端持有的 SNP 信用。

Figure 8.2 shows the permitted state transitions.

8.4.2. Messages

As part of MiscU.Connect message type, there are four messages defined to support interface Coherency connect flow:

1. CohConnectReq
2. CohConnectAck
3. CohDisconnectReq
4. CohDisconnectAck

作为 MiscU.Connect 消息类型的一部分，定义了四种消息来支持接口一致性连接流：

1. CohConnectReq
2. CohConnectAck
3. CohDisconnectReq
4. CohDisconnectAck

See Table 8.4 for their message format and Table 8.5 for ConnectOp encoding.

Table 8.6 describes the behavior of the two interfaces during connecting and disconnecting to a coherency domain.

Note Coherence connect states are independent in each direction. An interface Transmitter may continue to send Snoop requests while the Receiver on the same side of the interface is in coherency disabled state. 注意 Coherence 连接状态在每个方向上都是独立的。当接口同侧的接收器处于一致性禁用状态时，接口发送器可以继续发送 Snoop 请求。

8.5. DVM domain connect and disconnect

The DVM domain connect and disconnect messages are used to connect and disconnect the interface from address translation tables management.

DVM 域连接和断开消息用于连接地址转换表管理和从地址转换表管理断开接口。

8.5.1. DVM connect states

A C2C interface can be in one of four DVM domain connect states. See8.5.3. DVM domain connect and disconnect flow for details of each state.

• DVMDisabled
  • The interface is removed from DVM domain and does not send or receive DVM requests.
• DVMConnect
  • An interface is requesting to join the DVM domain.
• DVMEnabled
  • An interface is participating in DVM domain activities.
• DVMDisconnect
  • An interface is requesting to be taken out of DVM domain.

C2C 接口可以处于四种 DVM 域连接状态之一。

• DVMDisabled
  • 该接口已从 DVM 域中删除，并且不会发送或接收 DVM 请求。
• DVMConnect
  • 接口正在请求加入DVM域。
• DVMEnabled
  • 接口正在参与 DVM 域活动。
• DVMDisconnect
  • 接口正在请求退出 DVM 域。

When an interface removes itself from DVM domain, it neither sends or accepts DVM requests.

当接口将自身从 DVM 域中删除时，它既不发送也不接受 DVM 请求。

The permitted state transitions are:

• DVMDisabled to DVMConnect
• DVMConnect to DVMEnabled
• DVMEnabled to DVMDisconnect
• DVMDisconnect to DVMDisabled

允许的状态转换是：

• DVMDisabled 到 DVMConnect
• DVMConnect 到 DVMEnabled
• DVMEnabled 到 DVMDisconnect
• DVMDisconnect 到 DVMDisabled

Figure 8.3 shows the permitted state transitions.

8.5.2. Messages

The following four messages, grouped together as part of MiscU.Connect message type, are defined to support interface DVM connect flow:

• DVMConnectReq
• DVMConnectAck
• DVMDisconnectReq
• DVMDisconnectAck

以下四个消息组合在一起作为 MiscU.Connect 消息类型的一部分，定义为支持接口 DVM 连接流：

• DVMConnectReq
• DVMConnectAck
• DVMDisconnectReq
• DVMDisconnectAck

See Table 8.4 for their message format and Table 8.5 for ConnectOp encoding.

8.5.3. DVM domain connect and disconnect flow

The interface behavior in each DVM connect state includes:

• DVMDisabled

  • The Requesters on the interface must not cache address translations.
  • The interface must not send or receive DVM transactions.
  • The interface is permitted to receive a DVMConnectReq message.
  • A DVMConnectReq message can be sent if the interface wants to participate in DVM domain activities.
  • When an interface has sent or received a DVMConnectReq message, it must move into the DVMConnect state.

• DVMConnect

  • If not already sent, then send a DVMConnectReq.
  • If not already received, wait for DVMConnectReq message.
  • Once DVMConnectReq is received, send DVMConnectAck in a timely manner.
  • Must remain in DVMConnect state until DVMConnectAck is sent and received and then move to DVMEnabled state.

• DVMEnabled

  • Permitted to send DVM transactions.
  • Can receive DVM transactions.
  • If the interface wants to be removed from the DVM domain, it must first complete all outstanding DVM transactions and then send DVMDisconnectReq.
  • When an interface has sent or received a DVMDisconnectReq message, it must move into the DVMDisconnect state.

• DVMDisconnect

  • If not already sent, wait for all outstanding DVM transactions to complete then send a DVMDisconnectReq message.
  • After sending a DVMDisconnectReq, must not send any DVM requests.
  • Must continue to respond to DVM requests until a DVMDisconnectReq is received.
  • Must send DVMDisconnectAck in a timely manner after DVMDisconnectReq is received.
  • When an interface has sent and received DVMDisconnectAck message, it must move into the DVMDisabled state.

每个 DVM 连接状态下的接口行为包括：

• DVMDisabled
  • 接口上的请求者不得缓存地址转换。
  • 该接口不得发送或接收 DVM 事务​​。
  • 允许接口接收 DVMConnectReq 消息。
  • 如果接口想要参与 DVM 域活动，则可以发送 DVMConnectReq 消息。
  • 当接口发送或接收 DVMConnectReq 消息时，它必须进入 DVMConnect 状态。
• DVMConnect
  • 如果尚未发送，则发送 DVMConnectReq。
  • 如果尚未收到，请等待 DVMConnectReq 消息。
  • 收到DVMConnectReq后，及时发送DVMConnectAck。
  • 必须保持在 DVMConnect 状态，直到发送和接收 DVMConnectAck，然后转至 DVMEnabled 状态。
• DVMEnabled
  • 允许发送 DVM 交易。
  • 可以接收DVM交易。
  • 如果接口想要从 DVM 域中删除，它必须首先完成所有未完成的 DVM 事务​​，然后发送 DVMDisconnectReq。
  • 当接口发送或接收 DVMDisconnectReq 消息时，它必须进入 DVMDisconnect 状态。
• DVMDisconnect
  • 如果尚未发送，请等待所有未完成的 DVM 事务​​完成，然后发送 DVMDisconnectReq 消息。
  • 发送 DVMDisconnectReq 后，不得发送任何 DVM 请求。
  • 必须继续响应 DVM 请求，直到收到 DVMDisconnectReq。
  • 收到DVMDisconnectReq后必须及时发送DVMDisconnectAck。
  • 当接口发送和接收 DVMDisconnectAck 消息时，它必须进入 DVMDisabled 状态。

9. Interface initialization

This chapter describes the C2C interface initialization.

本章介绍C2C接口初始化。

9.1. Introduction

C2C interface initialization establishes the interface to enable the sending and receiving of protocol messages. The initialization flow has the following steps:

1. Coordinate with the Link layer to check if the remote Protocol layer is up within the interface.
2. Exchange interface properties using MiscU.Properties messages. This sets up the interface to start exchanging message credits followed by protocol messages.

C2C接口初始化建立接口以实现协议消息的发送和接收。初始化流程有以下步骤：

• 与链路层协调以检查远程协议层是否在接口内启动。
• 使用 MiscU.Properties 消息交换接口属性。这将设置接口以开始交换消息信用，然后交换协议消息。

Note Discovery, enumeration, and negotiation of global or common capabilities, such as Re q A ddr Width, Node ID assignment, address maps, routing table set up, is not managed by the hardware property exchange flows. The exchange of capabilities that are not part of the hardware property exchange flow is expected to be handled by software.

全局或通用功能的发现、枚举和协商，例如请求地址宽度、节点 ID 分配、地址映射、路由表设置，不由硬件属性交换流管理。不属于硬件属性交换流程一部分的功能交换预计将由软件处理。

9.2. Initialization flow

The key features of the initialization flow include:

• The Protocol layers on the two sides of the link are guaranteed to be able to receive Miscellaneous messages before link initialization is completed. This enables the Protocol layers to exchange MiscU.Activation messages using the default container format.

初始化流程的主要特征包括：

在链路初始化完成之前，保证链路两侧的协议层能够接收到杂项消息。这使得协议层能够使用默认容器格式交换 MiscU.Activation 消息。

Figure 9.1 shows the possible transaction flows for interface initialization.

The sequence for interface initialization is:

1. The interface initialization starts with link reset and initialization.

   • Before the link initialization is complete, the Link layer must wake up the Protocol layer. The Link layer to Protocol layer wake-up handshake method is IMPLEMENTATION DEFINED.
   • An example wake-up handshake using CXS interface between the Link layer and Protocol layer is shown in Figure 9.1.
     • The Link layer sends CXSACTIVEREQ to the local Protocol layer.
     • Once up, the Protocol layer sends the CXSACTIVEACK response.
     • In response to CXSACTIVEREQ from the Link layer, the protocol goes through the same handshake in the reverse direction. This reverse-direction CXSACTIVE handshake can be performed as late as during the end-to-end, that is, PL-to-remote-PL Activate handshake.

2. After the Link layer initialization is complete, the Link layer must be able to receive and recognize ActivateReq from the remote side. This is to be able to receive the ActivateReq request message, as described in (4).

3. After the Link layer initialization is complete, the Link layer sends MiscU.LinkStatus message to the local Protocol layer.

   • The LinkStatus message informs the Protocol layer of the completion of link initialization and includes information on negotiated flit format. For LinkStatus message details, see 9.2.1. LinkStatus message format

4. Protocol layer to ensure that the remote Protocol layer is active:

   • Each Protocol layer sends ActivateReq message to the remote Protocol layer.
   • The Protocol layer responds to received ActivateReq with ActivateAck message.

5. At this stage, both sides are ready to exchange supported property values using Properties message, if requested in the ActivateReq :

   • The Protocol layer sends Properties message to the remote.
   • Once the Protocol layer receives Properties messages from the remote, the Protocol layer is permitted to grant credits to the remote.

接口初始化的顺序为：

1. 接口初始化从链路重置和初始化开始。
   • 在链路初始化完成之前，链路层必须唤醒协议层。链路层到协议层的唤醒握手方法是由实现定义的。
   • 图 9.1 显示了链路层和协议层之间使用 CXS 接口的唤醒握手示例。
     • 链路层将 CXSACTIVEREQ 发送到本地协议层。
     • 一旦启动，协议层将发送 CXSACTIVEACK 响应。
     • 为了响应来自链路层的 CXSACTIVEREQ，协议在相反方向上经历相同的握手。这种反向 CXSACTIVE 握手可以晚于端到端期间执行，即 PL 到远程 PL 激活握手。
2. 链路层初始化完成后，链路层必须能够接收并识别来自远端的ActivateReq。这是为了能够接收ActivateReq请求消息，如(4)中所述。
3. 链路层初始化完成后，链路层向本地协议层发送MiscU.LinkStatus消息。
   • LinkStatus 消息通知协议层链路初始化已完成，并包含有关协商的 flit 格式的信息。
4. 协议层确保远程协议层处于活动状态：
   • 每个协议层向远程协议层发送ActivateReq消息。
   • 协议层用ActivateAck消息响应接收到的ActivateReq。
5. 在此阶段，如果在 ActivateReq 中请求，双方已准备好使用 Properties 消息交换支持的属性值：
   • 协议层将属性消息发送到远程。
   • 一旦协议层从远程接收到属性消息，协议层就被允许向远程授予信用。

For details of interface properties, their exchange and negotiation see 10. Protocol layer property exchange.

At the time when the link activation phase is completed, and properties exchange is required, the interface Coherency and DVM states are in Disabled state. If required, the interface coherency connection and DVM connection must be enabled by going through individual Coherency and DVM connect flows.

当链路激活阶段完成并且需要属性交换时，接口Coherency和DVM状态处于Disabled状态。如果需要，必须通过单独的一致性和 DVM 连接流程来启用接口一致性连接和 DVM 连接。

9.2.1. LinkStatus message format

The MiscU.LinkStatus message is used by the Link layer to inform the Protocol layer the completion of Link layer initialization and change in power status of the link. This message is sent during the interface initialization as described in 9.2. Initialization flow and the Link layer is permitted to send whenever the physical link power state changes.

MiscU.LinkStatus消息被链路层用来通知协议层链路层初始化完成以及链路电源状态的改变。该消息在接口初始化期间发送。

Table 9.1 shows the LinkStatus message fields.

9.2.1.1. FlitFormat

The FlitFormat field in the LinkStatus message is used by the Link layer to inform the Protocol layer how many bytes are required to populate the Link layer specific fields, such as link header, FEC, and CRC.

LinkStatus 消息中的 FlitFormat 字段由链路层用来通知协议层需要多少字节来填充链路层特定字段，例如链路头、FEC 和 CRC。

Table 9.2 shows the mapping of the FlitFormat values to the Protocol layer container format.

9.2.1.2. Link Power State

The Link Power State field in the LinkStatus message allows the Link layer to inform the protocol of the power state of the link. This information is sent to the Protocol layer during link initialization and also whenever there is a change in link power state.

LinkStatus 消息中的链路电源状态字段允许链路层向协议通知链路的电源状态。该信息在链路初始化期间以及每当链路电源状态发生变化时发送到协议层。

Table 9.3 shows the Link Power Status message fields.

10. Protocol layer property exchange

This chapter describes the exchange of properties for the Protocol layer.

本章描述协议层的属性交换。

10.1. Introduction

After the interface initialization is completed and the activation sequence requires a property exchange, interface properties must be communicated in both directions for each logical link before any protocol messages are sent.

在接口初始化完成并且激活序列需要属性交换之后，在发送任何协议消息之前，必须在每个逻辑链路的两个方向上传送接口属性。

A property is used to declare a capability.

属性用于声明功能。

The interface properties are grouped into three class i cations:

1. On-chip payload
   • Details either the presence or width, or both, of certain on-chip fields.
   • Allows for the optimization of the payload fields prior to the message selection, potentially allowing for more efficient packing.
2. On-chip opcode/flow
   • Details the on-chip support of certain class i cations of transactions.
   • Ensures that the interface does not deadlock by preventing unsupported messages being sent across the C2C link.
3. C2C specific
   • Details which specication release the interface supports, to ensure backward compatibility.
   • Provides additional information to assist with link usage.

接口属性分为三类：

1. 片上有效负载
   • 详细说明某些片上字段的存在或宽度或两者。
   • 允许在消息选择之前优化有效负载字段，从而可能实现更有效的打包。
2. 片上操作码/流程
   • 详细说明某些事务类别的片上支持。
   • 通过阻止通过 C2C 链路发送不受支持的消息来确保接口不会死锁。
3. C2C 特定网络
   • 详细说明接口支持哪些规范版本，以确保向后兼容性。
   • 提供附加信息以协助链接使用。

Both sides of the logical link send MiscU.Properties messages with an indication of their capabilities.

逻辑链路的双方都发送 MiscU.Properties 消息以及其功能的指示。

The property values in each Properties message are driven from a set of registers that define the capabilities of the chip sending the message.

每个属性消息中的属性值均由一组寄存器驱动，这些寄存器定义发送消息的芯片的功能。

There are certain properties that have Receiver, Rx, and Transmitter, Tx, variants:

• Property_Rx
  • This indicates the capability of the chip sending the Properties message as a Receiver. The Transmitter chip must be able to terminate any messages that the Receiver chip indicates it does not support.
• Property_Tx
  • This indicates the capability of the chip sending the Properties message as a Transmitter.

某些属性具有接收方 (Rx) 和发射方(Tx) 变体：

• Property_Rx
  • 这表明芯片作为接收器发送属性消息的能力。发送端芯片必须能够终止接收器芯片指示其不支持的任何消息。
• Property_Tx
  • 这表明芯片作为发送端发送属性消息的能力。

Awareness at the Receiver chip of what it could receive enables potential power optimizations.

接收方芯片了解其可以接收的内容可以实现潜在的功率优化。

Where there is no _Tx or _Rx extension, the property is classified as Uniform and applies to the interface in both directions.

如果没有 _Tx 或 _Rx 扩展，则该属性被归类为“统一”并适用于两个方向的接口。

It is permitted for software to update the register values prior to sending a Properties message to reduce the advertised capabilities of the interface.

允许软件在发送属性消息之前更新寄存器值，以减少接口的分发功能。

Upon receipt of a Properties message, the Receiver must compare each of the communicated properties against its own properties.

收到属性消息后，接收方必须将每个传送的属性与其自己的属性进行比较。

When the property values align, no modification of behavior is required.

当属性值一致时，不需要修改行为。

When the properties differ, the Transmitter is permitted to adapt its behavior accordingly. The required adaptation depends upon the property class i cation and the differences seen in the:

• On-chip payload
  • If the Transmitter, _Tx, property is True and the Receiver, _Rx, property is False, it is permitted, but not required, that the associated field value is zeroed prior to message selection and container packing.
  • If the Transmitter, _Tx, property is False and the Receiver, _Rx, property is True, it is required that the associated field value is zeroed prior to message selection and container packing.
  • If the Transmitter, _Tx, property is a larger value than the Receiver, _Rx, property, it is permitted, but not required, that the most significant bits that are not supported at the Receiver are zeroed at the Transmitter prior to message selection and container packing.
  • If the Transmitter, _Tx, property is a smaller value than the Receiver, _Rx, property, it is required that the associated field value is 0 extended at the Transmitter prior to message selection and container packing.
• On-chip opcode and flow
  • If the local Transmitter, _Tx, property is True and the Receiver, _Rx, property is False, the Transmitter must terminate or downgrade any associated on-chip message in an on-chip protocol-compliant manner. It is IMPLEMENTATION DEFINED how this downgrade or termination takes place.
  • If the Transmitter, _Tx, property is False and the Receiver, _Rx, property is True, there should be no further action required. The associated on-chip protocol messages should not be presented to the Transmitter for communication across the C2C link.
  • Optionally, if the Receiver, _Rx, property is True and the Transmitter, _Tx, property is False, the Receiver chip might be able to save power by turning off certain portions of logic.

Note For example: Downgrade includes converting a SnpUniqueStash to a SnpUnique, if the target chip does not support stashing but has a copy of the data that is needed to complete a transaction. Termination includes a Requester performing an Atomic transaction locally when it is established that there is no downstream atomic support. This might be achieved through the use of an on-chip BROADCAST ATOMIC signal on the Requester or an alternative control register.

例如：如果目标芯片不支持存储但具有完成事务所需的数据副本，则降级包括将 SnpUniqueStash 转换为 SnpUnique。终止包括当确定不存在下游原子支持时，请求者在本地执行原子事务。这可以通过在请求器上使用片上广播原子信号或替代控制寄存器来实现。

• C2C specific
  • If the Transmitter, _Tx, property is True and the Receiver, _Rx, property is False, the Transmitter must not use the associated feature or transaction flow.
  • If the Transmitter, _Tx, property is False and the Receiver, _Rx, property is True, the Receiver might be able to save power by turning off certain portions of logic.
  • If the Transmitter, _Tx, and Receiver, _Rx, properties have values other than True or False, and these values differ between both sides of the link, additional statements will describe the expected behavior.
  • If the Uniform properties on either side of the link do not match, additional statements will describe the expected behavior.

当属性不同时，发送方可以相应地调整其行为。所需的调整取决于属性类别以及以下方面的差异：

• 片上有效负载
  • 如果发送器 _Tx 属性为 True 并且接收器 _Rx 属性为 False，则允许（但不要求）在消息选择和容器打包之前将关联的字段值清零。
  • 如果发送器 _Tx 属性为 False 并且接收器 _Rx 属性为 True，则需要在消息选择和容器打包之前将关联字段值清零。
  • 如果发送器 _Tx 属性的值大于接收器 _Rx 属性的值，则允许（但不要求）在消息选择和容器之前将接收器不支持的最高有效位在发送器处清零包装。
  • 如果发送器 _Tx 属性的值小于接收器 _Rx 属性的值，则需要在消息选择和容器打包之前在发送器处将关联字段值扩展为 0。
• 片上操作码和流程
  • 如果本地发送器_Tx属性为True并且接收器_Rx属性为False，则发送器必须以片上协议兼容的方式终止或降级任何关联的片上消息。降级或终止的发生方式由实现定义。
  • 如果发送器\ _Tx 属性为 False，接收器 _Rx 属性为 True，则无需执行进一步操作。相关的片上协议消息不应呈现给发送器以通过 C2C 链路进行通信。
  • 或者，如果接收器 _Rx 属性为 True 并且发送器 _Tx 属性为 False，则接收器芯片可能能够通过关闭逻辑的某些部分来节省功耗。
• C2C 特定网络
  • 如果发送器 _Tx 属性为 True 并且接收器 _Rx 属性为 False，则发送器不得使用关联的功能或事务流。
  • 如果发送器 _Tx 属性为 False 并且接收器 _Rx 属性为 True，则接收器可能能够通过关闭逻辑的某些部分来节省电量。
  • 如果发送器 _Tx 和接收器 _Rx 属性具有 True 或 False 以外的值，并且这些值在链接两侧不同，则附加状态将描述预期行为。
  • 如果链接两侧的 Uniform 属性不匹配，则附加状态将描述预期行为。

The properties in opposing directions on a link can differ. That is, it may be possible that certain transactions can be initiated in one direction, but not the other.

链接上相反方向的属性可能不同。也就是说，某些事务可能可以在一个方向上启动，但不能在另一个方向上启动。

10.1.1. Properties message format

The MiscU.Properties field is used by the Protocol layers to exchange their supported property values with the remote Protocol layer.

协议层使用 MiscU.Properties 字段与远程协议层交换其支持的属性值。

Table 10.1 shows the Properties field encodings. See Table 10.11 for details of the Payload field.

10.2. On-chip payload properties

Table 10.2 lists the properties that are used to describe specific on-chip field payload characteristics of the chip as a Receiver.

Table 10.3 lists the properties that are used to describe specific on-chip field payload characteristics of the chip as a Transmitter.

10.3. On-chip opcode and flow properties

Table 10.4 lists the properties that are used to describe specific on-chip opcode and flow support of the chip as a Receiver.

Table 10.5 lists the properties that are used to describe specific on-chip opcode and flow support of the chip as a Transmitter.

10.4. C2C specific properties

This section describes C2C specific properties

本节描述 C2C 特定属性

10.4.1. Uniform properties

Table 10.6 lists the properties that are used to describe C2C specific capabilities that are uniform in both directions of the interface.

10.4.2. Receiver and Transmitter properties

Table 10.7 lists the properties that are used to describe C2C specific capabilities of the interface.

Table 10.8 lists the properties that are used to describe C2C specific capabilities of the interface as a Transmitter.

10.4.3. Expectations when exchanged C2C specific properties differ

Table 10.9 details the expected outcome when C2C specific properties differ between two sides of a link and those properties are:

• Uniform properties
• Transmitter, _Tx, and Receiver, _Rx, properties that have values other than True or False

表 10.9 详细说明了当链路两侧的 C2C 特定属性不同时的预期结果，这些属性是：

• 统一的特性
• 发送器 _Tx 和接收器 _Rx 属性的值不是 True 或 False

10.4.3.1. Container Format resolution

There are two parts to the determination of the container format that is used:

1. The two Protocol layers exchange the Container Format property to determine what options are available.
2. The container formats that can be supported at the Protocol layer are combined with the requirements of the FlitFormat needed by the Link layer.

确定所使用的容器格式有两个部分：

• 两个协议层交换容器格式属性以确定哪些选项可用。
• 协议层可以支持的容器格式与链路层所需的FlitFormat的要求相结合。

Table 10.10 shows how these two aspects are combined.

10.5. Property packing in MiscU.Properties message

Table 10.11 illustrates the packing of properties in the payload of MiscU.Properties message.

10.6. Property packing into registers

It is expected that each interface will have multiple sets of 64-bit registers that contain the properties for use during runtime. The defined sets of registers are detailed in Table 10.12.

预计每个接口将具有多组 64 位寄存器，其中包含运行时使用的属性。