你好赵伟

这个屌丝很懒，什么也没留下！

热门标签

一步一步开始FPGA逻辑设计 - 高速接口之PCIe_pcie expansion rom

作者：你好赵伟 | 2024-04-27 11:34:21

踩

pcie expansion rom

写在前面

近两年来和几个单位接触下来，发现PCIe还是一个比较常用的，有些难度的案例，主要是涉及面比较广，需要了解逻辑设计、高速总线、Linux和Windows的驱动设计等相关知识。

这篇文章主要针对Xilinx家V6和K7两个系列的PFGA，在Linux和Windows两种系统平台下，基于Xilinx的参考案例XAPP1052的基础上，设计实现了总线主控DMA（Bus Master DMA），透明映像内存空间和中断机制，在实际工程实践中得到了良好的应用，主要应用在光纤PCIe数据采集卡、FPGA加速卡、存储子系统等所有需要和主机进行高速数据交互的场所。这篇博客记录了在学习、开发、调试FPGA和主机之间的PCIe通讯接口的方方面面，记录难免有些差错，有任何事宜，欢迎邮件交流学习，jackxu8#163.com。需要完整设计文件或协助进行二次开发的，也可邮件联系。

第一版本多以开发记录为主，不尽完善，看得人多的话我在逐步完善，尽量讲的更加清楚一下。

PCIe协议基础知识

在高速互连领域中，使用高速差分总线替代并行总线是大势所趋。与单端并行信号（PCI总线）相比，高速差分信号（PCIe总线）可以使用更高的时钟频率，从而使用更少的信号线，完成之前需要许多单端并行数据信号才能达到的总线带宽。

PCI总线使用并行总线结构，在同一条总线上的所有外部设备共享总线带宽，而PCIe总线使用了高速差分总线，并采用端到端的连接方式，因此在每一条PCIe链路中只能连接两个设备。这使得PCIe与PCI总线采用的拓扑结构有所不同。PCIe总线除了在连接方式上与PCI总线不同之外，还使用了一些在网络通信中使用的技术，如支持多种数据路由方式，基于多通路的数据传递方式，和基于报文的数据传送方式，并充分考虑了在数据传送中出现服务质量QoS (Quality of Service)问题。

PCIe总线

与 PCI 总线不同， PCIe 总线使用端到端的连接方式，在一条 PCIe 链路的两端只能各连接一个设备，这两个设备互为是数据发送端和数据接收端。 PCIe 链路可以由多条 Lane 组成，目前 PCIe 链路× 1 、× 2 、× 4 、× 8 、× 16 和× 32 宽度的 PCIe 链路，还有几乎不使用的× 12 链路。

PCIe总线规范	总线频率	单Lane的峰值带宽	编码方式	单个Lane带宽
1.x	1.25GHz	2.5GT/s	8/10b编码	250MB/s
2.x	2.5GHz	5GT/s	8/10b编码	500MB/s
3.0	4GHz	8GT/s	128/130b编码	1GB/s

在PCIe总线中，使用GT(Gigatransfer)计算PCIe链路的峰值带宽。GT是在PCIe链路上传递的峰值带宽，其计算公式为总线频率×数据位宽×2。

按照常理新一代的带宽要比上一代翻倍，PCIe3.0的原始数据传输带宽应该是10GT/s才对而实际却只有8.0GT/s。我们知道，在1.0，2.0标准中，采用的是8b/10b的编码方式，也就是说，每传输8比特有效数据，要附带两比特的校验位，实际要传输10比特数据。因此，有效带宽=原始数据传输带宽*80%。而3.0标准中，使用了更为有效的128b/130b编码方案从而避免20%带宽损失，3.0的浪费带宽仅为1.538%，基本可以忽略不计，因此8GT/s的信号不再仅仅是一个理论数值，它将是一个实在的传输值。

PCIe总线采用了串行连接方式，并使用数据包(Packet)进行数据传输，采用这种结构有效去除了在PCI总线中存在的一些边带信号，如INTx和PME#等信号。在PCIe总线中，数据报文在接收和发送过程中，需要通过多个层次，包括事务层、数据链路层和物理层。PCIe总线的层次结构如下。

PCIe总线的层次组成结构与网络中的层次结构有类似之处，但是PCIe总线的各个层次都是使用硬件逻辑实现的。在PCIe体系结构中，数据报文首先在设备的核心层(Device Core)中产生，然后再经过该设备的事务层(TransactionLayer)、数据链路层(Data Link Layer)和物理层(Physical Layer)，最终发送出去。而接收端的数据也需要通过物理层、数据链路和事务层，并最终到达Device Core。

在PCIe总线层次结构中，事务层最易理解，同时也与系统软件直接相关。

事务层定义了PCIe总线使用总线事务，其中多数总线事务与PCI总线兼容。这些总线事务可以通过Switch等设备传送到其他PCIe设备或者RC，RC也可以使用这些总线事务访问PCIe设备。事务层接收来自PCIe设备核心层的数据，并将其封装为TLP(Transaction Layer Packet)后，发向数据链路层。此外事务层还可以从数据链路层中接收数据报文，然后转发至PCIe设备的核心层。事务层还使用流量控制机制保证PCIe链路的使用效率。

