tilelink_reading note

发表于 更新于 本文字数： 8.2k 阅读时长 ≈ 30 分钟

Tilelink协议

架构与信号描述

TileLink 支持多种类型的通讯代理模块，并定义了三个从简单到复杂的的协议扩展级别。每个级别定义了兼容该级别的通讯代理模块需要支持的协议扩展子集，如下图所示。最简单的是 TileLink 无缓存轻量级(Uncached Lightweight, TL-UL)，只支持简单的单个字读写(Get/Put)的存储器操作。相对复杂的 TileLink无缓存重量级(Uncached Heavyweight,TL-UH)，添加了预处理(hints)、原子访问和突发访问支持，但不支持一致性的缓存访问。最后，缓存相关级别 TileLink Cached(TL-C)是最复杂（完整）的协议，支持使用一致性的缓存模块。

image-20250306151247639

除了 clock 和 reset 信号之外，TileLink 信号名字的组成：通道识别符（a到e）跟着一个下划线，再接一个信号名（在下面小节中一一列举）。

对于拥有多个 TileLink 接口的设备，推荐在所有 TileLink 信号名字之前加上一些描述性的标示加下划线。例如，a_opcode 变成 gpio_a_opcode。

image-20250306151441976

通道A

通道A从主接口流向从接口，携带发送到特定地址的请求消息。此通道由所有TileLink一致性级别使用，并且是强制性的。

image-20250306151716023

通道B

通道B从从接口流到主接口，携带发送到特定主接口保存的特定缓存数据块的请求消息。该通道由TL-C一致性级别使用，在较低级别中是可选的。

image-20250306151802131

通道C

通道C从主接口流向从接口。它可以携带对发送到特定缓存数据块的通道B请求的响应消息。它还用于主动写回脏缓存数据。此通道用于TL-C一致性级别，在较低级别中是可选的。

image-20250306151850411

通道D

通道D从从接口流向主接口。它携带发送到特定地址的通道A请求的响应消息。它还携带通道C自愿回写的确认。此通道由所有TileLink一致性级别使用，并且是非可选的。

image-20250306151931772

通道E

通道E从主接口流向从接口，携带通道D响应消息的接收确认，用于操作序列化，该通道用于TL-C一致性级别，在较低级别可选。

image-20250306152019419

序列化、死锁

Flow Control Rules

为了实现正确的ready和valid信号握手，需要遵守以下规则：

  • 当ready信号为低时，接收者不能处理数据并且发送者认为该拍内的数据未被处理。
  • 当valid信号为低时，接收者应当认为该数据信号并不是一个正确的TileLink数据。
  • valid必须与ready信号独立，如果一个发送者希望发送一拍数据，则必须使能一 个valid信号，同时该valid信号是与接收者的ready信号独立的。
  • 从ready到valid信号或者任何数据或控制信号之间不能存在任何组合逻辑路径。
  • 一个低优先级的有效不能组合地依赖于一个高优先级的有效。换句话说，发送一个请求的决定不能基于在同一个周期内接收到一个响应
  • 高优先级就绪可能不会组合依赖于低优先级就绪。换句话说，响应的接受可能不会取决于同一周期内接受的请求。

对于能够携带簇发的TileLink的通道，有着额外的规则约束。一个簇发一旦第一拍数据 被接收，直到最后一拍数据传输结束都认为处于传输过程中。当一个数据包处于传输过程中 时，如果valid信号为高，发送者必须满足：

  • 只有同消息的簇发的一拍数据。
  • 控制信号与第一拍相同。
  • 数据为与之前拍数据的地址再加上按数据总线的字节宽度得到的地址所对应的数据。

image-20250306153533273

第一个信息为F，size为5，表示传输32个字节，需要四拍，opcode 0表示为PutFullData 4表示Get操作，第二个信息为G，大小为1字节，H被拒绝接受，并且下个周期控制信号改变，变为了传输4个字节的I，之后J虽然size含有16个字节，但GET操作不含数据，故一周期完成

