老男孩读PCIe系列

老男孩读PCIe之一：从PCIe速度说起

从今天开始，老男孩要开始讲PCIe了。对我来说，这是个很大的挑战：首先，我自己本身，对PCIe并没有做到胸有成竹，我的PCIe知识也只是停留在理论阶段，我并没有实际做过任何有关PCIe的东西；其次，我要把PCIe讲得深入浅出，让读者轻易接受，我觉得很难，根本原因就是我还没有做到胸有PCIe；最后，我的文章都会通过ssdfans公众号推出（还没有关注的同学，赶快关注），很多读者都是PCIe高手，班门弄斧，我深感压力。但尽管如此，我还是决定出发，我自己努力学习，尽我最大能力把我学到的东西分享给大家，也希望各位PCIe大拿们，帮忙斧正文章的错误，我希望不是我一个人，而是和各位大拿们一起，带领大家攀上PCIe的高峰。

我是从事SSD工作的，为什么要讲PCIe，原因很简单，现在很多SSD都开始使用PCIe接口。那为什么SSD要用PCIe接口？因为它快，比SATA快。它究竟有多快？我们今天首先从PCIe接口的速度开始我们的PCIe之旅。

PCIe发展到现在，从PCIe 1.0，PCIe 2.0，到现在的PCIe 3.0，速度一代比一代快。

Link Width这一行，我们看到X1，X2，X4…，这是什么意思？这是指PCIe连接的通道数（Lane）。就像高速一样，有单根道，有2根道的，有4根道的，不过像8根道或者更多道的公路不常见，但PCIe是可以最多32条道的。

两个设备之间的PCIe连接，叫做一个Link，如下图所示：

从A到B，之间是个双向连接，车可以从A驶向B，同时，车也可以从B驶向A，各行其道。两个PCIe设备之间，有专门的发送和接收通道，数据可以同时往两个方向传输，PCIe spec称这种工作模式为双单工模式（dual-simplex），可以理解为全双工模式。

SATA是什么工作模式呢？

和PCIe一样，SATA也有独立的发送和接收通道，但与PCIe工作模式不一样：同一时间，只有一条道可以进行数据传输，也就是说，你在一条道上发送数据，另外一条道上不能接收数据，反之亦然。这种工作模式应该是半双工模式。PCIe犹如我们的手机，双方可以同时讲话，而SATA就是对讲机了，一个人在说话，另外一个人就只能听不能说。

回到前面PCIe带宽那张表，上面的带宽，比如PCIe3.0x1，带宽为2GB/s，是指双向带宽，即读写带宽。如果单指读或者写，该值应该减半，即1GB/s的读速度或者写速度。

我们来看看表里面的带宽是怎么算出来的。

PCIe是串行总线，PCIe1.0的线上比特传输速率为2.5Gb/s，物理层使用8/10编码，即8比特的数据，实际在物理线路上是需要传输10比特的，因此：

PCIe1.0 x 1的带宽=（2.5Gb/s x 2（双向通道））/ 10bit = 0.5GB/s

这是单条Lane的带宽，有几条Lane，那么整个带宽就0.5GB/s乘以Lane的数目。

PCIe2.0的线上比特传输速率在PCIe1.0的基础上翻了一倍，为5Gb/s，物理层同样使用8/10编码，所以：

PCIe2.0 x 1的带宽=（5Gb/s x 2（双向通道））/ 10bit = 1GB/s

同样，有多少条Lane，带宽就是1GB/s乘以Lane的数目。

PCIe3.0的线上比特传输速率没有在PCIe2.0的基础上翻倍，不是10Gb/s，而是8Gb/s，但物理层使用的是128/130编码进行数据传输，所以：

PCIe3.0 x 1的带宽=（8Gb/s x 2（双向通道））/ 8bit = 2GB/s

同样，有多少条Lane，带宽就是2GB/s乘以Lane的数目。

由于采用了128/130编码，128比特的数据，只额外增加了2bit的开销，有效数据传输比率增大，虽然线上比特传输率没有翻倍，但有效数据带宽还是在PCIe2.0的基础上做到翻倍。

这里值得一提的是，上面算出的数据带宽已经考虑到8/10或者128/130编码，因此，大家在算带宽的时候，没有必要再考虑线上编码的问题了。

和SATA单通道不同，PCIe连接可以通过增加通道数扩展带宽，弹性十足。通道数越多，速度越快。不过，通道数越多，成本越高，占用更多空间，还有就是更耗电。因此，使用多少通道，应该在性能和其他因素之间进行一个综合考虑。单考虑性能的话，PCIe最高带宽可达64GB/s，PCIe 3.0 x 32对应的带宽，很恐怖的一个数据。不过，现有的PCIe接口SSD，一般最多使用4通道，如PCIe3.0x4，双向带宽为8GB/s，读或者写带宽为4GB/s。

几个GB/s的传输速度，读写小电影那是杠杠的。

在此，顺便来算算PCIe3.0x4理论上最大的4K IOPS。PCIe3.0x4理论最大读或者写的速度为4GB/s，不考虑协议开销，每秒可以传输4GB/4K个4K大小的IO，该值为1M，即理论上最大IOPS为1000K。因此，一个SSD，不管你底层用什么介质，flash还是3d xpoint，接口速度就这么块，最大IOPS是不可能超过这个值的。

