验证符合AXI/ACE标准的互连的策略:第三部分

描述

这篇文章中,我将讨论规范中与访问重叠地址相关的一些细微差别。由于多个主站可能共享同一位置,并且数据可以分布在不同主站的缓存中,因此这是验证相干系统的重要组成部分。互连在维护此类访问的一致性方面起着非常重要的作用。

相对于对重叠事务的访问,互连应注意三个关键方面。

对事务进行排序

窥探访问的时间相对于对连贯事务的响应

如果从内存读取的数据可能与所有相关 snoop 事务完成后读取的数据不同,则从内存中“重新获取”数据

对事务进行排序

请考虑以下示例:

接口

在这里,主站 1 和主 2 希望写入同一位置,并将其大致同时存储在其本地缓存中。为此,主节点 1 和主节点 2 发送 MakeUnique 事务(如图 1a 和 2a 表示)。让我们暂时考虑一下互连不正确的行为模式的影响。假设互连发送主站 1 和主 2 MakeInvalid 侦听事务(由 1b 和 2b 表示),分别对应于它从主站 2 和主 1 收到的 MakeUnique 事务。一旦主站响应 snoop 响应(由 1c 和 2c 表示),互连将响应发送回主站(由 1d 和 2d 表示)。当事务在主服务器 1 和主服务器 2 中完成时,两个主服务器都会将缓存更新为唯一状态。这违反了协议,因为缓存行只能由主节点保持唯一状态。此外,每个主节点可能会在其本地缓存中存储不同的值,而两个主节点都错误地认为它们具有缓存行的唯一副本。显然,未正确排序的影响是不连贯的,如图所示,其中两个主节点对数据有两种不同的视图。为了解决这个问题,规范要求对重叠地址的此类访问进行排序。规范指出:

“互连有责任确保有一个定义的顺序,可以发生到同一缓存行的事务,并且所有组件的定义顺序都是相同的。如果两个主站几乎同时向同一缓存行发出事务,则互连将确定哪些事务首先排序,哪个事务最后排序。互连使用的仲裁方法未由协议定义。互连通过对事务响应和对主节点的侦听事务进行排序来指示到同一缓存行的事务顺序。排序规则如下:

• 如果主服务器向缓存行发出事务,并且在收到对其发出的事务的响应之前,它在同一缓存行接收侦听事务,则侦听事务定义为优先排序。

• 如果主服务器向缓存行发出事务,并且在收到到同一缓存行的侦听事务之前收到对该事务的响应,则主服务器发出的事务被定义为优先排序。[1]

在上面的例子中,让我们假设互连优先于主站1。如果是这样,它必须向主站1发送一个窥探事务(2b),等待窥探响应(1c)并将响应发送回主站1(1d)。在此序列结束时,主 1 的缓存行将处于唯一状态,并可能在其缓存中写入值。然后,互连可以对主站 2 进行排序,并可以将侦听事务 (2b) 发送到主站 1,这将使主站 1 中的缓存行无效,等待侦听响应 (2c) 并将响应发送回主站 2 (2d)。在此序列结束时,主 1 的缓存行无效,主 2 的缓存行将分配给唯一状态。

Snoop 访问的时间相对于对连贯事务的响应

该规范规定了对同一缓存行的一致性事务和侦听事务的响应顺序的一些规则。这些给出如下:

“互连必须确保以下几点:

• 如果互连为主站提供对事务的响应,则在收到来自该主站的相关 RACK WACK 响应之前,它不得将该主站发送侦听事务到同一缓存行

• 如果互连将侦听事务发送到主站,则在收到来自该主站的相关 CRRESP 响应之前,它不得向该主站提供对同一缓存行事务的响应。

接口

与协议的这一方面相比,需要注意的重要一点是,此要求不适用于 WriteBack 和 WriteClean 事务,尽管规范中没有明确说明。将上述规则应用于 WriteBack 和 WriteClean 事务可能会导致死锁。这是因为允许接收到缓存行的侦听事务的主服务器将其停止,直到它启动或即将启动到同一缓存行的任何挂起的写回或 WriteClean 事务完成。换句话说,必须允许此主服务器接收对 WriteBack 或 WriteClean 事务的响应,然后才能允许传入的窥探继续(即响应它)。如果上述规则应用于 WriteBack 或 WriteClean 事务,则互连将无法向 WriteBack 或 WriteClean 事务发送响应,因为侦听事务已发送到主服务器。因此,此规则不适用于写回和写清理事务非常重要。

从内存中重新获取数据

在某些情况下,可能必须从内存中重新获取数据。例如,假设主 1 发出 ReadShared 事务,而具有缓存行脏副本的主 2 发出写回事务。假设互连发出从主内存读取 ReadShared 事务。发送到主内存的读取事务完成后,让我们假设写回有进展。在此之后,互连发送的任何窥探事务都不会返回数据,因为写回会使主 2 中的缓存行无效。但是,如果互连使用先前读取内存中接收的数据,则该互连将过时,因为 WriteBack 事务在发出读取内存后更新了内存。因此,有必要从内存中重新获取数据,并使用该数据来响应主 1。我们如何检测与此相关的问题?这些可以通过一致性检查来检测。在上面的示例中,ReadShared 事务将传递干净的数据,其内容应与内存的内容匹配。如果没有,则可能意味着互连使用了过时的数据来响应 ReadShared 事务。

测试对重叠地址的访问

测试与访问重叠地址相关的所有方案可能会让人不知所措。给定一个系统,有多个不同接口类型的端口可以将事务发送到重叠的地址。但是,并非所有访问给定地址的主节点组合都有效,因为某些主节点可能只允许访问某些地址空间,而一组主节点可能只访问一组有限的地址空间,而这些主节点组形成一个可共享性域。除此之外,对于给定地址的缓存行,具有不同初始状态的主节点可以启动许多不同的事务类型。随机化和配置感知序列的强大功能可以满足这些要求。对此进行测试的序列可以执行以下操作:

根据用户给出的可共享性域,在该域中随机选择两个主节点

根据这些主节点的接口类型,为每个主节点选择一个随机交易类型

将缓存行初始化为一组地址的有效随机状态

同时从两个主服务器发送交易

关键验证点

上一篇博客中提到的所有验证点也适用于此处。除此之外,还需要检查以下内容:

事务顺序:事务的顺序必须与所有主节点看到的顺序相同

与相干响应和窥探访问相关的排序要求

确保需要从内存中重新获取数据时的一致性

在这篇文章中,我描述了测试策略和测试相对于访问重叠地址的关键方面。

审核编辑:郭婷

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分