image-20250306154049652

第一个信息为L，opcode为1 表示AccessAckData，含有数据，故需要4拍，之后和上面例子类似

请求响应数据排序

我们现在定义在一个具有多拍数据包的情况下，发送响应消息时的规则。在如下情况下，响应消息的第一拍可以出现在响应通道上：

  • 在请求消息被接收了的同一个周期出现，但不会在这周期之前出现。
  • 在请求消息的第一拍握手成功之后的任意时间

跟随在包的响应消息的第一拍后的多拍信号可以在任意延迟后出现，但与此同时，不能有来自其他消息的任一拍数据交错地插入此次传输中。

Burst Responses

image-20250306155350105

第一个请求的ack在任意延迟后出现在D通道，第二个请求在被接受的同时，d通道出现ack

Burst Requests

image-20250306155621522

第一个AcessAck被延迟任意长时间，但请求者会发送余下的信息

第二个AcessAck在PutFullData同一拍出现，

Burst Requests and Responses

image-20250306155905329

对于大小为4，16字节（2拍）的操作，要么在请求和响应消息之间存在较长的延迟，要么两者的各拍信号重叠。如果每条消息的整体都能放入一拍之中(2ˆ3=8=1beat)，那么这些消息就能完全地重叠。

Byte Lanes

带有数据域的TileLink通道总是自然地以小端对齐方式运载数据载荷，一个字节通路传输的数据的地址的最低一部分总是相同的，如下图所示。

image-20250306160214144

一个操作要么使用所有的数据字节通道，要么使用其中一个2的幂大小的片段。操作使用的字节通道称为活动字节通道。

在携带掩码字段的通道A和B上，所有非活动字节通道的掩码必须始终为LOW。此外，对于PutPartialData以外的所有消息，所有活动字节通道的掩码位必须为HIGH。PutPartialData可以降低掩码的各个位，并且这些位不必连续。

掩码也用于没有数据有效载荷的消息。当操作大小小于数据总线时，掩码的生成应该与携带数据有效载荷的操作相同。对于大于数据总线的无数据操作，掩码的所有位都应该为高，尽管消息仍然是单拍。例如，参见图12。

image-20250306161231625

在图12中，PutFullData（0）必须将掩码的所有活动通道驱动为高。因此，第一个消息在多个节拍上具有所有节拍高。相比之下，PutPartialData（1）可以将掩码的活动通道驱动为高或低。Get（4）消息从不是多节拍的，但仍然必须将活动字节通道上的掩码驱动为高。对于小于节拍的消息，掩码的所有非活动字节通道必须被驱动为低（寻址0x62的操作中的位0和1）。

Deadlock Freedom

image-20250306162310858

image-20250306162236254

  1. 接受（accept）一拍：若发送者在某个通道上把valid信号拉高，接收者若把ready信号拉高则接受一拍。
  2. 拒绝（reject）一拍：若发送者在某个通道上把valid信号拉高，接收者若把ready信号拉低则接受一拍。
  3. 撤回（retract）一拍：若接收者拒绝一拍，发送者可以拉低valid或在下一拍修改控制或数据信号来撤回一拍。
  4. 呈现（present）一拍：若valid拉高且所有控制和数据信号在ready也拉高之前都保持不变，称之为呈现一拍。
  5. 进行中（in progress）：一个消息正在进行，表示从被接受的第一拍到最后一拍被接受之间的这段时间。
  6. 传输中（in flight）：一个消息正在进行，表示从被呈现的第一拍到最后一拍被接受之间的这段时间。
  7. 请求消息：需要一个对应的响应消息，所有的TileLink操作都从某个通道的请求消息开始。
  8. 响应消息：跟随在请求消息之后的响应。
  9. 已收到的（received）消息：从簇发传输的第一拍被接受开始，消息被收到。
  10. 已回答的（answered）消息：收到的请求被响应后，消息被回答。
  11. 代理（agent）：TileLink系统中的参与者，有一或多个TileLink链路。
  12. 优先级：一个消息的优先级与对应通道的优先级对应，响应消息的优先级总是比对应请求的优先级高，转发消息的优先级也更高。
  13. 最终事件：一个事件在任意长但并非无穷长之后最终发生。
  14. 向前推进：当所有呈现的拍最终被接受，且所有收到的请求最终被回答时，系统可以向前推进。
  15. 不活动的（quiescent）：当没有添加新的消息时，系统处于不活动的状态，注意尽管TileLink保证不出现死锁，但仍然可能产生活锁或饥饿状态。为了限制这种情况，代理只被允许发送n+rf个消息，包括n为该代理允许发送的新消息、r为该代理接收的消息以及f为该代理为每个收到的消息允许发送的后续消息。

