PCIe扫盲:Memory & IO 地址空间/基地址寄存器详解/Base & Limit寄存器详解

转载:PCIe扫盲:Memory & IO 地址空间/基地址寄存器详解/Base & Limit寄存器详解 - 极术社区 - 连接开发者与智能计算生态 (aijishu.com)

Memory & IO 地址空间

早期的PC中,所有的IO设备(除了存储设备之外的设备)的内部存储或者寄存器都只能通过IO地址空间进行访问。但是这种方式局限性很大,而且效率低,于是乎,软件开发者和硬件厂商都不能忍了……然后一种新的东西就出来了——MMIO。

MMIO,即Memory Mapped IO,也就是说把这些IO设备中的内部存储和寄存器都映射到统一的存储地址空间(Memory Address Space)中。

但是,为了兼容一些之前开发的软件,PCIe仍然支持IO地址空间,只是建议在新开发的软件中采用MMIO。

注:PCIe Spec中明确指出,IO地址空间只是为了兼容早期的PCI设备(Legacy Device),在新设计中都应当使用MMIO,因为IO地址空间可能会被新版本的PCI Spec所抛弃。

IO地址空间的大小是4GB(32bits),而MMIO则取决于处理器(和操作系统),并且由处理器进行统一分配管理。

如下图所示,PCIe总线中有两种MMIO:P-MMIO和NP-MMIO。
image.png
P-MMIO,即可预取的MMIO(Prefetchable MMIO);

NP-MMIO,即不可预取的MMIO(Non-Prefetchable MMIO)。其中P-MMIO读取数据并不会改变数据的值。

注:P-MMIO和NP-MMIO主要是为了兼容早期的PCI设备,因为PCIe请求中明确包含了每次的传输的大小(Transfer Size),而PCI并没有这些信息。

基地址寄存器(BAR)详解

基地址寄存器(BAR)在配置空间(Configuration Space)中的位置如下图所示:
image.png
其中Type0 Header最多有6个BAR,而Type1 Header最多有两个BAR。

这就意味着,对于Endpoint来说,最多可以拥有6个不同的地址空间。但是实际应用中基本上不会用到6个,通常1~3个BAR比较常见。

主要注意的是,如果某个设备的BAR没有被全部使用,则对应的BAR应被硬件全被设置为0,并且告知软件这些BAR是不可以操作的。

对于被使用的BAR来说,其部分低比特位是不可以被软件操作的,只有其高比特位才可以被软件操作。

而这些不可操作的低比特决定了当前BAR支持的操作类型和可申请的地址空间的大小。

一旦BAR的值确定了(Have been programmed),其指定范围内的当前设备中的内部寄存器(或内部存储空间)就可以被访问了。当该设备确认某一个请求(Request)中的地址在自己的BAR的范围内,便会接受这请求。

下面用几个简单的例子来熟悉BAR的机制:

例1. 32-bit Memory Address Space Request

如下图所示,请求一个4KB的NP-MMIO一般需要以下三个步骤:
image.png
Step1:如图中(1)所示,未初始化的BAR的低比特(11~4)都是0,高比特(31~12)都是不确定的值。

所谓初始化,就是系统(软件)向整个BAR都写1,来确定BAR的可操作的最低位是哪一位。

当前可操作的最低位为12,因此当前BAR可申请的(最小)地址空间大小为4KB(2^12)。如果可操作的最低位为20,则该BAR可申请的(最小)地址空间大小为1MB(2^20)。

Step2:完成初始化(写1操作)之后,软件便开始读取BAR的值,来确定每一个BAR对应的地址空间大小和类型。其中操作的类型一般由最低四位所决定,具体如上图右侧部分所示。

Step3:最后一步是,软件向BAR的高比特写入地址空间的起始地址(Start Address)。如图中所示,为0xF9000000。

例2. 64-bit Memory Address Space Request

下面是一个申请64MB P-MMIO地址空间的例子,由于采用的是64-bit的地址,因此需要两个BAR。具体如下图所示:
image.png
例3. IO Address Space Request

下面是一个申请IO地址空间的例子,如下图所示:
image.png
注:需要特别注意的是,软件对BAR的检测与操作(Evaluating)必须是顺序执行的,即先BAR0,然后BAR1,……,直到BAR5。当软件检测到那些被硬件设置为全0的BAR,则认为这个BAR没有被使用。

