如何计算组关联缓存和 TLB 中标记、索引和偏移量的缓存位宽
How to compute cache bit widths for tags, indices and offsets in a set-associative cache and TLB
问题如下：
We have memory system with both virtual of 64-bits and physical
address of 48-bits. The L1 TLB is fully associative with 64 entries.
The page size in virtual memory is 16KB. L1 cache is of 32KB and 2-way
set associative, L2 cache is of 2MB and 4-way set associative. Block
size of both L1 and L2 cache is 64B. L1 cache is using virtually
indexed physically tagged (VIPT) scheme.
我们需要计算标签、索引和偏移量。这是我到目前为止制定的解决方案：
- 页面偏移量=log base 2(页面大小)=14bits
- 块偏移量=log base 2（块大小）= 6 位
- 虚拟页号=虚拟地址-pageoffset=64-14=50位
- 一级缓存索引=页偏移-块偏移=8位
- L1 tag=物理地址-L1索引-块偏移量=50位
- TLB index= log base 2 (64/64)=0 bits {因为它是完全关联的并且整个缓存可以被认为是一组。}
- TLBtag=虚拟页码-索引=50位
- 二级缓存索引=log base 2 (缓存大小/(块大小*路数))13bits
- L2 标签= 21 位
供参考：
这是我的解决方案 calculated.Please 告诉我是否有误。
提前致谢:)
看起来不错。
您应该像计算 L2 一样计算 L1D 索引位：log2(32KiB / (64B * 2)) = log2(256) = 8 位。
将 L1 索引位计算为 page offset - block offset 是唯一可能的，因为您的图表显示您的缓存具有所需的 属性，即所有索引位都是页面偏移位。 （因此对于别名行为，它就像一个 PIPT 缓存：同音异义词和同义词是不可能的。
因此，您可以获得 VIPT 速度，而没有虚拟缓存的任何别名缺点。）
所以我想真正计算这两种方法并检查是一个很好的健全性检查。即检查它是否与图表匹配，或者图表是否与其他参数匹配。
也不需要 L1D 索引+偏移位 "use up" 所有页面偏移位：例如增加 L1D 关联性将留下 1 个或多个页面偏移位作为标记的一部分。 （这很好，不会引入别名问题，这只是意味着您的 L1D 没有给定关联性和页面大小的大。）
不过，以这种方式构建缓存很常见，尤其是对于较小的页面大小。例如，x86 有 4k 页，Intel CPUs 已经使用 32kiB / 8-way L1D 十多年了。 （32k / 8 = 4k）。让它更大（64kiB）也需要使它成为 16 向关联，因为改变页面大小不是一个选项。对于具有并行标记 + 数据获取的低延迟高吞吐量缓存来说，这将开始变得过于昂贵。较早的 CPU 像 Pentium III 有 16kiB / 4 路，他们能够将其扩展到 32kiB / 8 路，但我认为我们不应该期望更大的 L1D 除非发生根本性的变化。但是对于具有 16kiB 页面的假设 CPU 架构，具有更多关联性的小型+快速 L1D 当然是合理的。 （您的图表非常清楚，索引一直延伸到页面拆分，但在不放弃 VIPT 优势的情况下，其他设计也是可能的。）
另见 Why is the size of L1 cache smaller than that of the L2 cache in most of the processors? for more about the "VIPT hack" and why multi-level caches are necessary to get a combination of low-latency and large capacity in practical designs. (And note that current Intel L1D caches are pipelined and multi-ported (with 2 reads and 1 write per clock) for access widths up to 32 bytes, or even all 64 bytes of a line with AVX512. How can cache be that fast?。因此，让 L1D 更大、关联性更高会耗费大量电力。）
问题如下：
We have memory system with both virtual of 64-bits and physical address of 48-bits. The L1 TLB is fully associative with 64 entries. The page size in virtual memory is 16KB. L1 cache is of 32KB and 2-way set associative, L2 cache is of 2MB and 4-way set associative. Block size of both L1 and L2 cache is 64B. L1 cache is using virtually indexed physically tagged (VIPT) scheme.
我们需要计算标签、索引和偏移量。这是我到目前为止制定的解决方案：
- 页面偏移量=log base 2(页面大小)=14bits
- 块偏移量=log base 2（块大小）= 6 位
- 虚拟页号=虚拟地址-pageoffset=64-14=50位
- 一级缓存索引=页偏移-块偏移=8位
- L1 tag=物理地址-L1索引-块偏移量=50位
- TLB index= log base 2 (64/64)=0 bits {因为它是完全关联的并且整个缓存可以被认为是一组。}
- TLBtag=虚拟页码-索引=50位
- 二级缓存索引=log base 2 (缓存大小/(块大小*路数))13bits
- L2 标签= 21 位
供参考：
这是我的解决方案 calculated.Please 告诉我是否有误。 提前致谢:)
看起来不错。
您应该像计算 L2 一样计算 L1D 索引位：log2(32KiB / (64B * 2)) = log2(256) = 8 位。
将 L1 索引位计算为 page offset - block offset 是唯一可能的，因为您的图表显示您的缓存具有所需的 属性，即所有索引位都是页面偏移位。 （因此对于别名行为，它就像一个 PIPT 缓存：同音异义词和同义词是不可能的。
因此，您可以获得 VIPT 速度，而没有虚拟缓存的任何别名缺点。）
所以我想真正计算这两种方法并检查是一个很好的健全性检查。即检查它是否与图表匹配，或者图表是否与其他参数匹配。
也不需要 L1D 索引+偏移位 "use up" 所有页面偏移位：例如增加 L1D 关联性将留下 1 个或多个页面偏移位作为标记的一部分。 （这很好，不会引入别名问题，这只是意味着您的 L1D 没有给定关联性和页面大小的大。）
不过，以这种方式构建缓存很常见，尤其是对于较小的页面大小。例如，x86 有 4k 页，Intel CPUs 已经使用 32kiB / 8-way L1D 十多年了。 （32k / 8 = 4k）。让它更大（64kiB）也需要使它成为 16 向关联，因为改变页面大小不是一个选项。对于具有并行标记 + 数据获取的低延迟高吞吐量缓存来说，这将开始变得过于昂贵。较早的 CPU 像 Pentium III 有 16kiB / 4 路，他们能够将其扩展到 32kiB / 8 路，但我认为我们不应该期望更大的 L1D 除非发生根本性的变化。但是对于具有 16kiB 页面的假设 CPU 架构，具有更多关联性的小型+快速 L1D 当然是合理的。 （您的图表非常清楚，索引一直延伸到页面拆分，但在不放弃 VIPT 优势的情况下，其他设计也是可能的。）
另见 Why is the size of L1 cache smaller than that of the L2 cache in most of the processors? for more about the "VIPT hack" and why multi-level caches are necessary to get a combination of low-latency and large capacity in practical designs. (And note that current Intel L1D caches are pipelined and multi-ported (with 2 reads and 1 write per clock) for access widths up to 32 bytes, or even all 64 bytes of a line with AVX512. How can cache be that fast?。因此，让 L1D 更大、关联性更高会耗费大量电力。）