【CHI协议学习笔记—8.DVM操作】

最新推荐文章于 2024-10-21 17:25:19 发布

大小姐在学习

最新推荐文章于 2024-10-21 17:25:19 发布

阅读量2.7k

点赞数 36

分类专栏： CHI 文章标签： arm 笔记学习

本文链接：https://blog.csdn.net/m0_62972188/article/details/139436613

版权

CHI 专栏收录该内容

1 篇文章

订阅专栏

学习笔记搬运到博客的Day1——CHI协议之DVM operations！
参考文档《ARM® AMBA®5 CHI Architecture Specification》

【CHI协议】-8.DVM 操作

前言
一、DVMop是什么？
二、DVM事务流
三、DVMop 域段
- 1.DVMop Payload
- 2.DVMop和SnpDVMop的packet(包）
总结

前言

博客初衷

初入职场小白，学习CHI协议的过程中发现DVM相关的博客内容并不太多，很多CHI协议的博客也是针对AMBA协议内容前面章节的概念等，因此在这里记录和分享我的学习知识积累和一些思考，供自己和大家一起学习和指正。

一、DVMop是什么？

首先，回顾一下，CHI协议包括几种transaction：

read
write
dataless
snoop
atomic
other（DVMop、Prefetch Tgt、PcrdReturn）

其中DVMop(Distributed Virtual Memory Operation)就是一种特殊的操作，用于管理虚拟内存的操作。那么问题来了，为什么需要有这样的操作以及底层原理是什么呢？这里不做深究，因为路漫漫其修远兮，博主也想知道这个问题hh(无辜脸），希望未来有时间能在此补充自己的学习和思考(狗头）。

二、DVM事务流

那么发出DVM请求事务的流程是怎样的呢？在介绍DVM事务流之前，先介绍一下支持的DVM操作有哪些：

TLB Invalidate
Branch Predictor Invalidate
Instruction Cache Invalidate
Physical address invalidate
Virtual address invalidate
Synchronization

基于此，可以把DVM分为同步和非同步两种类型（博主的理解是除了Synchronization，其他都是非同步，目前只实践过TLB Invalidate和Sync两种），两种类型对应有不同的事务流情形，下面分别介绍。

1.非同步DVM事务流

首先，贴上协议原文的非同步DVM的事务流图如下：
在这里插入图片描
总共分为以下几个步骤：

某个请求节点RN-F0通过请求通道TXREQ发出DVM操作请求；处理DVM请求的节点MN通过请求接收通道RXREQ接收请求并通过响应通道TXRSP返回一个DBIDresp的响应给原始请求节点，表示有data buffer用于接收数据。
原请求节点RN-F0接收到MN节点的响应后，通过数据通道DAT发送一个8byte的数据包给MN节点。
然后MN节点向系统中所有的RN-F和RN-D（支持DVM操作的RN节点）节点广播SnpDVMOp窥探请求。SnpDVMOp在SNP通道上发送，会发送两次，SnpDVMOp的两个部分分别用后缀_P1和_P2进行标记。（两次请求的TxnID相同并且其他RN必须有足够的资源接收SnpDVMop请求）
完成所需的操作后，SnpDVMOp的每个接收方会向MN发送单个snprep响应。
（发送snprep意味着目标RN已经将SnpDVMOp转发到所需的RN结构（比如说core)，并且已经释放了接受另一个DVM操作所需的资源。这并不意味着请求的DVM操作已经完成，这也是与同步DVM的区别之一）
在接收到所有snprep响应后，MN向请求节点发送一个Comp响应表示事务结束。

2.同步DVM事务流

同步DVM事务流的结构图如下：
在这里插入图片描述
实际上与非同步是类似，但有一些细微差别，总体步骤如下：

RN-F0向MN发送DVMOp(Sync)请求，MN接受DVMOp(同步)请求并向请求者发送一个DBIDResp响应。
（在RN发送DVMOp(Sync)之前，先前DVMOp同步请求必须收到Comp响应）
RN-F0在数据通道上发送数据包给MN，数据包大小为8字节。
MN向RN-F1发送SnpDVMOp，SnpDVMOp在SNP通道上发送，同样发送两次侦听请求，SnpDVMOp的两个部分分别用后缀_P1和_P2进行标记。
完成DVM同步操作后，RN-F1向MN发送snpresp响应。
（发送snprep意味着所有与DVM相关的操作已经在RN结构上完成，并且目标RN已经释放了接受另一个SnpDVMOp所需的资源，同步和非同步DVM的主要区别体现在这里）
在接收到所有snprep响应后，MN向请求节点发送一个Comp响应表示DVM事务完成。

3.事务流控制

对于DVM操作过程中的各个事务流，有一定的控制要求如下：

DVMop请求流：

DVMOp可以接收来自MN的RetryAck响应，可以理解为支持retry操作吧。
接收到RetryAck响应的DVMOp必须等待具有相应PCrdType的MN的PCrdGrant响应。
所有之前需要DVMOp(同步)保证完成的DVMOp请求必须在RN发送DVMOp(同步)之前收到Comp响应。
一个MN必须有足够的资源来接受系统中所有的DVMOp(同步)，并且仍然有资源来接受至少一个DVMOp(非同步)请求。
如果DVMOp(Sync)不需要保证完成DMVOp(Non-sync)，则允许来自同一RN的DVMOp(Non-sync)和DVMOp(Sync)重叠。所以可以理解为同步DVM请求发出必须要求之前的同步请求已经完成，但是如果不要求非同步的必须完成，那么是允许同步和非同步DVM的在同一个RN节点同时发生的

SnpDVMop请求流：

每个SnpDVMOp事务需要两个SnpDVMOp请求包。
两个SnpDVMOp请求包对应于一个单一的事务必须使用相同的TxnID。
两个SnpDVMOp请求包对应于一个单一的事务可以以任何顺序发送或接收。
多个SnpDVMOp(非同步)事务可以从MN中outstanding发出。
从一个MN到一个RN，只有一个SnpDVMOp(Sync)事务是可以被outstanding
为了防止死锁，由于SnpDVMOp请求的两个部分使用snoop通道，因此只有在接收RN有预先分配的资源来接受SnpDVMOp事务的两个部分时，才能发送SnpDVMOp事务。
RN必须在接收到与该事务相对应的两个SnpDVMOp请求包之后才对该事务提供响应。
只有当RN能够接受来自MN的进一步SnpDVMOp时，它才必须对SnpDVMOp提供响应
系统中的每个RN-F和RN-D指定它可以同时接受的SnpDVMOp事务的数量。
除了SnpDVMOp(Sync)事务之外，系统中的每个RN-F和RN-D必须能够接受至少一个SnpDVMOp(非同步)事务。
必须同时接受的SnpDVMOp事务的最小数量为2，对于没有指定数量的RN，这是默认数量。

三、DVMop 域段

两个SnpDVMOp请求报文对应一个DVMOp，以下字段的值必须相同:•TxnID•Opcode•SrcID•TgtID

对于具体的域段介绍，大家可以参考协议原文的表格，此处不再赘述。这里介绍一下DVMop的payload，我理解的就是DVM操作产生的相关DVM事务请求中承载的DVM相关的信息的部分，包括前面提到的操作类型以及更详细的信息等。

1.DVMop Payload

DVM操作的主要相关事务请求包括RN发给MN的DVMop和MN发给其他RN的SnpDVMop。

RN到MN的payload分布在:
 -  来自RN的DVM请求中的addr字段
 -  NonCopyBackWrData报文中低8字节写数据。   
MN到RN的DVM操作的payload分布在两个SnpDVMOp请求数据包的addr字段上。

以下截取了协议原文中DVMop相关的域段及其含义：
在这里插入图片描述

2.DVMop和SnpDVMop的packet(包）

协议中表格8-3显示了来自RN的DVMOp请求中的负载分布以及来自MN的SnpDVMOp请求中的负载分布。

在DVMOp中，请求中的addr字段和8字节写数据的组合传输完整的payload。addr[3]在请求中不使用，必须设置为0。
在两个SnpDVMOp请求中，两个请求的addr字段的组合传输了完整的payload。在SnpDVMOp请求中使用addr[3]来指示正在传输的有效负载的哪一部分。

注意：Snoop报文不包括三个最低有效地址位。例如，VA Valid字段被放置在Addr[4]通常占用的位置。在Request报文中，这将是Addr字段中的第5位，但是在Snoop报文中，这将是第2位。虽然不知道为什么，但确实在实践过程中追波形和数据包发现如此的。
此外，PA[6]与Data[4]在写数据包中的位置相同，与Addr[4]在Snoop数据包中的位置相同。PA[6]在Part 2 Snoop包中提供，而VA Valid在Part 1 Snoop包中提供。

后续第8章的章节就是针对前文提过的几种类型的DVM操作分别对addr等字段进行解包拆解payload以及不同域段的含义介绍，理解了前面所述的内容后面也就不难理解啦！