Examples of agent conformance

周期性转发的主设备（不符合）

一个代理有一个主接口和一个从接口，在A通道接受请求消息，但在转发消息时只在偶数周期拉高valid信号。这个代理不符合协议要求，原因是该代理不能完整呈现转发的消息，不能保证最终回答一个收到的请求。

等待刷新（符合）

一个DDR控制器周期性地无法处理请求，在这段时间内无条件地拉低所有ready信号，但注意到该代理仍然最终可以接受呈现的拍，因此还是符合协议要求的。

等待消息被接收（不符合）

一个代理有两个用于发送消息的链路，在链路1上发起簇发传输A，并且几拍中的第一拍被接受，表明消息已被接收，但仍在传输中，然后在链路2上发起簇发传输B，此时A的传输还未结束。在恢复A之前等待B被接受是不符合协议要求的。

非常慢的仲裁器（符合）

考虑一个具有三个链路的TL-UH代理，仲裁来自两条链路的A通道请求，并转发到第三条链路的A通道，但该仲裁器的吞吐量非常低。

代理空闲时将从任一输入的A通道中选择一个valid请求，一旦选择了一个请求，就会在另一个A通道上拉低ready信号，并在所选链路和输出链路之间连接ready和valid（通道A和D）。一旦请求的所有拍都已被输出通道接受，代理在两个输入A通道上拉低ready信号，并等待响应消息的最后一拍被所选的通道接受。

该代理符合规则2，因为可以假设输入的A通道都遵守规则2，因此其输出的A通道请求将呈现接收到的请求的所有节拍，D通道也同理。

假设代理正在处理输入的一个消息，在转发链路上分别有一个未回答或进行中的消息。由于该链路的优先级高于输入的链路，因此适用规则3，并且代理可以无限期地拒绝后续提交的A通道请求。

假设代理空闲并且没有输入呈现消息，这种情况满足规则3i，因为没有消息可以接受，同时也满足规则3ii，因为只有在收到的请求被回答时，仲裁器才会再次空闲。

操作与信息

操作分类

TileLink 操作能被分为下列三组:

  • Accesses (A) 在具体的地址读或写数据。
  • Hints (H) 只是提供一些信息，没有实际的影响。
  • Transfers (T) 在拓扑网络中改变权限或移动缓存拷贝。

不是每个TileLink代理都需要支持所有操作。取决于其的TileLink兼容级别，一个代理需要支持的操作如下表所列。

image-20250306165146627

消息分类

image-20250306165249965

操作为蓝色，紫色为消息

image-20250306165453357

image-20250306165606275

在一个TileLink拓扑网络中，在任意给定时间内会有多个操作在进程中。这些操作可能以任意的顺序完成。为了确保主端能在一个操作完成后，再执行其他操作，TileLink要求从端在操作结束时及时发送一个回复消息。因此，如果处理器要确保两个写操作X和Y的顺序被其他所有代理获取时都是一致的，那么处理器发送X的PutFullData后，必须等待AccessAck回复，在此之后，才发送Y的PutFullData。

