文档概述

本文档描述 ICache 的模块列表、设计规格、参数列表、功能概述和详述。
功能概述部分提供 ICache 整体数据流向图和过程。

术语说明

ICache 和 DCache 区别

功能用途

ICache 专门用于存储指令。当 CPU 从内存中读取指令时，这些指令会先被存储在 ICache 中。这样，当 CPU 需要再次执行相同的指令时，可以直接从 ICache 中读取，而无需再次访问速度较慢的内存，从而提高指令的读取速度，加快程序的执行效率。

DCache 用于存储数据。程序运行过程中，CPU 需要频繁地读取和写入数据。DCache 的作用就是缓存这些数据，使得 CPU 对数据的访问速度更快。当 CPU 访问内存中的数据时，如果数据已经在 DCache 中，就可以直接从 DCache 中读取或写入，减少了访问内存的次数，提高了数据访问的效率。

数据一致性问题

ICache 通常不需要考虑数据一致性问题。因为指令是只读的，一旦程序开始运行，指令的内容一般不会改变。所以，ICache 中的指令可以一直使用，直到程序结束或者新的指令被加载进来。即使内存中的指令被修改了，也不会影响 ICache 中已经缓存的指令的执行。

DCache 数据一致性是一个重要的问题。因为数据可能会被多个处理器或者设备访问和修改。如果一个处理器修改了 DCache 中的数据，而其他处理器或者设备仍然使用旧的数据，就会导致数据不一致的问题。为了保证数据一致性，需要采用一些机制，如缓存一致性协议（如 MESI 协议等），来确保所有处理器和设备看到的数据是一致的。

为什么我们需要区分数据和指令呢？原因之一是出于性能的考量。CPU 在执行程序时，可以同时获取指令和数据，做到硬件上的并行，提升性能。另外，指令和数据有很大的不同。例如，指令一般不会被修改，所以 iCache 在硬件设计上是可以是只读的，这在一定程度上降低硬件设计的成本。所以硬件设计上，系统中一般存在 L1 dCache 和 L1 iCache，L2 Cache 和 L3 Cache。

区分原因

指令访问模式是：通常按照程序的顺序依次执行，具有较高的局部性。并且在程序运行过程中通常是只读的，不会被修改。 数据访问模式是：数据的访问通常较为随机，可能涉及频繁的读写操作。数据需要支持读写操作，这意味着 DCache 需要处理数据的写入和一致性问题。

将数据和指令分开存储到 DCache 和 ICache，有利于提高命中率和减少冲突，提升性能（CPU 在执行程序时，可以同时获取指令和数据，做到硬件上的并行），简化设计（ICache 可以专注读指令，而 DCache 需要数据的读写操作，还需要考虑数据一致性问题）。

为什么需要预取

预取是 CPU 用来提高执行性能的一种技术，它在实际需要之前将指令或数据从原来存储在较慢内存中的位置取到较快的本地内存中（因此称为 “预取”）。

CPU 和内存的性能差异

由处理器和内存之前的性能差异越来大，所以我们需要预取。
从上图可以看出，1980年至2015年间，CPU的性能提升了将近一万倍，可是内存相关的性能只提升了十倍。如果等CPU需要执行相关指令或者需要修改数据的时候再从内存中去读取，那么大部分时间都会花费在等待数据上，这是不可容忍的。这时预取的重要性就体现了，把将要访问的内容提前从内存搬移到Cache中，CPU就可以即时拿到所需的内容，避免了等待。当然，如果预取做得不好，是有可能导致性能下降的，由于Cache的大小是很宝贵的，如果预取判断出错，预取的是无用的数据，然后反而把Cache中后续有可能还会用到的数据给Evict了，那么会增加系统的功耗，减低性能。

模块列表

设计规格

• 缓存指令数据
• 缺失时通过 tilelink 总线向 L2 请求数据
• 软件维护 L1 I/D Cache 一致性（fence.i）
• 支持跨 cacheline （预）取指请求
• 支持冲刷（bpu redirect、backend redirect、fence.i）
• 支持预取指请求
  • 硬件预取为 FDIP 预取算法
  • 软件预取为 Zicbop 扩展prefetch.i指令
• 支持可配置的替换算法
• 支持可配置的缺失状态寄存器数量
• 支持检查地址翻译错误、物理内存保护错误
• 支持错误检查 & 错误恢复 & 错误注入¹
  • 默认采用 parity code
  • 通过从 L2 重取实现错误恢复
  • 软件可通过 MMIO 空间访问的错误注入控制寄存器
• DataArray 支持分 bank 存储，细存储粒度实现低功耗

参数列表

若和 chisel 代码不一致，以 chisel 代码为准。

功能概述

FTQ 指针示意

