缓存维护与Barrier：系统级一致性的协调机制
引言
在ACE系统中，硬件一致性协议自动维护缓存之间的数据一致性，但软件仍然需要某些机制来管理缓存。例如，当软件需要确保数据已经写回主存以便DMA设备访问时，或者当软件需要确保所有缓存都不再持有某个地址的副本时，就需要缓存维护操作（Cache Maintenance Operations，CMO）。
同时，在多核系统中，软件还需要建立事务之间的顺序关系。例如，当一个Master写入数据数组后设置标志位，其他Master必须能够观察到数组的更新才能读取标志位。这种顺序保证需要Barrier事务来实现。
缓存维护和Barrier是ACE协议中两个重要的系统级协调机制。它们虽然不直接参与数据的一致性维护，但对于系统的正确运行至关重要。理解这些机制，不仅要理解它们的功能，更要理解它们如何与一致性协议协同工作，以及它们的设计如何平衡软件需求和硬件实现复杂度。
本文将从软件需求出发，深入解析缓存维护操作的设计和实现，探讨Barrier事务的工作原理和应用场景，揭示这些机制如何成为系统级一致性协调的重要组成部分。
缓存维护操作：软件缓存管理的硬件支持
缓存维护操作是ACE协议为软件提供的缓存管理工具。虽然硬件一致性协议自动维护缓存之间的数据一致性，但软件仍然需要某些控制能力来管理缓存行为。
缓存维护操作主要分为两类：缓存清理（Cache Cleaning）和缓存无效化（Cache Invalidation）。缓存清理确保脏缓存行的内容被写回主存，使得非一致性代理（如DMA设备）能够访问到最新的数据。缓存无效化确保后续的加载操作不使用缓存的副本，而是直接从主存读取，使得一致性或非一致性代理可以更新该位置。
这两种操作反映了软件在不同场景下的需求。当软件需要将数据传递给DMA设备时，它需要确保数据已经写回主存，因此需要缓存清理。当软件需要更新内存内容时，它需要确保所有缓存都不再持有旧数据的副本，因此需要缓存无效化。
ACE协议定义了三种缓存维护事务：CleanShared、CleanInvalid和MakeInvalid。CleanShared确保指定域内所有缓存副本都是Clean的，并且所有相关的写操作都是可观察的。CleanInvalid确保指定域内所有缓存副本都被无效化，如果是脏的则先写回主存，并且所有相关的写操作都是可观察的。MakeInvalid确保指定域内所有缓存副本都被无效化，但脏数据可能被丢弃。
这些事务类型的设计反映了不同的软件需求。CleanShared适用于需要确保数据已经写回主存但不需要无效化缓存的场景。CleanInvalid适用于需要确保数据已经写回主存并且缓存被无效化的场景。MakeInvalid适用于只需要无效化缓存而不关心脏数据的场景。
CMO的域属性：精确控制维护范围
缓存维护操作的域属性决定了哪些缓存需要执行维护操作。这种设计允许软件精确控制维护操作的范围，在保证正确性的同时最小化性能开销。
对于Non-shareable域的CMO，如果事务是Cacheable的，它只影响发起Master的下游缓存（in-line caches）。如果事务是Non-cacheable的，它不影响任何缓存。这种设计反映了Non-shareable域的特性：只涉及单个Master，不需要与其他Master协调。
对于Inner Shareable域的CMO，如果事务是Cacheable的，它影响Inner域内的对等缓存（peer caches）和下游缓存。如果事务是Non-cacheable的，它只影响Inner域内的对等缓存。这种设计允许软件在处理器集群级别执行缓存维护，而不影响其他集群。
对于Outer Shareable域的CMO，如果事务是Cacheable的，它影响Outer域内的所有对等缓存和下游缓存。如果事务是Non-cacheable的，它影响Outer域内的所有对等缓存。这种设计允许软件在系统级别执行缓存维护，确保所有相关缓存都被维护。
System域不能用于CMO事务，因为System域主要用于设备内存，而设备内存不允许缓存。这种限制确保了CMO事务只能用于可缓存的内存区域。
域属性的选择需要仔细考虑。过于宽泛的域会增加维护操作的开销，因为需要维护更多的缓存。过于狭窄的域可能导致维护不完整，因为某些缓存可能被遗漏。软件需要根据具体的应用场景选择合适的域属性。
CMO的传播机制：多级缓存层次的支持
在具有多级缓存层次的系统中，CMO操作需要向下游传播，以确保所有层级的缓存都被正确维护。这种传播机制的设计考虑了系统拓扑的复杂性。
CMO必须向下游传播的条件是：CMO是Cacheable的，并且存在下游缓存可能分配了该缓存行，并且在该缓存下游存在观察者。这种设计确保了CMO操作能够到达所有需要维护的缓存层级。
控制CMO传播的机制是实现定义的，选项包括使用接口控制信号或改变接口属性。例如，缓存的Slave接口可以配置为接受CMO，但Master接口可能配置为不发出CMO。这种灵活性允许系统设计者根据具体需求配置CMO的传播行为。
CMO传播的设计考虑了系统性能。如果CMO不需要向下游传播，组件可以立即响应CMO，而不需要等待下游的响应。这种设计减少了CMO操作的延迟，提高了系统性能。
然而，如果CMO需要向下游传播，组件必须等待下游的响应才能完成CMO操作。这种设计确保了CMO操作的完整性，所有层级的缓存都被正确维护。
CMO的信号通道：读通道与写通道的选择
ACE协议允许CMO在读通道或写通道上传输，这种设计考虑了不同组件的实现特性和系统兼容性。
在传统设计中，CMO在读通道（AR和R通道）上传输。这种设计保持了与早期ACE规范的兼容性，使得传统组件可以继续工作。CMO事务在AR通道上发出请求，在R通道上返回单beat响应，表示CMO已被观察，所有缓存行已被清理和无效化（如果需要）。
在新设计中，协议推荐CMO在写通道（AW和B通道）上传输。这种设计简化了CMO的处理，因为写通道不需要数据传输，更适合CMO这种不涉及数据传输的操作。CMO事务在AW通道上发出请求，在B通道上返回响应，W通道不进行数据传输。
CMO_On_Read和CMO_On_Write属性用于指示接口支持哪些通道。如果CMO_On_Read为True，接口支持在读通道上传输CMO。如果CMO_On_Write为True，接口支持在写通道上传输CMO。这种设计允许系统设计者根据组件特性选择最合适的通道。
对于写通道上的CMO，只有CleanInvalid和CleanShared被支持，MakeInvalid不被支持。这种限制反映了写通道CMO的设计目标：主要用于需要写回脏数据的操作。
Barrier事务：建立事务顺序的机制
Barrier事务是ACE协议中用于建立事务之间顺序关系的机制。在多核系统中，软件经常需要确保某些事务在其他事务之前被所有Master观察到，Barrier事务提供了这种保证。
ACE协议支持两种Barrier类型：内存Barrier（Memory Barrier）和同步Barrier（Synchronization Barrier）。内存Barrier保证如果域内任何其他Master能够观察到Barrier之后发出的任何事务，它必须能够观察到Barrier之前发出的所有事务。同步Barrier保证Barrier之前发出的所有事务在Barrier完成时对域内所有Master都是可观察的。
这两种Barrier的区别在于保证的强度。内存Barrier只保证顺序关系，不要求所有Master同时观察到事务。同步Barrier要求所有事务在Barrier完成时对所有Master都是可观察的，这提供了更强的保证。
内存Barrier适用于基于内存的通信场景。例如，当一个Master写入数据数组后设置标志位时，它可以在设置标志位之前发出内存Barrier，确保任何能够观察到标志位的Master都能观察到数组的更新。
同步Barrier适用于需要与边带信号（如中断）协同的场景。例如，当一个Master写入数据数组后生成中断时，它可以在生成中断之前发出同步Barrier，确保当Barrier完成时，所有Master都能观察到数组的更新。
Barrier对：读Barrier和写Barrier的协同
ACE协议要求Master必须成对发出Barrier事务：一个在读地址通道上，一个在写地址通道上。这种设计考虑了AXI协议的双通道架构，确保两个通道上的事务都能正确排序。
对于每个地址通道，在Barrier事务之前发出的任何事务都被定义为在Barrier之前，即使它在另一个通道的对应Barrier之后发出。这种定义确保了Barrier对的一致性：无论事务在哪个通道上，它们相对于Barrier的顺序都是一致的。
一个事务只有在收到读Barrier响应和写Barrier响应之后才被定义为在Barrier之后。这种定义确保了Barrier的完整性：只有当两个Barrier都完成时，Barrier才真正完成。
Barrier对必须具有相同的AxID、AxBAR、AxDOMAIN和AxPROT值。如果ARID和AWID信号宽度不同，较窄的版本必须零扩展到较宽的版本。这种要求确保了Barrier对可以被正确识别和匹配。
Barrier对必须在读地址通道和写地址通道上以相同的顺序发出。这种要求确保了Barrier对的一致性，避免了顺序混乱。
Master不需要在同一周期发出Barrier对的两个事务，但必须在合理的时间内发出。这种灵活性允许Master根据通道状态优化Barrier的发出时机，同时确保Barrier对能够及时完成。
Barrier的域属性：顺序保证的范围
Barrier事务的域属性决定了顺序保证的范围。不同的域属性提供了不同级别的顺序保证，软件可以根据具体需求选择合适的域。
对于Non-shareable域的Barrier，它只作为当前事务流的Barrier。当两个或多个事务流合并时，不需要相对于新合并的事务流建立顺序关系。这种设计反映了Non-shareable域的特性：只涉及单个Master，不需要与其他Master协调。
对于Inner Shareable域的Barrier，必须建立与同一Inner Shareable域内所有Master的其他事务的顺序关系。这种设计允许软件在处理器集群级别建立顺序关系，而不影响其他集群。
对于Outer Shareable域的Barrier，必须建立与同一Outer Shareable域内所有Master的其他事务的顺序关系。这种设计允许软件在系统级别建立顺序关系，确保所有相关Master都能观察到正确的顺序。
对于System域的Barrier，必须建立与所有其他事务的顺序关系。对于同步Barrier，响应只有在Barrier之前发出的所有事务都已到达目标Slave时才能给出。这种设计提供了最强的顺序保证，适用于需要全局顺序的场景。
域属性的选择需要仔细考虑。过于宽泛的域会增加Barrier操作的开销，因为需要协调更多的Master。过于狭窄的域可能导致顺序保证不足，因为某些Master可能被排除在外。软件需要根据具体的通信模式选择合适的域属性。
域边界与Bi-section边界：Barrier响应的关键
Interconnect响应Barrier事务的能力取决于它在系统中的位置，特别是相对于域边界（Domain Boundary）和Bi-section边界（Bi-section Boundary）的位置。
域边界是域内所有Master组件下游的接口。对于接口成为域边界，所有Master访问的地址集合必须相同，并且所有Master对这些地址的访问都必须通过该接口。这种定义确保了域边界是域内所有Master的共同下游点。
Bi-section边界是域内Master子集下游的接口，但不是所有Master的下游。对于接口成为Bi-section边界，子集内所有Master访问的地址集合必须相同，并且所有Master对这些地址的访问都必须通过该接口，同时域内但不在子集中的Master不能通过该接口访问这些地址。这种定义确保了Bi-section边界是子集Master与其他Master之间的通信点。
对于内存Barrier，Interconnect可以在适当的Bi-section边界、域边界或域边界之外响应。这种设计允许Interconnect在系统的不同位置响应Barrier，提供了实现的灵活性。
对于同步Barrier，如果应用于Non-shareable、Inner Shareable或Outer Shareable域，Interconnect可以在域边界或域边界之外响应。如果应用于System域，Interconnect只有在Barrier之前的所有事务都已到达目标Slave时才能响应。这种设计确保了同步Barrier的强保证。
Barrier实现技术：保证顺序的三种方法
Interconnect可以使用三种技术来实现Barrier的顺序保证：阻塞所有事务并发送Barrier、阻塞所有事务并等待完成、以及危险检查事务。
第一种技术是阻塞所有在Barrier之后收到的事务，并向下游发出Barrier事务。阻塞在收到下游发出的Barrier事务的读数据通道和写响应通道响应后解除。这种技术简单直接，但可能导致性能问题，因为所有事务都被阻塞。
第二种技术是阻塞所有在Barrier之后收到的事务，并等待Barrier之前的事务提供响应。阻塞在所有Barrier之前的事务都提供响应后解除。使用这种技术需要所有事务都具有确保响应来自域内所有Master可观察位置的属性。这种技术可以减少阻塞时间，但需要更复杂的实现。
第三种技术是危险检查事务。Interconnect阻塞所有在Barrier之后收到的事务，直到Barrier之前对相同或重叠地址的事务都提供响应。这种技术最精细，只阻塞可能冲突的事务，但需要地址比较逻辑，实现复杂度最高。
这三种技术的选择取决于具体的系统需求和实现约束。简单的实现可以使用第一种技术，保证正确性但可能影响性能。复杂的实现可以使用第三种技术，在保证正确性的同时优化性能。
CMO与Barrier的协同：软件缓存管理的完整工具集
CMO和Barrier虽然功能不同，但它们共同构成了软件缓存管理的完整工具集。理解它们如何协同工作，有助于正确使用这些机制。
一个典型的场景是软件需要将数据传递给DMA设备。首先，软件需要确保数据已经写回主存，因此发出CleanInvalid CMO。这个CMO确保所有缓存中的脏数据都被写回主存，并且所有缓存副本都被无效化。然后，软件可能需要确保DMA设备能够访问到数据，因此发出同步Barrier。这个Barrier确保所有写操作（包括CMO操作）都对DMA设备可见。
另一个典型场景是软件需要更新共享数据结构。首先，软件发出MakeInvalid CMO，确保所有缓存都不再持有旧数据的副本。然后，软件更新数据结构。最后，软件发出内存Barrier，确保其他Master能够观察到更新后的数据结构。
这些场景展示了CMO和Barrier如何协同工作。CMO负责管理缓存状态，确保数据的一致性和可见性。Barrier负责建立事务顺序，确保操作的可见性顺序。两者结合，为软件提供了完整的缓存管理和顺序控制能力。
实际应用：CMO和Barrier的典型使用场景
理解CMO和Barrier的关键在于理解它们在实际应用中的使用场景。让我们通过几个典型场景来说明这些机制的工作方式。
第一个场景是DMA数据传输。当软件需要将数据传递给DMA设备时，它首先发出CleanInvalid CMO，确保所有缓存中的脏数据都被写回主存，并且所有缓存副本都被无效化。然后，软件发出同步Barrier，确保所有写操作都对DMA设备可见。最后，软件启动DMA传输。这个序列确保了DMA设备能够访问到最新的数据。
第二个场景是共享数据结构的更新。当一个Master需要更新共享数据结构时，它首先发出MakeInvalid CMO，确保所有缓存都不再持有旧数据的副本。然后，Master更新数据结构。最后，Master发出内存Barrier，确保其他Master能够观察到更新后的数据结构。这个序列确保了数据更新的正确性和可见性。
第三个场景是内存映射I/O。当软件需要访问内存映射I/O设备时，它可能需要确保之前的写操作已经完成。软件发出同步Barrier，确保所有写操作都对I/O设备可见。然后，软件访问I/O设备。这个序列确保了I/O设备能够看到所有相关的写操作。
这些场景展示了CMO和Barrier在实际应用中的重要性。它们虽然不是数据一致性协议的核心，但对于系统的正确运行至关重要。理解这些机制，有助于正确设计和实现多核系统。
总结：系统级协调的完整机制
缓存维护操作和Barrier事务是ACE协议中两个重要的系统级协调机制。它们虽然不直接参与数据的一致性维护，但对于系统的正确运行至关重要。
CMO为软件提供了缓存管理的能力，允许软件控制缓存的状态和行为。通过CleanShared、CleanInvalid和MakeInvalid三种事务类型，软件可以精确控制缓存维护的范围和方式。通过域属性的选择，软件可以控制维护操作影响的范围，在保证正确性的同时最小化性能开销。
Barrier为软件提供了建立事务顺序的能力，允许软件确保某些事务在其他事务之前被所有Master观察到。通过内存Barrier和同步Barrier两种类型，软件可以根据具体需求选择合适的顺序保证强度。通过域属性的选择，软件可以控制顺序保证的范围，在保证正确性的同时优化性能。
理解CMO和Barrier，不仅要理解它们的功能，更要理解它们如何与一致性协议协同工作，以及它们的设计如何平衡软件需求和硬件实现复杂度。只有深入理解这些机制，才能正确使用它们，充分发挥ACE协议的能力。
在后续的文章中，我们将深入探讨ACE事务的完整流程，通过典型场景的完整解析，展示ACE协议各个组件如何协同工作，实现系统级的一致性保证。
本文是ACE协议学习系列的第六篇，下一篇将通过典型场景的完整解析，展示ACE协议各个组件如何协同工作。