TileLink的从端，包括缓存，不能在Put操作确认前就将数据写回。唯一的约束是，一旦确认消息发出后，整个拓扑网络不能观察到过去的状态，这是因为在确认消息发出后，所有的被缓存的数据的拷贝都必须是已更新的。例如，对于一个Put操作，其他缓存要么被Probe现有的数据拷贝，要么通过PutFullData将消息前递给其他缓存，并且在确认原始的请求消息前，收集对应的回复消息。

发射回复消息的代理需要保证它们接收的操作是一个有效的序列。例如，假设一个代理接收了两个Put，X和Y，并且都没有被确认，必须选择一定的顺序，例如说是X在Y之前。如果选择了这样的顺序，必须保证只有三个状态，X与Y前的状态，X之后且Y之前的状态和X与Y之后的状态。代理不一定要以这样的顺序发射回复消息。然而，在代理已发射了一条回复之后，例如Y，如果此时接受了新的操作Z，那么Z必须排在Y之后。

这些规则确保每个代理看到的全局操作排序与主端的确认信号引导的局部排序是一致的。处理器可以等待发出的确认消息返回后再发起其他请求，来实现fence指令。这样的能力使得多处理器在TileLink的共享存储系统中，安全地同步执行操作。

这里的意思是A写入的值需要广播，以此来更新所有缓存块的状态

TL-UL

TileLink无缓存轻量级（TL-UL）是最简单的TileLink协议兼容级别，可用于连接低性能的外设以减小总线的面积消耗。该兼容级别的代理都支持两种存储访问操作：

  • 读（Get）操作：从底层内存中读取一定量的数据。
  • 写（Put）操作：向底层内存中写入一定数目的数据，写操作支持基于字节t通路掩码的部分写功能。

在TL-UL中，每条消息都必须放在一拍中，不支持簇发操作，TL-UL一共定义了与存储访问操作相关的三种请求消息和两种响应消息类型，下表列举了这些消息。

image-20250306221635531

Flows and Waves

image-20250306221708281

image-20250306221947941

image-20250306222005808

image-20250306222028232

TL-UH

TileLink无缓冲重量级（TL-UH）用于最后一级缓存之外的总线，这种应用中不需要使用权限转换的操作。TL-UH建立在TL-UL的基础上，并提供一部分额外的操作，包括：

  • 原子（Atomic）操作：在原子性地读取现存的数据值的同时，同步地写入一个新的值，此新值为某些逻辑和算法操作的结果。
  • 预处理（Hint）操作：提供了与某些性能优化相关的可选的提示性消息。
  • 簇发（Burst）消息：允许带有比数据总线宽度更大的数据的消息在多个周期内作为数据包传输，应用于在Get、Put和原子操作中多种包含数据的消息。

image-20250306222211086

Flows and Waves

image-20250306222236442

image-20250306222547617

image-20250306222555978

ArithmeticData

image-20250306222657857

LogicalData

image-20250306222737816

Intent

image-20250306222754968

HintAck

image-20250306222842419

TL-C

TileLink缓存支持级（TL-C）给主端代理提供缓存共享数据块副本的能力，保证缓存一致性。本章描述TL-C中缓存的数据副本上允许进行哪些访存操作，以及用来传输数据块的缓存的消息类型，实现中所定义的一致性协议描述了副本和权限如何通过具体的TileLink代理网络传输以回复所接收的存储访问操作，但具体的一致性协议描述不在TileLink协议内容范围内。

TL-C新添加了三种操作、三个通道、一个五步的消息序列模板以及十种消息类型。

新的操作transfer可以创建或者清除数据块的缓存副本。转换操作不会修改数据块的值，但是会改变他们的读写权限。转换操作可以与之前定义的TL-UL、TL-UH访存操作无缝协作，保证操作进行序列化的正确性。

可缓存性是存储地址范围的一个属性，一个TileLink的实现需保证避免无法缓存地址范围的副本出现。

所有基于Tilelink的一致性协议都由一系列操作组成，通过这些操作，可以完成读写数据块权限的在转变。在代理对已缓存的副本执行响应的操作之前，必须获得正确的权限。当代理希望在本地处理一个访问操作时，它必须首先使用转换操作来获得必要的权限。转换操作在网络上创建或删除副本，从而修改每个副本可以提供的权限。