总线信号

在一个处理器系统中，一般提供×16的PCIe插槽，并使用PETp0~15、PETn0~15和PERp0~15、PERn0~15共64根信号线组成32对差分信号，其中16对PETxx信号用于发送链路，另外16对PERxx信号用于接收链路。除此之外PCIe总线还使用了下列辅助信号。

1 PERST#信号

该信号为全局复位信号，由处理器系统提供，处理器系统需要为PCIe插槽和PCIe设备提供该复位信号。PCIe设备使用该信号复位内部逻辑，当该信号有效时，PCIe设备将进行复位操作。PCIe总线定义了多种复位方式，其中Cold Reset和Warm Reset这两种复位方式的实现与该信号有关。

2 REFCLK+和REFCLK-信号

PCIe设备与PCIe插槽都具有REFCLK+和REFCLK-信号，其中PCIe插槽使用这组信号与处理器系统同步。

当PCIe设备作为Add-In卡连接在PCIe插槽时，可以直接使用PCIe插槽提供的REFCLK+和REFCLK-信号，也可以使用独立的参考时钟，只要这个参考时钟在100MHz±300ppm范围内即可。在PCIe设备配置空间的Link Control Register中，含有一个“Common ClockConfiguration”位。当该位为1时，表示该设备与PCIe链路的对端设备使用“同相位”的参考时钟；如果为0，表示该设备与PCIe链路的对端设备使用的参考时钟是异步的。如果主机系统使用用了扩谱时钟，那么最好使用这个参考时钟信号，不要使用自己的晶振产生时钟。

3 WAKE#信号

当PCIe设备进入休眠状态，主电源已经停止供电时，PCIe设备使用该信号向处理器系统提交唤醒请求，使处理器系统重新为该PCIe设备提供主电源V_cc。在PCIe总线中，WAKE#信号是可选的，因此使用WAKE#信号唤醒PCIe设备的机制也是可选的，产生该信号的硬件逻辑必须使用辅助电源V_aux供电。

WAKE#是一个Open Drain信号，一个处理器的所有PCIe设备可以将WAKE#信号进行线与后，统一发送给处理器系统的电源控制器。当某个PCIe设备需要被唤醒时，该设备首先置WAKE#信号有效，然后在经过一段延时之后，处理器系统开始为该设备提供主电源V_cc，并使用PERST#信号对该设备进行复位操作。此时WAKE#信号需要始终保持为低，当主电源V_cc上电完成之后，PERST#信号也将置为无效并结束复位，WAKE#信号也将随之置为无效，结束整个唤醒过程。

配置空间

PCI总线定义了两类配置请求，一个是Type00h配置请求，另一个是Type 01h配置请求。

其中HOST主桥或者PCI桥使用Type 00h配置请求，访问与HOST主桥或者PCI桥直接相连的PCI Agent设备或者PCI桥；而使用Type 01h配置请求，需要至少穿越一个PCI桥，访问没有与其直接相连的PCI Agent设备或者PCI桥。在PCI总线中，只有PCI桥能够接收Type 01h配置请求。Type 01h配置请求不能直接发向最终的PCI Agent设备，而只能由PCI桥将其转换为Type 01h继续发向其他PCI桥，或者转换为Type 00h配置请求发向PCI Agent设备。

基本配置空间

这个基本配置空间共由64个字节组成，其地址范围为0x00~0x3F，这64个字节是所有PCI设备必须支持的。

PCI设备都有独立的配置空间，HOST主桥通过配置读写总线事务访问这段空间。PCI总线规定了三种类型的PCI配置空间，分别是PCI Agent设备使用的配置空间，PCI桥使用的配置空间和Cardbus桥片使用的配置空间。

在PCI设备配置空间中出现的地址都是PCI总线地址，属于PCI总线域地址空间。

在PCI Agent设备的配置空间中包含了许多寄存器，这些寄存器决定了该设备在PCI总线中的使用方法，系统软件只对部分配置寄存器感兴趣。PCI Agent设备使用的Type 00配置空间如下。

在PCI Agent设备配置空间中包含的寄存器如下所示。

(1) DeviceID和Vendor ID寄存器

这两个寄存器的值由PCISIG分配，只读。其中Vendor ID代表PCI设备的生产厂商，而Device ID代表这个厂商所生产的具体设备。如Xilinx公司的K7，其Vendor ID为0x10EE，而Device ID为0x7028。

(5) SubsystemID和Subsystem Vendor ID寄存器

这两个寄存器和DeviceID和Vendor ID类似，也是记录PCI设备的生产厂商和设备名称。但是这两个寄存器和Device ID与Vendor ID寄存器略有不同。下文以一个实例说明Subsystem ID和Subsystem

(6) ExpansionROM base address寄存器

