在计算中，术语“缓存”指的是一种硬件或软件组件，它存储数据的方式可以更快地满足未来对该数据的请求。由于我是一名专业的硬件设计工程师，并且本专栏主要关注维护硬件缓存的一致性，所以让我们从忘记软件缓存等野兽的存在开始。
我不了解你，但我已经忘记了(我不喜欢自夸，但随着年龄的增长，我越来越擅长忘记事情)。
让我们首先回顾一下整个缓存难题是如何产生的。这一切都始于去年的大型计算机(提示竖琴音响效果想象一下使用你选择的时间交通工具回到过去)．
“大型机”一词最初的用法来自一个大的机柜，称为主框架，里面装有中央处理单元(CPU)和主存储器(后来，大型机这个名字被用来区分高端商用计算机和功能较弱的机器)。
在某些系统中，主存托管在CPU旁边的独立机柜中。为了避免你在这一点上怀疑我，我刚刚问了我的朋友史蒂夫·莱布森，他是公司的首席分析师和合伙人TIRIAS研究如果他能脱口而出什么例子，他就会这样回答:
嗨，Max，我能想到三个主存不在CPU柜里的例子。第一个是曼彻斯特的婴儿，使用了威廉姆斯管RAM。在这种情况下，存储是由单色阴极射线管(crt)上的荧光粉持久性提供的。这种存储技术出现在磁芯之前。另外两台电脑是旋风和AN / FSQ-7机器，后者被用于圣人．这是第一台，也可能是第二台使用磁芯的计算机。我记得看到一个SAGE装置，可能在计算机历史博物馆，其中磁芯平面被呈现在一个单独的、独立的机柜中(见图这一列)．哦，还有第一个“尤尼华科”电脑面世机器使用水银延迟线和声波脉冲作为移位寄存器存储器。这些东西肯定不在一个柜子里。当装满水银时，它们真的有一吨重。这项技术源自第二次世界大战的雷达存储器[…]
问题是，即使主存是由于与CPU位于同一个机柜中，数据在两个子系统之间读写和来回传输的时间相对较长。因此，缓存内存的想法诞生了，这个名字来源于法语单词，意思是“一个安全的存储场所”(名词)或“将某物存储在一个安全的地方”(动词)。
无缓存的主机(左)和有缓存的主机(右)
(图片来源:Max Maxfield)
缓存是用最快的技术实现的相对较小的内存(“该死的功耗”)，并且它位于尽可能靠近CPU的位置。事实上，缓存通常被认为是CPU的一部分;我把它分开的原因是为了简化后面的图表。
应该指出的是，上面的例子充其量只是一个粗略的简化。例如，当CPU第一次从主存请求一个数据时，该数据将同时加载到CPU和缓存中(而不是像我的插图所暗示的那样“通过”缓存)。如果CPU第二次请求相同的数据，它将来自缓存(假设此条目在此期间没有被其他东西覆盖)。如果需要的数据在缓存中，我们称之为“缓存命中”。如果需要的数据不在缓存中，我们称之为“cache miss”。当CPU希望存储计算结果时，该数据可以同时写入缓存和主存，在这种情况下，我们使用术语“write-through”。或者，数据最初可能只写入缓存，写入主存储被推迟，直到缓存的那部分即将被覆盖，在这种情况下，我们使用术语“回写”(或“后写”)。
这里有各种各样的技巧。例如，当一个程序从主存中访问一段数据时，它通常会希望访问位于附近的其他数据(即在附近的内存位置)。因此，除了将请求的数据复制到缓存中之外，系统还可能“预取”其他可能很快会感兴趣的数据。指令也是如此。事实上，我们所展示的单个缓存通常分为两个实体:数据缓存和指令缓存。
第一个商用的具有高速缓存的大型计算机是IBM系统/360 85型1968年1月宣布，1969年12月首次发货。早期的微处理器没有缓存。相比之下，据我所知，第一个拥有片上缓存的微处理器是仙兆半导体公司在1986年推出的C100。C100基于32位类似risc的指令集架构(ISA)，称为Clipper架构。
顺便说一句，1985年推出的英特尔386可以支持16到64KB的外部(芯片外)缓存(有时称为2级或L2级缓存，即使没有1级或L1级缓存)。随后在1989年又推出了Intel 486，它支持8到16kb的片上L1缓存。
其他微处理器制造商不知道的是，仙童半导体公司为具有片上缓存的微处理器概念申请了专利。1987年，当飞兆公司将克利伯(Clipper)的架构和相关专利出售给鹰图公司(Intergraph Corporation)时，这些宝贵的知识可能已经被遗漏了。你只能想象其他微处理器制造商的惊讶和惊愕——他们所有的高端微处理器在这个时候都炫耀片上缓存——当他们最终发现Intergraph坐在里面时猫鸟座椅在缓存专利方面，可以说是这样，但那是另一个故事了。
随着时间的推移，事情变得越来越复杂，设计师开始添加更多级别的缓存，他们将其命名为L1(一级)，L2(二级)，L3(三级)等等。在这种情况下，L1缓存将是最小和最快的，并且离CPU最近。L2缓存将比L1缓存大，但速度可能没有L1那么快，而且每比特的功耗可能更低。类似地，L3缓存将比L2缓存更大，但是—再一次—可能没有那么快，而且可能每比特消耗更少的能量。事实上，现代高端嵌入式、桌面和服务器微处理器可能有多达六种类型的缓存(令人难以置信)。
另一方面，一些现代cpu也经常有一个很小的“L0”缓存。通常只有几KB大小，用于存储微操作(micro-ops或µOPs)，并由CPU的功能单元直接访问。
为了便于讨论，我们假设只有三层缓存。你可能会把它想象成一个简单的堆栈，CPU在一端，L1、L2和L3缓存在中间，主存在另一端。如果是这样，我真羡慕你。我还记得我年轻天真的时候。问题是我们经常面临多核处理系统和分层内存子系统。例如，让我们考虑片上系统(SoC)的一部分，它具有两个处理器集群，每个处理器集群包含四个CPU内核。在这种情况下，我们可能会看到如下所示的内存层次结构:
SoC的一部分，显示两个处理器集群，每个处理器集群有四个处理器核心，以及L1、L2和L3缓存(图片来源:Max Maxfield)
再一次，请记住，我们在这里展示的所有内容都被简化到n次(还请记住，例如，我们可以同时拥有指令和数据缓存)。我们需要担心的下一个问题是缓存一致性(又称缓存一致性)。在如上所示的多处理器系统中，共享数据可能有多个副本:一个副本在主存中，另一个副本在请求它的每个处理器的本地缓存中。当数据的一个副本发生更改时，必须更新其他副本以反映该更改。缓存一致性是确保共享数据值的更改在整个系统中及时传播的原则。
和大多数事情一样，如果你大声说话，疯狂地做手势，这听起来很简单，但实际上这是一个相当棘手的话题，因为已经有整本书都在写这个主题了。所有这些都将我们引向验证的问题。如果您是设计上述类型SoC的团队中的一员，那么当您的设计受到实际工作负载的严重冲击时，您如何验证您的设计将保持缓存一致性?
您可能决定手工制作一套测试，但是您如何知道是否已经验证了所有的极端情况呢?一般来说，一种非常成功的验证方法是使用受约束的随机刺激序列，但当你拥有像我们在这里谈论的这样复杂的系统时，这种方法就不太适用了。这种情况下的问题是，你从刺激开始，通过所有可能的组合和电路状态的排列，直到你达到输出，但如果你考虑所有可能发生的事情，这可能会导致10^60个测试路径，这是一个愚蠢的数字。
在项目的生命周期中，我们可能在模拟中管理10^4个测试用例，可能在模拟中管理10^5个测试用例，可能在硅后管理10^6或10^7个测试用例。因此，验证工程师试图在SoC上执行系统级验证的任务是在10^60的空间中运行10^5的实验，并确保没有错误。这是一个很大的要求。他们最好挑选好的样本。
人们普遍认为，大约70%的SoC开发项目将用于创建验证测试，然后运行这些测试并调试相关SoC。这项工作的很大一部分将用于验证缓存的一致性。
令人高兴的是，有一个解决方案。我刚刚和David Kelf聊天，他是CEO，还有Adnan Hamid，他是总统的首席技术官断路器验证系统．我们谈了那么多事情，触及了那么多话题，我的大脑开始从耳朵里流出来，所以最好把事情总结如下。考虑下面的例子。
人工智能规划算法驱动的测试套件合成(图片来源:Breker)
SoC设计如图左上角所示。一个典型的验证过程将涉及验证工程师使用白板来捕获验证意图的高级流程图。在过去，他们会将此作为手工制作测试套件的起点。相比之下，在Breker世界中，它们将捕获与可执行规范相同的验证意图。
然后，Breker的工具使用可执行规范来确定从可能的输入状态到可能的输出状态的所有路径。然后我们来到了聪明的部分:使用人工智能(AI)技术，系统从所需的输出开始，并计算出实现这些输出需要什么。作为测试的一部分，它决定哪些测试需要共享资源，哪些测试可以并发执行。有多种场景，但对我来说最有趣的一个是，系统可以输出C代码在处理器核心上运行，以及应用于SoC输入/输出(I/ o)的事务。这种方法成功的一个衡量标准是比较手工测试和使用Breker的Cache Coherency TrekApp工具创建的测试的效果。
缓存一致性TrekApp的有效性(图片来源:Breker)
我认为这是你所期望看到的。在手工创建的定向一致性测试的情况下，只有有限的并发量，因为这是验证工程师能够考虑的所有问题。相比之下，缓存一致性TrekApp生成了大量的并发测试，这确实给系统带来了压力。
Adnan和David还向我介绍了一个真实的博通案例研究，其中涉及一个复杂的手机SoC。似乎一个非常能干的验证工程师花了2.5个月的时间生成了大约500个独特的、高影响的测试，但是这些测试的结果只有89%的覆盖率。顾客不满意，要求更多，这时，布雷克大张旗鼓地唱起了sarrusophone(听过，永远不会忘记)。使用他们的可执行规范技术，在短短两周内，Breker合成了一套超过10,000个测试，覆盖率达到97%。
典型用户结果(图片来源:Breker)
不要问我纵轴上有趣的反对数式缩放，因为我没有时间或精力(或语言)来解释它。
这可能是一个很好的时机来提及缓存一致性TrekApp只是TrekApp家族的一个成员，每个成员都针对设计的不同方面。其他成员包括ARM TrekApp、RISC-V TrekApp、电源管理TrekApp、安全TrekApp和网络TrekApp。
之所以现在是提到所有这些TrekApp的好时机，是因为在最近于2021年12月在加利福尼亚州圣何塞举行的设计自动化会议(DAC)上，Breker推出了他们最新、最棒的TrekApp——系统一致性TrekApp。这基本上为验证工程师提供了一个统一的框架，允许他们与其他TrekApp一起运行缓存一致性TrekApp，以验证缓存一致性与电源、安全性和中断之间的相互作用……
除了…
……我最近一直在与云服务提供商和超大规模数据中心合作，这些中心具有分解服务，如处理器机架和其他内存机架，大量的虚拟机在不间断地运行的情况下从一台服务器迁移到另一台服务器。如果您认为在单个SoC上保持缓存一致性很困难，那么想象一下这种云中心场景所涉及的问题，在这种场景中，您可能拥有分散在多个处理节点上的多个缓存的虚拟机。为了增加趣味性和轻浮感，可以让数据在节点之间流动。显然，在(a)实际实现体系结构和(b)让客户和他们的虚拟应用程序到处跑之前，验证一切都将按计划工作是一个好主意。
然后我开始考虑Breker，它开始在半导体级别工作，现在在固件级别很高兴地跳跃。让我震惊的是，Breker的可执行规范方法可以扩展到这些更高层次的架构场景。
“嗯，”我想，“很多人可能会对Breker技术的发展感兴趣，包括那些创建电子设计自动化(EDA)工具套件的人，以及那些制造为这些超大规模环境提供动力的处理器和其他芯片的人。”
我大胆地对阿德南和大卫说出了我的沉思。这导致了某种意味深长的停顿，之后我被告知，这可能是“一个响亮的‘无可奉告’的绝佳时机”。’”我不知道这是否意味着他们认为这是一个愚蠢的想法。
我真的应该指出，在描述Breker技术的功能方面，我只是触及了表面。如果你有兴趣了解更多，请放心，布雷克的伙计们和女孩们会很高兴地告诉你我错过的一切。与此同时，你对目前为止听到的内容有什么看法?