代理中数据块副本的基本权限可以包括：None、Read或Read+Write。缓存架构中副本 可用的权限取决于缓存层次结构中副本的当前存在情况，如下所述。

对于任何给定的地址，在给定主端和拥有该地址范围的从端之间都只会存在一个具体的路径。在TileLink网络DAG中，所有这些路径都覆盖会形成一个树，根节点上仅有一个从端节点。对于每个地址，此树包含所有针对该地址的操作执行的路径。如果我们省略了所有不能缓存数据的代理，那么就会留下一个描述所有可能缓存该地址数据的缓存代理位置的树。

在逻辑时间的任意时刻，这些代理的某些子集真正包含缓存数据的副本。这些代理形成 了一致性树 。包容性（Inclusive）的TileLink一致性协议要求树在响应内存访问操作时进行提权（Grow）和降权（Shrink）操作。图中的每个节点都属于树中的位置，分为以下四类：

  • Nothing：当前没有缓存数据副本的节点，没有读写权限。
  • 主干（Trunk）：在顶点（Tip）和根（Root）之间的路径上拥有缓存副本的节点，具有其副本的读权限，该副本可能包含脏数据。
  • 无分支的顶点（Tip with no Branches）：具有缓存副本的节点，且可以用作内存访问序列化，对其拥有的可能包含脏数据的副本具有读写权限。
  • 有分支的顶点（Tip with Branches）：具有缓存副本的节点，且可以用作内存写入序列化，对其拥有的可能包含过去写入的脏数据的副本具有读写权限。
  • 分支（Branch）：该节点由Trunk结点分出，具有只读数据缓存副本。

image-20250306223229723

上图例举了几个覆盖在单个TileLink网络上的一致性树。在A中，树的根节点有唯一的 副本，这使得它既是树的根节点，也是树的顶端节点。在B中，主端通过提升主干的特权 (Grow)，获得读写权限，直到其位于顶点处。在C中，另一个主端通过扩展一个分支获得了读权限，这意味着之前的顶点现在也是一个只读分支，且公共的父节点是主干节点。在D中，其他主端也升级为分支，进一步将尖端向根部移动，而最初的请求者已经主动修剪了其分支。

Operations

三个新操作统称为transfer操作，原因是这些操作将数据块的副本传输到内存层次结构中的新位置，包括：

  • Acquire：在请求主端中创建块（或其特定权限）的新副本。
  • Release：从请求的主端将块的副本（或其特定权限）释放回从端。
  • Probe：强制将块的副本（或其特定权限）从主端移到发起请求的从端。

Acquire操作要么以扩展树干的形式，要么以从现存的分支或者尖端添加新的分支的形式来拓展树。在新的分支生成前，旧的主干或分支可能需要递归的Probe方法进行修剪。为了响应缓存容量冲突，可通过Release操作主动裁剪分支。

Channels

为了支持转换操作，TL-C在执行内存访问操作所需的两个基本通道上添加了三个新通道。A和D通道也被重新用于发送额外的消息，以实现转换操作。转换操作使用的五个通道

分别是：

通道A. 主端为了读取或写入缓存块副本而发起对权限的请求。

通道B. 从端查询或修改主端对缓存数据块的权限，或将内存访问前递(forward)给主端。

通道C. 主端响应通道B传输的消息，可能会释放带有任脏数据块的权限。也用于主动回写脏的缓存数据。

通道D. 从端向原始请求者提供数据或权限，授予对缓存块的访问权。也用于确认脏数据的主动写回。

通道E. 主端提供此次事务完成的最终确认消息，从端可用来事务序列化

这五个通道可分为11种消息

image-20250306224348821

Permissions Transitions

image-20250306224553036

Prune: 权限降级，缩小一致性树。相比过去，完成操作之后具有较低的权限。

Grow: 权限升级，增大一致性树。相比过去，完成操作之后具有较高的权限。

