写在前面
本文系转载,略做格式调整与增加解释(_使用斜体表示_),转自:
PCIe扫盲——PCIe总线性能评估(有效数据速率估算)
转载正文
连载目录篇:http://blog.chinaaet.com/justlxy/p/5100061871
物理层编码开销
前面的文章提到过PCIe总线(Gen1&Gen2)采用了8b/10b编码,因此其有效数据速率为物理线路上的速率的80%。即Gen1的有效速率为2.0Gbps=2.5Gbps x 80%,而Gen2的有效速率为 4Gbps=5Gbps x 80%。
如果以数据包的Data Payload为真实有效数据,来计算得话,实际应用中的有效速率会更低。因为,数据包的包头、包尾(LCRC和ECRC等)、数据链路层添加的包编号等等;用于Ack/Nak和Flow Control等的DLLP;用于链路训练和Skip的Order Sets等都会影响真实的有效速率。
这一篇文章,将来详细地聊一聊,如何粗略地估算一个PCIe总线的真实有效速率。
注:由于设备反应时间、数据处理时间、不确定的插入等待时间等等原因,无法从理论上,准确无误地计算出一个PCIe总线的真实有效速率。
注:关于8b/10b编码,前面的文章中已经详细地介绍过了,这里就不再重复了。
Non-Payload 开销
Packet Non-Payload 开销
对于任意的一个TLP来说,除了Data Payload,还有物理层添加的包头(1 Byte)、数据链路层添加的包编号(2 Bytes)、事务层添加的包头(12 or 16 Bytes)、事务层添加的ECRC(4Bytes,可选的)、数据链路层添加的LCRC(4Bytes)和物理层添加的包尾(1 Byte)。具体如下图所示:
如果以3DW的事务层包头来计算,且不添加ECRC,则该TLP至少含有20 Bytes的额外数据(除了Data Payload之外的)。我们姑且称之为TLP Overhead。
注:32bits地址的TLP是3DW包头,而64bits地址的TLP是4DW包头,具体请参考前面的文章。
TLP 间隔开销
如果只从TLP Overhead考虑的话,显然每个TLP包含的Data Payload的量越大,真实有效速率越高。然而,实际应用中却并非如此,因为链路上的其他因素也在影响实际的真实有效速率。PCIe Spec规定,任何TLP都不允许被Order Sets或者DLLP打断。也就是说,Skip Order Sets和FC DLLP、Ack/Nak DLLP都只能在两个TLP之间发送。换一句话说,Data Payload越大,TLP的也就越长,为了保证正常通信,两个TLP之间的时间间隔也就越大。这就是为什么Data Payload越大,但真实有效速率却未必会越高的原因。
比如一般每 5 个 TLP 之后就要发送一个 ACK 报文,每 4 个 TLP 之后要发送一个流控报文。
ACK 与流控开销
除了TLP Overhead之外,前面文章介绍的Ack/Nak机制和Flow Control机制都是需要花费时间的。这里我们分别称其所消耗的时间为Link Protocol Overhead和Flow Control Protocol Overhead。具体这里就不详细,介绍了,请参考之前的文章。
注:显然,更低频率的Flow Control Update,会一定程度上提高真实有效速率,但这需要更大的Rx Buffer,从而带来更高的硬件成本开销。一般情况下,PCIe设备都应当遵循Spec所定义的FC Update周期计算方式,具体可可参考前面的文章:http://blog.chinaaet.com/justlxy/p/5100053465
除了前面介绍的TLP Overhead、Link Protocol Overhead和Flow Control Protocol Overhead之外,另一个影响真实有效速率的关键因素便是Max_Payload_Size,以及Read_Completion_Boundary(RCB)。
系统 Max_Payload_Size 开销
虽然PCIe Spec规定,TLP的Data Payload最高可达4096 Bytes,但同时也规定了PCIe体系结构中,所有的设备,都必须使用相同的Max_Payload_Size值。换一句话说,整个总线的Max_Payload_Size值必须使用总线体系结构中所有设备所支持的最小的Max_Payload_Size值。具体如下图所示:
注:每个设备中的Function的所支持的最大的Max_Payload_Size值应当是相同的。
注:每个设备所支持的Max_Payload_Size最大值信息,存在于Device Capability Register中。
Max_Payload_Size值的设置是在PCIe总线枚举和配置的过程中完成的,软件确定了Max_Payload_Size的值后,会将该值写入到每个设备的Device Control Register中。
简单有效速率计算
在不考虑Ack/Nak机制和Flow Control机制等因素的情况下,真实有效速率可以这样计算:
则有:
以128 Bytes的Max_Payload_Size为例,不考虑Ack/Nak机制和Flow Control机制等因素的情况下,理论极限真实有效速率如下:
其中,1720Mb/s = 86% * 2000Mbps。(x1 Gen1)
注:读操作还需要考虑RCB等因素,后面会详细介绍。表格里的数据是在假设RCB为64 Bytes的情况下得到的,因此其计算方法为:64/(64+20)=76%。
RCB 开销
针对读操作,还有一个Maximun Read Request Size(即最大读请求)的概念,在PCIe总线配置的过程中,该值会被写入到每个设备的Device Control Register中。PCIe Spec规定,Maximun Read Request Size的值可以超过Max_Payload_Size,例如,可以向Max_Payload_Size为128 Bytes的设备,一次请求读512 Bytes的数据。此时,一次请求会对应多个返回的Completion。
然而,Maximun Read Request Size的值也并非越大越好,该值设置的过大,会导致某个PCIe设备独占整个系统带宽的时间过长。但是如果Maximun Read Request Size设置的过小,则需要发起多个读请求操作。
Read Completion Boundary(RCB)确定了针对读请求返回的每个Completion的Data Payload的最大值,一般为64 Bytes或者128 Bytes(由系统或者软件设置)。当然,Completion的Data Payload值,是可以小于RCB的。以64 Bytes 的RCB和一次读256 Bytes的请求为例,可能的情况如下图所示:
注:目前,大部分的Root都固定地使用64 Bytes的RCB,尽管Max_Payload_Size的值可能是128或者更大。
最后,以几个例子,来回顾一下上面的内容。
参考文献:
1、Xilinx. Understanding Performance of PCI Express Systems
版权声明
版权声明:本文为 AET 博主「Felix」的原创文章,转载请附上原文出处链接及本声明。
原文链接:PCIe扫盲--PCIe总线性能评估(有效数据速率估算)-Felix-电子技术应用-AET-中国科技核心期刊-最丰富的电子设计资源平台
转载自:知乎
作者:Felix
推荐阅读
- Recovery.Equalization 基础知识
- PCI Express 学习篇_物理层 LTSSM(1):Recovery 子状态介绍
- 国密标准IPsec VPN协议处理及其密码IP设计与FPGA实现(2)
更多招聘及面经请关注FPGA的逻辑。