PCIe是从PCI发展过来的，PCIe的”e”是express的简称，快的意思。PCIe怎么就能比PCI（或者PCI-X）快呢？PCIe在物理传输上，跟PCI有着本质的区别：PCI使用并口传输数据，而PCIe使用的是串口传输。我PCI并行总线，单个时钟周期可以传输32bit或者64bit，怎么就比不了你单个时钟周期传输1个bit数据的串行总线呢？

在实际时钟频率比较低的情况下，并口因为可以同时传输若干比特，速率确实比串口快。随着技术的发展，数据传输速率要求越来越快，要求时钟频率也越来越快，但是，并行总线时钟频率不是想快就能快的。

在发送端，数据在某个时钟沿传出去（左边时钟第一个上升沿），在接收端，数据在下个时钟沿（右边时钟第二个上升沿）接收。因此，要在接收端能正确采集到数据，要求时钟的周期必须大于数据传输的时间（从发送端到接收端，flight time)。受限于数据传输时间（该时间还随着数据线长度的增加而增加），因此时钟频率不能做得太高。另外，时钟信号在线上传输的时候，也会存在相位偏移（clock skew )，影响接收端的数据采集；还有，并行传输，接收端必须等最慢的那个bit数据到了以后，才能锁住整个数据 （signal skew）。

PCIe使用串行总线进行数据传输就没有这些问题。它没有外部时钟信号，它的时钟信息通过8/10编码或者128/130编码嵌入在数据流，接收端可以从数据流里面恢复时钟信息，因此，它不受数据在线上传输时间的限制，你导线多长都没有问题，你数据传输频率多快也没有问题；没有外部时钟信号，自然就没有所谓的clock skew问题；由于是串行传输，只有一个bit传输，所以不存在signal skew问题。但是，如果使用多条lane传输数据（串行中又有并行，哈哈），这个问题又回来了，因为接收端同样要等最慢的那个lane上的数据到达才能处理整个数据。

老男孩读PCIe之二：PCIe拓扑结构

“计算机网络的拓扑结构是引用拓扑学中研究与大小、形状无关的点、线关系的方法，把网络中的计算机和通信设备抽象为一个点，把传输介质抽象为一条线，由点和线组成的几何图形就是计算机网络的拓扑结构。”

计算机网络的最主要的拓扑结构有总线型拓扑、环形拓扑、树形拓扑、星形拓扑、混合型拓扑以及网状拓扑。

PCI采用的是总线型拓扑结构，一条PCI总线上挂着若干个PCI终端设备或者PCI桥设备，大家共享该条PCI总线，哪个人想说话，必须获得总线使用权，然后才能发言。下面是一个基于PCI的传统计算机系统：

北桥下面的那根PCI总线，挂载了以太网设备、SCSI设备、南桥以及其他设备，他们共享那条总线，某个设备只有获得总线使用权才能进行数据传输。

而PCIe则采用树形拓扑结构，一个简单而又典型的PCIe拓扑结构如下：

整个PCIe拓扑结构是一个树形结构，Root Complex（RC）是树的根。RC为CPU代言，与整个计算机系统其它部分通讯，比如CPU通过它访问内存，通过它访问PCIe系统中的设备。

CPU像皇上一样高高在上，而RC好比皇上身边当红的太监，皇上想叫下面的人做点事情，通过太监传达；下面的人也是通过太监，向皇上反应一些情况。不过，这个太监不寻常，它是有根（root）的。

RC的内部实现很复杂，PCIe Spec也没有规定RC该做什么，还是不该做什么。我们也不需要知道那么多，只需清楚：它一般实现了一条内部PCIe总线（BUS 0)，以及通过若干个PCIe bridge，扩展出一些PCIe Port，如下图所示：

PCIe Endpoint，就是PCIe终端设备，比如PCIe SSD，PCIe网卡等等，而Legacy Endpoint，接口是PCIe，但是内部的行为却和传统的PCI或者PCI-x一样（比如支持IO空间）。这些Endpoint可以直接连在RC上，也可以通过Switch连到PCIe总线上。Switch用于扩展链路，提供更多的端口用以连接Endpoint。拿USB打比方，我们计算机主板上提供的USB口有限，如果你要连接很多USB设备，比如无线网卡、无线鼠标、USB摄像头、USB打印机、U盘等等，这时候不够用，怎么办？我会去找马云，向它买个USB HUB，下面这个就不错：

Switch扩展了PCIe端口，靠近RC的那个端口，我们叫上游端口（upstream port），而分出来的其他端口，我们叫下游端口（downstream port）。一个Switch只有一个上游端口，可以扩展出若干个下游端口。下游端口可以直接连接Endpoint，也可以连接Switch，扩展出更多的PCIe端口。

对每个Switch来说，它下面的Endpoint或者Switch，都是归他管的：上游下来的数据，它需要甄别数据是传给它下面哪个设备，然后进行转发；下面设备向RC传数据，也要通过Switch代为转发的。因此，Switch的作用就是扩展PCIe端口，并为挂在它上面的设备（endpoint 或者switch)提供路由和转发服务。

每个Switch内部，也是有一根内部PCIe总线的，然后通过若干个Bridge，扩展出若干个下游端口，如下图所示：

最后小结一下：

