sdp 协议翻译

SOC-15_Specification_Scalable_Data_port_(SDP)_Rev_1.5.0,_Nov_10,_2022_1.pdf

sdp 协议翻译

第1章 介绍

部分介绍了SDP （Scalable Data Port）架构。 这个介绍_以下部分中呈现：

• 1.1 概述 提供了架构的概述。
• 1.2 系统上下文 为架构建立了系统上下文。

1.1 概述

SDP架构定义了一个逻辑信令interface和协议，设备可以通过该协议交换数据和控制信息，包括各种命令和响应消息。 SDP还定义了链路级和分离的请求/响应事务级协议。

端口是该架构定义的信令接口，它允许独立设计的逻辑块（IP块）通过结构化的方式直接或通过通信网络（fabric）进行通信。 端口的定义包括所需信号的枚举和信令方案在链路级别的管理。

链路级协议提供了：

1. 用于特定类型请求/响应消息和数据传输的多个物理通道。
2. 于时钟速率匹配的简单同步接口，带有链路级握手信号。
3. 号数量与物理通道带宽需求之间的平衡。
4. 口请求/ack握手允许IP请求将接口激活到活动状态，或快速关闭时钟并节约功率。

事务级协议提供以下功能和优点：

1. 分离请求/响应消息提高了fabric带宽的利用率。
2. 每个事务标识tags支持在设备中为每个originator提供多个挂起的请求。
3. 支持不需要originator生成探测响应的缓存一致内存读写操作。
4. 支持一致和不一致的读写。
5. 支持PCIe协议。
6. 支持图形系统、x86和PCIe排序规则。
7. 原子内存操作。
8. 使用独立的基于credit的虚拟通道。
9. QOS服务质量提示。
10. 事务安全特权级别。

据通过请求/响应消息对进行传输。请求及其后续响应构成事务。

发起请求的设备称为“发起者”（originator）。 能够响应请求的设备称为“完成者”（completer）。 请求也称为命令。这些术语在本规范中可以互换使用。

端口定义了提供标准化附件方法的接口。 链路级协议定义了用于设备信息传输的信令模式，以及链路级传输握手协议。 由于扩展的数据端口专为芯片上应用设计，其中连接的IP块物理上靠近，因此接口相对宽泛，信令与SDP时钟同步。

当IP未直接点对点连接时，fabric 请求和响应消息在代理之间传递。 这样可以让IP块较少受到SOC时钟敏感性的影响，也不会受到SOC中的放置影响。 此外，IP块也可以与SoC专用时钟隔离，并解决测试确定性问题。 IP和SoC地面计划的物理实现选择将影响受此隔离影响的fabric的功率、面积和性能。

事务协议定义了可以由originator或通过fabric发出的请求，以及由fabric或completer发出的响应。 所有类型的请求都会返回给originator或fabric。响应通过fabric发送给originator，fabric作为completer的代理。 fabric内的消息流负责为所有缓存提供一致性控制。这允许包含缓存的IP块参与系统缓存一致性协议。

非一致协议是一致协议的子集，用于提高验证的便捷性。

SDP支持独立IP块设计和验证。链路级和事务级协议使得IP块能够将许多细节隔离，以处理一致和非一致数据的传输。 该架构为IP块之间的事务传输提供了清晰的分离。端口接口被清晰定义和标准化。 这允许端口接口逻辑由IP块自由使用。

1.2 系统上下文

图 1

SDP架构（可扩展数据端口架构），它旨在提供一个丰富的功能集，以支持完全缓存一致性系统的实现，并通过接口将多个设备连接到共享系统内存。

为了更好地说明SDP的全部功能，该系统被描述为一个包含发起设备和响应设备的缓存一致性系统。 图 1 中的“可扩展数据端口系统上下文”显示了各种交换信息的设备类型， 以及它们使用该架构所定义的协议进行通信的方式。

图 1 中展示的系统包含四种能够发起Transaction Request的设备（CPU Complex、GPU Complex、多媒体Complex 和PCI Host Bridge），以及三个可以成为请求目标的设备（PCI Host Bridge和两个系统内存区域）。 图中展示的PCI Host Bridge不仅可以发起请求，还能响应Transaction Request。内存设备通过单一端口连接到fabric（结构）， 而第二个带地址切片的系统内存模块被包含在图中，表示内存可以通过多个端口连接到fabric，以提供更高的数据传输带宽。

该系统将发起事务的设备称为发起设备（Originator Devices），这些设备通过发起端口连接到fabric。 发起设备可以进一步细分为一致性发起设备（Coherent Originator）和非一致性发起设备（Non-Coherent Originator）。 一致性发起设备发布可被缓存一致性机制识别的缓存感知命令（如RdBlk或VIcBlkFull）， 而非一致性发起设备虽然可以发出请求，但不参与缓存一致性协议。

专门响应请求的设备被称为完成设备（Completer Devices），这些设备通过完成端口连接到fabric。 系统内存模块和PCI Host Bridge的完成通道在图中以完成设备的形式出现。

架构并未明确规定fabric本身的拓扑结构，但基于假设，每个端口能够适当地满足请求，系统内存读取请求可以通过缓存中的数据副本来响应， 而不是直接从系统内存中获取数据。

连接到fabric的不同设备在系统中具有不同的角色，需要通过端口在fabric与设备之间传输不同类型的信息。 为了满足这一需求，SDP端口被定义为具有可选特性。特性提供特定的功能或能力。 当设备需要某个功能时，它必须实现为该特性定义的所有信号。例如，一些Originator不实现虚拟通道， 这些Originator不需要实现构成该特性的任何Field（如请求VC）。

SDP定义的所有特性都在 TODO 中进行了描述。

在 图 1 中，PCI主机桥的独特之处在于它既可以发起请求，又可以响应请求。 这样的设备通过一对端口连接到fabric，即一个Originator端口和一个Completer端口。

Originator通过发出读取或写入系统内存中目标位置的请求来启动一个事务。该请求通过Originator端口提交给fabric。 然后，fabric负责满足该请求，方法是访问内部缓存中的数据副本、在一致性域的某个缓存中找到请求的数据， 或读取或写入系统内存。作为该过程的一部分，fabric可能修改请求并生成自己的请求，以探测一致性域内的其他缓存。 fabric合并探测响应，并回复给Originator以完成事务。

该协议支持虚拟通道（VC），并允许Originator施加特定的VC内和VC间的顺序约束。

一个Originator可能包含多个功能unit。该协议通过为Originator内的每个请求者分配唯一的UnitID，支持每个功能unit的多个未完成请求。

允许事务乱序完成。事务tag使Originator能够将请求与后续的响应配对。读取和写入请求都需要响应。

每个设备都连接到fabric中的一个代理。 在 图 1 中，CM表示为一致性客户端（那些包含硬件一致性缓存的设备）代理的代理， nCM表示为非一致性客户端（那些不包含缓存或仅包含软件一致性缓存的设备）代理的代理，CS表示为需要保持硬件一致性的内存代理， 而nCS代理不需要一致性的内存请求。nCM+nCS的一个特殊用途是作为一个组合的I/O代理，如 图 1 所示。 fabric合并来自一致性域中系统缓存的探测响应，并通过一致性Originator端口向连接的Originator呈现单一结果。

本规范未定义请求和响应消息在fabric上各端口之间路由的机制。 为在设备之间可靠且安全地传递这些消息而需要的任何请求和响应消息的翻译、编码和封装，都由fabric的更低层处理，并在其他文档中进行了说明。

SDP架构识别并支持为缓存一致性内存访问指定一致性域。 每个Transaction Request都包括必须探测的缓存域的规范，作为缓存一致性内存读取或写入请求的副作用。并非所有域都适用于每个请求。

本规范的其余部分按以下主题组织：

• 第2章 端口定义 ：描述端口接口的物理方面。
• 第3章 事务层 ：描述事务级别的协议。

第2章 端口定义

端口定义指定了通道内每个Field的名称和用途、链路级协议对信号状态变化时序施加的约束，以及在特定Field宽度方面给予实现的自由度。

以下章节描述了SDP物理接口：

• 2.1 端口特性 ：定义了端口定义的一些可选特性。
• 2.2 接口信号 ：定义了构成SDP物理接口的Field。
• 2.3 端口参数化 ：定义了具有可变宽度的Field之间的依赖关系。
• 2.4 信号需求 ：描述了对信号以及这些信号状态转换时序的约束。
• 2.5 端口控制 ：描述了用于激活和断开接口的信令协议。

SDP由八个物理通道组成，每个通道可以有多个实例。每个通道实例在特定方向上传输特定类型的信息。 例如，请求通道从Originator通过接口向系统传递Transaction Request。

Transaction Request、Originator数据，以及读和写响应通道支持最多八个虚拟通道（VC）。 虚拟通道构建在物理通道之上，提供请求消息传递保证（用于防止死锁）并支持所需的排序规则。 每个实现了flow control的通道都包含一个专用的credit释放通道，在相反方向上传递flow control信息。 对于支持多个VC的通道，flow control是按虚拟通道进行的。

2.1 端口特性

SDP定义了以下特性：

Asynchronous Port Control Feature（异步端口控制特性）

当实现时，OrigClkReq、CompClkReq、OrigClkAck和CompClkAck与SdpClk是异步的。 这仅推荐用于对SDP端口在低时钟频率状态下重新连接延迟敏感的实现。

Byte Enable Compression Feature（字节使能压缩特性）

当实现时，Originator写/Probe数据通道实现一个单一的OrigDataBytEn，并改为在OrigData上携带字节使能。 参见 3.2.1字节使能压缩 。

支持Byte Enable Compression的实现可能不支持Metadata Compression。

Cache Tag Tracking Feature（缓存Tag跟踪特性）

当实现时，Originator在请求通道上提供缓存路和分配信息。 这使Completer能够使用“shadow tags”跟踪缓存的行以限制探测。 需要实现Probe Support Feature。需要ReqStWayId、ReqStUpdate和ReqStInvalidate。

Credit Count Feature（credit计数特性）

当实现时，允许端口一次返回多个credit。 需要实现 ReqCreditCnt、AckCreditCnt、RdRspCreditCnt、WrRspCreditCnt、PrbCreditCnt、PrbRspCreditCnt和OrigDataCreditCnt。 每个通道上credit计数的宽度和可用性是独立的。

Completer Fatal Error Notification Feature（Completer致命错误通知特性）

当实现时，允许Completer利用写响应通道（仅当未实现写响应通道时才使用读响应通道）以非请求（且无credit）的方式传递系统致命错误。

Data Compression Feature（数据压缩特性）

添加了四个新命令： VicBlkFullZero、VicBlkFullComp、WrSizedFullZero、WrSizedFullComp，以及一种压缩数据的方法。

Data Source Feature（数据源特性）

当实现时，Completer利用RdRspSrcData和/或WrRspSrcData来传达数据或响应的来源。 这两个Field可以独立实现，不要求SDP同时具有RdRspSrcData和WrRspSrcData。

Enhanced Port Control Feature（增强的端口控制特性）

需要实现OrigClkCtl和CompClkCtl信号。 该特性允许代理在完全断开连接后请求重新初始化credit。该特性还允许代理为单边或全边断开连接发送提示。

Enhanced RAS (V1, V2, V3) Feature（增强的RAS（版本1、2、3）特性）

增强的RAS分为三个版本，允许在不同Field上独立的奇偶校验。这三个版本可以独立实现，且无先决条件。

• 增强的RAS V1特性：需要实现 ReqParity、ReqAddrParity、RdRspParity、WrRspParity、AckParity、PrbParity、PrbRspParity和OrigDataMetaParityField。
• 增强的RAS V2特性：需要实现 RdRspDataStatusParityField。
• 增强的RAS V3特性：需要实现 ReqCreditParity、RdRspCreditParity、WrRspCreditParity和OrigDataCreditParityField。

External Last Layer Cache Support（外部最后一层缓存支持）

需要：ReqCacheHint（以前称为ReqNoAlloc）。

Floating Point Atomic Feature（浮点原子操作特性）

增强了Atomic*命令，包含了用于浮点原子操作的额外ReqAttr编码。

Heads-up Feature（预通知特性）

需要实现RdRspDataVld。没有该特性，N_lag必须为零。

I/O Stream Feature（I/O流特性）

需要：ReqStreamID。还必须实现ReqBlockLevel = 01b（Stream）。

I/O Space Feature（I/O空间特性）

需要：ReqIOField。

Low-Power Signaling Feature（低功耗信令特性）

需要实现*ClkEn_m1，用于使能时钟。在某些实现中，时钟使能可能通过OR逻辑组合在一起。

Metadata Compression Feature（元数据压缩特性）

需要实现ReqCompMode、ReqSpecDataFetch、RdRspDataCompMeta以及某些请求的额外属性编码。 对于压缩写入，OrigDataBytEn的使用也会发生变化。 参见 3.2.2 元数据压缩 。

支持Metadata Compression的实现可能不支持Byte Enable Compression。

Multiple Request Address Feature（多请求地址特性）

添加了ReqSubAddrField，指定了一些（但不是全部）地址位， 以便Originator可以将两个不同的地址组合成一个请求。

Multiple Cache Line Feature（多缓存行特性）

当实现时，Originator可以为多个缓存行（或单个缓存行）发出缓存读取命令，如ReqLen中指定。 实现可能会限制地址对齐和请求的缓存行数量。此特性不适用于缓存更新和缓存驱逐命令。

当未实现此特性时，所有缓存读取命令必须针对单个缓存行发出。

Ordered Cacheable Command（有序可缓存命令）

当实现时，Originator将所有块读取命令限制为仅RdBlkS， 并要求Completer对该可缓存命令和先前的WrSized*命令实现读后写排序。

Physical Channel Multiplexing Feature（物理通道复用特性）

需要实现ReqChanAB、ReqCreditChanAB、OrigDataChanAB和OrigDataCreditChanAB信号。

Posted Write Ordering Feature（posted写入排序特性）

需要实现ReqPassPW、ReqRspPassPW、RdRspPassPW、WrRspPassPW。

Probe Chain Feature（探测链特性）

需要实现rbChainField和Probe Support Feature的实现。

Probe Compression Feature（探测压缩特性）

需要实现rbCompType和PrbCompIndex，以及Probe Support Feature的实现。

Probe Interrupt Delivery Feature（探测中断传递特性）

该特性有两个版本。版本1添加了探测地址，可用于将向量中断传递给处理器线程。 版本2移除了第一组探测地址，添加了新地址，可用于将任何类型的向量和非向量中断传递给处理器线程。 版本2还增强了中断区域，允许处理器传递LVT，并添加了一个服务中区域，允许处理器确认先前传递的中断向量。 需要实现Probe Support Feature。

Probe Support Feature（探测支持特性）

需要实现探测请求和探测响应通道。 需要在Originator（写入/探测）数据通道上实现OrigDataChan和OrigDataPrbCreditRel。

Read Response Feature（读响应特性）

用于发出在读响应通道中响应的命令的Originator。需要实现读响应通道。仅当“只写”端口时才省略此特性。

Response Acknowledge Feature（响应确认特性）

需要实现响应确认通道的所有Field和ReqAckField。

Secure Transaction Feature（安全事务特性）

需要实现ReqSecLevel。

Trusted Memory Feature（可信内存特性）

需要实现ReqTMZ以及安全事务特性。

Variable Heads-up Feature（可变预通知特性）

需要RdRspDelayField。需要预通知特性作为先决条件。

Virtual Address Feature（虚拟地址特性）

需要实现ReqVirtAddr、ReqVfidValid、ReqVfid。