Report: 包含权限保持不变，但报告当前权限状态。

Cap: 包含权限更改，但不指定原始权限是什么，而只指定它们应该成为什么。

Flows and Waves

Transfer操作引入新的事务流，这些事务流可以组成完整的缓存一致性协议事务。下图描述了三个新消息流。

image-20250306225034736

image-20250306225615605

上图的消息流涵盖了三种新操作：

  1. 缓存主代理向从代理发送Acquire。
  2. 为保证给响应消息留足够空间，主代理主动发送Release，即写回操作。（替换脏数据）
  3. 从代理访问存储结构，以完成写操作。
  4. 从代理通过ReleaseAck确认写回操作已完成。
  5. 从代理向其他主代理发送必需的Probe。
  6. 从代理等待所有被Probe的主代理返回ProbeAck。
  7. 若有需要，从代理还需访问存储结构。
  8. 从代理向原请求设备发送Grant。
  9. 原主代理以GrantAck说明此次事务成功完成。

虽然这三个流程构成了所有涉及缓存块传输的TileLink事务的基础，但是当它们临时地重叠或分层地组合时，会出现一些边界情况。现在我们将讨论TileLink如何管理并发性，并分散到各主从代理之间。

TileLink假设消息并不完全是点到点的有序的传递，来自高优先级通道的消息必须能够在网络中先于较低优先级的消息处理，从端充当连接到它的所有主端的一个同步节点。由于每个事务都必须通过发送给从端的一条Acquire消息作为初始消息，因此从端可以轻松对事务进行排序。一个非常安全的实现方式是一次只接受一个事务，但是这种方式对性能影响巨大，而且事实证明我们可以在继续提供正确的序列化的同时增加并发性。尽管事务有着天然的分布式属性，对代理的行为施加一些限制，仍能够保证事务间的有序性。下图描述了每种操作并发的一些限制。

image-20250306225754731

对TileLink代理上的并发限制在发射或阻塞请求消息方面最容易理解。所有请求消息都会引发响应消息，并且响应消息保证最终产生向前推进的效果，但是在某些情况下，在收到还未处理的响应消息之前，不应该发出针对同一块的递归请求消息。我们按照请求消息类型来对这些情况分类：

  • Acquire：如果在块上有一个pending的Grant块，主端就不应发射一个Acquire。一旦Acquire被发出，主端不应该在该块发出进一步的Acquire，直到它收到一个Grant。
  • Grant：在块上有一个pending的ProbeAck时，从端不应该发射Grant。一旦发出了一个Grant时，从端不应该在该块上发射Probe，直到它收到一个GrantAck。
  • Release：在块上有一个pending的Grant时，主端不应该发射一个Release。一旦发出了一个Release后，主端不能发射ProbeAck，直到它收到来自从端确认写回操作完成的ReleaseAck。
  • Probe：在块上有一个pending的GrantAck时，从端不应该发射一个Probe。一旦发射了一个Probe，从端不能进一步发射Probe，直到它收到一个ProbeAck。

image-20250306231030603

上图展示了一个消息流，包含了Grant和Probe，具体如下：

  1. 主代理A先发送Acquire，但由于网络延迟，后到从代理。
  2. 主代理B后发送Acquire，但先到达从代理，被序列化在A的前面。
  3. 从代理向A发送Probe，即使A还在等待Grant，也必须先处理Probe。
  4. 从代理接收到A的ProbeAck后，向B发送Grant。
  5. 从代理接收到A的Acquire，但由于正等待B的GrantAck，所以现在还不能处理这个请求。
  6. 一旦接收到B的GrantAck，A的事务就可以正常处理了。
  7. 从代理向B发送Probe，但这个操作被在上一个Grant之后。
  8. 从代理向A发送合适类型的Grant(包括数据副本)，说明A在Acquire后被Probe过。

image-20250306231336559