PCIe采用的是树形拓扑结构，RC是树的根，或者主干，它为CPU代言，与PCIe系统其它部分通讯，一般为通讯的发起者；Switch是树枝，树枝上有叶子（Endpoint），也可节外生枝，Switch上连Switch，归根结底，是为了连接更多的Endpoint。Switch为它下面的Endpoint或Switch提供路由转发服务；Endpoint是树叶，诸如SSD，网卡，显卡等等，实现某些特定功能（function）。我们还看到有所谓的Bridge，用以将PCIe总线转换成PCI总线，或者反过来，不是我们要讲的重点，忽略之。PCIe与采用总线共享式通讯方式的PCI不同，PCIe采用点到点（Endpoint to Endpoint）通讯方式，每个设备独享通道带宽，速度和效率都比PCI好。

最后，以一个实际的计算机系统例子结束本文：

老男孩读PCIe之三：PCIe分层结构

绝大多数的总线或者接口，都是采用分层实现的。PCIe也不例外，它的层次结构如下：

PCIe定义了下三层（彩色部分）：事务层（Transaction Layer），数据链路层（Data Link Layer）和物理层（Physical Layer），每层职能是不同的，且下层是为上层服务的。分层设计的一个好处：如果层次分得够好，接口版本升级时，硬件设计可能只需要改动某一层，其它层次可以保持不动。

PCIe传输的数据从上到下，都是以packet的形式传输的，每个packet都是有其固定的格式的。

事务层的主要职责是创建（发送）或者解析（接收）TLP (Transaction Layer packet)，流量控制，QoS，事务排序等。

数据链路层的主要职责是创建（发送）或者解析（接收）DLLP(Data Link Layer packet)，Ack/Nak协议（链路层检错和纠错），流控，电源管理等。

物理层的主要职责是处理所有的Packet数据物理传输，发送端数据分发到各个Lane传输（stripe），接收端把各个Lane上的数据汇总起来（De-stripe），每个Lane上加扰（Scramble，目的是让0和1分布均匀，去除信道的电磁干扰EMI）去扰（De-scramble)，以及8/10或者128/130编码解码，等等。

今天只讲个大概，这三层以后还会专门细讲。这里先贴个这三层的细节图，自己看：

数据从上到下，一层一层打包，上层打包完的数据，作为下层的原始数据，再打包。就像人穿衣服一样，穿了内衣穿衬衫，穿了衬衫穿外套。

红色的是TLP的格式，Data是事务层上层给的数据，事务层给它头上加个Header，然后尾巴上再加个CRC校验，就构成了一个TLP；这个TLP下传到数据链路层，又被数据链路层头上加了个包序列号，尾巴再加个CRC校验，构成一个DLLP；然后DLLP下传到物理层，头上加个Start，尾巴加个End符号，把这些数据分派到各个Lane上，然后每个Lane上加扰码，经8/10或128/130编码，最后通过物理传输介质传输给接收方。

接收方物理层是最先接收到这些数据的，然后执行逆操作；在数据链路层，校验序列号和LCRC，如果没错，剥掉序列号和LCRC，往事务层走；如果校验出差，通知对方重传；在事务层，校验ECRC，有错，数据抛弃，没错，去掉ECRC，获得数据。整个过程犹如脱衣睡觉，外套脱了，衬衫脱了，内衣也脱了，光溜溜钻进被窝。

和PCI数据裸奔不同，PCIe的数据是穿有衣服的。PCIe数据以packet的形式传输，比起PCI冷冰冰的数据，PCIe的数据是鲜活有生命的。

每个Endpoint都需要实现这三层，每个Switch的每个Port也是需要实现这三层的：

上图中，如果RC要与EP1通信，中间要经历怎样的一个过程?

如果把前述的数据发送和接收过程，我们通俗的叫做穿衣脱衣，那么，RC与EP1数据传输过程中，则存在好几次这样穿衣脱衣过程：RC跟数据穿好衣服，发送给Switch的上游端口，A为了知道该笔数据发送给谁，就需要脱掉该数据的衣服，找到里面的地址信息。衣服脱光后，Switch发现它是往EP1的，又帮它换了身新衣服，发送给端口B。B又不嫌麻烦的脱掉它的衣服，换上新衣服，最后发送给EP1。

Switch的主要功能是转发数据，为什么还需要实现事务层？Switch必须实现这三层，因为数据的目的地信息是在TLP中的，如果不实现这一层，就无法知道目的地址，也就无法实现数据寻址路由。

老男孩读PCIe之四：TLP类型

Host与PCIe设备之间，或者PCIe设备与设备之间，数据传输都是以Packet形式进行的。事务层根据上层（软件层或者应用层）请求（Request）的类型、目的地址和其它相关属性，把这些请求打包，产生TLP，也就是Transaction Layer Packet。然后这些TLP往下，经历数据链路层，物理层，最终到达目标设备。

根据软件层的不同请求，事务层产生四种不同的TLP请求：

1. Memory

2. IO

3. Configuration

4. Message

前三种分别用于访问内存空间、IO空间、配置空间，这三种请求在PCI或者PCI-X时代就有了；最后的Message请求是PCIe新加的。在PCI或者PCI-X时代，像中断、错误以及电源管理相关信息，都是通过边带信号（sideband signal）进行传输的，但PCIe干掉了这些边带信号线，所有的通讯都是走带内信号，即通过Packet传输，因此，过去一些由边带信号线传输的数据，比如中断信息、错误信息等，现在就交由Message来传输了。