Virtual Channel Support Feature（虚拟通道支持特性）

需要实现 ReqVC、ReqCreditVC、ReqCreditType、RdRspVC、RdRspCreditType、RdRspCreditVC、 WrRspVC、WrRspCreditVC、WrRspCreditType、OrigDataVC、OrigDataCreditType、OrigDataCreditVC。

Write Response Feature（写响应特性）

用于发出在写响应通道中响应的命令的Originator。需要实现写响应通道。仅当“只读”端口时才省略此特性。

2.2 接口信号

图 2

本节描述了构成SDP接口的信号。

2.2.1 信号组

SDP接口被组织为以下组：

• Port Control信号
• Command / Request通道
• Data通道

在 图 2 中，标有“Originator”的模块代表发出命令（请求）的代理， “Completer”代表满足这些请求的代理。在典型的应用中，Originator并不直接连接到Completer，而是通过fabric间接连接。 在Originator端口，fabric作为Completer的代理；在Completer端口，fabric作为Originator的代理。

如 图 2 所示，物理通道可以组织为三组： 端口控制信号、命令/响应通道和数据通道。 共享名称并编码特定信息的一组信号称为Field。Field的大小属性表示构成该Field的信号数量。 Field内的信号根据二进制重要性编号。一个n位的Field由n-1到0的信号组成。

图 2 为每个模块显示了一个独立的时钟。 这些时钟信号由SOC逻辑提供。如果这些时钟在频率上不匹配且没有静态相位关系，则必须提供重新同步逻辑。同步逻辑已被考虑，但未具体规定。

注意，读响应和读响应数据通道共享相同的链路级握手信号，并在 Read Response Channel 中一起描述。

端口控制

每个端口包括两对端口控制信号。 这些信号允许连接的设备请求将端口提升到活动状态，或置于静止状态，以便设备过渡到时钟停止或电源门控状态。 端口控制状态转换也可以由端口发起。这些信号在 2.2.4 端口控制信号 中进行了描述。

命令/响应通道

命令和响应通道包含用于请求或确认数据和/或控制信息传输的Field。这些通道包括：

• 2.2.6 Originator Request Channel
• 2.2.7 Read Response Channel
• 2.2.8 Write Response Channel
• 2.2.9 Response Acknowledge Channel
• 2.2.10 Probe Request Channel
• 2.2.11 Probe Response Channel

Data Channels

数据通道用于在系统中从Originator到Completer或从Completer到Originator传输数据。这些通道包括：

• Originator (Write/Probe) Data Channel
• Read Response Channel

其他信号

每个端口接口都包括一个由SOC逻辑提供的时钟和复位信号。这些内容在 2.2.3 通用信号 中进行了描述。

端口接口上的所有信号都与公共时钟同步。 信号从接口一侧的寄存器发出，预期在接收端用于在接收寄存器中锁存信息的时钟边沿之前， 能够到达另一侧并有足够的时间被用于少量逻辑（可能导致Vld/Rdy的去使能，或将发送队列推进到下一个项目）。 在实际实现中，接口一侧提供一组信号的寄存器可能与接收信号的一侧处于不同的时钟域。 本规范未指定的一种机制会跟踪独立时钟之间的任何相位偏移并进行补偿。

端口信号

请参见 图 3 。 请注意，一个Originator设备通过称为Originator端口的接口连接到fabric， 一个Completer设备通过称为Completer端口的接口连接到fabric。 Completer端口是Originator端口的子集，因为Completer不需要与Originator相同的功能。

图 3

在Originator端口，Originator设备（或简称为Originator）驱动请求信号，而Originator端口接收请求信号。 Fabric要么直接满足请求，要么将请求路由到适当的Completer端口，在那里请求被呈现给Completer设备。

在Completer端口，端口发出请求信号，Completer设备接收这些信号。 Completer设备处理请求并生成响应。设备发出响应信号，端口接收它们。 由fabric路由回Originator的响应出现在Originator端口的响应物理通道上。 在Originator端口，端口发出响应信号，Originator接收这些信号。

在之后的小节中，表格列出了属于SDP接口每个通道的Field。 在这些表中，指定了originator端口中每个Field的驱动者。 因此，指定的驱动者要么是originator，要么是端口。 在completer端口，如果Field被实现，信息流向右的Field将由端口驱动，信息流向左的Field将由completer设备驱动。

可选Field根据它们支持的特性进行标识。未实现的可选Field的默认值为0，除非另有说明。

当originator和completer以点对点连接时，fabric消失，originator对completer设备看起来像一个completer端口。 反过来，completer看起来像一个originator端口。

2.2.2 在单个通道内增加带宽的方法

有多种方法可以利用单个端口来增加带宽。本节描述了这些方法并区分了它们的预期用例。请注意，这些方法是可互操作的，且一个SDP实现可能具有多个。

实现多个通道实例

一个实现可能提供单个通道类型的多个实例。例如，一个实现可能有两个originator请求通道和三个读响应通道。 当引用这些通道和通道中的所有Field时，它们分别标记为“A”、“B”、“C”等，例如可能有一个“Request Channel A”，具有FieldReqAVld、ReqAVc（等等）， 然后可能有一个“Request Channel B”，具有FieldReqBVld、ReqBVc（等等），依此类推，直到实现的数量（A-Z）。 当给定类型只有一个通道时，“A”是多余的，可以省略。在本规范中，Field名称始终被使用，好像只有一个通道，为了简单起见，省略了“A”。 没有要求端口对每种通道类型具有相同数量的实例。

在本规范中，当提及所有实例化的通道整体时，通道名首字母大写（“Originator Request Channel”）， 例如指代credit或Tag，假定讨论的主题可能发生在任何实例化的通道上。 当指代单个实例时，通道名不大写（“originator request channel”或“originator request channel A”）， 例如指代在originator request channel的某个实例上出现的请求。

给定通道的所有实例共享credits、Tags和UnitID编码。 在不同通道类型的实例之间没有必需的关联关系。 例如，在“originator request channel A”上的请求可能使用最初在“originator request channel B”上（从completer）传输的credit。 此外，该请求的响应然后可能由completer在“read response channel C”上传输。

给定通道的多个实例在所有排序目的上使用它们的字母编号被视为“时分复用”的。 也就是说，在“originator request channel B”上某个周期出现的请求被认为比同一周期在“originator request channel A”上（如果有有效请求）传输的任何请求更晚传输， 并被认为比在“originator request channels C”到最后一个originator request channel实例上（如果有有效请求）传输的任何请求更早传输。 如果两个请求之间没有必需的排序，例如它们在不同的VC中，那么这种时分复用关系就无关紧要。

通道类型的所有Field在每个实例中都被复制，包括*ClkEn_m1、*Vld和*Rdy信号。 为了确保维护时分复用的排序关系，任何端口延迟或时钟交叉实现必须在所有实例之间相同。 如果originator request channel A的ReqRdy信号在一个周期内未激活，而originator request channel B的ReqRdy信号在该周期内激活， 那么时分复用的排序要求可能被违反。因此，*Rdy信号，虽然独立实例化并可能独立生成，必须最终彼此完全相同，无论最初是否有必需的排序关系。

每个通道实例都有独立的*ClkEn_m1实例，允许端口独立地对一个或多个实例进行时钟门控。 没有要求较高命名的端口在较低命名的端口之前或之后被时钟门控。 例如，“originator request channel A”可能被时钟门控，而“originator request channel B”可能正在传输请求。 当一个实例在周期x上取消置位ClkEn_m1时，假定端口的另一侧可能在周期x+1将该通道实例视为Vld=0，这在每个实例上独立发生。

无论实现了多少通道以及每种通道类型的实例数量，对于单个端口只有一组端口控制信号。

多个通道实例的预期目的是在较低的时钟速率下支持更高的带宽。 具有两个实例的端口可以被认为其操作就像SDPClk的频率是原来的两倍，一个实例在偶数时钟周期传输第一个通道实例，第二个实例在奇数时钟周期传输。

物理通道复用特性

物理通道复用特性允许两个独立的completer实体共享单个SDP用于所有数据传输， 尽管该特性（在规范的未来版本中）可能允许独立的originator实体和/或将数量扩展到两个以上。 要求originator知道两个completer实体，并为每一个跟踪单独的credits。 例如，在ReqCreditChanAB=0（子通道A）上返回的credit只能用于断言ReqChanAB=0的请求。 originator必须有一种方法在两个子通道之间进行选择，例如通过对请求地址进行哈希。实际方法超出了本规范的范围。

物理通道多路复用特性的预期目的是两个completer总是与单个originator通信时共享线路（SDP端口），例如逻辑上是单个内存通道的两个子通道。

2.2.3 通用信号

表 2 通用信号 列出了通用信号组的信号。

表 2 通用信号

SdpClk的上升沿决定了接口上传输信息的时序。 一般来说，所有信号在SdpClk的上升沿之前和紧接之后都必须保持稳定。 实际上，端口接口两侧的寄存器可能位于不同的时钟域中。 *Rdy用于确保发射器的时钟有效边沿相对于接收器的有效边沿之间有足够的时间。

SdpReset_N是一个负有效信号（即，当信号的电压水平为低时，信号被置位），并且可以在任何时间被置位。 有关与SdpReset_相关的信令要求的更多信息，请参见 2.4 信号需求。

2.2.4 端口控制信号

每个端口提供了两对请求/确认信号，允许Originator或Completer请求将端口提升到其正常的活动状态， 或者，一旦端口处于正常的活动状态，请求将端口降级并逻辑上断开连接。 在断开连接的状态下，接口之间没有信息交换。所有*Vld信号都是非活动的，所有物理通道Field都被忽略。 这允许一个或两个代理进入低功耗的时钟停止或电源门控状态。增强的端口控制特性增加了第三对信号，用于提供关于连接或断开请求的更多信息。

表3 端口控制信号列出了端口控制信号。

标有“Required”（必需）的列指示了哪个可选特性需要实现此Field。“Yes”表示所有实现都需要该特性。标有“Driver”（驱动者）的列指示了在Originator端口上信号的方向。

表 3 端口控制信号

SDP接口由多个单向物理通道组成。 例如，一个一致性的Originator在Originator Request、Originator (Write/Probe) Data、Response Acknowledge和Probe Response Channels上担任发送者的角色。 在Read Response（包括读取数据）、Write Response和Probe Request Channels上，它担任接收者的角色。 作为Completer代理的端口在每个通道上具有互补的角色。

虽然接口由多个物理通道组成，但为Originator（或在Completer端口上的端口）提供了一个单一的信号， 用于请求接口的激活（OrigClkReq），以及为端口（或Completer）提供了一个单一的信号来发出此请求（CompClkReq）。 信号CompClkAck（由接口的Completer侧驱动）和OrigClkAck（由Originator侧驱动）用于完成将端口带入其活动操作模式所需的握手协议。 在初始化协议完成时，所有四个信号都处于其活动状态。这表明接口处于正常的活动状态。

OrigClkReq

Originator（或在Completer端口上的port）置位OrigClkReq以请求将端口接口提升到活动状态。 该信号在端口处于其正常活动操作模式时必须保持激活。 当通过置位CompClkAck得到确认时，端口（或在Completer端口上的Completer）已准备好在其所有入站通道上接收信息。 Originator（或在Completer端口上的port）取消置位该信号以请求断开端口。 断开请求由端口（或在Completer端口上的Completer）通过取消置位CompClkAck信号来确认。

CompClkAck

由port（或在completer端口上的completer）置位，以响应OrigClkReq，指示port（completer）已准备好在相应的物理通道上主动接收入站的命令、数据或流控制credit。

CompClkReq

port（或在completer端口上的completer）置位CompClkReq，以请求将端口接口提升到活动状态。 在端口处于其正常活动操作模式时，该信号必须保持激活。 当收到OrigClkAck的置位确认时，port（或在originator端口上的originator）已准备好在其所有入站通道上接收信息。 port（或在completer端口上的completer）取消置位该信号以请求断开端口。 断开请求由originator（或在completer端口上的port）通过取消置位OrigClkAck信号来确认。

OrigClkAck

由originator（或在completer端口上的port）置位，以响应CompClkReq，指示completer已准备好在相应的物理通道上主动接收入站的命令、数据或流控制credit。

OrigClkCtl

当检测到OrigClkReq信号的转换时，port（或在completer端口上的completer）可以对该信号进行采样。 originator（或在completer端口上的port）在置位OrigClkReq之前置位此信号， 以请求port（completer）为originator（port）的使用流控制的出站通道发出（或重新发出）流控制credit。 originator在置位OrigClkReq之前取消置位此信号，以明确请求completer不发出这些credit。 在连接请求得到port（或在completer端口上的completer）的确认之前，该信号的状态必须保持稳定。

如果originator（或在completer端口上的port）请求完全断开连接，则在取消置位OrigClkReq之前置位此信号。 如果请求临时（单向）断开连接，则在取消置位OrigClkReq之前取消置位此信号。 在断开请求得到port（或在completer端口上的completer）的确认之前，该信号的状态必须保持稳定。

一些SDP端口实现可能通过固件或复位序列等替代方式处理流控制credit，并且可能仅使用OrigClkReq来指示完全断开连接。

CompClkCtl

当检测到CompClkReq信号的转换时，originator（或在completer端口上的port）可以对该信号进行采样。 port（或在completer端口上的completer）在置位CompClkReq之前置位此信号， 以请求originator（或在completer端口上的port）为port（completer）的使用流控制的出站通道发出（或重新发出）流控制credit。 port在置位CompClkReq之前取消置位此信号，以明确请求originator（port）不发出这些credit。

如果port（或在completer端口上的completer）请求完全断开连接，则在取消置位CompClkReq之前置位此信号。 如果请求临时（单向）断开连接，则在取消置位CompClkReq之前取消置位此信号。 在断开请求得到originator（或在completer端口上的port）的确认之前，该信号的状态必须保持稳定。

一些SDP端口实现可能通过固件或复位序列等替代方式处理流控制credit，并且可能仅使用CompClkReq来指示完全断开连接。

关于连接和断开端口的协议细节在 端口控制 中讨论。

端口控制信号的同步要求

当端口实现异步端口控制特性时，OrigClkReq、CompClkReq、OrigClkAck和CompClkAck的置位和取消置位可能与SdpClk异步。 接收逻辑有责任在IP时钟域内使用一个或多个锁存器或其他方法对信号进行采样，以防止亚稳态。 当只有端口的一侧实现了异步端口控制特性时，端口之间需要广泛逻辑，以在异步到同步方向上同步信号。

2.2.5 通道之间的关系

作为本规范其他部分的总结，本规范对通道类型之间要求以下关系：

• 除了Cancel、QosControl和ErrEvent请求包，以及SYSFATALERR响应外，代理不得在没有由其他代理发出足够credit的情况下，发出请求、探测、响应或数据包。 不消耗credit的命令或响应例外。

• 对于一个请求，在它已经在Request Channel上发出了对应的请求之前，不得在originator数据通道上发送该请求的数据。 数据只能在与请求同时的周期或更晚的周期发送。

• 对于一个探测响应的数据，在originator探测数据通道上，originator必须在已在探测响应通道上发出对应的探测响应之后，才能发送数据。 数据只能在与探测响应同时的周期或更晚的周期出现。

• 除了针对SYSFATALERR的“非请求”响应外，completer不得在接收到Request Channel上的请求（由ReqTag和ReqUnitID匹配）之前提供响应。 此外，当请求包含数据时，completer不得在接收到Originator Data Channel上所有数据节拍之前，为该请求发出响应。 特定请求无关的“非请求”响应例外。