有些PCI设备在处理器还没有运行操作系统之前，就需要完成基本的初始化设置，比如显卡、键盘和硬盘等设备。为了实现这个“预先执行”功能，PCI设备需要提供一段ROM程序，而处理器在初始化过程中将运行这段ROM程序，初始化这些PCI设备。ExpansionROM base address记载这段ROM程序的基地址。

(7) CapabilitiesPointer寄存器

在PCI设备中，该寄存器是可选的，但是在PCIe设备中必须支持这个寄存器，Capabilities Pointer寄存器存放Capabilities寄存器组的基地址，PCI设备使用Capabilities寄存器组存放一些与PCI设备相关的扩展配置信息。

(8) InterruptLine寄存器

这个寄存器是系统软件对PCI设备进行配置时写入的，该寄存器记录当前PCI设备使用的中断向量号，设备驱动程序可以通过这个寄存器，判断当前PCI设备使用处理器系统中的哪个中断向量号，并将驱动程序的中断服务例程注册到操作系统中。

(9) InterruptPin寄存器

这个寄存器保存PCI设备使用的中断引脚，PCI总线提供了四个中断引脚INTA#、INTB#、INTC#和INTD#。InterruptPin寄存器为1时表示使用INTA#引脚向中断控制器提交中断请求，为2表示使用INTB#，为3表示使用INTC#，为4表示使用INTD#。

如果PCI设备只有一个子设备时，该设备只能使用INTA#；如果有多个子设备时，可以使用INTB~D#信号。如果PCI设备不使用这些中断引脚，向处理器提交中断请求时，该寄存器的值必须为0。值得注意的是，虽然在PCIe设备中并不含有INTA~D#信号，但是依然可以使用该寄存器，因为PCIe设备可以使用INTx中断消息，模拟PCI设备的INTA~D#信号。

(10) BaseAddress Register 0~5寄存器

该组寄存器简称为BAR寄存器，BAR寄存器保存PCI设备使用的地址空间的基地址，该基地址保存的是该设备在PCI总线域中的地址。其中每一个设备最多可以有6个基址空间，但多数设备不会使用这么多组地址空间。

在PCI设备复位之后，该寄存器将存放PCI设备需要使用的基址空间大小，这段空间是I/O空间还是存储器空间，如果是存储器空间该空间是否可预取。

系统软件对PCI总线进行配置时，首先获得BAR寄存器中的初始化信息，之后根据处理器系统的配置，将合理的基地址写入相应的BAR寄存器中。系统软件还可以使用该寄存器，获得PCI设备使用的BAR空间的长度，其方法是向BAR寄存器写入0xFFFF-FFFF，之后再读取该寄存器。

处理器访问PCI设备的BAR空间时，需要使用BAR寄存器提供的基地址。值得注意的是，处理器使用存储器域的地址，而BAR寄存器存放PCI总线域的地址。因此处理器系统并不能直接使用“BAR寄存器+偏移”的方式访问PCI设备的寄存器空间，而需要将PCI总线域的地址转换为存储器域的地址。

扩展配置空间

此外PCI/PCI-X和PCIe设备还扩展了0x40~0xFF这段配置空间，在这段空间主要存放一些与MSI或者MSI-X中断机制和电源管理相关的Capability结构。其中所有能够提交中断请求的PCIe设备，必须支持MSI或者MSI-X Capability结构。

PCIe设备还支持0x100~0xFFF这段扩展配置空间。PCIe设备使用的扩展配置空间最大为4KB，在PCIe总线的扩展配置空间中，存放PCIe设备所独有的一些Capability结构，而PCI设备不能使用这段空间。

PCIe总线规范要求其设备必须支持Capabilities结构。在PCI总线的基本配置空间中，包含一个Capabilities Pointer寄存器，该寄存器存放Capabilities结构链表的头指针。在一个PCIe设备中，可能含有多个Capability结构，这些寄存器组成一个链表。一个PCIe设备可以包含多个Capability结构，包括与电源管理相关、与PCIe总线相关的结构、与中断请求相关的Capability结构、PCIe Capability结构和PCIe扩展的Capability结构。

事务层协议

事务层是PCIe总线层次结构的最高层，该层次将接收PCIe设备核心层的数据请求，并将其转换为PCIe总线事务，PCIe总线使用的这些总线事务在TLP头中定义。

在PCIe总线中，Non-Posted总线事务分两部分进行，首先是发送端向接收端提交总线读写请求，之后接收端再向发送端发送完成(Completion)报文。PCIe总线使用Split传送方式处理所有Non-Posted总线事务，存储器读、I/O读写和配置读写这些Non-Posted总线事务都使用Split传送方式。PCIe的事务层还支持流量控制和虚通路管理等一系列特性。

TLP格式

当处理器或者其他PCIe设备访问PCIe设备时，所传送的数据报文首先通过事务层被封装为一个或者多个TLP，之后才能通过PCIe总线的各个层次发送出去。