我们知道，一个设备的物理空间，可以通过内存映射（Memory map）的方式映射到Host的主存，有些空间还可以映射到Host的IO空间（如果Host存在IO空间的话）。但新的PCIe设备（区别于Legacy PCIe设备）只支持内存映射，之所以还存在访问IO空间的TLP，完全是为了照顾那些老设备。以后IO映射的方式会逐渐取消，为减轻学习压力，我们以后看到IO 相关的东西，大可或略之。

所有的配置空间（Configuration）的访问，都是Host发起的，确切的说是RC发起的，往往只在上电枚举和配置阶段会发起Configuration的访问，这样的TLP很重要，但不是常态； Message也是一样，只有有中断，或者有错误等情况下，才会有Message TLP，属非主流。PCIe线上主流传输的是Memory访问相关的TLP，Host与device，或者device与device之间，数据都是在彼此的Memory之间（抛掉IO)交互，因此，这种TLP是我们最常见的。

这四种请求，如果需要对方响应的，我们叫做Non-Posted的TLP；如果不期望对方给响应的，我们称之为Posted TLP。Post，有”邮政”的意思，我们只管把信投到邮箱，能不能到达对方，就取决于邮递员了。Posted TLP，就是不指望对方回复（信能不能收到都是个问题）；Non-Posted TLP，就是要求对方务必回复。

哪些TLP是Posted，哪些又是non-posted的呢？像Configuration和IO访问，无论读写，都是Non-posted的，这样的请求必须得到设备的响应；Message TLP是Posted；Memory Read必须是Non-posted，我读你数据，你不返回数据（返回数据也是响应），那肯定不行的。所以，Memory Read必须得到响应。而Memory Write是Posted，我数据传给你，无需回复，这样Host或者Device可以不等对方回复，趁早把下一笔数据写下去，这样一定程度上提高了写的性能。有人会担心如果没有得到对方的响应，发送者就没有办法知道数据究竟有没有成功写入,就有丢数据的风险。虽然这个风险存在（概率很小），但数据链路层提供了ACK/NAK机制，一定程度上能保证TLP正确交互，因此能很大程度减小数据写失败的可能。

Request Type	Non-Posted or Posted
Memory Read	Non-Posted
Memory Write	Posted
Memory Read Lock	Non-Posted
IO Read	Non-Posted
IO Write	Non-Posted
Configuration Read (Type 0 and Type 1)	Non-Posted
Configuration Write (Type 0 and Type 1)	Non-Posted
Message	Posted

所以，只要记住只有Memory Write和Message两种TLP是Posted就可以了。

Memory Read Lock是历史的遗留物,Native PCIe设备已经抛弃了这个，存在的意义完全是为了兼容Legacy PCIe设备。和IO一样，我们以后也忽略。能不看的就不看，PCIe东西本来就多，不要被这些过时没用的东西挡着我们学习的道路。

Configuration一栏，看到有Type 0和Type 1。我们在之前的拓扑结构中，看到除了Endpoint之外，还有Switch，他们都是PCIe设备，但配置种类不同，因此用Type 0和Type 1区分。

Request Type	Non-Posted or Posted
Memory Read	Non-Posted
Memory Write	Posted
Configuration Read (Type 0 and Type 1)	Non-Posted
Configuration Write (Type 0 and Type 1)	Non-Posted
Message	Posted

这样，Request TLP是不是清爽点？

对Non-Posted的Request，是一定需要对方响应的，对方是通过返回一个Completion TLP来作为响应的。对Read Request，响应者通过Completion TLP返回请求者所需的数据，这种Completion TLP包含有效数据；对Write Request（现在只有Configuration Write了）来说，响应者通过Completion TLP告诉请求者执行状态，这样的Completion TLP不含有效数据。

因此,PCIe里面所有的TLP = Request TLP + Completion TLP。

TLP Packet Type	Abbreviated Name
Memory Read	MRd
Memory Write	MWr
Configuration Read（Type 0 and Type 1）	CfgRd0, CfgRd
Configuration Write（Type 0 and Type 1）	CfgWr0,CfgWr1
Message Request with Data	MsgD
Message Request without Data	Msg
Completion with Data	CplD
Completion without Data	Cpl

看个Memory Read的例子：

例子中，Switch B下面的某个Endpoint想读Host内存的数据，因此，它在事务层上生成一个Memory Read TLP，该MRd一路向上，翻过B，越过A，最终到达RC。RC收到该Request，就到内存中取该Endpoint所需的数据，RC通过Completion with Data TLP（CplD)返回数据，原路返回，直到Endpoint。

一个TLP，最多只能携带4KB有效数据，因此，上例子，如果Endpoint需要读16KB的数据，RC必须返回4个CplD给Endpoint。注意，Endpoint只需发1个MRd就可以了。

再看个Memory Write的例子：

该例子中，Host想往某个Endpoint写入数据，因此RC在其事务层生成一个Memory Write TLP（要写的数据在该TLP中），翻过A，越过B，直到目的地。前面说过Memory Write TLP是Posted的，因此，Endpoint收到数据后，是不需要返回Completion TLP（如果这个时候返回Completion TLP，反而是画蛇添足）。