• 在完成端口控制握手之前，代理不得在任何通道上传输任何信息，包括credits或请求/响应/探测/数据包。

本规范还要求以下通道之间的死锁避免要求：

• Originator必须能够处理探测请求，返回适当的credit，并提供响应和数据（如果有），而无需completer对未完成的请求提供读或写响应的任何要求。

• Originator必须能够处理探测请求，返回适当的credit，并提供响应和数据（如果有），而无需completer提供请求通道credits或断言ReqRdy的任何要求。

• 实现Response Acknowledge Feature的originator必须能够在completer已经发出完成后，发出响应确认， 而不需要除在Response Acknowledge Channel上拥有credit之外的任何依赖。

• 一旦originator发出了请求，它必须能够处理（或“接收”）响应，包括返回读或写响应credit，而无需completer处理任何其他命令的任何要求， 包括但不限于其他victims或写入。该要求也可以表述为：在发出可能在读响应通道上提供数据的命令时，originator必须有一个缓冲区来消耗读取的数据， 而不依赖于completer处理其他请求，包括victims或写入。只要originator有一种无依赖的方法来接收读响应，则此缓冲区不必在请求时被宣告为读响应credit。

2.2.6 originator request channel

Originator使用Originator请求通道来请求将数据写入或从系统内存空间读取数据。 表 4 Originator请求通道信号 列出了构成Originator请求通道的信号。

标记为Required的列指示了哪个可选特性要求实现该Field。“Yes”表示所有实现都需要该特性。

标记为Driver的列指示了在Originator端口中Field内的信息流方向。

表 4 Originator请求通道信号

Originator设备使用Originator请求通道来启动与系统内存空间之间的数据传输。 请求的数据量以及传输类型由地址指示。可以请求的最小数据量是一个双字。 携带信息的物理通道（RdRspData或OrigData）的数据Field大小以内的数据可以在一个时钟周期（一个节拍）内传输。 更大量的数据以一系列节拍（一个突发）的形式传输。 有关数据如何在接口上传输的讨论，请参见 3.2 数据传输 。

Originator请求通道的Field在以下章节中进一步描述。

ReqTag

此Field标识由Originator设备的特定功能unit（由其UnitID标识）发起的每个未完成请求。Originator的每个unit都被分配自己独立的一组Tag。

在接收到响应的最后一拍（没有RETRANSMIT或EARLY）之前，每个功能unit不得重用一个ReqTag。 当响应头和响应数据之间存在延迟时，如果响应头中的信息允许功能unit预测响应数据状态将不会是RETRANSMIT，而无需等待数据，那么功能unit也可以重用ReqTag。 除了Cancel命令外，当一个请求没有响应（如QosControl、SpecDramRd和ErrEvent）时，ReqTag Field是无意义的。

对于需要Originator明确确认的事务，在Originator通过响应确认通道发送与请求相同的unitID（AckUnitID）和Tag（AckTag）的响应确认之前，这些事务并未完成。 但是，Originator可以在发送响应确认之前重用Tag，前提是并且仅当它承诺发送此确认时，除了Response Acknowledge credit和AckRdy之外没有任何依赖； 并且仅当它承诺按照接收响应的顺序发送重复Tag的响应确认。 有关响应确认通道信号的更多信息，请参见 2.2.9 响应确认通道 。 表 40 命令 指出了哪些命令需要Originator的确认。

ReqAddr

对于非缓存读取、原子操作和写入（包括WrNoDataNC），此Field提供正在访问的数据的字节地址，或者，在系统管理命令的情况下，提供管理功能的更多细节。

对于缓存读取、缓存升级、缓存驱逐和缓存维护命令，ReqAddr提供正在访问的数据的缓存行地址。 缓存行地址以下的ReqAddr位不使用，通常保留。 然而，对于缓存读取和ChgToX，ReqAddr指定请求的对齐缓存块内的关键字节。如果可能，包含关键字节的节拍应在其他节拍之前传输。

始终执行n字节对齐操作的接口可以省略位[log2n-1:0]。ReqAddr[1:0]始终是可选的。地址是小端序的。

ReqSubAddr

在本节中，寻址缓存行大小一半的地址位将被称为地址位“x”（即在具有64字节缓存行的实现中，x是第5位）。 此外，本节将引用一个“ReqAddr2”，可以通过ReqAddr和ReqSubAddr之间的算术操作确定，尽管ReqAddr2不是SDP端口上的一个Field。

当实现了多请求地址特性，并且ReqSubAddr非零时，事务由一个单一的合并SDP请求中的两个具有不同地址的独立逻辑事务组成。 除了地址外，这两个逻辑事务的所有其他Field（例如ReqCmd、ReqAttr、ReqSecLevel、ReqVC等）必须相同。 然后，Completer访问这两个独立的地址，并返回响应和数据（对于读取）给两个地址。

多请求地址特性的目的是优化在Completer使用两个子通道一起操作以执行缓存行大小访问的系统。 在这些实现中，每当Originator进行子缓存行大小的请求时，Completer带宽的使用效率就会降低。 为了恢复带宽，Originator可以指定两个独立的半缓存行大小的请求——一个使用ReqAddr用于第一个子通道，另一个使用ReqSubAddr用于第二个子通道。 Originator必须确保ReqAddr映射到第一个子通道，ReqAddr2（第二个地址）映射到第二个子通道。 如果不是这种情况，可能会发生不可预知的结果。通常，这需要Originator具有一个地址位选择子通道的映射。

Completer通过以下XOR操作创建ReqAddr2：

• ReqAddr2[x:0] 基于子通道选择逻辑隐含确定。
• 对于在ReqSubAddr中指定的地址位，ReqAddr2[n] = ReqAddr ^ ReqSubAddr。
• 对于未在ReqSubAddr中指定的地址位（除了特定的x之外），ReqAddr2 = ReqAddr。

由于只有某些地址位在两个逻辑事务之间可能不同，Field ReqSubAddr的宽度与ReqAddr不同。 此外，指定的地址位可能不是连续的。 例如，ReqSubAddr[0]可能映射到地址位7，ReqSubAddr[1]可能映射到地址位9。 在创建ReqAddr2的XOR操作期间，Completer假定所有未实现的位为零，除了地址位“x”，它未被指定但被适当地设置以选择另一个子通道。 哪些地址位在ReqSubAddr中指定以及ReqSubAddr[a]到ReqAddr[b]的映射是实现相关的。 通常，预计Originator和Completer会有配置位来指定ReqSubAddr到ReqAddr位的这种映射。 注意，在事务中ReqAddr[x]不一定为零，因为ReqAddr[x]可能是选择两个子通道之间的位之一。 如果不考虑多请求地址特性，这会导致SDP事务似乎跨越一个缓存行。ReqSubAddr中的非零值表明正在访问两个独立的缓存行。

在以下情况下，ReqSubAddr是保留的，且必须为零：

• 缓存读取（RdBlk*）、缓存驱逐命令（VicBlk*）、SpecDramRd和缓存升级命令。
• 对于ReqLen不等于缓存行长度的非缓存请求。
• 当ReqIO=1或ReqSpecialAddr=1时。
• 取决于实现，对于一致性读取或写入。在本规范发布时，没有SOC-15实现允许一致性请求使用ReqSubAddr。
• 取决于实现，对于原子命令。在本规范发布时，没有SOC-15实现允许原子请求使用ReqSubAddr。
• WrNoDataNC。

当ReqAddr Field保留或被忽略时（例如Fence、Flush、ErrEvent、QosControl），则ReqSubAddr也是保留的，且必须为零。

虽然两个逻辑请求的长度都是缓存行的一半，但在SDP端口上的合并请求和ReqLen是一个缓存行（即，对于具有64字节缓存行的实现，ReqLen为0xF）。

Completer始终在一个单一的读取完成或写入完成中返回响应。 数据根据子通道进行寻址——最低有效数据字节（从0到缓存行大小的一半减1）用于第一个事务和第一个子通道（ReqAddr）。 最高有效字节（从缓存行大小的一半到缓存行大小减1）用于第二个事务和第二个子通道（ReqAddr2），无论ReqAddr[x]的值如何。 由于可能有多个地址位用于选择子通道，用于事务数据的字节通道可能不是Originator进行两个独立事务时使用的字节通道。

对两个地址中的任何一个的错误都会导致整个事务出错。Completer遵循所有其他规则，包括排序，就像这些请求是两个独立的请求一样。

ReqSpecialAddr 和 ReqIO

ReqSpecialAddr 和 ReqIO 用于确定地址的编码。 当 ReqAddr 是物理地址（ReqVirtAddr=0 或不存在虚拟地址特性）时，地址可能被编码为“系统或设备/本地内存”、“IO 内存”，或者可能被编码为系统管理功能。 Fields ReqSpecialAddr 和 ReqIO 确定地址类型，如表5 ReqIO 和 ReqSpecialAddr 编码所示。 当端口需要访问物理地址空间末尾12GB区域之外的系统消息时，必须使用 ReqSpecialAddr。否则，“系统内存”地址限制为 2^ReqAddr 大小减去 12GB。

在适配器上，“IO 内存”也包括“主机内存”（所有不在适配器上的内存）。“系统内存”和“IO 内存”的确切含义可能取决于系统。

对于 CPU Originator，I/O 空间特性（ReqIO）允许使用 x86 架构特性，其中物理地址可以动态地映射到 I/O 或系统内存空间。 预计这种动态映射不会在非 x86 实现中出现。

表5 ReqIO 和 ReqSpecialAddr 编码

表5 ReqIO 和 ReqSpecialAddr 编码

注意：

1. 当端口上未实例化 ReqSpecialAddr 或 ReqVirtAddr 时，Field 被视为零。

2. 当未实例化 ReqSpecialAddr 时，所有系统消息都通过解码地址来识别。如果未实例化 ReqSpecialAddr，则只能使用系统管理的最后 12GB 中的系统地址。

ReqLen

此 Field 指定要传输的双字数量。指示的transfer Size为 (ReqLen + 1)。 此大小可以小于用于传输数据的读响应或 Originator 数据通道的 *Data Field 的宽度。此 Field（Nrl）的宽度是实现相关的。

对于所有具有写语义但没有数据负载的命令，如 VicBlkCln、WrNoDataNC、Fence、Flush，以及缓存维护命令（如 WbInvBlkAll），ReqLen Field 保留。 对于这些命令，ReqLen Field 必须设置为 0。

对于在缓存块上操作的命令，例如缓存读取（RdBlk*）、缓存升级（ChgToX、ChgToXNR、ValBlk）、除 VicBlkCln 之外的缓存驱逐命令（VicBlkFull*、VicBlkClnD、VicBlkPtl），以及缓存维护命令（ClnBlkAll、WbInvBlkAll 和 InvBlkAll），ReqLen 预计指示缓存块的大小。

ReqAck

大多数请求定义了此 Field 的值，但对于不需要在先前请求之后排序的请求，某些请求允许可选地将其清除。 有关使用响应确认特性的命令的定义，请参见 3.10 命令 。

ReqAttr

提供关于事务请求的特定属性信息。编码取决于请求的类型，如以下表格所示。对于本节未包含的任何命令，ReqAttr 保留。 ReqAttr 中所有保留位必须为零。

表6 WrSized、WrSizedFull、WrSizedFullZero、WrSizedFullComp 和缓存读取请求的 ReqAttr 用法

Steering Tag

• Steering Tag 是对系统中某组件（如缓存）的指示或提示，数据可能被定向（写入）或来源（读取）于此。
• Steering Tag 的编码超出了本文档的范围。
• 建议使用 0000000b 表示“无特定的 Steering Tag”， 此情况下，Completer 或 Fabric 可使用实现特定的算法来选择数据定向的组件。 在这种用例中，Steering=1 仅表示 Completer 或 Fabric 可能希望定向数据。

Prefetch Hint

• 00b = 无Prefetch Hint
• 01b、10b、11b = 保留

Cache State（仅适用于 WrSized/WrSizedFull/WrSizedFullZero/WrSizedFullComp），指示一致性 Originator 的Cache State：

• 0xb = 未知或任意；可能对 Originator 进行探测。
• 10b = 已知无效或无关；不会对 Originator 进行探测。
• 11b = 共享；不会对 Originator 进行探测。此编码适用于 Originator 已经更新其缓存的写直达缓存。

transfer Size

• 00b = 保留
• 01b = 半大小压缩——即当 ReqLen=0xF 时实际发送 32 个压缩字节，当 ReqLen=0x7 时发送 16 个压缩字节。注意：当使用字节使能压缩时，如果任何节拍用于传输字节使能，transfer Size不变。
• 1xb = 保留

Metadata Compression

• 00b = 写数据未压缩。ReqLen 指示未压缩数据的大小。
• 01b = 写数据已压缩。未压缩长度为 128B（ReqLen 指示压缩数据的大小）。
• 10b = 写数据已压缩。未压缩长度为 256B（ReqLen 指示压缩数据的大小）。
• 11b = 保留

如果未实现 Metadata Compression 特性，对于 WrSized* 命令，ReqAttr 的Metadata Compression Field 保留，且必须为 00b。参见 MetaData Compression。

Storing Probe Fetch

• 0b = 此缓存读取不是存储探测的结果。 Completer 不会对这些缓存读取使用 RdRspStatus=OKAY_NODATA 进行响应。
• 1b = 此缓存读取是在存储探测导致 CPU 获取该行后生成的结果。 Completer 在某些情况下可能返回 RdRspStatus=OKAY_NODATA。

表 7 ChgToX、ChgToXNR、ValBlk 请求的 ReqAttr 用法

Cache State指示一致性 Originator 的Cache State：

• 0xb = 未知或任意；可能对 Originator 进行探测。
• 10b = 已知无效或无关；不会对 Originator 进行探测。
• 11b = 共享或已拥有；不会对 Originator 进行探测（当使用此编码时，Originator 必须正确维护Cache State）。

**表 8 RdSized、RdSizedNC 的 ReqAttr 用法 **

注意：如果读取比请求的字节数更多，对于没有副作用的情况（如 DRAM 读取），Completer 可能会忽略字节使能。

**表 9 原子请求的 ReqAttr 用法 **

表 10 WrSizedNC 的 ReqAttr 用法

表 11 Victim Block 的 ReqAttr 用法

表12 ErrEvent 的 ReqAttr 用法

ReqQosForward

此字段的编码如 表 表13 ReqQosForward 编码所示 。

表 13 ReqQosForward 编码

Fabric 可以选择升级比必要更多的请求，以简化升级的跟踪。 实现 QoS 特性的端口实现可以将其作为在 Originator 请求通道上指示当前请求优先级的方法，而不需要任何优先级转发。 在这种情况下，Originator 始终将 ReqQosForward=00b。允许的实现可以完全不实例化 ReqQosForward 字段，并将其视为 ReqQosForward == 00b。

表 14 AddrXlateRdSz 和 AddrXlateWrSz 的 ReqAttr 用法

表 15 SpecPrefCmd 的 ReqAttr 用法

ReqCmd

此字段指示此请求的命令。有关命令列表及其编码，请参见 3.6 命令 。 当 ReqCmd[5] 为 1b 时，Originator 还必须在 Originator 数据通道上传输数据。 除了 Originator 请求通道的流控制外，还必须根据通道流控制中定义，获得一个或多个 Originator（写入/探测）数据通道的 credit。 参见 3.4 通道流控制

**ReqDomain **

此信号指示请求的可共享域。每个一致性 Originator 端口都表现为单个缓存实体，无论其背后有多少缓存或缓存级别。此字段的编码如 *表 16 ReqDomain 编码*所示。