一个完整的TLP由1个或者多个TLP Prefix、TLP头、Data Payload(数据有效负载)和TLP Digest组成。TLP头是TLP最重要的标志，不同的TLP其头的定义并不相同。TLP头包含了当前TLP的总线事务类型、路由信息等一系列信息。在一个TLP中，Data Payload的长度可变，最小为0，最大为1024DW。

TLPDigest是一个可选项, 一个TLP是否需要TLP Digest由TLP头决定。DataPayload也是一个可选项，有些TLP并不需要DataPayload，如存储器读请求、配置和I/O写完成TLP并不需要Data Payload。

TLPPrefix由PCIe V2.1总线规范引入，分为LocalTLP Prefix和EP-EP TLP Prefix两类。其中Local TLP Prefix的主要作用是在PCIe链路的两端传递消息，而EP-EP TLP Prefix的主要作用是在发送设备和接收设备之间传递消息。

TLP头由3个或者4个双字(DW)组成。其中第一个双字中保存通用TLP头，其他字段与通用TLP头的Type字段相关。一个通用TLP头由Fmt、Type、TC、Length等字段组成，如图5‑2所示。

如果存储器读写TLP支持64位地址模式时，TLP头的长度为4DW，否则为3DW。而完成报文的TLP头不含有地址信息，使用的TLP头长度为3DW。

通用TLP头的Fmt字段和Type字段

Fmt和Type字段确认当前TLP使用的总线事务，TLP头的大小是由3个双字还是4个双字组成，当前TLP是否包含有效负载。这里列举一些常用的

Fmt[2:0]	TLP的格式
0b000	TLP大小为3个双字，不带数据。
0b001	TLP大小为4个双字，不带数据。
0b010	TLP大小为3个双字，带数据。
0b011	TLP大小为4个双字，带数据。

其中所有读请求TLP都不带数据，而写请求TLP带数据，而其他TLP可能带数据也可能不带数据，如完成报文可能含有数据，也可能仅含有完成标志而并不携带数据。在TLP的Type字段中存放TLP的类型，即PCIe总线支持的总线事务。该字段共由5位组成，这里列举一些常用的

TLP类型	Fmt[2:0]	Type[4:0]	描述
MRd	0b000 0b001	0b0 0000	存储器读请求；TLP头大小为3个或者4个双字，不带数据。
MWr	0b010 0b011	0b0 0000	存储器写请求；TLP头大小为3个或者4个双字，带数据。
CplD	0b010	0b0 1010	带数据的完成报文，TLP头大小为3个双字，包括存储器读、I/O读、配置读和原子操作读完成。

PCIe总线的数据报文传送方式与PCI总线数据传送有类似之处。其中存储器写TLP使用Posted方式进行传送，而其他总线事务使用Non-Posted方式。PCIe总线规定所有Non-Posted存储器请求使用Split总线方式进行数据传递。当PCIe设备进行存储器读、I/O读写或者配置读写请求时，首先向目标设备发送数据读写请求TLP，当目标设备收到这些读写请求TLP后，将数据和完成信息通过完成报文(Cpl或者CplD)发送给源设备。

其中存储器读、I/O读和配置读需要使用CplD报文，因为目标设备需要将数据传递给源设备；而I/O写和配置写需要使用Cpl报文，因为目标设备不需要将任何数据传递给源设备，但是需要通知源设备，写操作已经完成，数据已经成功地传递给目标设备。

存储器和配置读写请求TLP

(1) 存储器读请求TLP和读完成TLP

当PCIe主设备，RC或者EP，访问目标设备的存储器空间时，使用Non-Posted总线事务向目标设备发出存储器读请求TLP，目标设备收到这个存储器读请求TLP后，使用存储器读完成TLP，主动向主设备传递数据。当主设备收到目标设备的存储器读完成TLP后，将完成一次存储器读操作。

(2) 存储器写请求TLP

在PCIe总线中，存储器写使用Posted总线事务。PCIe主设备仅使用存储器写请求TLP即可完成存储器写操作，主设备不需要目标设备的回应报文。

(5) 配置读写请求TLP和配置读写完成TLP

从总线事务的角度上看，配置读写请求操作的过程与I/O读写操作的过程类似。配置读写请求TLP都需要配置读写完成作为应答，从而完成一个完成的配置读写操作。

在PCIe总线中，存储器写请求TLP使用Posted数据传送方式。而其他与存储器和I/O相关的报文都使用Split方式进行数据传送，这些请求报文需要完成报文，通知发送端之前的数据请求报文已经被处理完毕。存储器读写请求TLP使用地址路由方式进行数据传递，在这类TLP头中包含Address字段，Address字段具有两种地址格式，分别是32位和64位地址。在存储器读写和I/O读写请求的第3和第4个双字中，存放TLP的32或者64位地址。存储器、I/O和原子操作读写请求使用的TLP头较为类似。

1 Length字段