FTQ 中存储着 BPU 生成的预测块，fetchPtr 指向取指预测块，prefetchPtr 指向预取预测块，当复位时 prefetchPtr 与 fetchPtr 相同，每成功发送一次取指请求时 fetchPtr++，每成功发送一次预取请求时 prefetchPtr++。详细说明见FTQ 设计文档。

ICache整体数据流向图

ICache 结构如上图所示，有 MainPipe 和 IPrefetchPipe 两个流水线，MainPipe 接收来自 FTQ 的取指请求，IPrefetchPipe 接收来自 FTQ/MemBlock 的硬/软件预取请求。

• 对于预取请求，IPrefetch 对 MetaArray 进行查询，将元数据（在哪一路命中、ECC 校验码、是否发生异常等）存储到 WayLookup 中，如果该请求缺失，就发送至 MissUnit 进行预取。

• 对于取指请求，MainPipe 首先从 WayLookup 中读取命中信息，如果 WayLookup 中没有可用信息，MainPipe 就会阻塞，直至 IPrefetchPipe 将信息写入 WayLookup 中，该方案将 MetaArray 和 DataArray 的访问分离，一次只访问 DataArray 单路，代价是产生了一个周期的重定向延迟。

• MissUnit 处理来自 MainPipe 的取指请求和来自 IPrefetchPipe 的预取请求，通过 MSHR 进行管理，所有 MSHR 公用一组数据寄存器以减少面积。

• CtrlUnit 主要负责 ECC 校验使能/错误注入等功能。从 MetaArray 读取元数据，之后向 MetaArray 写入毒化的标签，向 DataArray 写入毒化的数据。Tilelink 用于外部配置和状态监控，通过 eccctrl 和 ecciaddr 寄存器实现读写交互。

• Replacer 为替换器，采用 PLRU 替换策略，接收来自 MainPipe 的命中更新，向 MissUnit 提供写入的 waymask。

• MetaArray 分为奇偶两个 bank，用于支持跨 cacheline 的双行访问。

• DataArray 中的 cacheline 分为 8 个 bank 存储，每个 bank 中存储的有效数据为 64bit，另外对于每 64bit 还需要 1bit 的校验位，由于 65bit 宽度的 SRAM 表现不好，所以选用深度 256*宽度 66bit 的 SRAM 作为基本单元，一共有 32 个这样的基本单元。一次访问需要 34Byte 的指令数据，每次需要访问 5 个 bank($8\times 5 > 34$)，根据起始地址进行选择。

功能详述

取指/预取指请求

ICache 两条流水线的关系

FTQ 分别把取指/预取指请求发送到对应的取指/预取指流水线进行处理。如前所述，由 IPrefetch 对 MetaArray 和 ITLB 进行查询，将元数据（在哪一路命中、ECC 校验码、是否发生异常等）在 IPrefetchPipe s1 流水级存储到 WayLookup 中，以供 MainPipe s0 流水级读取。

在上电解复位/重定向时，由于 WayLookup 为空，而 FTQ 的 prefetchPtr、fetchPtr 复位到同一位置，MainPipe s0 流水级不得不阻塞等待 IPrefetchPipe s1 流水级的写入，这引入了一拍的额外重定向延迟。但随着 BPU 向 FTQ 填充预测块的进行和 MainPipe/IFU 因各种原因阻塞（e.g. miss、IBuffer 满），IPrefetchPipe 将工作在 MainPipe 前（prefetchPtr > fetchPtr），而 WayLookup 中也会有足够的元数据，此时 MainPipe s0 级和 IPrefetchPipe s0 级的工作将是并行的。

详细的取指过程见MainPipe、IPrefetchPipe和WayLookup。

硬件预取与软件预取

V2R2 后，ICache 可能接受两个来源的预取请求：

1. 来自 Ftq 的硬件预取请求，基于 FDIP 算法。
2. 来自 Memblock 中 LoadUint 的软件预取请求，其本质是 Zicbop 扩展中的 prefetch.i 指令，请参考 RISC-V CMO 手册。

然而，PrefetchPipe 每周期仅可以处理一个预取请求，故需要进行仲裁。ICache 顶层负责缓存软件预取请求，并与来自 Ftq 的硬件预取请求二选一送往 PrefetchPipe，软件预取请求的优先级高于硬件预取请求。

逻辑上来说，每个 LoadUnit 都有可能发出软件预取请求，因此每周期至多会有 LoadUnit 数量（目前默认参数为 LduCnt=3）个软件预取请求。但出于实现成本和性能收益考量，ICache 每周期至多仅接收并处理一个，多余的会被丢弃，端口下标最小的优先。此外，若 PrefetchPipe 阻塞，而 ICache 内已经缓存了一个软件预取请求，那么原先的软件预取请求将被覆盖。

ICache 预取请求接收与仲裁