表 16 ReqDomain 编码*

可共享域用于在仅有一部分 Originator（将参与同一域）已知正在使用内存区域时，限制维持一致性所需的探测事务的范围和数量。 例如，这可以用于允许一组多媒体处理器使用缓存一致的访问方式访问特定的内存区域，同时将探测限制为仅针对与该处理器组关联的缓存。

ReqUnitID

请求者unit ID。标识发起事务的 Originator 内的unit。对于来自 CPU 的请求，ReqUnitID 标识发出请求的线程。 这用于线程特定的寄存器访问（如 MSR 和 APIC 空间）、安全检查和调试。

ReqStreamID

标识 ReqUnitID 内的特定有序流。

ReqSecLevel

指示请求的安全特权级别。

ReqPassPW

当 ReqVC 指定一个 posted 或 non-posted 虚拟通道（在上行或下行方向）时，ReqPassPW 指定（当为 0 时）此请求必须与先前的 posted 写入（无论地址或目的地）保持顺序。 有关更多信息，请参见 3.7 排序 。

在“上行”方向上，ReqPassPW 顺序仅在上行事务到达 PCIe 接口后建立，如果上行 posted 和 non-posted 虚拟通道是分开的，则在 Fabric 内不会建立。 Fabric 将该位作为有效载荷传递给 PCIe 接口。对于所有其他虚拟通道，此位保留，但建议为这些事务设置该位（由于不同的虚拟通道，它们将能够通过 posted 写入）。

ReqBlockLevel

指示此请求在同一虚拟通道内阻塞在早期请求后面所需的匹配级别。

此字段的编码如 表 17 ReqBlockLevel 编码 所示。

表 17 ReqBlockLevel 编码

ReqRspPassPW

当 ReqVC 指定一个 non-posted 虚拟通道（在上行或下行方向）时，ReqRspPassPW 指定（当为 0 时）对此请求的响应不得通过与响应流向相同方向的 posted 写入。有关更多信息，请参见 Ordering。

此位对于所有其他虚拟通道是保留的，但建议为这些事务设置该位（因为它们的响应将能够通过 posted 写入）。

ReqVC

指定请求的虚拟通道。参见 3.3 虚拟通道部分。

ReqChain

可选字段，提供一个提示，指示应将同一 VC 中的后续请求分组在一起以进行路由。

ReqStWayId ReqStUpdate ReqStInvalidate

在为了限制探测而拥有 Originator 缓存的“影子标签”的实现中，Fields ReqStWayId、ReqStUpdate、ReqStInvalidate 共同指示 Originator 的缓存和替换算法。 然后，Completer 更新影子标签，以维护所有正在一致性缓存的缓存行的准确状态。这些影子标签用于将探测限制为仅针对已知在 Originator 缓存中的缓存行。尽管这些影子标签应该准确地限制探测，但 Originator 不得将接收到未命中缓存的探测视为错误。

实现注意：要求 Originator 和 Completer 共享相同的算法，该算法基于 ReqAddr 选择索引，因为 SDP 上未指定索引。

表 18 缓存Tag跟踪 指定了这些位的含义以及它们如何与此事务引起的预期缓存分配或失效相关。

对于所有非一致性命令（RdSizedNC、WrSizedNC、AtomicNC*），这些字段是保留的，且 ReqStUpdate 和 ReqStInvalidate 应为 00b。

**表 18 缓存Tag跟踪 **

注意：

1）ReqStUpdate 和 ReqStInvalidate 的其他组合是保留的。

ReqCacheHint（ReqNoAlloc）

此字段为读取、写入、Victim 和原子操作提供时间性提示。当 ReqIO=1 或 ReqSpecialAddr=1 时，此字段保留。

表 19 ReqCacheHint 用法

在先前的规范中，ReqCacheHint 被命名为 ReqNoAlloc，且为单个位。通过设置 ReqCacheHint[1]=0b 且 ReqCacheHint[0]=ReqNoAlloc，可以将 ReqNoAlloc 扩展为 ReqCacheHint。

ReqCompMode

此字段为Metadata Compression指定请求的压缩模式。

**表 20 ReqCompMode 用法 **

ReqSpecDataFetch

此字段向 Completer 提供一个提示，指示在压缩元数据的内容已知之前，是否应预取内存块。此字段对非缓存读取、写入、原子操作和缓存读取有效。对于所有其他命令，此字段保留（00b）。

**表 21 ReqSpecDataFetch 用法 **

ReqVld

此信号指示 Originator 在此通道上提供了有效信息。

ReqCreditType

当 ReqCreditType = 1 时，正在释放的 credit 是一个池 credit，可用于任何虚拟通道中的请求。 当 ReqCreditType = 0 时，正在释放的 credit 是特定 VC 的 credit。有关 credits 和流控制的更多信息，请参见 3.4 通道流控制 。

ReqCreditVC

指定正在释放的 credit 的虚拟通道。仅当 ReqCreditType = 0 时有效。

ReqCreditVld

当 ReqCreditVld 断言时，端口（或在 Completer 端口，Completer）正在释放一个或多个 credits。 当实现时，ReqCreditCnt、ReqCreditType、ReqCreditVC 和 ReqCreditChanAB 提供有关正在释放的 credits 的类型和数量的信息。 当未实现任何可选的 ReqCredit* 字段时，每当在活动时钟边沿断言此信号时，都会释放一个 Originator 请求通道 credit。

ReqUser

可选信号，可用于任何目的。信息流必须与通道的方向相同。ReqUser 位不会自动复制到响应中。

2.2.7 Read Response Channel

Read Response Channel(s) 为特定的读请求提供读取请求的 meta-data、完成状态和响应数据。 此外，如果实现了 Completer Fatal Error Notification Feature 且未实现 Write Response Channel， Completer 还可能发送一个未关联到任何未完成请求的 RdRspStatus=SYSFATALERR 的非请求读响应。 有关更多信息，请参阅*3.12.4 sing Response Channels for Unsolicited Fatal Errors*。

Read Response Channel 基于特定的预告间隔，在随后的时钟周期开始提供请求的数据。 请参阅 3.2 Data Transfer

数据在一个或多个数据传输周期（也称为 beats）中通过 RdRspData Field 返回。 响应根据 RdRspUnitID 和 RdRspTag Fields 中的信息与引发它的请求进行匹配。 对于一个读响应要对应于一个读请求，响应的 RdRspUnitID 必须与请求的 UnitID 匹配，RdRspTag 必须与 ReqTag 匹配。

表 22 Read Response Channel Signals 列出了构成 Read Response Channel 的信号。所有的信号名称都采用单通道接口的命名约定。

标记为 Required 的列指示了哪个可选 feature 要求实现该 field。 “Yes” 表示所有实现都需要该 feature。 如果 Originator 未实现 Read Response feature 且未发出任何生成读响应的命令（仅写接口）， 则整个 Read Response Channel 是可选的。

标记为 Driver 的列指示了在 Originator port 中 field 内的信息流方向。

表 22 Read Response Channel Signals

注意：

1. 在 Completer 端口由 Completer 设备驱动；在 Originator 端口不支持。

2. 在 Completer 端口由 port 驱动；在 Originator 端口不支持。

RdRspData

此 Field 的大小依赖于实现，但必须是 8 的整数倍且不大于系统缓存行大小。 此 Field 相对于读响应滞后 N_lag 个周期。更多细节请参见 3.2 Data Transfer。

RdRspStatus

RdRspStatus 同时提供读响应的成功/失败指示，此外还可能指示缓存状态。

RdRspStatus 的宽度可以是 3、4 或 6 位，具体取决于实现并在端口参数化（N_rdstat）中指定。 所需的宽度取决于发出的命令类型和端口类型：

• 如果端口可能发出缓存读取或缓存更新请求（RdBlk*、ChgToX* 等），则 N_rdstat 必须为六位。
  • 仅发出 RdBlkS 作为唯一缓存读取且不发出任何缓存更新请求的端口不受此规则限制。
• 如果端口使用 AddrXlateRd 命令，或者端口具有可能传达完成超时或配置请求重试的 PCI 附件，则 N_rdstat 必须至少为四位。
• 所有其他实现要求 N_rdstat 至少为三位。

总体的读响应完成状态由 RdRspStatus[3:0] 提供，同时也指示任何失败的原因。 然而，当发出缓存读取命令时，RdRspStatus[5:3] 用于编码缓存状态，而 RdRspStatus[2:0] 指示读响应完成状态。 当 RdRspStatus[3] 编码为缓存状态时，只有 RdRspStatus[2:0] 指示读响应完成失败，并且应将 表 23 解释为 RdRspStatus[3] 为零。

RdRspStatus[3:0] 的编码如表 23 所示。

表23 RdRspStatus[3:0] 编码

实现注意：CMPTO 和 CRS 仅保留用于连接到 PCI 的 SDP 端口。SOC-15 数据 Fabric 不返回 CMPTO 或 CRS。

EARLY 表示请求数据的系统范围缓存行的合并状态尚未确定，返回的数据可能是过时的。 随后将跟随第二个 Read Response，带有新的数据或无数据（NODATA），以更新合并的系统状态信息。 对 EARLY 读响应特性的支持是可选的，originator 并不需要支持它。

对于未以错误响应（RdRspStatus[2:0] = OKAY 或 OKAY_NODATA）结束的缓存读取或缓存更新命令（RdBlk*、ChgToX*），RdRspStatus[3] = PassDirty， RdRspStatus[5:4] 返回请求缓存行的合并系统状态，编码如 表 24 RdRspStatus[5:3] Encoding 所示。 除非使用了探测 originator 的命令，否则系统状态不包括 originator 的缓存状态。 对于缓存读取和缓存更新命令以外的任何命令的响应，系统状态和 PassDirty 位没有意义，对于在 RdRspStatus[2:0] 中指示错误的任何响应也是如此。 例如，以保护违规结束的 RdBlkL 并未探测同级缓存。当 RdRspStatus[2:0] 指示错误时，期望 originator 不缓存该行。

对于非缓存读取命令（RdSized*）和 AddrXlateRd，RdRspStatus[3] 用于编码上述表格中显示的扩展状态（最后 8 行）。 CMPTO 和 CRS 编码仅用于直接连接到 PCI 主桥的端口。

对于不发出缓存读取或缓存升级命令（非一致性 originators）且未连接到 PCI 主桥的端口，RdRspStatus[5:3] 保留。 对于不发出缓存读取或缓存升级命令（非一致性 originators）且连接到 PCI 主桥的端口，RdRspStatus[5:4] 保留。 建议这些端口使用配置参数 N_rdstat 仅实例化必要的位。

表 24 RdRspStatus[5:3] Encoding

RdRspDataStatus

此 field 提供通过 RdRspData field 在端口接口上呈现的数据的信息。 此 field 相对于读响应滞后 N_lag 个周期（与 RdRspData 同步有效）。 此 field 的编码在 表 25 RdRspDataStatus Encoding 中定义。

表 25 RdRspDataStatus Encoding

RdRspOffset

读取数据在 RdRspData field 中以一个或多个称为 beats 的传输周期返回给 originator。 每个 beat 按照内存中数据的顺序，从 0 开始顺序分配编号，直到 n-1；n 是传输请求数据所需的 beats 总数。 当传输需要多个 beat 时，completer 可以以不同于顺序的顺序返回 beats。此 field 提供与此响应对应的 beat 的编号。

Beat 0（RdRspOffset = 0）将始终包含请求数据有效载荷的初始（最低地址）字节。 对于 RdSized* 命令，初始地址是读取请求的 ReqAddr field 中提供的值。 对于 RdBlk* 命令，completer 将返回包含请求数据的缓存块。因此，beat 0 的初始（最低地址）是对 ReqAddr 进行系统缓存行大小对齐的值。

在时钟 x 上返回的 RdRspOffset field 的值是将在未来周期 x + N_lag 中在 RdRspData* fields 中呈现的 beat 的偏移量。

Read Response Credit Release Sub-channel

当 RdRspCreditVld 断言时，originator（或在 completer 端口上的 port）正在释放一个或多个 credits。 当实现时，RdRspCreditCnt、RdRspCreditType 和 RdRspCreditVC 提供有关正在释放的 credits 的类型和数量的信息。 一个 credit 表示一个读响应数据块的缓冲区空间。 读响应数据块大小依赖于实现，但必须是 RdRspData field 大小的字节数的 2 的幂倍数，且不超过系统缓存行大小。 有关通道流控制的信息，请参见 3.2 Data Transfer 。

2.2.8 Write Response Channel

Write Response Channel(s) 向写请求的发起者提供反馈，指示请求在目标处的结果和完成情况。 Responses 根据发起者的 UnitID 和请求 tag 与请求进行匹配。

表 26 Write Response Channel Signals 列出了构成 Write Response Channel 的信号。 此外，如果实现了 Completer Fatal Error Notification Feature， completer 还可能发送一个未关联到任何未完成请求的 WrRspStatus=SYSFATALERR 的非请求写响应。 有关更多信息，请参阅“Using the Write Response Channel for Unsolicited Fatal Errors”。

标记为 Required 的列指示了哪个可选 feature 要求实现该 field。“Yes” 表示所有实现都需要该 feature。如果 originator 未实现 Write Response feature，且未发出任何生成写响应的命令（只读接口），则整个 Write Response Channel 是可选的。

标记为 Driver 的列指示了在 originator port 中 field 内的信息流方向。

表 26 Write Response Channel Signals

注意：

1. 在 completer port 由 completer 设备驱动；在 originator port 不支持。

2. 在 completer port 由 port 驱动；在 originator port 不支持。

WrRspStatus

表 27 WrRspStatus Encoding

Completer（或 completer proxy）在接收到与此请求关联的所有数据之前，不得生成除 EARLY 之外任何状态的写响应。

对于 WrSized*，EARLY 响应并不表示最终响应将具有“正常完成”。事务可能会以错误结束，例如由于在探测期间观察到的事务错误。 EARLY 响应仅表示不再需要跟踪它以进行错误报告和/或排序。对 EARLY 写响应特性的支持是可选的，originator 并不需要支持它。

对于未连接到 PCI 主桥的非一致性 originator port，WrRspStatus[3] 保留。

Write Response Credit Release Sub-channel

当 WrRspCreditVld 断言时，originator（或在 completer port 由 port）正在释放一个或多个 credits。 当实现时，WrRspCreditCnt、WrRspCreditType 和 WrRspCreditVC 提供有关正在释放的 credits 的类型和数量的信息。有关通道流控制的信息，请参见 3.2 数据传输 。

2.2.9 Response Acknowledge Channel

Response Acknowledge Channel(s) 被 Originator 用于向 Fabric 指示它已提交了指定事务的结果。 如果未收到没有 EARLY 或 RETRANSMIT 状态的响应的最后一个 beat，则不能发送响应确认。 对于带有 NODATA 的响应，在接收到具有 RdRspStatus=OKAY_NODATA 的读取响应后，任何时候都可以发送响应确认。 Originator 不需要等待 NODATA 的滞后的 RdRspDataStatus。对于发出需要响应确认请求的 Originator，此通道是必需的。Completer 端口不包含此通道。

表 28 Response Acknowledge Channel Signals 列出了构成 Response Acknowledge Channel 的信号。

表 28 Response Acknowledge Channel Signals

2.2.10 Probe Request Channel