在存储器读请求TLP中并不包含Data Payload，在该报文中，Length字段表示需要从目标设备数据区域读取的数据长度；而在存储器写TLP中，Length字段表示当前报文的DataPayload长度。Length字段的最小单位为DW。当该字段为n时，表示需要获得的数据长度或者当前报文的数据长度为n个DW，其中0£n£0x3FF。值得注意的是，当n等于0时，表示数据长度为1024个DW。

2 DWBE字段

PCIe总线以字节为基本单位进行数据传递，但是Length字段以DW为最小单位。为此TLP使用Last DW BE和First DW BE这两个字段进行字节使能，使得在一个TLP中，有效数据以字节为单位。

这两个DW BE字段各由4位组成，其中Last DW BE字段的每一位对应数据Payload最后一个双字的字节使能位；而First DW BE字段的每一位对应数据Payload第一个双字的字节使能位。

Last DW BE	第3位	为1表示数据Payload的最后一个双字的字节3有效
	第2位	为1表示数据Payload的最后一个双字的字节2有效
	第1位	为1表示数据Payload的最后一个双字的字节1有效
	第0位	为1表示数据Payload的最后一个双字的字节0有效
First DW BE	第3位	为1表示数据Payload的第一个双字的字节3有效
	第2位	为1表示数据Payload的第一个双字的字节2有效
	第1位	为1表示数据Payload的第一个双字的字节1有效
	第0位	为1表示数据Payload的第一个双字的字节0有效

LastDW BE和First DW BE这两个字段的使用规则如下。

· 如果传送的数据长度在一个对界的双字(DW)之内，则Last DW BE字段为0b0000，而First DW BE的对应位置1；如果数据长度超过1DW，Last DW BE字段一定不能为0b0000。PCIe总线使用LastDW BE字段为0b0000表示所传送的数据在一个对界的DW之内。

· 如果传送的数据长度超过1DW，则First DW BE字段至少有一个位使能。不能出现First DW BE为0b0000的情况。

· 如果传送的数据长度大于等于3DW，则在First DW BE和Last DW BE字段中不能出现不连续的置1位。

· 如果传送的数据长度在1DW之内时，在First DW BE字段中允许有不连续的置1位。此时PCIe总线允许在TLP中传送1个DW的第1，3字节或者第0，2字节。

· 如果传送的数据长度为2DW之内时，则First DW BE字段和Last DW BE字段允许有不连续的置1位。

值得注意的是，PCIe总线支持一种特殊的读操作，即“Zero-Length”读请求。此时Length字段的长度为1DW，而First DW BE字段和LastDW BE字段都为0b0000，即所有字节都不使能。此时与这个存储器读请求TLP对应的读完成TLP中不包含有效数据。再次提醒读者注意“Zero-Length”读请求使用的Length字段为1，而不是为0，为0表示需要获得的数据长度为1024个DW。

“Zero-Length”读请求的引入是为了实现“读刷新”操作，该操作的主要目的是为了确保之前使用Posted方式所传送的数据，到达最终的目的地，与“Zero-Length”读对应的读完成报文中不含有负载，从而提高了PCIe链路的利用率。在PCIe总线中，使用Posted方式进行存储器写时，目标设备不需要向主设备发送回应报文，因此主设备并不知道这个存储器写是否已经达到目的地。而主设备可以使用“读刷新”操作，向目标设备进行读操作来保证存储器写最终到达目的地。

3 RequesterID字段

RequesterID字段包含“生成这个TLP报文”的PCIe设备的总线号(Bus Number)、设备号(Device Number)和功能号(Function Number)，其格式如图5‑9所示。对于存储器写请求TLP，Requester ID字段并不是必须的，因为目标设备收到存储器写请求TLP后，不需要完成报文作为应答，因此Requester ID字段对于存储器写请求TLP并没有实际意义。

TLP中与数据负载相关的参数

在PCIe总线中，有些TLP含有Data Payload，如存储器写请求、存储器读完成TLP等。在PCIe总线中，TLP含有的Data Payload大小与Max_Payload_Size、Max_Read_Request_Size和RCB参数相关。

Max_Payload_Size参数

PCIe总线规定在TLP报文中，数据有效负载的最大值为4KB，但是PCIe设备并不一定能够发送这么大的数据报文。PCIe设备含有“Max_Payload_Size”和“Max_Payload_SizeSupported”参数，这两个参数分别在Device Capability寄存器和Device Control寄存器中定义。

“Max_Payload_SizeSupported”参数存放在一个PCIe设备中，TLP有效负载的最大值，该参数由PCIe设备的硬件逻辑确定，系统软件不能改写该参数。而Max_Payload_Size参数存放PCIe设备实际使用的，TLP有效负载的最大值。该参数由PCIe链路两端的设备协商决定，是PCIe设备进行数据传送时，实际使用的参数。

PCIe设备发送数据报文时，使用Max_Payload_Size参数决定TLP的最大有效负载。当PCIe设备的所传送的数据大小超过Max_Payload_Size参数时，这段数据将被分割为多个TLP进行发送。当PCIe设备接收TLP时，该TLP的最大有效负载也不能超过Max_Payload_Size参数，如果接收的TLP，其Length字段超过Max_Payload_Size参数，该PCIe设备将认为该TLP非法。