同样的，由于一个TLP只能携带 4KB数据，因此Host想往Endpoint上写入16KB数据，RC必须发送4个MWr TLP。

老男孩读PCIe之五：TLP结构

无论Request TLP，还是作为回应的Completion TLP，它们模样都差不多：

TLP主要由三部分组成：Header，Data和CRC。TLP都是生于发送端的事务层（Transaction Layer），终于接收端的事务层。

每个TLP都有一个Header，跟动物一样，没有头就活不了，所以TLP可以没手没脚，但不能没有头。事务层根据上层请求内容，生成TLP Header。Header内容包括发送者的相关信息、目标地址（该TLP要发给谁）、TLP类型（前面提到的诸如Memory read，Memory Write之类的）、数据长度（如果有的话）等等。

Data Payload域，用以放有效载荷数据。该域不是必须的，因为并不是每个TLP都必须携带数据的，比如Memory Read TLP，它只是一个请求，数据是由目标设备通过Completion TLP返回的。后面我们会整理哪些TLP需要携带数据，哪些TLP不带数据的。前面也提到，一个TLP最大载重是4KB，数据长度大于4KB的话，就需要分几个TLP传输。

ECRC(End to End CRC)域，它对之前的Header和Data（如果有的话）生成一个CRC，在接收端然后根据收到的TLP，重新生成Header和Data（如果有的话）的CRC，和收到的CRC比较，一样则说明数据在传输过程中没有出错，否则就有错。它也是可选的，可以设置不加CRC。

Data域和CRC域没有什么好说的，有花头的是Header域，我们要深入其中看看。

一个Header大小可以是3DW，也可以是4DW。以4DW的Header为例，TLP的Header长下面样子：

红色区域为所有TLP Header公共部分，所有Header都有这些；其它则是跟具体的TLP相关。

稍微解释一下：

Fmt：Format, 表明该TLP是否带有数据，Header是3DW还是4DW；
Type：TLP类型，上一节提到的，Memory Read, Memory Write, Configuration Read, Configuration Write, Message和Completion，等等；
R： Reserved，为0；
TC: Traffic
Class，TLP也分三六九等，优先级高的先得到服务。这里是3比特，说明可以分为8个等级，0-7，TC默认是0，数字越大，优先级越高；
Attr: Attrbiute, 属性，前后共三个bit，先不说；
TH: TLP Processing Hints，先不说；
TD: TLP Digest，之前说ECRC可选，如果这个这个bit置起来，说明该TLP包含ECRC，接收端应该做CRC校验；
EP: Poisoned data, 有毒的数据，远离，哈哈；
AT: Address Type，地址种类，先不说；
Length： Payload数据长度，10个bit，最大1024，单位DW，所以TLP最大数据长度是4KB; 该长度总是DW的整数倍，如果TLP的数据不是DW的整数倍（不是4Byte的整数倍），则需要用到下面两个域：Last DW BE 和 1st DW BE。

我觉得，到目前为止，对于Header，我们只需知道它大概有什么内容，没有必要记住每个域是什么。

这里重点讲讲Fmt和Type，看看不同的TLP（精简版的，Native PCIe设备所有）其Fmt和Type应该怎样编码：

TLP	Fmt	Type	Comment
Memory Read Request	000=3DW,no data 001=4DW,no data	0 0000	3DW或者4DW是指Header大小，Memory Read不带数据
Memory Write Request	010=3DW,with data 011=4DW,with data	0 0000	Memory Write必须带数据
Configuration Type 0 Read Request	000=3DW,no data	0 0100	读Endpoint的Configuration，不带数据，Header总是3DW
Configuration Type 0 Write Request	010=3DW,with data	0 0100	写Endpoint的Configuration，带数据，Header总是3DW
Configuration Type 1 Read Request	000=3DW,no data	0 0101	读Switch的Configuration，不带数据，Header总是3DW
Configuration Type 1 Write Request	010=3DW,with data	0 0101	写Switch的Configuration，带数据，Header总是3DW
Message Request	001 = 4DW, no data	1 0rrr	Message的Header总是4DW
Message Request with Data	011 = 4DW, with data	1 0rrr	Message的Header总是4DW
Completion	000=3DW,no data	0 1010	Completion的Header总是3DW
Completion with Data	010=3DW,with data	0 1010	Completion的Header总是3DW

从上可以看出，Configuration和Completion 的TLP（以C打头的TLP)，其Header大小总是3字节；Message TLP的Header总是4字节；而Memory相关的TLP取决于地址空间的大小，地址空间小于4GB的，Header大小为3DW，大于4GB的，Header大小则为4DW。

上面介绍了几个TLP Header的通用部分，下面分别介绍具体TLP的Header。

Memory TLP

有两个重要的东西在前面没有提到，那就是TLP的源和目标，即，该TLP是哪里产生的，它要到哪里去，它们都包含在Header里面的。因为不同的TLP类型，寻址方式不同，因此要具体TLP具体来看这两个东西。

对一个PCIe设备来说，它开放给Host访问的设备空间首先会映射到Host的内存空间，Host如果想访问设备的某个空间，TLP Header当中的地址应该设置为该访问空间在Host内存的映射地址。如果Host内存空间小于4GB，则Memory读写TLP的Header大小为3DW，大于4GB，则为4DW。那是因为，对4GB内存空间，32bit的地址用1DW就可以表示，该地址位于Byte8-11；而4GB以上的内存空间，需要2DW表示地址，该地址位于Byte8-15。