探测请求通道由 Fabric 用于向一致性 Originator 发送探测请求和其他系统消息，包括每个一致性 Originator 后面的多个探测单元（probe unit）。 一个一致性探测单元表现为两个独立的一致性 Originator，其中 ReqUnitID 中的一个配置位指定探测单元。 这些探测单元共享一个探测请求、探测响应和 Originator 数据通道，但具有独立的 PrbVld 和 PrbRspVld 信号。 由于逻辑上只有一个探测单元可以对单个探测请求返回数据，因此只有一个 OrigDataVld 信号。

Fabric 生成探测请求，作为满足 Originator 发起的一致性读或写请求的一部分。 探测请求通道还用于向能够处理这些消息的处理器发送系统消息，例如分布式虚拟内存（DVM）和系统事件（中断）。 对于包含参与系统缓存一致性协议的缓存或处理系统消息的 Originator，此通道是必需的。 Completer 端口不包含此通道。

表 29 Probe Request Channel Signals 列出了构成探测请求通道的信号。

探测请求通道可以选择性地支持额外的 Probe Compression Feature（探测压缩特性）。有关更多信息，请参见 Probe Compression Feature 。

表 29 Probe Request Channel Signals

PrbAddr

在不支持 DVM / 系统消息的系统中，PrbAddr 的宽度由系统支持的物理地址大小决定。 所有支持 DVM 的 Originator 都需要实现 表 83 DVM Field Assignments 中指定的 PrbAddr 位。 为支持 DVM 所需的任何附加位在内存一致性探测中设置为零。 所有支持存储探测（引导事务）的 Originator 都需要实现 <a href="#表 51 存储探测 PrbAddr 用法">表 51 存储探测 PrbAddr 用法*/a>* 中指定的 PrbAddr 位。 所有支持系统消息的 Originator 都需要实现 3.10 系统消息 中指定的 PrbAddr 位。 不支持 DVM、系统消息和存储探测的 Originator 不需要实现 PrbAddr[5:2]。 PrbAddr[1:0] 保留，未实现。对于某些 DVM 和系统消息，PrbAddr 字段可能采用 3.10 系统消息 中描述的修改编码。

PrbAction

指定探测请求的缓存行状态的预期更改、DVM / 系统管理消息，以及/或是否需要探测响应。 高两位（PrbAction[3:2]）指示它是一个一致性探测还是 DVM 操作或系统消息。 当 PrbAction 为 1001b 至 10011b 时，PrbAddr 被解码以确定系统管理消息。

请参见 表 30 PrbAction 编码 。

表 30 PrbAction 编码

PrbRD

表 31 PrbRD 编码

PrbChain

此字段仅用于 DVMOpMsg 探测数据包（PrbAction 为 1000b），并指示必须一起处理的 DVM 数据包对中的第一个。 PrbChain 对于所有一致性和其他系统管理探测数据包都是保留的（必须为零）。

DVMOpMsg 将消息的元数据放置在 PrbAddr 字段中，但它包含的数据比单个 PrbAddr 字段所能容纳的更多，因此消息分布在两个探测数据包中。

当在探测链上收到 PrbChain=1 的数据包时，Originator 应保留 PrbAddr，直到在探测请求通道上收到具有相同 PrbAction 为 1000b 的第二个（后续）数据包。 第二个数据包的 PrbChain=0，除了 PrbAddr 之外的其他字段（如 PrbTag）相同。 对于 DVMOpMsg 探测数据包，PrbRD 保留，且在两个数据包中都必须为零。

收到第二个数据包（PrbAction=1000b 且 PrbChain=0）后，Originator 将两个 PrbAddr 字段组合为一个 DVMOpMsg，如 DVM Operations 中所述。 在这两个数据包之间，可能会有其他一致性或系统管理探测数据包，但不能有：

1. DVMSync 消息。
2. 另一个 PrbChain=1 的 DVMOpMsg。此情况特别保留，以防将来的规范变体需要三或更多探测数据包来处理某些 DVM 操作消息。
3. SysMgmtJoin 消息。
4. 或者 SysMgmtLeave 消息。

DVMOp 消息中的两个探测数据包使用单独的信用，具有独立的分配。在探测请求通道上接受 DVMOpMsg 的客户端必须要么发送至少两个信用，要么释放第一个信用（在单独的缓冲区中保留 PrbAddr），以便第二个数据包可以被传递。

有关更多信息，请参见 DVM Operations *。

Probe Compression Feature

探测压缩特性要求双方（Originator 和端口 / Fabric）实现一个包含 2^Nct 个条目的“探测压缩表”。每个条目可以容纳 PrbAddr[n:16]，其中 n 由 Npa 指定（PrbAddr 中的最高物理地址位）。该表由探测压缩索引（当 PrbCompType=01b 时在 PrbCompIndex 中指定）进行索引。当 PrbCompType=10b 时，有两个压缩索引——一个（PrbCompIndex0）在 PrbCompIndex0 中指定，另一个（PrbCompIndex1）在 PrbAddr 中指定。如果未断言任何 PrbVld 信号，PrbCompType 被忽略，操作方式如同 PrbCompType=00b。所有系统管理消息必须指定 PrbCompType=00b。

PrbCompType 的编码如 表32 PrbCompType 编码 所示。

表 32 PrbCompType 编码

端口（或 Fabric）控制表的加载，一旦通过 PrbCompType=01b 加载后，可以使用 PrbCompType=10b 在一个 SDP 事务中发送两个压缩探测。在压缩探测中，由于探测地址的高位从探测压缩表中指定，这释放了 PrbAddr 的部分空间，用于保存这两个探测中第二个探测所使用的 PrbAction、PrbTag、PrbRD 和 PrbCompIndex 的单独副本。

探测压缩特性不改变 SDP 信用处理。当 PrbCompType 指定两个压缩探测（10b）时，即使在一个事务中有两个探测，该事务仍然消耗一个探测信用。探测压缩特性也不改变探测响应通道。除了使用单个探测信用外，每个压缩探测都是独立的，必须以两个唯一的响应进行响应。对于这两个探测的响应顺序，没有任何特定的要求。

端口指定未先前加载的 PrbCompIndex 值的压缩探测是非法的。探测表重置为所有条目均无效的状态，直到加载后才能使用。此外，Originator 可能在电源管理事件期间清除探测压缩表。通知端口 Originator 已经历电源管理的方法超出了本规范的范围。

所有系统管理探测消息必须指定 PrbCompType=00b。探测压缩特性仅可用于内存一致性探测（当 PrbAction != 10xx 时）。

2.2.11 Probe Response Channel

OrigDataChan字段指示数据是写数据还是探测响应数据。表34列出了构成发起者数据通道的信号。由于写数据和探测响应数据的传输必须独立，因此在描述其中一个数据流时，可能会提到“发起者写数据通道”或“发起者探测数据通道”。

表 Originator (Write/Probe) Data Channel Signals

注释：

1. 在Completer端口由端口驱动；在发起者端口不支持。

2. 在Completer端口由Completer驱动；在发起者端口不支持。

OrigDataOffset

要写入的数据在一个或多个称为节拍（beats）的周期中从发起者传输到OrigData字段中。每个节拍根据内存中数据的顺序，从0开始顺序编号，直到n-1；n是传输要写入的数据所需的节拍总数。当传输需要多个节拍时，允许发起者以不同于顺序的顺序传输节拍。此字段提供当前传输周期中正在呈现的节拍编号。

节拍0（OrigDataOffset = 0）将始终包含数据有效载荷的初始（最低地址）字节。

对于双操作数矢量原子操作，第二个操作数数据的OrigDataOffset相对于内存地址加上操作数的大小。

信用释放子通道

每当在有效边沿断言OrigDataCreditVld信号时，都会释放一个或多个数据信用。OrigDataCreditCnt、OrigDataPrbCreditRel、OrigDataCreditType和OrigDataCreditVC字段指定信用的类型和数量，如下表所示。当未实现任何可选的OrigData*Credit*字段时，每当在有效时钟边沿断言OrigDataCreditVld信号时，都会释放一个写数据信用。

要求返回探测响应数据的发起者必须为探测响应数据保留至少一个池信用，以防止死锁。

表 34 Originator (Write/Probe) Data Credit Type

2.3 端口参数化

Scalable Data Port 架构允许对各种 Field 宽度进行参数化，以支持不同的应用和实现。许多参数是独立的，但并非全部。必须匹配的 Field 宽度共享相同的参数名称。例如，ReqTag 的位数必须与 RdRspTag 的位数相同。该值由名为 Nrt 的变量表示。

表 36 Port Field Widths 列出了所有端口参数以及这些参数适用的 Fields。

表 36 Port Field Widths

注意： 表中未包含表示用户定义 Field 宽度的参数。用户定义 Field 的宽度根据应用程序确定。

2.4 信号需求

图 4 Port Interface Valid and Ready Signaling 概述了 SDP 接口的信令要求。

图 4

每当 Originator 或 Completer 设备或其连接的 Port 的 *ClkAck 信号被断言时，它必须准备好接收所有已断言 *Rdy 的入站通道上的信息。信息在接口的源端呈现，并传输到接收端的锁存器中。

源端通过断言其 *Vld 信号来指示命令和数据信号在接口上是稳定的，接收端通过断言其 *Rdy 信号来指示它已准备好接收命令和数据信息。如果 Port 实现了 Low-Power Signaling 功能，源端还必须在任何断言 *Vld 的周期之前至少一个周期断言相应的 *ClkEn_m1 信号。传输发生在 *Vld 和 *Rdy 都为高电平的时钟上升沿。*Rdy 可以由实际的 Originator 或 Completer 驱动，或者可以由实际的 Originator 或 Completer 模块之外的普适逻辑断言以执行时钟同步，在这种情况下，可以忽略来自 Port 的任何 *Rdy 信号，并且 Port 必须在连接时始终准备就绪。一旦源端断言了 *Vld 信号，除非 Port 复位（SdpReset_N 的去断言），否则不应在观察到 *Rdy 之前取消断言它。

当源端未断言其 *Vld 信号时，该 Port 上的所有命令和数据信息都是无效的，必须被忽略。例如，不要求 ReqCmd 具有有效的编码，或者奇偶校验信号与数据一致。除了 Port Control 信号（*ClkReq、*ClkAck、*ClkCtl）和 SdpReset_N 的去断言外，SDP 接口上的所有信号都与系统普适逻辑提供的公共时钟（SdpClk）同步。预期源逻辑切换和信号传播时间应使得到下一个时钟上升沿有足够的时间裕量，以允许接收端接口上的简单组合逻辑。该逻辑可以执行诸如在数据/控制信息被锁存之前取消断言 *Rdy 或推进队列指针等功能。在一些高频实现中，*Rdy 信号也可以通过使用名为 Nrdy_shift 的 Port 参数，以整数个时钟周期提前提供。每个 *Rdy 信号将被替换或复制为信号 *Rdy_m<Nrdy_shift>，以指示该信号被流水线了该数量的时钟。

请注意，接口接收端的逻辑块可以通过取消断言或延迟断言其 *Rdy 信号来阻止传输。这提供了一定程度的链路级节奏控制。然而，接收端逻辑不能使其 *Rdy 信号的断言取决于源端逻辑对 *Vld 信号的断言，或取决于其处理或缓存传入数据或命令信息的能力。这种节奏控制由更高级别的基于 Credit 的协议提供。 图 5 Port Interface Reset Requirements 提供了关于接口初始化的信息。

图 5

端口（或系统）复位信号 SdpReset_N 是一个负有效信号，用于初始化接口逻辑。预期在一次复位事件中不会保留任何状态信息。任何已建立的 Credit 都会被复位，任何未完成的事务都会被中止且不会收到响应。

虽然 SdpReset_N 的断言（负跳变沿）与 SdpClk 是异步的，但 SdpReset_N 的去断言（上升沿）必须与时钟同步。

当 SdpReset_N 处于活动状态时，*Vld 和 *Rdy 以及端口控制 *ClkReq 和 *ClkAck 信号必须处于非活动（低）状态。其他信号的状态为“不关心（don’t care）”。接口上不会发生任何数据传输。

在复位之后，*ClkReq 信号必须保持非活动状态，直到 SdpReset_N 去断言后的第一个 SdpClk 上升沿之后。在此时，提供端口控制 *ClkReq 信号的逻辑块可以开始端口激活。*ClkAck 通常仅在观察到互补的 *ClkReq 信号断言后才会断言。

接收器逻辑块可以使用 *Rdy 信号指示其接收信息的准备状态。即使在 *ClkAck 之前，*Rdy 信号也可以断言，尽管在 *ClkAck 和 *Rdy 都被断言之前，通道无法接收信息。

**实现注意：**当端口涉及时钟跨越边界时，接收逻辑可能会在第一个时钟之前，甚至在它观察到复位去断言之前，观察到 *ClkReq 被断言，尽管源逻辑可能不会在其从复位中恢复后的第一个时钟之前断言。这可能发生，例如，当 *ClkReq 是一个异步信号时，端口两侧的频率差导致，或者由于超出本规范范围的时钟或复位结构的实际差异所致。接收器不应依赖于在复位后实际观察到输入的 *ClkReq 上的边沿。

2.5 端口控制

SDP 提供了信号，允许端口以有序的序列进入活动状态或过渡到断开状态，从而消除可能破坏接口上信息传输的竞争条件。握手协议可以由接口两侧的状态机协调，或者直接由 SOC 级逻辑和/或管理固件协调。

在以下图表和讨论中，“originator”指的是在 Originator Port 的 originator 设备，或在 Completer Port 中作为 originator 代理的 Fabric 内的代理。“Completer”指的是在 Completer Port 的 completer 设备，或在 Originator Port 中作为 completer 代理的 Fabric 内的代理。

Port Control 使用四个信号：OrigClkReq、OrigClkAck、CompClkReq 和 CompClkAck。增强的 Port Control 增加了两个额外的信号：OrigClkCtl 和 CompClkCtl。

Originator 使用 OrigClkReq 来请求其出站通道的连接或断开。Completer 使用 CompClkAck 来确认 Originator 的请求。仅当 OrigClkReq 和 CompClkAck 都被断言时，Originator 到 Completer 的方向才处于活动状态，包括流控制 credits 在内的信息才能从 Originator 传递到 Completer（使用 *Vld 和 *Rdy 握手协议）。即使 Completer 到 Originator 的方向尚未（或尚未）激活，信息也可能从 Originator 流向 Completer。

Completer 使用 CompClkReq 来请求其出站通道的连接或断开。Originator 使用 OrigClkAck 来确认 Completer 的请求。仅当 CompClkReq 和 OrigClkAck 都被断言时，Completer 到 Originator 的方向才处于活动状态，包括流控制 credits 在内的信息才能从 Completer 传递到 Originator（使用 *Vld 和 *Rdy 握手协议）。即使 Originator 到 Completer 的方向尚未（或尚未）激活，信息也可能从 Completer 流向 Originator。

当两个方向都处于活动状态时（所有四个信号，*ClkReq 和 *ClkAck 都被断言），端口处于活动状态。

在下文中，本节将 Originator 或 Completer 称为 “agent”，并使用 *ClkReq 和 *ClkAck 来泛化端口的两侧。

促使 agent 启动激活、重新连接或断开连接的条件超出了本规范的范围。在某些情况下，这可能涉及外部固件操作，可能取决于有关端口连接或断开是否发生的配置信息。

2.5.1 Activating or Reconnecting the Port

为了使序列继续进行，端口需要被激活并且时钟保持同步。任意一个非发起的 agent 都可以通过延迟 *ClkAck 响应或推迟其 *ClkReq 的断言来阻止连接的完成。在断言 *ClkAck 之前，确认的 agent 必须准备好锁存由请求 agent 在其任何出站通道上提供的有效信息。一旦请求设备断言 *ClkReq，它必须在收到确认（即 *ClkAck 的断言）之前保持该信号的断言。