• 软件预取请求不会影响控制流，即不会发送到 MainPipe（和后续的 Ifu、IBuffer 等环节），仅做：1) 判断是否 miss 或异常；2) 若 miss 且无异常，发送到 MissUnit 做预取指并重填 SRAM。

关于 PrefetchPipe 的细节请查看子模块文档。

异常传递/特殊情况处理

ICache 负责对取指请求的地址进行权限检查（通过 ITLB 和 PMP），可能的异常和特殊情况有：

需要指出，对于一般的取指流程来说，并不存在 backend 异常这一项。但 XiangShan 出于节省硬件资源的考虑，在前端传递的 pc 只有 41 / 50 bit（Sv394 / Sv484），而对于 jr、jalr 等指令，跳转目标来源于 64 bit 寄存器。根据 RISC-V 规范，高位非全 0 或全 1 时的地址不合法，需要引发异常，这一检查只能由后端完成，并随同后端重定向信号一起发送到 Ftq，进而随同取指请求一起发送到 ICache。其本质是一种 ITLB 异常，因此解释描述和处理方式与 ITLB 相同。

另外，L2 cache 通过 tilelink 总线响应 corrupt 可能是 L2 ECC 错误（d.corrupt），亦可能是无权限访问总线地址空间导致拒绝访问（d.denied）。tilelink 手册规定，当拉高 d.denied 时必须同时拉高 d.corrupt。而这两种情况都需要将取指块标记为 access fault，因此目前在 ICache 中无需区分这两种情况（即无需关注 d.denied，其可能被 chisel 自动优化掉而导致 verilog 中看不到）。

这些异常间存在优先级：backend 异常 > ITLB 异常 > PMP 异常 > MissUnit 异常。这是自然的：

1. 当出现 backend 异常时，发送到前端的 vaddr 不完整且不合法，故 ITLB 地址翻译过程无意义，检查出的异常无效；
2. 当出现 ITLB 异常时，翻译得到的 paddr 无效，故 PMP 检查过程无意义，检查出的异常无效；
3. 当出现 PMP 异常时，paddr 无权限访问，不会发送（预）取指请求，故不会从 MissUnit 得到响应。

而对于 backend 的三种异常、ITLB 的三种异常，由 backend 和 ITLB 内部进行有优先级的选择，保证同时至多只有一种拉高。

此外，一些机制还会引发一些特殊情况，在旧版文档/代码中也称为异常，但其实际上并不引发 RISC-V 手册定义的 exception，为了避免混淆，此后将称为特殊情况：

DataArray 分 bank 的低功耗设计

目前，ICache 中每个 cacheline 分为 8 个 bank，bank0-7。一个取指块需要 34B 指令数据，故一次访问连续的 5 个 bank。存在两种情况：

1. 这 5 个 bank 位于单个 cacheline 中（起始地址位于 bank0-3）。假设起始地址位于 bank2，则所需数据位于 bank2-6。如下图 a。
2. 跨 cacheline（起始地址位于 bank4-7）。假设起始地址位于 bank6，则数据位于 cacheline0 的 bank6-7、cacheline1 的 bank0-2。有些类似于环形缓冲区。如下图 b。

DataArray 分 bank 示意图

当从 SRAM 或 MSHR 中获取 cacheline 时，根据地址将数据放入对应的 bank。

由于每次访问只需要 5 个 bank 的数据，因此 ICache 到 IFU 的端口实际上只需要一个 64B 的端口，将两个 cacheline 各自的 bank 选择出来并拼接在一起返回给 IFU（在 DataArray 模块内完成）；IFU 将这一个 64B 的数据复制一份拼接在一起，即可直接根据取指块起始地址选择出取指块的数据。不跨行/跨行两种情况的示意图如下：

DataArray 单行数据返回示意图

DataArray 双行数据返回示意图

亦可参考 IFU.scala 中的注释。

NOTE: the following `Cat(_data, _data)` _is_ intentional.
Explanation:
In the old design, IFU is responsible for selecting requested data from two adjacent cachelines,
so IFU has to receive 2*64B (2cacheline * 64B) data from ICache, and do `Cat(_data(1), _data(0))` here.
However, a fetch block is 34B at max, sending 2*64B is quiet a waste of power.
In current design (2024.06~), ICacheDataArray is responsible for selecting data from two adjacent cachelines,
so IFU only need to receive 40B (5bank * 8B) valid data, and use only one port is enough.
For example, when pc falls on the 6th bank in cacheline0(so this is a doubleline request):
MSB LSB
cacheline 1 || 1-7 | 1-6 | 1-5 | 1-4 | 1-3 | 1-2 | 1-1 | 1-0 ||
cacheline 0 || 0-7 | 0-6 | 0-5 | 0-4 | 0-3 | 0-2 | 0-1 | 0-0 ||
and ICacheDataArray will respond:
fromICache.bits.data || 0-7 | 0-6 | xxx | xxx | xxx | 1-2 | 1-1 | 1-0 ||
therefore simply make a copy of the response and `Cat` together, and obtain the requested data from centre:
f2_data_2_cacheline || 0-7 | 0-6 | xxx | xxx | xxx | 1-2 | 1-1 | 1-0 | 0-7 | 0-6 | xxx | xxx | xxx | 1-2 | 1-1 | 1-0 ||
requested data: ^-----------------------------^
For another example, pc falls on the 1st bank in cacheline 0, we have:
fromICache.bits.data || xxx | xxx | 0-5 | 0-4 | 0-3 | 0-2 | 0-1 | xxx ||
f2_data_2_cacheline || xxx | xxx | 0-5 | 0-4 | 0-3 | 0-2 | 0-1 | xxx | xxx | xxx | 0-5 | 0-4 | 0-3 | 0-2 | 0-1 | xxx ||
requested data: ^-----------------------------^
Each "| x-y |" block is a 8B bank from cacheline(x).bank(y)
Please also refer to:

- DataArray selects data:
  https://github.com/OpenXiangShan/XiangShan/blob/d4078d6edbfb4611ba58c8b0d1d8236c9115dbfc/src/main/scala/xiangshan/frontend/icache/ICache.scala#L355-L381
  https://github.com/OpenXiangShan/XiangShan/blob/d4078d6edbfb4611ba58c8b0d1d8236c9115dbfc/src/main/scala/xiangshan/frontend/icache/ICache.scala#L149-L161
- ICache respond to IFU:
  https://github.com/OpenXiangShan/XiangShan/blob/d4078d6edbfb4611ba58c8b0d1d8236c9115dbfc/src/main/scala/xiangshan/frontend/icache/ICacheMainPipe.scala#L473

冲刷

在后端/IFU 重定向、BPU 重定向、fence.i 指令执行时，需要视情况对 ICache 内的存储结构和流水级进行冲刷。可能的冲刷目标/动作有：

1. MainPipe、IPrefetchPipe 所有流水级
   • 冲刷时直接将 s0/1/2_valid 置为 false.B 即可
2. MetaArray 中的 valid
   • 冲刷时直接将 valid 置为 false.B 即可
   • tag、code不需要冲刷，因为它们的有效性由 valid 控制
   • DataArray 中的数据不需要冲刷，因为它们的有效性由 MetaArray 中的 valid 控制
3. WayLookup
   • 读写指针复位
   • gpf_entry.valid 置为 false.B
4. MissUnit 中所有 MSHR
   • 若 MSHR 尚未向总线发出请求，请求和预取请求直接置无效（valid === false.B）
   • 若 MSHR 已经向总线发出请求，记录待冲刷（flush === true.B 或 fencei === true.B），等到 d 通道收到 grant 响应时再置无效，同时不把 grant 的数据回复给 MainPipe/PrefetchPipe，也不写入 SRAM     - 需要留意，当 d 通道收到 grant 响应的同时收到冲刷（io.flush === true.B 或 io.fencei === true.B）时，MissUnit 同样不写入 SRAM，但会将数据回复给 MainPipe/PrefetchPipe，避免将端口的延时引入响应逻辑中，此时 MainPipe/PrefetchPipe 也同步收到了冲刷请求，因此会将数据丢弃

每种冲刷原因需要执行的冲刷目标：

ICache 进行冲刷时不接收取指/预取请求（io.req.ready === false.B）

对 ITLB 的冲刷

ITLB 的冲刷比较特殊，其缓存的页表项仅需要在执行 sfence.vma 指令时冲刷，而这条冲刷通路由后端负责，因此前端或 ICache 一般不需要管理 ITLB 的冲刷。只有一个特例：目前 ITLB 为了节省资源，不会存储 gpaddr，而是在 gpf 发生时去 L2TLB 重取，重取状态由一个 gpf 缓存控制，这要求 ICache 在收到 ITLB.resp.excp.gpf_instr 时保证下面两个条件之一：

1. 重发相同的 ITLB.req.vaddr，直到 ITLB.resp.miss 拉低（此时gpf、gpaddr均有效，正常发往后端处理即可），ITLB 此时会冲刷 gpf 缓存。
2. 给 ITLB.flushPipe，ITLB 在收到该信号时会冲刷 gpf 缓存。

若 ITLB 的 gpf 缓存未被冲刷，就收到了不同 ITLB.req.vaddr 的请求，且再次发生 gpf，将导致核卡死。

因此，每当冲刷 IPrefetchPipe 的 s1 流水级时，无论冲刷原因为何，都需要同步冲刷 ITLB 的 gpf 缓存（即拉高 ITLB.flushPipe）。

ECC