该TLP经过Switch的时候，Switch会根据地址信息，把该TLP转发到目标设备。之所以能唯一的找到目标设备，那是因为不同的Endpoint设备空间会映射到Host内存空间的不同位置。

关于TLP路由，后面还会专门讲。

Memory TLP的目标是通过内存地址告知的，而源是通过”Requester ID”告知。每个设备在PCIe系统中都有唯一的ID，该ID由总线（Bus）、设备（Device）、功能（Function）三者唯一确定。这个后面也会专门讲，这里只需知道一个PCIe组成有唯一的ID，不管是RC，Switch还是Endpoint。

Configuration TLP

Endpoint和Switch的配置（Configuration）格式不一样，分别为Type 0和 Type 1来表示。配置可以认为是一个Endpoint或者Switch的一个标准空间，这段空间在初始化时也需要映射到Host的内存空间。与设备的其他空间不同，该空间是标准化的，即不管哪个厂家生产的设备，都需要有这么段空间，而且哪个地方放什么东西，都是协议规定好的，Host按协议访问这部分空间。由于每个设备ID唯一，而其Configuration又是固定好的，因此，Host访问PCIe设备的配置空间，只需指定目标设备的ID就可以了，不需要内存地址。

下面是访问Endpoint的配置空间的TLP Header （Type 0）：

Bus Number + Device + Function就唯一决定了目标设备； Ext Reg Number + Register Number相当于配置空间的偏移。找到了设备，然后指定了配置空间的偏移，就能找到具体想访问的配置空间的某个位置。

Message TLP
Message TLP用以传输中断、错误、电源管理等信息，取代PCI时代的边带信号传输。Message TLP的Header 大小总是4DW。

Message Code来指定该Message的类型，具体如下：

不同的Message Code，最后两个DW的意义也不同，这里不展开。

Completion TLP
有non-posted request TLP，才有Completion TLP。有因才有果。前面看到，Requester 的TLP当中都有Requester ID和Tag，来告诉接收者发起者是谁。那么响应者的目标地址就很简单，照抄发起者的源地址就可以了。因此，Completion TLP的Header如下：

Completion TLP，一方面，可以返回请求者的数据，比如作为Memory或者Configuration Read的响应；另一方面，还可以返回该事务（Transaction）的状态，因此，在Completion TLP的Header里面有一个Completion Status，用以返回事务状态：

老男孩读PCIe之六：配置和地址空间

每个PCIe设备，有这么一段空间，Host软件可以读取它获得该设备的一些信息，也可以通过它来配置该设备，这段空间就叫做PCIe的配置空间。不同于每个设备的其它空间，PCIe设备的配置空间是协议规定好的，哪个地方放什么内容，都是有定义的。PCI或者PCI-X时代就有配置空间的概念，那时的配置空间如下：

整个配置空间就是一系列寄存器的集合，其中Type 0是Endpoint的配置，Type 1是Bridge（PCIe时代就是Switch）的配置，都由两部分组成：64 Bytes的Header+192Bytes的Capability结构，后者是设备告诉Host它有多牛逼，都会什么绝活。

进入PCIe时代，PCIe能耐更大，192 Bytes不足以罗列它的绝活。为了保持后向兼容，又要不把绝活落下，怎么办？很简单，我扩展后者的空间，整个配置空间由256 Bytes扩展成4KB，前面256 Bytes保持不变：

PCIe有什么能耐（Capability）我们不看，我们先挑软柿子捏，先看看只占64 Bytes的Configuration Header。

像Device ID，Vendor ID，Class Code和Revision ID，是只读寄存器，PCIe设备通过这些寄存器告诉Host软件，这是哪个厂家的设备、设备ID是多少、以及是什么类型的（网卡？显卡？桥？）设备。

其它的我们暂时不看，我们看看重要的BAR（Base Address Register）。

对Endpoint Configuration（Type 0），提供了最多6个BAR，而对Switch（Type 1）来说，只有2个。BAR是干什么用的？

每个PCIe设备，都有自己的内部空间，这部分空间如果开放给Host（软件或者CPU)访问，那么Host怎样才能往这部分空间写入数据，或者读数据呢？

我们知道，CPU只能直接访问Host内存（Memory）空间（或者IO空间，我们不考虑），不对PCIe等外设直接操作。怎么办？记得皇帝身边那个有根的太监吗？Root Complex，RC。RC可以为CPU分忧。

解决办法是：CPU如果想访问某个设备的空间，由于它不能（或者不屑）亲自跟那些PCIe外设打交道，因此叫太监RC去办。比如，如果CPU想读PCIe外设的数据，先叫RC通过TLP把数据从PCIe外设读到Host内存，然后CPU从Host内存读数据；如果CPU要往外设写数据，则先把数据在内存中准备好，然后叫RC通过TLP写入到PCIe设备。完美！

上图例子中，最左边虚线的表示CPU要读Endpoint A的数据，RC则通过TLP（经历Switch）数据交互获得数据，并把它写入到系统内存中，然后CPU从内存中读取数据（紫色箭头所示），从而CPU间接完成对PCIe设备数据的读取。