RC或者EP在发送存储器读完成TLP时，这个存储器读完成TLP的最大Payload也不能超过Max_Payload_Size参数，如果超过该参数，PCIe设备需要发送多个读完成报文。值得注意的是，这些读完成报文需要满足RCB参数的要求，有关RCB参数的详细说明见下文。

在实际应用中，尽管有些PCIe设备的Max_Payload_Size Supported参数可以为256B、512B、1024B或者更高，但是如果PCIe链路的对端设备可以支持的Max_Payload_Size参数为128B时，系统软件将使用对端设备的Max_Payload_Size Supported参数，初始化该设备的Max_Payload_Size参数，即选用PCIe链路两端最小的Max_Payload_Size Supported参数初始化Max_Payload_Size参数。

在多数x86处理器系统的MCH或者ICH中，Max_Payload_SizeSupported参数为128B。这也意味着在x86处理器中，与MCH或者ICH直接相连的PCIe设备进行DMA读写时，数据的有效负载不能超过128B。而在PowerPC处理器系统中，该参数大多为256B。

目前在大多数EP中，Max_Payload_Size Supported参数不大于512B，因为在大多数处理器系统的RC中，Max_Payload_Size Supported参数也不大于512B。因此即便EP支持较大的Max_Payload_SizeSupported参数，并不会提高数据传送效率。

而Max_Payload_Size参数的大小与PCIe链路的传送效率成正比，该参数越大，PCIe链路带宽的利用率越高，该参数越小，PCIe链路带宽的利用率越低。

PCIe总线规范规定，对于实时性要求较高的PCIe设备，Max_Payload_Size参数不应设置过大，因此这个参数有时会低于PCIe链路允许使用的最大值。

Max_Read_Request_Size参数

Max_Read_Request_Size参数由PCIe设备决定，该参数规定了PCIe设备一次能从目标设备读取多少数据。

Max_Read_Request_Size参数在Device Control寄存器中定义。该参数与存储器读请求TLP的Length字段相关，其中Length字段不能大于Max_Read_Request_Size参数。在存储器读请求TLP中，Length字段表示需要从目标设备读取多少数据。

值得注意的是，Max_Read_Request_Size参数与Max_Payload_Size参数间没有直接联系，Max_Payload_Size参数仅与存储器写请求和存储器读完成报文相关。

PCIe总线规定存储器读请求，其读取的数据长度不能超过Max_Read_Request_Size参数，即存储器读TLP中的Length字段不能大于这个参数。如果一次存储器读操作需要读取的数据范围大于Max_Read_Request_Size参数时，该PCIe设备需要向目标设备发送多个存储器读请求TLP。

PCIe总线规定Max_Read_Request_Size参数的最大值为4KB，但是系统软件需要根据硬件特性决定该参数的值。因为PCIe总线规定EP在进行存储器读请求时，需要具有足够大的缓冲接收来自目标设备的数据。

如果一个EP的Max_Read_Request_Size参数被设置为4KB，而且这个EP每发出一个4KB大小存储器读请求时，EP都需要准备一个4KB大小的缓冲[1]。这对于绝大多数EP，这都是一个相当苛刻的条件。为此在实际设计中，一个EP会对Max_Read_Request_Size参数的大小进行限制。

RCB参数

RCB位在Link Control寄存器中定义。RCB位决定了RCB参数的值，在PCIe总线中，RCB参数的大小为64B或者128B，如果一个PCIe设备没有设置RCB的大小 [2]，则RC的RCB参数缺省值为64B，而其他PCIe设备的RCB参数的缺省值为128B。PCIe总线规定RC的RCB参数的值为64B或者128B，其他PCIe设备的RCB参数为128B。

在PCIe总线中，一个存储器读请求TLP可能收到目标设备发出的多个完成报文后，才能完成一次存储器读操作。因为在PCIe总线中，一个存储器读请求最多可以请求4KB大小的数据报文，而目标设备可能会使用多个存储器读完成TLP才能将数据传递完毕。

当一个EP向RC或者其他EP读取数据时，这个EP首先向RC或者其他EP发送存储器读请求TLP；之后由RC或者其他EP发送存储器读完成TLP，将数据传递给这个EP。

如果存储器读完成报文所传递数据的地址范围没有跨越RCB参数的边界，那么数据发送端只能使用一个存储器完成报文将数据传递给请求方，否则可以使用多个存储器读完成TLP。

假定一个EP向地址范围为0xFFFF-0000~0xFFFF-0010这段区域进行DMA读操作，RC收到这个存储器读请求TLP后，将组织存储器读完成TLP，由于这段区域并没有跨越RCB边界，因此RC只能使用一个存储器读完成TLP完成数据传递。