首先需要指出，ICache 在默认参数下使用 parity code，其仅具备 1 bit 错误检测能力，不具备错误恢复能力，严格意义上不能算是 ECC（Error Correction Code）。但一方面，其可以配置为使用 secded code；另一方面，我们在代码中大量使用 ECC 来命名错误检测与错误恢复相关的功能（ecc_error、ecc_inject等）。因此本文档仍将使用 ECC 一词来指代错误检测、错误恢复、错误注入相关功能以保证与代码的一致性。

ICache 支持错误检测、错误恢复、错误注入功能，是 RAS⁴ 能力的一部分，可以参考 RISC-V RERI⁵ 手册，由 CtrlUnit 进行控制。

错误检测

在 MissUnit 向 MetaArray 和 DataArray 重填数据时，会计算 meta 和 data 的校验码，前者和 meta 一起存储在 Meta SRAM 中，后者存储在单独的 Data Code SRAM 中。

当取指请求读取 SRAM 时，会同步读取出校验码，在 MainPipe 的 s1/s2 流水级中分别对 meta/data 进行校验。软件可以通过向 mmio-mapped CSR 中相应位置写入特定的值来使能/关闭这一功能，详见 CtrlUnit 文档。

在校验码设计方面，ICache 使用的校验码可由参数控制，默认使用的是 parity code，即校验码为对数据做规约异或 $code = \oplus data$。检查时只需将校验码和数据一起做规约异或 $error = (\oplus data) \oplus code$，结果为 1 则发生错误，反之认为没有错误（可能出现偶数个错误，但此处检查不出来）。

ICache 支持错误注入，这要求 ICache 支持向 MetaArray/DataArray 写入错误的校验码。因此实现了一个poison位，当其拉高时，翻转写入的 code，即 $code = (\oplus data) \oplus poison$。

为了减少检查不出的情况，目前将 data 划分成 DataCodeUnit（默认为 64bit）的单元分别进行奇偶校验，因此对每个 64B 的缓存行，总计会计算 $8(data) + 1(meta) = 9$ 个校验码。

当 MainPipe 的 s1/s2 流水级检查到错误时，会进行以下处理：

在 6 月至 11 月的版本中：

1. 错误处理：引起 access fault 异常，由软件处理。
2. 错误报告：向 BEU 报告错误，后者会引起中断向软件报告错误。
3. 取消请求：当 MetaArray 被检查出错误时，其读出的 ptag 不可靠，进而对 hit 与否的判断不可靠，因此无论是否 hit 都不向 L2 Cache 发送请求，而是直接将异常传递到 IFU、进而传递到后端处理。

在后续版本（#3899 后）实现了错误自动恢复机制，故只需进行以下处理：

1. 错误处理：从 L2 Cache 重新取指，见错误自动恢复。
2. 错误报告：拉高 erros.valid 向顶层报告错误。

错误自动恢复

注意到，ICache 与 DCache 不同，是只读的，因此其数据必然不是 dirty 的，这意味着我们总是可以从下级存储结构（L2/3 Cache、memory）中重新获取正确的数据。因此，ICache 可以通过向 L2 Cache 重新发起 miss 请求来实现错误自动恢复。

实现重取功能本身只需要复用现有的 miss 取指路径，走 MainPipe -> MissUnit -> MSHR –tilelink-> L2 Cache 的请求路径。MissUnit 向 SRAM 重填数据时会自然地计算新的校验码并存储，因此在重取后会回到无错误的状态而不需要额外的处理。

6-11 月和后续代码行为差异的伪代码示意如下：

- exception = itlb_exception || pmp_exception || ecc_error
+ exception = itlb_exception || pmp_exception

- should_fetch = !hit && !exception
+ should_fetch = (!hit || ecc_error) && !exception

需要留意的是：为了避免重取后出现 multi-hit（即，同一个 set 内存在多个 way 的 ptag 相同），需要在重取前将 metaArray 对应位置的 valid 清空：

• 若 MetaArray 错误：meta 保存的 ptag 本身可能出错，命中结果（one-hot 的 waymask）不可靠，“对应位置”指该 set 的所有 way
• 若 DataArray 错误：命中结果可靠，“对应位置”指该 set 中 waymask 拉高的那一 way

错误注入

根据 RERI 手册⁵的说明，为了使软件能够测试 ECC 功能，进而更好地判断硬件功能是否正常，需要提供错误注入功能，即主动地触发 ECC 错误。

ICache 的错误注入功能由 CtrlUnit 控制，通过向 mmio-mapped CSR 中相应位置写入特定的值来触发。详见 CtrlUnit 文档。

目前 ICache 支持：

• 向特定 paddr 注入，当请求注入的 paddr 未命中时，注入失败
• 向 MetaArray 或 DataArray 注入
• 当 ECC 校验功能本身未使能时，注入失败

软件注入流程示意如下：

inject_target:
  # maybe do something
  ret