具体实现就是上电的时候，系统把PCIe设备开放的空间（系统软件可见）映射到内存空间，CPU要访问该PCIe设备空间，只需访问对应的内存空间。RC检查该内存地址，如果发现该内存空间地址是某个PCIe设备空间的映射，就会触发其产生TLP，去访问对应的PCIe设备，读取或者写入PCIe设备。

一个PCIe设备，可能有若干个内部空间（属性可能不一样，比如有些可预读，有些不可预读）需要映射到内存空间，设备出厂时，这些空间的大小和属性都写在Configuration BAR寄存器里面，然后上电后，系统软件读取这些BAR，分别为其分配对应的系统内存空间，并把相应的内存基地址写回到BAR。（BAR的地址其实是PCI总线域的地址，CPU访问的是存储器域的地址，CPU访问PCIe设备时，需要把总线域地址转换成存储器域的地址。）

如上图例子，一个Native PCIe Endpoint，只支持Memory Map，它有两个不同属性的内部空间要开放给系统软件，因此，它可以分别映射到系统内存空间的两个地方；还有一个Legacy Endpoint，它既支持Memory Map，还支持IO Map，它也有两个不同属性的内部空间，分别映射到系统内存空间和IO空间。

来个例子，看一下一个PCIe设备，系统软件是如何为其分配映射空间的。

上电时，系统软件首先会读取PCIe设备的BAR0，得到数据：

然后系统软件往该BAR0写入全1，得到：

BAR寄存器有些bit是只读的，是PCIe设备在出厂前就固定好的bit，写全1进去，如果值保持不变，就说明这些bit是厂家固化好的，这些固化好的bit提供了这块内部空间的一些信息：

怎么解读？低12没变，表明该设备空间大小是4KB（2的12次方），然后低4位表明了该存储空间的一些属性（IO映射还是内存映射，32bit地址还是64bit地址，能否预取？做过单片机的人可能知道，有些寄存器只要一读，数据就会清掉，因此，对这样的空间，是不能预读的，因为预读会改变原来的值），这些都是PCIe设备在出厂前都设置好的，提供给系统软件的信息。

然后系统软件根据这些信息，在系统内存空间找到这样一块地方来映射这4KB的空间，把分配的基地址写入到BAR0：

从而最终完成了该PCIe空间的映射。一个PCIe设备可能有若干个内部空间需要开放出来，系统软件依次读取BAR1，BAR2。。。，直到BAR5，完成所有内部空间的映射。

上面主要讲了Endpoint的BAR，Switch也有两个BAR，今天不打算讲，下节讲TLP路由，再回过头来讲。继续说配置空间。

前面说每个PCIe设备都有一个配置空间，其实这样说是不准确的，而是每个PCIe设备至少有一个配置空间。一个PCIe设备，它可能具有多个功能（function），比如既能当硬盘，还能当网卡。每个功能对应一个配置空间。

在一个PCIe拓扑结构里，一条总线下面可以挂几个设备，而每个设备可以具有几个功能，如下所示：

因此，在整个PCIe系统中，只要知道了Bus+Device+Function，就能找到对应的Function。寻址基本单元是功能（function），它的ID就由Bus+Device+Function组成 （BDF)。一个PCIe系统，可以最多有256条Bus，每条Bus上可以挂最多32个Device，而每个Device最多又能实现8个Function，而每个Function对应着4KB的配置空间。上电的时候，这些配置空间都是需要映射到Host的内存空间，因此，需要占用内存空间是：256328*4KB =256MB。在这个动辄4GB、8GB内存的时代，256MB算不了什么。

系统软件是如何读取Configuration空间呢？不能通过BAR中的地址，为什么？别忘了BAR是在Configuration中的，你首先要读取Configuration，才能得到BAR。前面不是系统为所有可能的Configuration预留了256MB内存空间吗？系统软件想访问哪个Configuration，只需指定相应Function对应的内存空间地址，RC发现这个地址是Configuration映射空间，就会产生相应的Configuration Read TLP去获得相应Function的Configuration。

再回想一下前面介绍的Configuration Read TLP的Header格式：

Bus Number + Device + Function就唯一决定了目标设备； Ext Reg Number + Register Number相当于配置空间的偏移。找到了设备，然后指定了配置空间的偏移，就能找到具体想访问的配置空间的某个位置。

结束前，强调一下，只有RC才能发起Configuration的访问请求，其他设备是不允许对别的设备进行Configuration读写的。

老男孩读PCIe之七：TLP的路由

一个TLP，是怎样经历千山万水，最后顺利抵达目的地呢？

今天就以上图的简单拓扑结构为例，讨论一个TLP是怎样从发起者到达接收者，即TLP路由问题。

PCIe共有三种路由方式：基于地址（Address）路由，基于设备ID（Bus number + Device number + Function Number）路由，还有就是隐式（Implicit）路由。

不同类型的TLP，其寻址方式也不同，下表总结了每种TLP对应的路由方式：

TLP类型	路由方式
Memory Read/Write TLP	地址路由
Configuration Read/Write TLP	ID路由
Completion TLP	ID路由
Message TLP	地址路由或者ID路由或者隐式路由

下面分别讲讲这几种路由方式。

地址路由