如果存储器读完成报文所传递数据的地址范围跨越了RCB边界，那么数据发送端(目标设备)可以使用一个或者多个完成报文进行数据传递。数据发送端使用多个存储器读完成报文完成数据传递时，需要遵循以下原则。

· 第一个完成报文所传送的数据，其起始地址与要求的起始地址相同。其结束地址或者为要求的结束地址(使用一个完成报文传递所有数据)，或者为RCB参数的整数倍(使用多个完成报文传递数据)。

· 最后一个完成报文的起始地址或者为要求的起始地址(使用一个完成报文传递所有数据)，或者为RCB参数的整数倍(使用多个完成报文传递数据)。其结束地址必须为要求的结束地址。

· 中间的完成报文的起始地址和结束地址必须为RCB参数的整数倍。

中断

在PCI总线中，所有需要提交中断请求的设备，必须能够通过INTx引脚提交中断请求，而MSI机制是一个可选机制。而在PCIe总线中，PCIe设备必须支持MSI或者MSI-X中断请求机制，而可以不支持INTx中断消息。在PCIe总线中，MSI和MSI-X中断机制使用存储器写请求TLP向处理器提交中断请求。

不同的处理器对PCIe设备发出的MSI报文的解释并不相同。但是PCIe设备在提交MSI中断请求时，都是向MSI/MSI-X Capability结构中的Message Address的地址写Message Data数据，从而组成一个存储器写TLP，向处理器提交中断请求。

有些PCIe设备还可以支持Legacy中断方式，通过发送Assert_INTx和Deassert_INTx消息报文进行中断请求，即虚拟中断线方式。。但是PCIe总线并不鼓励其设备使用Legacy中断方式，在绝大多数情况下，PCIe设备使用MSI或者MSI/X方式进行中断请求。

PCIe总线提供Legacy中断方式的主要原因是，在PCIe体系结构中，存在许多PCI设备，而这些设备通过PCIe桥连接到PCIe总线中。这些PCI设备可能并不支持MSI/MSI-X中断机制，因此必须使用INTx信号进行中断请求。

当PCIe桥收到PCI设备的INTx信号后，并不能将其直接转换为MSI/MSI-X中断报文，因为PCI设备使用INTx信号进行中断请求的机制与电平触发方式类似，而MSI/MSI-X中断机制与边沿触发方式类似。这两种中断触发方式不能直接进行转换。因此当PCI设备的INTx信号有效时，PCIe桥将该信号转换为Assert_INTx报文，当这些INTx信号无效时，PCIe桥将该信号转换为Deassert_INTx报文。

与Legacy中断方式相比，PCIe设备使用MSI或者MSI-X中断机制，可以消除INTx这个边带信号，而且可以更加合理地处理PCIe总线的“序”。目前绝大多数PCIe设备使用MSI或者MSI-X中断机制提交中断请求。

FPGA设计

博主主要在Xilinx的FPGA上进行设计，好在X家提供了PCIe的IP和，支持到事务层，就不想SATA那么麻烦需要自己从物理层开始写逻辑。本文讲述了从IP核的建立、系统仿真环境的搭建、参考案例的讲解到BMD控制器中各个模块的设计方法。

IP核建立

这里V6使用ISE开发，K7使用Vivado开发。核的参数主要是Device Type、Lane Width、Link Speed、Interface Frequency和BAR选项。这个BAR建立BAR0必须要，地址大宇2KB就可以。其他的BAR是不是需要看您喜好。另外，各个ID和驱动安装有关，只要对应上就可以。

XAPP1052说明

xapp1052是xilinx官方给出的一个有关DMA数据传输的样例，用于PC端和FPGA端之间的DMA数据传输。首先需要说的是，xapp1052并不是一个完整的DMA数据传输的终端硬件设计，这个稍后会有说明。

最新的XAPP1052参考例程为3.3版本，手册在这里，设计文件在这里，下载需要Xilinx账号，我打包放在CSDN上了，可以到这里下载，算是给我贡献一点下载积分吧。

XAPP1052的3.3版本里，对于K7系列以及有一个基于KC705开发板的工程，是在vivado下建立的，使用vivado打开可以直接综合、仿真、测试。

里面包含的BMD的Example和V6系列的稍有差别。包括设计源码、约束和仿真源码。其中，仿真部分的EP是直接例化得设计源码的顶层。

对于使用V6的情况，可以使用XAPP1052 \dma_performance_demo\fpga\implement中的implement_dma.pl脚本自动生成ML605开发板对应的工程。

或者自己搭建工程

..\v6_pcie_v1_7\source全部

..\v6_pcie_v1_7\example_design中的xilinx_pcie_2_0_ep_v6_04_lane_gen2_xc6vlx240t-ff1156-1_ML605.ucf和xilinx_pcie_2_0_ep_v6.v

..\xapp1052\dma_performance_demo\fpga\BMD\common全部

..\xapp1052\dma_performance_demo\fpga\BMD中的BMD_64_RX_ENGINE.v和BMD_64_TX_ENGINE.v和v6_pci_exp_64b_app.v