test:
  la t0, $BASE_ADDR     # 载入 mmio-mapped CSR 基地址
  la t1, inject_target  # 载入注入目标地址
  jalr ra, 0(t1)        # 跳转到注入目标以保证其加载到 ICache
  sd t1, 8(t0)          # 向 CSR 写入注入目标地址
  la t2, ($TARGET << 2 | 1 << 1 | 1 << 0)  # 设置注入目标、注入使能、校验使能
  sd t1, 0(t0)          # 向 CSR 写入注入请求
loop:
  ld t1, 0(t0)          # 读取 CSR
  andi t1, t1, (0b11 << (4+1)) # 读取注入状态
  beqz t1, loop         # 如果注入未完成，继续等待

  addi t1, t1, -1
  bnez t1, error        # 如果注入失败，跳转到错误处理

  jalr ra, 0(t1)        # 注入成功，跳转到注入目标地址以触发错误
  j    finish           # 结束

error:
  # handle error
finish:
  # finish

我们编写了一个测试用例，见此仓库，其测试了如下情况：

1. 正常注入 MetaArray
2. 正常注入 DataArray
3. 注入无效的目标
4. 注入但 ECC 校验未使能
5. 注入未命中的地址
6. 尝试写入只读的 CSR 域

参考文献

1. Glenn Reinman, Brad Calder, and Todd Austin. “Fetch directed instruction prefetching.” 32nd Annual ACM/IEEE International Symposium on Microarchitecture (MICRO). 1999.

ICache 接口说明

为方便测试开展，需要对 ICache 的接口进行进一步的说明，以明确各个接口的含义。

*注意：源文件编译成 verilog/system verilog 后，部分接口会被优化，实际接口以编译后的为准。

IPrefetch 模块接口

控制接口

req:FTQ 预取请求

由于 BPU 基本无阻塞，它经常能走到 IFU 的前面，于是 BPU 提供的这些还没发到 IFU 的取指请求就可以用作指令预取，FTQ 中实现了这部分逻辑，直接给 ICache 发送预取请求。 预取请求来自 FTQ，在 S0 流水级传入。

flushFromBpu:来自 BPU 的刷新信息

由 FTQ 传递而来的 BPU 刷新信息，在 S0 流水级传入。 这是预测错误引起的，包括 s2 和 s3 两个同构成员，指示是否在 BPU 的 s2 和 s3 流水级发现了问题。 s2 的详细结构如下：

itlb:请求和响应 itlb 的信息

在 s0 流水级，发送 itlb_req；在 s1 流水级，如果 itlb 命中则直接接收 itlb_resp，否则重发 itlb_req。

req 的结构如下：

resp 的结构如下：

itlbFlushPipe:itlb 刷新信号

在 itlb 中，如果出现 gpf 的取指请求处于推测路径上，且发现出现错误的推测，则会通过 flushPipe 信号进行刷新（包括后端 redirect、或前端多级分支预测器出现后级预测器的预测结果更新前级预测器的预测结果等）。 当 iprefetchpipe 的 s1 被刷新时，itlb 也应该被刷新，该信号会在 s1 流水被置位。

pmp: 物理内存保护相关的信息

在 s1 流水级做 pmp 检查。 pmp 包含 req 和 resp 两个子结构。

req 的结构如下（编译后）：

resp 的结构如下（编译后）：

metaRead： 和 MetaArray 交互的读请求和读响应

在 s1 流水级读 meta。

metaRead 包含 toIMeta 和 fromIMeta 两个子结构，即读请求和读响应。

toIMeta 的结构如下（编译后）：

fromIMeta 的结构如下（编译后）：

MSHRReq： MSHR 请求

预取逻辑检测到未命中时，在 s2 流水级，向 MissUnit 发送请求。

MSHRResp: MSHR 响应

用于在 s1 流水级更新 waymasks 和 meta_codes 以及 s2 流水级判断返回的响应是否命中。

wayLookupWrite： 向 waylookup 写数据

在 s1 流水级，向 waylookup 写数据。 包含 entry（WayLookupEntry）和 gpf（WayLookupGPFEntry）两个子结构。

entry 的结构如下：

gpf 的结构如下：

MainPipe 模块接口

不需要关注的接口

hartId硬件线程 ID，difftest 使用，不需要关注。

perfInfo性能信息，不需要关注。

dataArray：和 DataArray 交互的读请求和读响应

在 s0 流水级读请求。

dataArray 包含 toData 和 fromData 两个子结构，即读请求和读响应。

toData 的结构如下：

fromData 的结构如下：

metaArrayFlush： 刷新 metaArray

在 s2 流水级，向 metaArray 发送刷新请求, 为重新取指做准备。

touch: 更新 replacer

在 s1 流水级，更新 replacer，向 replacer 发送 touch 请求。 把一次访问告诉 replacer，让它更新 plru 状态。