注:无论是PCI还是PCIe,都没有明确规定,第一个使用的BAR必须是BAR0。事实上,只要设计者原意,完全可以将BAR4作为第一个BAR,并将BAR0~BAR3都设置为不使用。

Base & Limit寄存器详解

上一篇文章介绍了Type0型配置空间Header中的BAR的作用和用法,但是PCIe中的桥设备(Switch和Root中的P2P)又是如何判断某一请求(Request)是否属于自己或者自己的分支下的设备的呢?这实际上是通过Type1型配置空间Header中的Base和Limit寄存器来实现的,这篇文章来进行简单地介绍一下。

Base和Limit寄存器在Type1 Header中的位置如下图所示:
image.png
Base和Limit寄存器分别确定了其所有分支下设备(The device that live beneath this bridge)的地址的起始和结束地址。根据请求类型的不同,分别对应不同的Limit&Base组合:

· Prefetchable Memory Space(P-MMIO)
· Non- Prefetchable Memory Space(NP-MMIO)
· IO Space(IO)

一旦该桥分支下面的任意设备的BAR发生改变,该桥的Base&Limit寄存器也需要做出对应的改变。

下面以一个简单的例子,来分析一下:
image.png
如上图所示,连接到Switch的PortB上的PCIe Endpoint分别配置了NP-MMIO、P-MMIO和IO空间。下面来简单地分析一下PortB的Header中的Base & Limit 寄存器。

P-MMIO Base & Limit
image.png
NP-MMIO Base & Limit
image.png
需要注意的是,Endpoint的需要的NP-MMIO的大小明明只有4KB,PortB的Header却给其1MB的空间(最小1MB),也就是说剩余的空间都将会被浪费掉,并且其他的Endpoint都将无法使用这一空间。

IO Base & Limit
image.png
注:IO空间可分配的最小值为4KB,最大值则取决于操作系统和BIOS。

Unused Base and Limit Registers

很多情况下,我们并不需要所有的地址空间类型,比如所在某一个Endpoint中没有使用IO Space。此时,其对应的桥的Header会把Base的地址设置为大于Limit的地址,也就是把地址范围设置为无效。

一个完整的例子如下图所示:
image.png

 

NP-MMIO(Non-Prefetchable Memory-Mapped I/O)和P-MMIO(Prefetchable Memory-Mapped I/O)以及IO空间是PCIe(Peripheral Component Interconnect Express)中定义的不同类型的地址空间,用于不同类型的内存访问:

1. **NP-MMIO(不可预取的内存映射I/O)**:
- 用于那些读取操作可能会改变设备状态的设备,例如某些硬件寄存器。
- 通常用于非易失性存储器或某些特殊硬件的访问,其中读取操作可能会有副作用。
- 地址空间可以是32位或64位,取决于系统和设备的支持。

2. **P-MMIO(可预取的内存映射I/O)**:
- 用于那些读取操作不会改变设备状态的设备,例如常规的内存访问。
- 由于读取操作没有副作用,因此可以安全地进行预取和缓存。
- 这种类型的地址空间通常用于通用的内存访问,如DRAM。

3. **IO空间**:
- 传统上用于访问IO设备,如硬盘控制器或网络接口卡的寄存器。
- 与MMIO相比,IO空间通常具有较低的带宽和更高的延迟。
- PCIe规范中仍然支持IO空间,主要是为了向后兼容旧的PCI设备,但在新设计中推荐使用MMIO。

在实际使用中,系统软件需要根据设备的特定需求来分配适当的地址空间。例如,如果一个设备需要高速数据传输且对数据的预取不会影响其状态,那么P-MMIO是更好的选择。相反,如果设备的某些寄存器在读取时会改变其状态,那么NP-MMIO或IO空间可能更合适。系统软件通过配置空间中的基地址寄存器(BAR)来分配和管理这些地址空间 。

总的来说,NP-MMIO、P-MMIO和IO空间在PCIe架构中提供了灵活的寻址选项,以满足不同设备的特定需求。随着技术的发展,新设计的设备越来越多地采用MMIO方式,以实现更高效的数据传输和更好的系统性能。

posted @ 2024-08-15 10:38  burlingame  阅读(42)  评论(0编辑  收藏  举报