由于事务的流动要求首先通过相反方向的信息流动来建立信用，因此每一方都需要连接端口。Completer 可以等待 Originator 首先建立连接，或者两方可以独立地激活/重新连接。Originator 等待 Completer 首先建立连接是不合法的。

图 6 Originator-Initiated Activation 展示了在从完全断开（或重置）状态下发起的激活握手协议的断言序列。
图 7 Completer-Initiated Activation 展示了在从完全断开（或重置）状态下由 Completer 发起的激活握手协议的断言序列。

图 6

图 7

2.5.2 Disconnecting the Port – One-sided Disconnect

单向断开表示发起 agent 已请求断开连接（通过取消断言 *ClkReq），并且非发起 agent 已确认请求（通过取消断言 *ClkAck），但尚未通过取消断言其 *ClkReq 来做出回应。

在单向断开状态下，发起 agent 无法断言 *Vld 或在任何其出站通道上提供信息（包括其入站通道的信用释放子通道）。此要求从 *ClkReq 取消断言时开始。发起 agent 必须保持准备状态，以接收其入站通道上的信息，包括其出站通道的信用释放子通道的信息。

发起 agent 无法关闭任何接收信息所需逻辑的电源或时钟，包括用于追踪从接收方在出站通道的信用释放子通道上接收到的信用数量的逻辑。

非发起 agent（继续保持其 *ClkReq 活跃）可以继续通过其出站通道发送信息，包括其入站通道的信用释放子通道，但可以关闭接收信息所需逻辑的时钟，包括接收其出站通道信用释放子通道的信息逻辑。

非发起 agent 可以通过延迟其 *ClkAck 取消断言响应来推迟对发起 agent 的断开请求的确认，但不能无限期地推迟。这个延迟可能是为了清空时钟同步 FIFO 或管道寄存器，但将此确认依赖于接收信用或完成未决事务或探测是非法的。这样的依赖关系将导致死锁，因为发起 agent 可能必须在重新断言 *ClkReq 后才能发送此信息，并且发起 agent 在观察到非发起 agent 取消断言 *ClkAck 之前无法重新断言 *ClkReq，这是非法的。

根据物理连接的实现，发起或确认 agent 可能有责任等待一个指定的时间，以便端口上最后发送的信息能够通过任何可能被断开连接影响的时钟同步逻辑。实现必须建立规则，如最小时钟数，以确保信息不会被滞留在两侧之间的任何同步逻辑中。这些规则超出了本文件的范围。

实现注释：对于具有电压域跨越接口（VDCI）的 SOC-15 端口，在 VDCI 对所有通道上的 *_Empty 信号断言之前，延迟取消断言 *ClkReq 或 *ClkAck。

总线在单向断开之前可能已被静默，也可能未被静默，而端口的断开过程可以在响应、确认和/或信用返回尚未完成的情况下继续进行。在单向断开期间，端口的状态不会改变。所有未完成的事务和信用保持不变，仿佛端口仍处于连接状态。

完成单向断开的 agent 保留在断开请求被确认后任何时候通过重新断言 *ClkReq 发起重新连接的权利。发起 agent 必须在有信息要发送时重新连接，包括流控制信用。发起 agent 可以在重新连接之前设定一个时间限制（滞后），但不得对重新连接之前必须发送的信用数量设定阈值。

在某些情况下，端口的两侧可能独立或甚至同时经历单向断开。最终结果是，端口处于完全断开状态，唯一的例外是端口可能没有完全静默（可能仍有未完成的事务或信用）。

2.5.3 Disconnecting the Port – Full Disconnect

完全断开意味着接口的两侧都请求断开连接，通过取消断言各自的 *ClkReq 信号，并且双方都已确认这些请求。在完全断开的状态下，OrigClkReq、CompClkReq、OrigClkAck 和 CompClkAck 都是非活动的。所有 *Vld 信号都是非活动的，所有通道信息字段都被忽略。在此状态下，单方或双方的 agent 可以被电源或时钟门控。

为了实现电源管理，端口在完全断开之前，所有的请求、探测、响应、确认和流控流量必须静默。新的请求必须停止，所有的响应必须返回给请求者。流控制信用的发出或返回必须被静默或暂停。一旦所有信息流被停止，断开的握手可以由任一方发起。本规范假设断开是由发起方发起的，这在大多数情况下是更自然的，因为通常是发起方掌握哪些事务可能未完成，并且了解未来可能会有更多事务。

端口两侧处于完全断开状态时，具有与发起单向断开相同的要求，即在 *ClkReq 被取消断言后停止信息流、确认 *ClkReq、等待任何同步逻辑等。

非发起 agent 不一定需要通过取消断言 *ClkReq 来回应断开请求。SOC 级别的硬件和/或固件（不在本规范的范围内）可能使发起 agent 知道对方会回应。若非发起 agent 确实回应且发起 agent 确认断开，则端口被视为完全断开。

与单向断开一样，端口的状态预计会在完全断开期间保持。为了简化状态的维护，需要静默所有请求、探测、响应和流控流量。如果端口的其中一侧或两侧在断开期间被电源门控，agent 必须在重新连接之前重新初始化或恢复端口的状态。用于恢复电源门控后状态的方法不在本规范的范围内。实现增强端口控制功能的 agent 可以选择在完全断开后不重新初始化信用，并要求重新发送信用。如果未明确要求重新发送信用，或者未实现增强端口控制功能，agent 必须恢复断开之前对方给出的信用数量和类型。

图 8 Originator-Initiated Full Disconnect 显示了在断开握手协议由发起方发起的情况下的断开序列。图 9 Completer-Initiated Full Disconnect 显示了在断开握手协议由接收方发起的情况下的断开序列。

图 8

图 9

2.5.4 Enhanced Port Control Feature

增强端口控制功能添加了两个信号，OrigClkCtl 和 CompClkCtl，它们在端口连接和断开过程中都使用。

增强端口控制功能还提供了一种方式，通过该方式，断开的发起 agent 可以请求完全断开或单向断开。完全断开请求是一种提示，表示发起 agent 已准备进入电源门控状态，并将在一段时间内不请求重新连接。

Connection with the Enhanced Port Control Feature

增强端口控制功能提供了一种方式，使得发起方和/或接收方可以显式地请求对方在完全断开后重新连接时重新发出（或重新发放）流控信用。代理也可以显式请求在断开后不重新发放流控信用（如果代理没有丢失断开之前已释放的信用）。

为了与增强端口控制功能正常工作，从完全断开后重新连接的第一个 agent 可能需要等待另一侧建立连接后，才能发出信用。

如果不支持增强端口控制功能，则在连接过程中所需的任何流控信用初始化必须通过本规范范围之外的方式提供。

图 10 增强激活协议 显示了在激活由发起方发起的情况下的增强端口激活序列。

图 10

Disconnect

发起方使用 OrigClkCtl 信号请求接收方为其出站通道发放（或重新发放）流控信用，或者请求接收方不为其出站通道发放（或重新发放）流控信用。发起方通过在断开请求（OrigClkReq）之前断言 OrigClkCtl 来请求发放流控信用；通过在断开请求之前去断言 OrigClkCtl 来表示不请求流控信用。

接收方使用 CompClkCtl 信号请求发起方为其出站通道发放（或重新发放）流控信用，或者请求发起方不为其出站通道发放（或重新发放）流控信用。接收方通过在断开请求（CompClkReq）之前断言 CompClkCtl 来请求发放流控信用；通过在断开请求之前去断言 CompClkCtl 来表示不请求流控信用。

需要注意的是，请求方必须保持 ClkCtl 信号的状态，直到它看到对连接请求的确认。如果请求方没有丢失它已经接收到的信用并且不希望对方重新发放信用，则在断言 ClkReq 时，ClkCtl 信号必须处于非激活状态。

代理在进行单向断开后不能请求重新发放流控信用，必须去断言 ClkCtl。

在第一次连接（即 SdpReset_N 去断言后），所有实现增强端口控制的代理都必须断言 ClkCtl 来表示信用释放，但也可以允许接收代理忽略该值，并假设端口重置后信用总是被释放。

在完全断开后的增强激活协议中，代理不能假设另一方会请求其重置并重新发放信用，仅因为第一个代理请求对方重置并重新发放信用。在上面的图中，发起方必须在断言 CompClkReq 之前采样 CompClkCtl，然后再向接收方发放信用。

图 11

非发起 agent 必须确认断开请求，但可以推迟其自身的断开请求。通常，如果发起 agent 请求完全断开，非发起 agent 在准备完成断开时，也会请求完全断开，但这并不是必须的。可能会提供本规范范围之外的方法来取消完全断开请求，允许发起 agent 请求重新连接。

图 12 显示了在完全断开请求从接口的 Completer 侧发起的情况下，增强断开协议的过程。

图 12

第3章 事务层

3.1 事务层概述

一个 SDP 事务由多个阶段组成，这些阶段分布在多个物理通道上。一个一致性的发起者设备发出缓存感知的事务请求。当一致性的发起者请求读取和写入系统内存中的一个或多个字节时，它会根据其本地缓存中包含目标数据元素的块（缓存行）的预期用途（例如，写入、只读或读取并打算修改），在多种不同类型的请求（也称为命令）之间进行选择。缓存感知的命令可以对发起者的缓存目录和系统中的其他缓存产生隐式或显式的影响。

图 13 Scalable Data Port Interface 显示了按类型分组的 SDP 物理通道。

图 13

在 SDP 的上下文中，发起者指的是在端口上生成请求的实体，而 Completer 是请求所指向的实体。发起者和 Completer 可以如图所示进行点对点连接。更常见的是，发起者和 Completer 通过通信网络（Fabric）间接连接。给定的 IP 模块可能使用多个端口，并且在某些端口上是发起者，而在其他端口上是 Completer。

事务流程由命令通道定义，这些通道按照它们在事务中使用的顺序列出。并非所有事务都使用所有通道。通常，事务由发起者在其发起者请求通道之一上启动。如果 Completer 是 Fabric，那么它可能会向各个发起者（包括请求的那个）生成探测请求，以收集满足请求所需的信息。（非 Fabric Completer 不生成探测。）每个被探测的发起者在其探测响应通道上进行响应。

Completer 生成适当的响应，并根据命令，通过读取响应通道或写入响应通道将其发送回发起者。最后，发起者可能生成响应确认，完成事务。

由于一个事务通常必须经过所有这些阶段才能完成，任何通道的阻塞都可能导致回溯并阻塞事务流程中较早的所有通道。因此，为了避免死锁，要求任何通道都不能使其发送数据的能力依赖于流程中更早的通道发送或接收。

在每个方向上都有一个数据通道，关联到同一方向上的一个或多个命令通道。发起者数据通道携带写请求和探测响应数据。发起者数据通道的仲裁必须保证即使另一种数据传输被阻塞，两种类型的数据传输都能够取得进展。读取响应通道携带读取响应的数据，以及 ChgToX、ChgToXNR 和 ValBlk。

最后，还有一些并非真正属于事务流程的附加通道。公共信号只是端口两侧共享的时钟和复位信号。

3.2 Data Transfer

SDP 有两个数据通道——Originator（Write/Probe）Data Channel（发起者到 Completer 方向）和 Read Response Channel（带有读取数据作为该通道的一部分，在 Completer 到 Originator 方向）。

数据传输请求在字节可寻址的系统内存地址空间中移动连续的、对齐的双字块。对于定长的读和写，这个块的初始地址（第一个双字的最低有效字节的地址）等于请求的 ReqAddr Field 的值。对于缓存读取和 ChgToX，块的初始地址等于请求的 ReqAddr Field 的值，且对齐到系统缓存行大小。对于双操作数原子操作，初始地址无关紧要，数据传输就像对缓存行的访问一样（如同 ReqAddr[5] 为零）。对于其他请求，初始地址等于请求的 ReqAddr Field 的值。由于地址是双字对齐的，地址的位 [1:0] 总是 0。

ReqLen 指定请求的双字数量减一。在以下讨论中，ReqSizeBytes 的值等于 4 × (ReqLen + 1)，即请求的字节数。注意，传输中字节的数量计数包括可能被屏蔽的连续双字块内的那些字节。单个请求的最大大小和地址对齐要求是实现特定的，对于读和写可能不同。

通过使用字节使能，可以在双字块内传输单个字节。如果字节使能为 0，则对应的字节被屏蔽（视为无效）。虽然数据字节上的实际值无关紧要，但它仍然会影响任何数据奇偶校验。此外，建议任何被屏蔽的字节被“围栏”，并以全零或全一提供，以避免未初始化数据的潜在安全泄漏。对于读请求，一个请求中传输的字节必须是连续的，且字节使能仅为第一个和最后一个双字提供。对于写请求，写入数据通过 Originator Data Channel 传输，为 OrigData Field 中的每个字节提供一个字节使能（OrigDataBytEn[i]）。OrigDataBytEn[0] 对应于字节 0，OrigDataBytEn[1] 对应于字节 1，依此类推。写入的字节使能可以是稀疏的——也就是说，不要求字节使能必须连续设置，也不要求在单个事务中设置任何字节使能。发起者必须将 ReqAddr/ReqLen 边界之外的字节通道的所有字节使能驱动为零，双操作数原子操作除外。对于双操作数原子操作，正在传输的缓存行中所有字节通道的字节使能为一。

SOC-15 Scalable Data Port (SDP) Specification, 1.5.0, 11/10/2022 AMD Confidential – Internal Use Only

在每个 *Vld 被断言的周期中，N 个字节通过接口传输，其中 N 小于或等于 *Data Field 的字节宽度（DataFieldWidth）。数据的每个字节都放置在 *Data Field 内其自然对齐的字节通道中。大于数据总线宽度的传输在多个周期（节拍）上发生，每个周期传输一个节拍的数据。每个节拍在传输期间仅传输一次。如果 ReqAddr 未对齐到 *Data Field 宽度，数据将左移，使得每个双字根据其地址定位在 *Data Field 中。在此移位中空出的通道在传输过程中被忽略。

不支持在 *Data Field 内的数据字节环绕。因此，当初始地址未对齐到 *Data Field 宽度且 ReqSizeBytes = DataFieldWidth 时，数据传输需要 2 个节拍。

与特定读或写请求相关的双字块内的节拍可以以任何顺序通过端口接口传输，除非在下面的实现注释中注明。传输的数据源选择节拍的顺序，并使用 *Offset Field 标识在给定周期中正在传输的节拍。包含初始双字的节拍的 *Offset 值为零。每个节拍的地址是请求的 ReqAddr 对齐到 *Data Field，加上 *Offset Field 的值乘以字段的字节宽度。

对于大于缓存行大小的传输，必须在移动到下一个缓存行大小的块之前传输每个对齐的缓存行大小块内的所有数据，但缓存行大小的块可以按照下面的实现注释中注明的任何顺序传输。最后一个节拍（即使只有一个）由 *Last 的断言指示。建议 Completers 在读响应中首先发送由原始请求地址指定的节拍，但不是必须的。实现可以保证和/或要求特定的数据节拍顺序以简化发起者的实现。