由于工程中使用了全局宏定义，在ISE上支持的不是特别好，在不对的情况下可以使用手动编译顺序

然后编译，由于要先编译BMD_PCIE_20.v，所以右键选择manual compile order，选中所有.v和.ucf文件。

XAPP1052结构

XAPP1052实现了在事务层的总线主控的DMA传输样例，虽然只是提供了收发固定数据的功能，但是为整个事务层的BMD实现提供的良好的参考。

该参考设计的结构如下

pci_exp_64b_app

|__BMD

|__BMD_EP

| |

| |__BMD_EP_MEM_ACCESS

| | |_BMD_EP_MEM

| |

| |__BMD_RX_ENGINE

| |__BMD_TX_ENGINE

| | |__BMD_INTR_CTRL

| |

| |__BMD_GEN2

| |__BMD_RD_THROTTLE

|__BMD_TO_CTRL

|__BMD_CFG_CTRL

其中，

1、TX_ENGINE.v：是产生TLP包的逻辑，包含读TLP请求用于DMA读；写TLP请求用于DMA写；CPLD用于BAR空间读。
2、RX_ENGINE.v：是解析TLP包的逻辑，包含读TLP解析用于BAR空间读、写TLP解析用于BAR空间写、CPLD解析用于DMA读。

这里先简单介绍一下DMA过程：

RT->EPDMA（存储器读）：

1、驱动程序向操作系统申请一片物理连续的内存;

2、主机向该地址写入数据；

3、主机将这个内存的物理地址告诉FPGA；

4、FPGA向主机发起读TLP请求—连续发出多个读请求；

5、主机向FPGA返回CPLD包—连续返回多个CPLD；

6、FPGA取出CPLD包中的有效数据；

7、FPGA发送完数据后通过中断等形式通知主机DMA完成；

EP->RTDMA（存储器写）：

1、驱动程序向操作系统申请一片物理连续的内存；

2、主机将这个内存的物理地址告诉FPGA；

3、FPGA向主机发起写TLP请求，并将数据放入TLP包中—连续发出多个写请求；

4、FPGA发送完数据后通过中断等形式通知主机DMA完成；

5、主机从内存中获取数据；

系统仿真环境

系统的仿真需要搭建如下一个系统，包括RT（模拟主机端）和我们自己的EP（FPGA）端，并提供相应的时钟和测试激励，系统结构大概如下图所示，只是其中的PIO APP被替换为了咱们的BMD APP

在Vivado下，设置使用Modelsim为仿真工具后，直接使用Vivado的仿真脚本生成功能直接生成的脚本就可以了。

在ISE下，最好是自己书写仿真脚本，注意BMD_PCIE_20.v必须放在最前面编译，完整的仿真脚本可以联系我获取（jackxu8#163.com）。

最后，打开Modelsim软件，更改目录至. . \simulation\functional，输入脚本dosimulate_mti.do 仿真结果如下，

但是XAPP1052没有提供对应的针对DMA的仿真测试脚本，需要我们根据DMA的配置稍后自行书写，详细仿真脚本可以联系我获取（jackxu8#163.com）。

BMD APP设计

万事具备，有了这个环境，我们就可以开始着手修改官方提供的BMD的example，首先这个Example只是用于传输一个固定的pattern，并不能正在的传输用户自己的数据。其次，也不能将接收的数据传输给用户。另外，没有提供用户寄存器和内存传输空间。用户也无法发送自定义的中断。等等这些限制，导致了这个Example只是一个能够用来测试PCIe的DMA传输速度的Example，而不具有实用价值。但是！但是！但是！它提供了很好的基于事务层设计DMA传输的范例，因此，在此基础上修改一个实用的DMA传输控制器将不是什么难事，so, flollow me and make it。

PIO传输

PIO传输就是Programmable IO，通常用于配置寄存器等小数据的传输，一次传输32bit数据。首先需要明确一点，PIO传输都用主机（也就是PC电脑RT端）主动发起，进行一次PIO传输主要需要地址和数据两个参数（TLP包格式参考前面的基础知识）。

那么我们来看一下，这两个参数在BMD的设计中是怎么传递的。

BMD_64_RX_ENGINE.trn_rd[63:0] –> BMD_64_RX_ENGINE.addr_o[10:0]–> BMD_EP.req_addr[10:0] ->BMD_EP_MEM_ACCESS.addr_i[6:0] -> 用于索引寄存器

从这条路径可以看出，BMD接收到RT发过来的地址参数后，将TLP包中解析得到的地址一路送给了BMD_EP_MEM_ACCESS，用来索引对应的寄存器。我们按图索骥，找到BMD_RX_ENGINE.v和BMD_EP_MEM.v中对应的部分，可以发现，不管是存储器写请求（BMD_MEM_WR32_FMT_TYPE）还是存储器读请求（BMD_MEM_RD32_FMT_TYPE）都是RT先发送一个地址下来，索引这个寄存器。