wayLookupRead： 读取预取流水写入 waylookup 的信息

在 s0 流水级，从 waylookup 获取元信息。 包含 entry（WayLookupEntry）和 gpf（WayLookupGPFEntry）两个子结构。

entry 的结构如下：

gpf 的结构如下：

mshr: 对 MissUnit 中的 mshr 的请求和响应

在 s1 流水级，监听 MSHR 的响应。 在 s2 流水级，缺失时将请求发送至 MissUnit，同时对 MSHR 的响应进行监听，命中时寄存 MSHR 响应的数据。

包含 req 和 resp 两个子结构。

req 的结构如下：

resp 的结构如下：

fetch: 与 FTQ 交互和 IFU 交互接口

包含 req 和 resp 两个子结构。

req： FTQ 取指请求

在 s0 流水级，接收 FTQ 的取指请求。 包含 pcMemRead,readValid 和 backendException 三个子结构。

其中 pcMemRead 的结构如下：

readValid:读取请求的有效性。

backendException：是否有来自后端的 Exception。

resp: IFU 取指响应

在 s2 流水级，向 IFU 发送取指响应。

flush：全局刷新信号

来自 FTQ。

pmp: 物理内存保护相关的信息

在 s1 流水级做 pmp 检查。 pmp 包含 req 和 resp 两个子结构。

req 的结构如下（编译后）：

resp 的结构如下（编译后）：

respStall

IFU 的 f3_ready 为低时会被置位,表示 IFU 没有准备好接收数据，此时需要 stall。

errors: 向 BEU 报告指令缓存中检测到的错误

在 s2 流水级，综合 data 的 ECC 校验加上从 s1 传来的 meta 的 ECC 校验结果，决定是否向 BEU 报告错误。

编译后：

perfInfo： 性能相关信息，不关注

WayLookup 模块接口

flush：全局刷新信号

来自 FTQ。

read：Mainpipe 的读接口

包含 entry（WayLookupEntry）和 gpf（WayLookupGPFEntry）两个子结构。

entry 的结构如下：

gpf 的结构如下：

write：IprefetchPipe 的写接口

包含 entry（WayLookupEntry）和 gpf（WayLookupGPFEntry）两个子结构。

entry 的结构如下：

gpf 的结构如下：

update：MissUnit 的更新接口

在 IPrefetchPipe 中等待入队 WayLookup 阶段和在 WayLookup 中等待出队阶段，可能会发生 MSHR 对 Meta/DataArray 的更新。也就是命中状态可能在出入队 WayLookup 时不同。

MissUnit 模块接口

fencei： 软件刷新信号

flush：全局刷新信号

来自 FTQ。

fetch_req：MainPipe 的取指请求缺失时的请求

fetch_respf: MainPipe 的取指响应缺失时的响应

prefetch_req: IPrefetchPipe 的预取请求缺失时的请求

meta_write: MetaArray 的写请求接口

data_write: DataArray 的写请求接口

victim：与缓存的替换器（replacer）交互，获取需要被替换的缓存路（way）的信息

mem_acquire：Tilelink a 通道发送请求

L2 的总线空闲时，发送请求。

mem_grant：Tilelink d 通道返回数据

FIFO 模块接口

enq: 入队信号

deq: 出队信号

Replacer 模块接口

touch： 更新 replacer

victim： 与缓存的替换器（replacer）交互，获取需要被替换的缓存路（way）的信息

MetaArray 模块接口

write: MetaArray 的写请求接口

写请求来自 MissUnit 或者 CtrlUnit。

read: MetaArray 的读请求接口

readResp： MetaArray 的读响应接口

fromIMeta 的结构如下（编译后）：

flush：双端刷新信号

来自 MainPipe 的刷新信号。可以只刷新指定的某一个端口，也可以都刷新。

flushAll：刷新所有 MetaArray

来自软件刷新信号 fencei。

DataArray 模块接口

write：DataArray 的写请求接口

来自 MissUnit 或者 CtrlUnit 的写请求。

read：DataArray 的读请求接口

来自 MainPipe 的读请求。

readResp：DataArray 的读响应接口

CtrlUnit 模块接口

auto_in: Tilelink 相关接口

CtrlUnit 和 Tilelink 交互，分为 a 通道和 d 通道。

a 通道：

d 通道：

ecc_enable： ecc 控制信号

指示 ecc 是否开启。

injecting： ecc 注入信号

指示 eccctrl 的 istatus 域是否处于 working 状态，即收到注入请求，注入中

metaRead： 对 MetaArray 的读请求

在对应读状态机 is_readMetaReq 中，对 MetaArray 发起读请求。

metaReadResp： 对 MetaArray 的读响应

在状态机 is_readMetaResp 中，接收 MetaArray 的读响应。

metaWrite： 对 MetaArray 的写