上图展示了一个消息流，包含了Release和Probe，具体如下：

  1. 主代理A向从代理发送Acquire。
  2. 与此同时，主代理B通过Release主动剔除相同的数据缓存块。
  3. 从代理向B发送Probe。
  4. 从代理等待每个发送出的Probe，但可以处理主动发起的Release。从代理发送ReleaseAck确认主动写回的操作完成。
  5. B在接收到写回确认前不处理Probe。
  6. 在从代理接收到B的ProbeAck后，A的事务就可以正常执行了。

TL-C Messages

权限转换新增的三个通道有六个新消息，另外新增了一个通道A消息、三个通道D消息。新的通道是B、C和E，新的消息类型是Acquire、Probe、ProbeAck[Data]、Release[Data]、ReleaseAck、Grant[Data]和GrantAck。

AcquireBlock

AcquireBlock消息是主代理计划在本地缓存数据块的副本时，发起的请求消息类型，主代理还可以使用这种消息类型来升级他们已缓存块上的权限（例如，获得只读副本的写权限），与Get消息一样，Acquire消息本身不包含数据，下表说明了通道A内该消息的信号编码。

image-20250306232112160

AcquirePerm

AcquirePerm消息是主代理计划升级缓存数据块的权限，且无需提供数据副本时，发起的请求消息类型，下表说明了通道A内该消息的信号编码。

image-20250306232227402

ProbeBlock

ProbeBlock消息是从代理用来查询或修改由特定主代理存储的数据块的缓存副本的权限的请求消息，从代理响应另一个主代理的Acquire或主动发起，可以取消主代理对一块缓存块的权限，下表说明了通道B内该消息的信号编码。

image-20250306232341927

ProbePerm

ProbePerm消息是从代理用来查询或修改由特定主代理存储的数据块的缓存副本的权限的请求消息，从代理响应另一个主代理的Acquire或主动发起，可以取消主代理对一块缓存块的权限，不过和ProbeBlock不同的是，ProbePerm要求不需要提供数据副本就可以发起请求，下表说明了通道B内该消息的信号编码。

image-20250306232441339

ProbeAck

ProbeAck消息是主代理用来回复Probe的消息，下表说明了通道C内该消息的信号编码。

image-20250306232604741

ProbeAckData

ProbeAckData消息是主代理使用的响应消息，用于确认接收到Probe，并写回发送请求的从代理所需的脏数据，下表说明了通道C内该消息的信号编码。

image-20250306232656619

Grant

Grant消息是一个响应也是一个请求消息，从代理使用它来确认接收到一个Acquire，并提供访问缓存块的权限给原始发送请求的主代理，下表说明了通道D内该消息的信号编码。

image-20250308111959008

GrantData

GrantData消息既是响应也是请求消息，从代理使用它向原始请求主代理提供确认消息以及数据块副本，下表说明了通道D内该消息的信号编码。

image-20250308111701640

GrantAck

GrantAck响应消息被主代理用来提供事务完成的最终确认消息，同时也被从代理用来确 保操作的全局序列化，下表说明了通道E内该消息的信号编码。

image-20250308111741557

Release

Release消息是主代理用来主动降低其对一个缓存数据块的权限的请求消息，下表说明了通道C内该消息的信号编码。

image-20250308111839616

ReleaseData

ReleaseData消息是主代理发起的请求消息，用于主动降低对一块缓存数据块的权限，并将脏数据写回从代理，下表说明了通道C内该消息的信号编码。

image-20250308111857294

ReleaseAck

ReleaseAck消息是一个从代理发起的响应消息，用来响应Release[Data]，用于确保从代理的操作的全局序列化，下表说明了通道D内该消息的信号编码。

image-20250308111940100

TL-UL and TL-UH Messages on Channel A and Channel D

TL-C规定了TL-UL和TL-UH现有消息的权限转换：

  • Get操作隐式地将权限Cap为None（Invalid）。
  • PutFullData、PutPartialData、ArthmeticData、LogicalData隐式地将权限Cap为非Read+Write（主干或顶点），即None（Invalid）或Read（分支）。

TL-UL and TL-UH messages on B and C