前面提到，Switch负责路由和TLP的转发，而路由信息是存储在Switch的Configuration空间的，因此，很有必要先理解Switch的Configuration。

BAR0和BAR1没有什么好说，跟前一节讲的Endpoint的BAR意义一样，存放Switch内部空间在Host内存空间映射基址。

Switch有一个上游端口（靠近RC）和若干个下游端口，每个端口其实是一个Bridge，都是有一个Configuration的，每个Configuration描述了其下面连接设备空间映射的范围，分别由Memory Base和Memory Limit来表示。对上游端口，其Configuration描述的地址范围是它下游所有设备的映射空间范围，而对每个下游端口的Configuration，描述了连接它端口设备的映射空间范围。大家看看下面这张图，理解一下我刚才说的。（Range由Memory Base和Memory Limit限定）

前面我们看到，Memory Read 或者Memory Write TLP的Header里面都有一个地址信息，该地址是PCIe设备内部空间在内存中的映射地址。

当一个Endpoint收到一个Memory Read或者Memory Write TLP，它会把TLP Header中的地址跟它Configuration当中的所有BAR寄存器比较，如果TLP Header中的地址落在这些BAR的地址空间，那么它就认为该TLP是发给它的，于是接收该TLP，否则就忽略。

当一个Switch上游端口收到一个Memory Read或者Memory Write TLP，它首先把TLP Header中的地址跟它自己Configuration当中的所有BAR寄存器比较，如果TLP Header当中的地址落在这些BAR的地址空间，那么它就认为该TLP是发给它的，于是接收该TLP（这个过程与Endpoint的处理方式一样）；如果不是，然后看这个地址是否落在其下游设备的地址范围内（是否在memory base 和memory limit之间），如果是，说明该TLP是发给它下游设备的，因此它要完成路由转发；如果地址不落在下游设备的地方范围内，说明该TLP不是发给它下面设备的，因此不接受该TLP。

刚才的描述是针对TLP从Upstream流到Downstream的路由。如果是TLP从下游往上走呢？

它首先把TLP Header中的地址跟它自己Configuration当中的所有BAR寄存器比较，如果TLP Header当中的地址落在这些BAR的地址空间，那么它就认为该TLP是发给它的，于是接收该TLP（跟前面描述一样）；如果不是，然后看这个地址是否落在其下游设备的地址范围内（是否在memory base 和memory limit之间），如果是，这个时候不是接受，而是拒绝；相反，如果地址不落在下游设备的地方范围内，Switch则把该TLP传上去。

ID路由

在一个PCIe拓扑结构中，由ID = Bus number+Device number+Function Number（BDF)能唯一找到某个设备的某个功能。这种按设备ID号来寻址的方式叫做ID路由。Configuration TLP和Completion TLP（以C打头的TLP）按ID路由，Message在某些情况下也是ID路由。

使用ID路由的TLP，其TLP Header中含有BDF信息：

当一个Endpoint收到一个这样的TLP，它用自己的ID和收到TLP Header中的BDF比较，如果是给自己的，就收下TLP，否则就拒绝。

如果是一个Switch收到这样的一个TLP，怎么处理？我们再回头去看看Switch的Configuration Header。

看三个寄存器：Subordinate Bus Number，Secondary Bus Number和Primary Bus Number，看下图就知道这几个寄存器是什么意思：

对一个Switch来说，每个Port靠近RC（上游）的那根Bus叫做Primary Bus，其Number写在其Configuration Header中的Primary Bus Number寄存器；每个Port下面的那根Bus叫做Secondary Bus，其Number写在其Configuration Header中的Secondary Bus Number寄存器；对上游端口，Subordinate Bus是其下游所有端口连接的Bus 编号最大的那个Bus，Subordinate Bus Number写在每个Port的Configuration Header中的Subordinate Bus Number寄存器。

当一个Switch收到一个基于ID寻址的TLP，首先检查TLP中的BDF是否与自己的ID匹配，如匹配，说明该TLP是给自己的，收下；否则，则检查该TLP中的Bus Number是否落在Secondary Bus Number和Subordinate Bus Number之间，如果是，说明该TLP是发给其下游设备的，然后转发到对应的下游端口；如果其他情况，则拒绝这些TLP。

隐式路由

只有Message TLP才支持隐式路由。在PCIe总线中，有些Message是与RC通信的，RC是该TLP的发送者或者接收者，因此没有必要明明白白的指定地址或者ID，而是采用”你懂的”的方式进行路由，这种路由方式为隐式路由。Message TLP还支持地址路由和ID路由，但以隐式路由为主。

Message TLP的Header总是4DW，如下图所示：

Type字段，低三位，用rrr表示的，指明该Message的路由方式，具体如下：

当一个Endpoint收到一个Message TLP，检查TLP Header，如果是RC的广播Message（011b）或者该Message终结于它（100b），它就接受该Message。

当一个Switch收到一个Message TLP，检查TLP Header，如果是RC的广播Message（011b），则往它每个下游端口复制该Message然后转发；如果该Message终结于它（100b），则接受该TLP；如果下游端口收到发给RC的message，往上游端口转发便是。

上面说的是Message使用隐式路由的情况。如果是地址路由或者ID路由，Message TLP的路由跟别的TLP一样，不赘述。

转载： [https://www.ssdfans.com] 谢谢！