在状态机 is_writeMeta 中，对 MetaArray 发起写。

dataWrite： 对 DataArray 的写请求

在状态机 is_writeData 中，对 DataArray 发起写请求。

ICache 顶层模块接口

在 scala 代码中，顶层模块除了包含对外的接口，实际上还包括了 MetaArray、DataArray 和 Replacer。在编译成 verilog 后，这三个模块会被编译成三个独立的模块，然后再通过顶层模块的接口连接起来。

不需要关注的接口

hartId硬件线程 ID，difftest 使用，不需要关注。 perfInfo性能信息，不需要关注。

auto_ctrlUnitOpt_in：CtrlUnit 和 Tilelink 交互的接口

CtrlUnit 和 Tilelink 交互，分为 a 通道和 d 通道。

a 通道：

d 通道：

auto_client_out： MissUnit 和 Tilelink 交互的接口

MissUnit 和 Tilelink 交互，分为 a 通道和 d 通道。 a 通道：

d 通道：

fetch: 与 FTQ 交互和 IFU 交互接口

包含 req 和 resp 两个子结构。

req： FTQ 取指请求

在 s0 流水级，接收 FTQ 的取指请求。 包含 pcMemRead,readValid 和 backendException 三个子结构。

其中 pcMemRead 的结构如下：

readValid:读取请求的有效性。

backendException：是否有来自后端的 Exception。

resp: IFU 取指响应

在 s2 流水级，向 IFU 发送取指响应。

ftqPrefetch:FTQ 预取相关信息

包含三个子结构： req： 来自 FTQ 的预取请求 flushFromBpu:来自 BPU 的刷新信息 bakckendException:来自后端的异常信息

req： 来自 FTQ 的预取请求

由于 BPU 基本无阻塞，它经常能走到 IFU 的前面，于是 BPU 提供的这些还没发到 IFU 的取指请求就可以用作指令预取，FTQ 中实现了这部分逻辑，直接给 ICache 发送预取请求。 预取请求来自 FTQ，在 MainPipe 的 S0 流水级传入。

flushFromBpu:来自 BPU 的刷新信息

由 FTQ 传递而来的 BPU 刷新信息，在 MainPipe 的 S0 流水级传入。 这是预测错误引起的，包括 s2 和 s3 两个同构成员，指示是否在 BPU 的 s2 和 s3 流水级发现了问题。 s2 的详细结构如下：

backendException： 后端异常信息

ICache 向 IFU 报告后端存在的异常类型

softPrefetch： 来自 Memblock 的软件预取信息

stop： IFU 发送到 ICache 的停止信号

IFU 在 F3 流水级之前出现了问题，通知 ICache 停下。

ToIFU： 发送给 I FU 的就绪信号

由 MainPipe 的 s0 流水级 s0_can_go 生成。该信号用于提醒 IFU，Icache 的流水可用，可以发送换存行了。

pmp： MainPipe 和 PrefetchPipe 的 pmp 信息

0,1 通道为 MainPipe 的 pmp 信息，2,3 通道为 PrefetchPipe 的 pmp 信息。 pmp 包含 req 和 resp 两个子结构。

req 的结构如下（编译后）：

resp 的结构如下（编译后）：

itlb：PrefetchPipe 的 itlb 信息

在 PrefetchPipe 的 s0 流水级，发送 itlb_req；在 PrefetchPipe 的 s1 流水级，如果 itlb 命中则直接接收 itlb_resp，否则重发 itlb_req。

itlb 包含 req 和 resp 两个子结构。

req 的结构如下：

resp 的结构如下：

itlbFlushPipe： itlb 刷新信号

在 itlb 中，如果出现 gpf 的取指请求处于推测路径上，且发现出现错误的推测，则会通过 flushPipe 信号进行刷新（包括后端 redirect、或前端多级分支预测器出现后级预测器的预测结果更新前级预测器的预测结果等）。 当 iprefetchpipe 的 s1 被刷新时，itlb 也应该被刷新，该信号会在 iprefetchpipe 的 s1 流水被置位。

error：向 BEU 报告指令缓存中检测到的错误

将 MainPipe 中收集到的 errors 多个错误信息，使用优先级选择器选择索引最小且有效的错误信息，然后通过 error 信号发送给 BEU。接口结构和 MainPipe 中相同，区别在于 MainPipe 中有两个端口，所以有两个 errors,而这里要发送的只有一个。

编译后：

csr_pf_enable

控制 s1_real_fire，软件控制预取开关

fencei： 软件刷新信号

flush： 全局刷新信号

在 FTQ 中，有后端重新定向或者 IFU 重定向时，会将其 icacheFlush 信号拉高，触发 icache 的刷新。

测试点汇总

再次声明，本测试点仅供参考，如果有其他测试点需要补充可以告知我们。

建议覆盖点采用功能名称_测试点名称命名。