**实现注释：**SOC-15 Fabric 限制了响应数据顺序和写数据顺序，使得单个命令（唯一的 ReqTag）的数据总是以“地址顺序”传输，缓存读取和 ChgToX 命令除外。地址顺序意味着对于每个事务，Offset Field 从零开始，每个后续的节拍将此 Offset 增加一，使得数据总是从最低地址到最高地址观察。数据必须以地址顺序提供的限制适用于连接到数据 Fabric 的数据 Fabric 和所有发起者和 Completers。作为此规则的例外，SOC-15 Fabric 可以以任何顺序返回缓存读取（RdBlk）和 ChgToX 命令的响应数据，而不管 ReqAddr[5:2]，并且当在单个 RdBlk 命令中请求多个缓存行时，可以以任何顺序返回每个单独的缓存行。

图 14 Aligned Data Transfer 说明了当请求地址对齐到 *Data Field 的宽度时，数据字节在 *Data Field 内的对齐方式。

图 14

在此示例中，*Data field 的宽度是 4 个 doubleword（128 位），并且一个对齐的 4 个 doubleword 块正在通过接口传输。Doubleword 0（DW 0）在字节通道 0–3（*Data[31:0]）中传输，Doubleword 1（DW 1）在字节通道 4–7（*Data[63:32]）中传输，Doubleword 2（DW 2）在字节通道 8–11（*Data[95:64]）中传输，Doubleword 3（DW 3）在字节通道 12–15（*Data[127:96]）中传输。Doubleword 内的每个字节都在自然对齐的位置传输。

如果 doubleword 块的起始地址未对齐到 Data field，doubleword 将被移位，使得每个 doubleword 在 Data field 内以其自然对齐的 doubleword 位置传输。图 15 Unaligned Data Transfer 显示了当起始地址的最低有效位（ReqAddr [3:0]）= 0100b 时，传输 4 个 doubleword 的情况。

图 15

请注意，上述显示的节拍不一定在连续的时钟周期中传输。

与写请求关联的写数据通过 Originator Data Channel 的 OrigData Field 提供。发起传输的请求呈现在 Originator Request Channel 上。对于对齐的写传输，OrigDataBytEn 信号的使用在 图 16 Aligned Write Data Transfer with Byte Enables 中进行了说明。请注意，被屏蔽的字节（OrigDataBytEn[i] = 0）在传输的每个节拍中可能不同。

图 16

请注意，上述显示的节拍并不一定在连续的时钟周期中传输。

在同一个虚拟通道内的 Originator Write Data Channel 上，写数据传输的顺序与 Originator Request Channel 上对应的写请求顺序相同。写请求可以在多个虚拟通道上发出。Field OrigDataVC 为每个节拍指定虚拟通道。不同虚拟通道的写数据可能被交织传输。没有要求不同虚拟通道的写数据在 Originator Write Data Channel 上出现的顺序与它们在 Originator Request Channel 上请求的顺序相同。

当实现了这些通道的多个实例时，它们在每个 Originator Write Data Channel 实现上的呈现顺序必须与它们在 Originator Request Channel 上的呈现顺序匹配，原始请求通道 A 被认为在 Originator 请求通道 B 之前，Originator 数据通道 A 被认为在 Originator 数据通道 B 之前。只要数据以相同的逻辑顺序出现，就不要求匹配通道实例——例如，来自 Originator 请求通道 B 上请求的数据可能出现在 Originator 写数据通道 A 上。然而，在同一个虚拟通道内，写数据必须按照写请求的顺序提供，不能在请求之间交错数据节拍。

当 Original Data Channel 同时用于写数据和探测响应数据时，探测响应数据（OrigDataChan=1）的行为类似于用于写数据的单独虚拟通道（OrigDataChan=0）——也就是说，探测响应数据的顺序必须与探测响应本身出现的顺序相匹配，但在写数据和探测响应数据之间可能存在交错和重新排序。这种交错可能是由于发起者实际重新排序引起的，或者可能由于 Probe Response Channel 和 Originator Request Channel 之间的通道延迟导致；使得数据看起来被重新排序。

在为写请求或探测响应呈现数据时，OrigDataVld 可以与对应的写命令或探测响应的 ReqVld 或 PrbRspVld 同时或在之后断言。不允许在命令或探测响应之前呈现数据。在遵守此要求时，发起者不需要检查 OrigDataRdy、ReqRdy 或 PrbRspRdy。只要按照逻辑顺序呈现，发起者可以在单个虚拟通道上有多个待处理的数据传输和/或用于探测响应的数据传输。

实现注意： SDP 端口如果具有时钟跨越边界，其中 OrigDataRdy、ReqRdy 或 PrbRspRdy 由外部时钟跨越模块生成，必须采取措施确保上述跨端口要求。一种可能的方法是为 Originator Request Channel、Originator（Write/Probe）Data Channel 和 Probe Response Channel 使用单个时钟跨越模块。实现 Physical Channel Multiplexing 功能的 SDP 端口作为两个独立的端口运行，共享一个 SDP 端口的物理线。这两个独立通道之间没有交错规则。

多个独立的读取响应可以在接口上交错传输。每个节拍都包括事务标识（RdRspTag 和 RdRspUnitID 的组合）。Completer 必须根据发起者的能力限制响应交错的最大数量。此限制为每个发起者以实现特定的方式配置。发起者必须有足够的响应缓冲，能够容纳可能被交错的响应总数。

实现注意： SOC-15 Fabric 将 Originator Data Channel 上的交错限制在缓存行边界；也就是说，除非节拍的关联地址跨越缓存行边界，否则两个独立的写入或探测响应的数据不能交错。物理通道复用发生在每个周期的基础上，不受任何限制。

体系结构注意： 当端口实现了 variable heads-up delay 功能时，交错限制（如果有）适用于响应子通道的时序。

对于定长读取命令，ReqAttr Field 为传输的第一个和最后一个双字提供字节使能。ReqAttr[3:0] 分别为第一个双字的字节 3 到字节 0 提供字节使能，ReqAttr[7:4] 为最后一个双字的字节 3 到字节 0 提供字节使能。如果 ReqAttr[i] = 1，表示正在请求对应的字节，并将在返回时处理；如果 ReqAttr[i] = 0，则将忽略对应字节中的数据。读取一个双字时，使用 ReqAttr[3:0] 作为字节使能，忽略 ReqAttr[7:4]。

在读取响应通道上未提供字节使能。对于请求中 ReqAttr 中对应字节使能未设置的那些字节位置，发起者必须忽略响应的第一个和最后一个双字中返回的数据。

RdBlk* 命令总是对一个缓存行进行操作，因此请求的传输大小必须等于缓存行大小。请求的 ReqAddr 提供关键字节的地址。如果可能，应该在响应的其他任何节拍之前传输包含所请求关键字节的节拍。

当实现了 multiple request address 功能，并且数据传输是针对使用非零 ReqSubAddr 的两个独立地址组成的事务时，数据传输与发起者进行单个缓存行大小请求时相同。具体而言，OrigDataOffset 和 RdRspOffset 的增加不考虑它们是两个独立地址的事实。

3.2.1 Byte Enable Compression

当实现 Byte Enable Compression 时，通过在 OrigDataBytEn 中仅使用一位，并使用 OrigData 来传输实际的字节使能内容，发起者数据通道的大小被减小。此特性旨在用于端口引脚受限的 SDP 实现。本节描述了在实现 Byte Enable Compression 时 OrigData 总线的功能。

如果数据传输的所有字节的字节使能都被断言——即从 ReqAddr 到 ReqAddr+ReqLen 的所有字节都被写入——或者当 OrigDataChan=1（携带完整缓存行的探测响应数据）时，发起者可以选择跳过传输字节使能。要跳过传输字节使能，发起者在整个数据传输期间去断言 OrigDataBytEn，并且数据节拍的数量等于字节数除以 OrigData 的大小（在数据传输中节拍的数量与未实现 Byte Enable Compression 时相同）。

否则，发起者在 OrigData 上传输字节使能。为此，发起者在前几个传输节拍期间断言 OrigDataBytEn，并将实际的字节使能放置在 OrigData 上。对于所有请求数据（例如写入和原子操作），OrigData 上的字节使能位置自然对齐到 OrigData 的宽度。例如，如果 OrigData 有 16 个字节，那么 OrigData[0] 将是 ReqAddr[5:4,000b] 的字节使能。对于探测响应数据，OrigData[0] 是缓存行的第一个字节。

如果 OrigData 的宽度过小，无法在第一个节拍中传输所有字节使能，则使用额外的节拍按照地址顺序传输剩余的字节使能，并在 OrigDataBytEn 被断言的情况下，直到字节使能传输完成。如果 OrigData 的宽度大于传输字节使能所需的宽度，则所有其他 OrigData 位被保留，应该设置为零。完成字节使能传输后，发起者在以正常方式传输数据节拍时去断言 OrigDataBytEn。

要么不使用任何数据节拍来传输字节使能（对于非稀疏写入或探测数据），要么发送每个传输数据字节的所有字节使能。

当 OrigDataBytEn 被断言时，OrigDataParity 提供字节使能的偶校验。

3.2.2 Originator Data Compression

实现了 Originator Data Compression 功能的 SDP 端口可以发出四个额外的命令：

• VicBlkFullZero
• WrSizedFullZero
• VicBlkFullComp
• WrSizedFullComp

VicBlkFullZero 和 WrSizedFullZero 在 ReqLen 中设置适当的写入长度，但不传输任何数据。Completer 的行为就好像数据节拍已使用全零数据传输，所有字节使能设置（与 ReqAddr/ReqLen 一致），并且 OrigDataError=0。

VicBlkFullComp 和 WrSizedFullComp 在 ReqLen 中设置适当的写入长度，但可能传输较少的数据节拍。实际的数据节拍数量在 ReqAttr[7:6] 中指定。基于 ReqLen，由于命令的对齐性质，任何必须为零的地址位携带压缩类型的信息。例如，如果 ReqLen=0xF，则该命令必须是一个对齐的 64 字节地址，因此 ReqAddr[5:2] 携带压缩类型。此压缩类型的编码超出了本文档的范围。

VicBlkFull 的所有其他要求适用于 VicBlkFullZero 和 VicBlkFullComp。WrSizedFull 的所有其他要求适用于 WrSizedFullZero 和 WrSizedFullComp。

3.2.3 MetaData Compression

实现 Metadata Compression 功能的 SDP 端口会在数据中添加一个额外的扩展——“metadata”，它指示数据是否被压缩以及如何解压数据。

从高层次来看，metadata 可以被视为压缩方法或数据的直接映射中的“字典索引”。只有同时拥有 metadata 和数据字节，才能重建未压缩的数据部分。metadata 的实际大小和编码以及字典方法超出了本规范的范围，但对于整个 SOC 必须是通用的。然而，规范要求，如果 metadata 全为 1（例如，如果 metadata 是 8 位，FFh），则表示数据未被压缩。Completer 用于存储 metadata 和查找 metadata 的方法也超出了本规范的范围。作为一个使用 8 位 metadata Field 的假设示例，metadata 值为 01h（使用第九位实现偶校验）可能表示数据块的每个字节都等于单个十六进制值。该值可能位于传输数据字节的字节 0（OrigData[7:0]）中。如果 OrigData[7:0] 是 55h，那么未压缩的数据块就是整个块的重复 55555555h….。为了恢复此数据，只需要存储两个字节——metadata（01h）和重复数据的值（55h）。

并非 SOC 中的每个 SDP Port 实现都必须实现 Metadata Compression 功能。当存在混合的 SDP 实现时，一个不实现 Metadata Compression 功能的端口（在本段中称为仅支持未压缩数据的端口）正在读取或写入数据时，读取响应中的数据总是未压缩的。当一个端口在没有实现 ReqCompMode 和 ReqSpecDataFetch 的情况下请求数据时，Completer 是否绕过 metadata 的查找取决于系统。如果 Completer 绕过查找，硬件和/或软件必须提供一种方法（也超出了本规范的范围），以确保在任何仅需要未压缩数据的 SDP Port 访问之前，数据是未压缩的。使用 ReqCompMode=11b 的 WrNoDataNC 可以在使用 Metadata Bypass 访问数据之前解压任何数据。SDP Port 在当前未压缩的数据上使用 WrNoDataNC 是合法的。使用 ReqCompMode=00b（bypass）也要求硬件和/或软件知道数据必须未压缩。Completer 没有要求进行一致性检查来检测当数据实际上被压缩时绕过 metadata 查找的读取和/或写入，必须特别小心以防止读取或写入不正确的数据。允许 Metadata Bypass 的实现可能需要软件清除数据块，以避免恶意行为者在压缩数据上绕过 metadata 导致的安全泄漏。这超出了本规范的范围。

在写入压缩数据时，要求等效的未压缩数据块是固定大小的。当前的 SDP 规范要求未压缩块为 128B 或 256B（压缩工作在 128B 或 256B 块上），并且地址必须对齐到块大小。因此，启用压缩的写入会更新一个对齐的固定大小块，因此可以假定字节使能全部为 1。OrigDataBytEn Field 被用于携带 metadata。当为此压缩传输传输多个数据节拍时，OrigDataBytEn 在所有节拍上重复。将 OrigDataBytEn 作为 metadata 的使用由命令（除 WrSizedFullComp 外的 WrSized*）以及当 ReqAttr[7:6] != 00b 时指定。所有其他命令（包括所有原子操作），或者当 ReqAttr[7:6] = 00b 时，OrigData* 上的数据未压缩，OrigDataBytEn Field 按 SDP 中数据传输的正常方式解释。压缩数据仍然根据其在压缩块中占据的顺序，从 0 到 n-1（其中 n 是实际传输的节拍数）分配连续的 OrigDataOffset 值。任何提供按地址顺序数据的要求也适用于压缩数据。

在读取压缩数据时，Originator 可以请求数据以压缩或未压缩形式返回。当请求数据以压缩形式返回时，压缩算法可能无法压缩当前数据块的内容——metadata 字典不可能包含所有任意的数据模式——因此 RdRspDataCompMeta 指定块的实际压缩状态（全 1 表示数据未压缩）。原子操作和不支持 Metadata Compression 的命令返回的数据以未压缩编码返回。当绕过 metadata 时，返回的 metadata 也表示数据块未压缩（全 1）。

在 Originator Data Channel 上传输压缩数据时，ReqLen 指示压缩数据的大小。ReqAttr[7:6] 将指示未压缩的大小。当在读取时返回压缩数据，指定的 ReqLen 假定数据块未压缩，因此它是请求的数据块的大小。返回的数据节拍数可能因压缩数据的实际大小而较小。RdRspLast Field 指示返回的压缩数据的实际大小。压缩数据仍然根据其在压缩块中占据的顺序，从 0 到 n-1（其中 n 是实际传输的节拍数）分配连续的 RdRspDataOffset 值。任何提供按地址顺序数据的要求也适用于压缩数据。

某些字典可能能够将固定的数据模式完全压缩到 metadata 本身中（例如，全零可能用唯一的 metadata 编码表示）。在这种情况下，仍然需要传输一个数据节拍，即使只是为了传输 metadata。建议任何未使用的字节被“围栏”，并以全零或全一提供，以避免未初始化数据的潜在安全泄漏，但 Completer 可以跳过实际数据块的访问以节省带宽。例如，实际内存可能未被写入，只有 metadata 被更新。数据奇偶校验仍然保持偶校验，无论是否需要字节来重建未压缩的数据块。此外，即使 OrigData 或 RdRspData 在重建未压缩的数据块时不是必需的，数据信用处理仍然对这个单个数据节拍正常运行。

具有数据传输的 Victims 和探测响应必须始终提供未压缩数据，因为 ReqAttr 和 ReqCompMode 没有方法指示 Victim 和探测响应数据的压缩状态。当 SDP Port 使用 WrNoDataNC 来解压数据时，任何系统缓存不一定被失效。

一个 256B 数据块的两半可以根据 metadata 值独立压缩。Completer 也可以压缩一个 256B 数据块，或者在 ReqCompMode 不要求禁用 Completer 压缩的情况下，将两个 128B 数据块的压缩合并。

3.2.4 Read Response with NODATA

“RdRspDataStatus” 为 NODATA 仅在以下情况下允许：

1）当总线上有空闲周期时（即 RdRspVld 未断言，或者如果实现了 Heads-up 功能，则 RdRspDataVld 未断言）。然而，当总线上有空闲周期时，Originators 必须忽略 RdRspDataStatus 的内容。

2）Completer 先前已使用 EARLY 状态（和数据）响应了事务，现在正在完成事务，同时指示先前提供的数据是有效数据。

3）Completer 可以使用 RdRspStatus=OKAY_NODATA 和 RdRspDataStatus=NODATA 作为对 ChgToX 事务的响应。

4）Completer 使用 RdRspStatus=OKAY_NODATA 和 RdRspDataStatus=NODATA 作为对 ChgToXNR 和 ValBlk 事务的响应。

5）Completer 可以对已被取消的事务以读取响应进行响应，使用 RdRspStatus=OKAY 或 OKAY_NODATA，且 RdRspDataStatus=NODATA。如果事务实际上被取消，则会发生这种编码。如果取消未执行，事务正常完成。

6）Completer 可以对指示为存储探测重取的 RdBlkL（ReqAttr[1:0] = 10b）使用 RdRspStatus=OKAY_NODATA 和 RdRspDataStatus=NODATA 进行响应。不提供存储探测获取数据的原因超出了本规范的范围。

7）Completer 对任何未经请求的 SYSFATALERR 响应使用 RdRspDataStatus 为 NODATA。

8）Originator 使用了某些不需要数据响应的 SpecPrefCmd 编码。

在其他情况下，当事务在非错误情况下会返回数据时，在错误情况下（例如，当 RdRspStatus 为 DECERR、SLVERR、TRANSERR 或 PROTVIOL）提供 RdRspDataStatus 为 NODATA 是不合法的。建议 Completer 对 ChgToX 事务的错误响应使用 NODATA。提供 RdRspStatus 为 OKAY_NODATA 且提供非 NODATA 的 RdRspDataStatus 也是不合法的。

带有 NODATA 的响应总是单个节拍（RdRspLast 被断言）。

3.2.5 Read Response and Data Associated with Error Status

如果 RdRspStatus 表示错误（SLVERR、DECERR、PROTVIOL、TRANSERR、CMPTO 或 CRS），Completer 必须传输所有请求的数据节拍，包括断言 RdRspLast；如果由于错误没有可用数据，则使用制造的数据。建议使用全一的制造数据模式。

对于可缓存的事务，Originator 不得缓存返回的数据。通常，任何以 RdRspStatus 或 WrRspStatus 表示错误完成的事务都不会改变该行的缓存状态。

3.2.6 Read Response Data Retransmission

如果在某个节拍上 RdRspDataStatus 是 RETRANSMIT，则数据传输必须完成，直到断言 RdRspLast 的节拍为止。一旦 RETRANSMIT 被断言，与 RETRANSMIT 同时的那个数据节拍以及该响应的所有后续节拍，必须由 Originator 保留，但在接收到最后一个节拍之前不得消耗或转发。

当在最后一个节拍上断言了 RETRANSMIT 时，Originator 必须丢弃任何已保留但未消耗或转发的节拍。在数据重新传输之前，Originator 不得发送响应确认（如果在此响应中使用了）。Completer 随后将重新传输整个响应序列，包括任何先前的节拍，而不依赖于 Probe Request Channel。在 RETRANSMIT 状态和实际的重新传输之间，Completer 可以交错其他事务响应。

在重新传输事件期间，Originator 必须跟踪哪些数据节拍（如果有的话）已被消耗或转发。Completer 允许在此重新传输事件期间发出任何有效的 RETRANSMIT、VALID 或 DATERR 的组合。Completer 必须提供一种方法来限制重新传输的次数以避免活锁，但 Originator 不得有任何限制。

当在除最后一个节拍之外的某个节拍上断言了 RETRANSMIT，且在最后一个节拍上未断言 RETRANSMIT，则最后一个节拍的 RdRspDataStatus 编码适用于所有已断言 RETRANSMIT 的节拍。

表 37 Read Response Data Retransmission Possibilities 显示了跨越两个数据节拍的响应的所有可能性。

表 37 读取响应数据重新传输的可能性

您可以将上述内容复制粘贴到微软 Word 中，格式将保持不变。 表 37 Read Response Data Retransmission Possibilities 显示了跨越两个数据节拍的响应的所有可能性。

3.2.7 Read Response Data Lag and the Variable Heads-Up Feature

当未实现 Heads-up 功能时，Read Response Channel 是一个通道，RdRspVld 对该通道上的所有信号进行限定。Read Response Tag 或 Status 与数据呈现之间没有延迟或时间差。

然而，当实现了 Heads-up 功能时，Read Response Channel 被拆分为两个子通道。第一个（Response 子通道）提供 Read Request 状态的提前通知，以及关于未来数据传输周期的信息。第二个子通道（Data 子通道）提供数据（RdRspData）、其奇偶校验（RdRspDataParity），以及关于数据的信息（RdRspDataStatus、RdRspDataStatusParity 和 RdRspDataUser）。

有了这个功能，在 RdRspVld 和 RdRspRdy 都被断言后的 Nlag 个周期，无条件地产生 Data 子通道，并且 RdRspDataVld 必须在该周期被断言。RdRspVld 仅限定任何给定时钟周期上的 Response 子通道上的数据，并且 RdRspVld 不一定在数据呈现的周期上被断言（除非此时启动了另一个 Read Response）。Data 子通道由 RdRspDataVld 进行限定，它是 RdRspVld 的一个等效延迟版本。在给定的时钟周期上，RdRspRdy 表示接受两个子通道。

Read Response Variable Heads-up 功能为 Read Request 的 Originator 提供两个间隔之一，指示 Read Request 的状态与随后的数据之间的延迟。未实现 Variable Heads-up 功能时，Read Request 状态和随后的数据只能延迟一个单一的间隔 Nlag。

当实现了 Variable Heads-up 功能时，RdRspDelay 指示将应用于该响应的两个固定的 Heads-up（或数据延迟，取决于视角）间隔中的哪一个。特定响应与任何关联数据之间的间隔是 Nlag 个时钟周期，其中 Nlag = （RdRspDelay = 0）？Nshort_lag ：Nlong_lag。如果可编程，这些值在正常操作期间必须是静态的。Nshort_lag 和 Nlong_lag 可以是任何整数（0，1，…），不一定限制为不同。当未实现 Variable Heads-up 功能时，Nlag 始终是为端口配置的单一固定 Nshort_lag。

应用说明： 当 Completer 和 Originator 实际上处于不同的时钟域时，通常情况下，较高频率的 IP 模块必须有一种方法来确定哪些时钟周期不应在确定响应与响应数据之间的延迟时计入，因为同步逻辑的原因。此类方法超出了本规范的范围。

实现注意： 大多数实现预计不实现 Heads-up 功能，因此将 Read Response Data 与 Read Response 对齐。一些实现将使用固定的 Heads-up 延迟（单一的 Nshort_lag）来实现 Heads-up 功能，预计很少有实现会实现 Variable Heads-up 功能。目前，没有 SOC-15 IP 计划实现 Variable Heads-up 功能。

3.2.8 Probe Data

Probe 数据在 OrigData Field 的 Originator Data Channel 上返回到 fabric，以响应 Probe Request Channel 上的探测请求。传输的大小始终等于系统缓存行大小。Probe 数据传输必须按照 Probe Response Channel 上相应信息的顺序进行。在 Probe Response Channel 内没有交错，但在 Originator Probe Data Channel 和 Originator Write Data Channel 之间的传输可能会交错。数据节拍基于 OrigDataChan 位来识别属于哪个通道。当此信号为 0 时，在 OrigData Field 上呈现的数据是写数据。当此信号为 1 时，OrigData 上的数据是 Probe Response Data。

3.3 Virtual Channels

Virtual channels (VCs) 被支持以提供传输保证（用于避免死锁）。它们还用作分组事务以进行排序的基础。VCs 是通过在物理通道上基于每个虚拟通道保留资源并重新排序不同 VCs 中的请求来实现的，以确保一个 VC 的阻塞不会导致另一个 VC 被阻塞。所有事务都由 Originator 分配一个 VC 标识符，并使用它在所有支持多个 VCs 的物理通道上选择 VC。

VCs 并非旨在表示各种事务之间的任何类型的优先级；然而，可能存在跨 VC 的依赖关系，导致一个 VC 被另一个阻塞。建立了一个 VCs 的层次结构，阻塞（无论是在同一物理通道上的 VC 内，还是在不同物理通道中，传入流量在传出流量后面阻塞）仅在一个方向上支持，以避免导致死锁的循环。

Originator Request Channel 和 Originator Write Data Channel 支持多个虚拟通道。IP 模块可以自由地不实现他们知道永远不会发起请求的任何虚拟通道的支持。Fabric 和 Completer 在一个虚拟通道中接收并完成请求，而不依赖于其他虚拟通道，除非通过 *PassPW 位在已发布通道和未发布通道之间特别请求的依赖关系。SDP 请求虚拟通道通常能够承载读取和写入。对于需要请求始终能够通过先前请求的情况（例如，在 PCIe 排序中已发布写入通过读取），后续请求必须放置在不同的虚拟通道中。在请求虚拟通道内允许重新排序，遵循 QoS 和排序规则，但不能为了避免死锁而保证。

Probe Request Channel 没有分成多个虚拟通道，这意味着被阻塞的探测请求可能阻塞与任何其他虚拟通道关联的请求，产生跨 VC 的依赖关系。此外，允许 Originator 基于其发出缓存逐出（VicBlk*）请求的能力来阻塞传入的 Probe Request Channel。为了避免死锁，有必要将逐出放置在不包含探测生成请求的虚拟通道中（逐出永远不会生成探测）。还要求用于逐出的虚拟通道必须忽略总线锁。探测必须在没有任何其他外部依赖的情况下完成，并且通常预期会迅速完成。

读取和写入响应物理通道也支持虚拟通道。Originator 永远不得将其接收响应的能力取决于其发出请求的能力，也不得将接收响应取决于接收单独的响应。Fabric 不能使其接收响应的能力取决于其发出探测的能力。

3.3.1 Virtual Channel Request Limitations

Virtual channel 的使用是实现特定的。对于支持 Posted Write Ordering 功能的接口，唯一的要求是 ReqVC 为 0 时用于非已发布请求，ReqVC 为 1 时用于已发布请求。一些 Virtual channel 限制了某些命令的使用。

SOC-15 Data Fabric 的 Virtual channel 使用如 表 38 Virtual Channel Usage for SOC-15 Data Fabric 所示。SOC-15 Command Processing Network（用于 CP Communication、Doorbells 和地址转换服务）的 Virtual channel 使用如表 表 39 Virtual Channel Usage for SOC-15 Command Interface Fabric 所示。

表 38 Virtual Channel Usage for SOC-15 Data Fabric

注释：

1. Writeback Virtual Channel 允许不依赖于系统探测的追踪和逐出。使用的通道通常是 VC1，除非该端口已使用已发布 VC，在这种情况下是 VC3。

表 39 Virtual Channel Usage for SOC-15 Command Interface Fabric

3.4.1 Channel Flow Control

Request、Read Response、Write Response 和 Originator Data 通道支持虚拟通道。虚拟通道流控使用两种不同类型的信用：VC-specific credits 和 pool credits。当接收器发出 VC-specific credit 时，这意味着它释放了一个用于存储与特定虚拟通道关联的信息的缓冲区。pool credit 不与任何特定的虚拟通道相关联。

当通道上的接收器发出信用时，释放的信用类型由 *CreditType 字段指示。如果 *CreditType = 0，信用是 VC-specific 的，虚拟通道号由 *CreditVC 字段提供。如果 *CreditType = 1，发出的信用是 pool credit，*CreditVC 字段被忽略。

SDP 实现了一个由传输器管理的缓冲区分配方案。

在初始复位时，接收器可能释放所有的 pool credits 或特定虚拟通道的 credits。预期接收器会选择其中一种，而不是混合使用。然而，传输器不应依赖于此行为。传输器管理这个信用池，使用它们在任何已实现的虚拟通道上发送信息。如果在存在其他流量的情况下需要避免死锁或保证带宽，传输器有责任为特定虚拟通道保留 credits。

当传输器使用 pool credit 来发送请求、响应或数据节拍时，它指示所使用的虚拟通道（例如 ReqVC）。接收器记录这个虚拟通道号，并将其与所使用的缓冲区关联。当接收器释放该缓冲区时，它通过 *CreditVC 字段（且 *CreditType = 0）将相同的虚拟通道号反映回传输器。传输器决定这个被释放的缓冲区是否应继续分配给特定的虚拟通道，还是返回到它管理的池中。

信用的释放不能被认为意味着特定的传输已经被接收器处理到一个排序点。

当未实现虚拟通道时，所有的 credits 实际上都是为 VC0 发放的。

3.5 Transaction Identification

在特定端口上发出的命令通过事务标签（transaction tag）进行标识。该标签包含在请求中，并随响应一起返回，允许每个请求及其对应的响应进行匹配。这对于在 Originator Request Channel 或 Probe Request Channel 上发出的命令都适用，并且是必需的，因为响应通常可能是乱序返回的。

从 Originator 设备发出的命令还包含一个 UnitID 字段，用于标识共享该端口的 Originator 设备内的特定请求者。每个独立的单元都有其自己的标签空间，需要结合 ReqUnitID 和 ReqTag 来标识事务。

当实现了多个同类型的通道（例如，Originator Request Channel A 和 Originator Request Channel B，或 Probe Request Channel A 和 Probe Request Channel B）时，每个通道并不拥有多个标签空间。Originator Request Channel 在所有已实现的通道之间共享一个公共的标签空间。当实现了多个 Probe Request Channel 时，Probe Request Channel 也共享一个公共的标签空间。Originator Request Channel 和 Probe Request Channel 上的标签之间没有关联。

系统中所有端口都有独立的标签空间。也就是说，不能保证 Originator 发出的请求的标签在它从 Completer 端口出现时仍然相同。Fabric 可以自由地分配这些标签，并且在计算中可能包括原始端口和单元信息。

3.6 Commands

SDP 发起者通过发出请求（也称为命令）来启动事务。请求的类型通过发起者请求通道的 ReqCmd 字段指示，如 表 40 命令所示。下方列出了各种命令编码的合法值和含义。ReqCmd[5] 表示该命令将在发起者数据通道上传输数据。

请注意标有 Orig Data、Resp Chan 和 Requires Ack 的列。Orig Data 列中的 “yes” 表示发起者还在发起者数据通道上提供数据。Resp Chan 列指示对该命令的响应是通过读取响应通道还是写入响应通道返回给发起者。Requires Ack 列指示发起者是否需要为该命令生成响应确认。该列中的 “Yes/No” 意味着发起者请求通道的 ReqAck 字段的值决定是否需要响应确认。

表 40 命令

以下部分按以下类别提供了关于这些命令的更多信息：

• Non-caching reads
• Writes
• Atomics
• Caching reads
• Cache upgrades
• Cache evictions
• Barriers
• Cache maintenance
• DVM Operations
• Other commands

3.6.1 Non-caching Reads

• ← Previous Post
• Next Post →