在上一篇中,我们介绍了PCIe设备的配置空间,及其设计的目的,最后我们说到了消息路由的设计。所以,这一篇我们就继续这个话题,来看看PCIe设备之间的通信方式吧。
1. PCIe协议栈
PCIe是以包(Packet)为单位传输数据的。和计算机网络类似,其协议也是分层的。
其协议栈主要分为三层:物理层(Physical Layer),数据链路层(Data Link Layer)和事务层(Transaction Layer),如下图所示:
2. 事务层(Transaction Layer)
PCIe的协议栈最上层叫做事务层,这一层定义了所有和用户相关的PCIe的操作,所以这也会时大家最感兴趣的一层。
2.1. 事务(Transaction)
PCIe的所有操作都被称为一个事务(Transaction),这些事务分为四种类型:
- 内存事务(Memory Transaction)
- IO事务(IO Transaction)
- 配置事务(Configuration Transaction)
- 消息事务(Message Transaction)
一个事务根据其请求的处理方式又被分为两种:
- Non-Posted:每个事务的请求消息发送出去后,会需要一个完成消息(Completion)来完成事务。比如,读内存。
- Posted:请求发送后不需要完成消息,属于Fire and forget。比如,写内存和所有的消息事务(这也是唯二的两类请求)
所以,事务层的消息有三类:Non-Posted(NP),Posted(P)和Completion(Cpl)。
2.2. TLP(Transaction Layer Packet)
PCIe的事务请求和完成消息都是以TLP(Transaction Layer Packet)为单位传输的。其结构如下:
- TLP Prefix:用来实现一些高级特性,比如精确时间测量(Precision Time Measurement),因为它不是必须的,所以我们先跳过。
- TLP Digest:4个字节,可以存放诸如CRC的校验码,不过一般不需要开启,因为后面说的数据链路层已经自带了校验了,这里相当于是双保险。
- TLP Header:这个是TLP中最重要的部分,我们后面马上会详细介绍。
- TLP Payload:这个是TLP中的数据部分,根据不同的事务类型,其大小也不同。比如,读事务就不需要Payload。另外Payload的大小也是有限制的,它不能超过Max_Payload_Size,最大为4096字节。
2.2.1. TLP头
TLP的头部根据处理地址长度的不同,会有12字节(称为3DW)或者16字节(称为4DW)宽。其前4个字节(第一个DW)是公共的头部,包含了绝大部分的用于描述该事务本身的信息和行为的字段,其后的8个字节(第二个和第三个DW)会根据事务种类的不同而产生变化。其前四个字节如下:
Fmt: TLP头的格式
- Bit 7:如果是1,则Fmt必须是100,表示这个头是TLP Prefix
- Bit 6:1 = 读事务(TLP头之后没有Payload),0 = 写事务(TLP头之后有Payload)
- Bit 5:1 = 使用32位地址,头部长度12字节(3DW Header),0 = 使用64位地址,头部长度16字节(4DW Header)
- Type:事务类型,表示这个事务是什么类型的事务,比如内存事务、IO事务、配置事务、消息事务等
- LN(Lightweight Notification):用于标识当前这个内存请求或者完成消息是不是一个轻量级通知
- TH(TLP Hints):用于表示TPH(TLP Processing Hint)是否启用和TPH TLP Prefix是否存在
- TD(TLP Digest):1 = 有TLP Digest,0 = 没有TLP Digest
- EP(Error Poisoning):1 = 有错误,0 = 没有错误
- AT(Address Translation):虚拟化相关的字段,00 = 无地址转换,01 = 需要地址转换,10 = 地址转换已完成,11 = 保留
- Length:Payload的长度,单位为DW(Double Word),1DW = 4字节
这里由两个字段TC和Attr我们没有介绍,因为它们是事务描述符的一部分,我们马上就会介绍。
2.2.2. 事务描述符(Transaction Descriptor)
为了帮助通信的双方知道对方的信息和对消息的处理方式进行描述,在TLP的头中有几个公共的字段,合在一起被称为事务描述符:事务ID(Requester ID和Tag两个字段),消息的属性(Attr字段),流量分类(TC字段)。
虽然TLP头中第二个DW开始的部分会随着请求类型的不同而发生变化,但是这四个字段几乎会在所有的消息中存在(某些情况下Tag会被忽略),所以这里我们用一个内存请求的消息来做例子,展示它们在TLP中的位置:
2.2.2.1. 事务ID(Transaction ID)
事务ID由Requester ID和Tag两个字段组成,用于标识一个事务。其中,
- Requester ID:一共16个bit,用于标识发起这个事务的设备,是请求发起者的BDF
- Tag:一共10个bit,每个发出的TLP都会被赋予一个唯一的标签,帮助PCIe进行数据传输的跟踪和管理,比如并行处理,流控或乱序处理。这里注意T8和T9两个bits,它们和其他的tag的bits不在一起(绿色高亮),且需要修改10-Bit Tag Requester Enable配置寄存器启用
2.2.2.2. 消息属性(Attributes)
消息属性一共有三个bits:高两位 Attr[2:1](Byte 1 - Bit 2,Byte 2 - Bit 5)用于控制消息处理的顺序,而最低位 Attr[0](Byte 2 - Bit 4)用于控制Coherency。
2.2.2.2.1. 消息处理顺序(Ordering)
Attr[2:1]这两个Bits用于控制消息处理的顺序,一共有四种情况:
2.2.2.2.2. No Snoop
NoSnoop(Attr[0])使用来控制缓存一致性的。默认的情况下(值为0),PCIe会对请求进行缓存一致性的处理,比如一个内存的读请求,它会保证先去读Cache,如果没有读到再去读主内存。但是如果这个值为1,PCIe就会直接跳过Cache,去操作主内存。这样就有可能导致一致性的问题,因为有可能Cache中的内容还没有被写入主内存中,这样就读到了错误的值。
但是,这并不代表这个flag没有用,如果我们非常确定我们不需要考虑缓存,那么我们可以启用这个flag,直接去操作主内存,从而提高性能。
当然,也正因为有一致性的问题,所以这个功能被很多事务禁止使用了:比如配置事务、IO事务、大部分的消息事务和MSI(跳过缓存发起中断会导致DMA等功能出错,读到脏数据)等。
2.2.2.3. 流量分类(Traffic Class)
Traffic Class总共有3个bit,用于把所有的事务分成8个不同的类别,用于流控。
基于TC的流控是通过和VC(Virtual Channel)合作来实现的:
- PCIe中的所有物理链路(Link)都可以创建多个VC(Virtual Channel),而每个VC都独立工作,并有着流量控制机制。
- 一个或者多个TC可以被映射到一个VC上,这样就可以通过操作TLP的TC来控制TLP走的VC了。
- VC通过信用机制来控制发包速度,每个VC都有着自己的Credit Pool,如果一个VC的Credit不为0,那么它就可以发送TLP,并且消耗特定的Credit。每个VC的Credit也会在特定的时候补充,保证通信不会中断。
- TC的默认值是0,也是所有设备必须实现的。它被Hardcoded到了VC0上,所以如果没有设置TC,那么所有的TLP都会走VC0。
- 最后,如果两个包有了不同的VC,或者不同的TC,那么它们之间将没有顺序的保证。
这里我们主要了解TC到VC的映射就好,关于VC的具体机制,我们会在后面数据链路层介绍。以下是一个TC和VC相互合作的配置的例子。通过这种方法,我们就可以对PCIe进行流量控制啦!
2.3. TLP事务路由
有了事务ID,我们可以很容易的了解当前事务的源是谁,然而为了能让通信双方通信,我们还需要知道事务的目的地是哪里,这样我们才能把事务发送到正确的地方。
在PCIe中,不同类型的事务中会使用不同的字段和方法来指定目的地,但是总结起来只有两种:
- 通过具体的地址来指定目的地:这种路由方式叫做基于地址的路由(Address-Based Routing)。这种方式主要用于内存事务(Memory Transaction)和IO事务(IO Transaction),通过需要访问的地址,我们就可以通过我们上一篇中介绍的路由机制来进行路由了。
- 通过BDF来指定目的地:这种路由方式叫做基于ID的路由(ID Based Routing)。这种方式主要用于非内存访问型的事务,比如:配置事务(Configuration Transaction),消息事务(Message Transaction)和事务完成的消息通知(Completion)。
另外,我们上一篇还提到了一种特殊的ID分配方式ARI(Alternative Routing ID),它的唯一区别就是把Device Number的5个Bit给了Function Number,用以支持更多的Function,如下:
2.4. TLP小结
好了,到此我们已经把最核心的TLP的公用字段都介绍完毕了,包括TLP主题格式,事务如何分类,如何路由,如何进行流控等等。这里,为了再来整体的来看一下事务层的处理,我们可以参照Intel Cyclone 10的总体框图,如下:
当然在TLP的头中,我们仍然有很多字段没有涉足,这些字段都和具体的事务类型相关,所以我们在这一篇中就不会过多的深入了。毕竟,我们这一篇主要是想聚焦在PCIe的通信协议本身上,来展示PCIe是如何进行通信的,关于每个具体的事务及其格式,我们会放在后面单独的说。
3. 数据链路层(Transaction Layer)
当事务层将事务消息准备好之后,就会向下传递给数据链路层(Data Link Layer)。对于我们发送的事务消息来说,数据链路层主要负责一件事情:保证事务消息能正确的传输到目的地。
数据链路层传输的包主要包括两种,一种用于传输TLP事务消息,一种用于传输数据链路层的控制消息,比如功能(Feature)控制,流量控制,电源管理等等。这两种类型的包通过物理层的Token来进行区分:STP(Start of TLP)表示TLP消息,SDP(Start of DLLP)表示控制消息(DLLP,Data Link Layer Packet)。我们这里一个一个来看。
3.1. TLP事务消息的传输
3.1.1. 数据包格式和数据发送
为了达到这个目的,数据链路层会对数据包再进行一层封装:
在包的前方添加一个序列号(Sequence Number),占用2个字节,用于保证包发送的顺序。这个序列号是每个Link独立的,只有上下游两端保存的序列号(NEXT_RCV_SEQ)一致,才会被对端接收。在包的后方添加一个CRC校验码,叫做LCRC(Link CRC),占用4个字节,用于保证包中数据的正确性。注意,计算CRC的时候,刚刚添加的序列号也会被纳入计算范围中。
封装完成后,为了保证成功的发送,数据链路层会先将包保存在Retry Buffer中,再转交给物理层(Physical Layer)进行发送。在每条消息发送完毕之后,发送方会等待接收方发送ACK消息,如果接收到的返回消息是失败消息,比如Seq错误,CRC校验错误,或者任何物理层的错误,发送方就会把Retry Buffer中的消息拿出来重新发送。[1](3.6 Data Integrity Mechansisms) 。
3.1.2. 数据接收
对于数据的接收方,操作流程则相反。接收方会检查接收到的数据包的序列号和CRC是否正确,如果不正确,就会发送一个Nak消息,要求发送方进行重传。如果正确,就会回发一个Ack消息,表示接收成功,而此时发送方在收到了ACK消息后也可以将其从Retry Buffer中移除。这样,数据链路层就保证了TLP的正确传输。[1](3.6 Data Integrity Mechansisms) 。
更加具体的数据接收处理流程如下:
3.2. 控制消息:DLLP(Data Link Layer Packet)
除了传输TLP数据包之外,数据链路层还需要很多专门用于控制的数据包,比如上面提到的Ack和Nak,这些数据包叫做DLLP(Data Link Layer Packet)。其格式如下:
DLLP中DLLP Type用来指定包的类型,而最后16位的CRC用来做校验,其主要分为以下几种类型:
3.2.1. Ack/Nak
我们在TLP事务消息传输的里就提到过Ack和Nak消息,它们可以说是DLLP中最常用的消息了。功能顾名思义,Ack表示接收成功,Nak表示接收失败,需要重传。这两个包的格式如下:
其中,AckNak_Seq_Num表示当前已经收到的最新的消息序号,所以和TCP类似,PCIe的Ack和Nak可以进行批量操作:无论是Ack还是Nak,当发送方收到这个消息之后,就可以将Retry Buffer中比这个序号老的消息全部移除了,所以Ack/Nak时只需要将最新的序号带上即可。Ack/Nak的差别在于:如果是Nak,那么发送方在移除之后,需要对Retry Buffer中这个序号之后的消息全部进行重传。
最后,DDLP的重传是由次数限制的,默认阈值是4次。如果超过四次,就出触发物理层开始重建(retrain)链路。如果依然失败,就会将该链路关闭。
3.2.2. VC(Virtual Channel)与流量控制
在说TLP的时候,我们提到了PCIe的流量控制是通过将TC(Traffic Class)映射到VC(Virtual Channel),并且利用VC的信用机制来实现的。这里我们就一起来看看这个信用机制吧!
数据链路层中的信用额度管理有两个重要的特点:
- 不同处理方式是的TLP消息有着单独的信用额度管理:Posted(P),Non-Posted(NP)和Completion(Cpl)。这三种消息的信用额度是独立的,互不影响。
- 每个VC都有着自己的独立的信用额度管理,而不是Link。也就是说,如果一个Link上有多个VC,那么每个VC都需要单独的初始化和更新。参与流量控制的消息有很多,主要有三类,每一类有三个变种(N/NP/Cpl),我们的流量控制也主要分三步,其细节和统一的消息格式如下:
- InitFC1-P/NP/Cpl:接收端设备使用此消息向发送端发起初始化流量控制的流程,并初始化信用额度,这是第一步。这个消息有接收端发起的原因是因为,不同的接收端能力不同,所以应该由接收端根据自己的能力,比如缓存的大小,来决定信用额度的大小。
- InitFC2-P/NP/Cpl:用于发送端向接收端确认InitFC1的消息,这是第二步。这个消息中会带有从第一步接收到的信用信息,但是它会被接收端忽略,并没有什么用。另外,这个消息发送之后,发送端将不会再理会任何后续的InitFC1消息了。
- UpdateFC-P/NP/Cpl:用于在信用额度初始化完成之后,接收端向发送端对信用额度进行更新。
这个消息中各个字段含义如下:
- Type:消息ID,映射如下:
- VC ID(v[2:0]):Virtual Channel的Id,Id一共有3位,代表8个VC。
- HdrFC:TLP头部的Credit数量。在发送时,一个TLP头对应着一个Header Credit,不论该TLP的大小如何。
- DataFC:TLP数据部分的Credit数量。一个 DW(Double Word,双字,即4字节)对应着一个Data Credit。
举个例子,我们假设有一个64位地址的内存的写请求,数据长度为128字节,那么我们会需要发送一个4 DW的TLP头,加上128字节的Payload,和一个1 DW可选的TLP Digest,所以我们一共最多消耗1个Header Credit,和 (128 + 4) / 4 = 33个Data Credit。
然后,为了保证发送方正常的消息发送,当接收方处理完部分消息后(或者一些特殊情况后),就会根据其当前缓存的大小,向发送方发送UpdateFC消息,告诉发送方,接收方的信用额度还剩下多少。另外,除了这种情况,接收方还会定时的向发送方上报自己的信用额度(最长间隔30us),这么做的原因是为了避免意外情况,如CRC校验出错,导致信用额度上报丢失,从而导致发送方停止发送消息的问题。
最后,数据链路层还支持Scaled Flow Control,即信用额度的数量可以是2的幂次方,这样就可以管理更大的信用额度了:
为了帮助理解,我们举一个例子:
注意:如果查看原始的包,在计算时需要注意,HdrFC和DataFC都没有对其到字节上,所以记得做好位运算。
- 首先,PCIe的Endpoint会向Switch发送如下三条消息来进行流控初始化:
- 当Switch收到这个消息后,也会向Endpoint发送三条类似的消息,进行反向的初始化。因为流程类似,从这里开始,之后Switch向Endpoint发送的反向流程我们就忽略了。
- Switch收到了InitFC1 DLLP后,会使用InitFC2 DLLP进行确认:
到此,等两边InitFC2的消息交换完毕之后,初始化就完成了!
3.3. 数据链路层小结
最后为了帮助理解,我们再来看一下数据链路层的整体架构:
到这里,数据链路层上和数据传输相关的核心内容就都介绍完了!数据链路层中其实还有很多其他的内容,比如Link的初始化,状态机,电源管理,和Vendor-specific DLLP等等,这些内容我们这里就不详细介绍了,有兴趣的读者可以自行查阅PCIe Spec [1]。
4. 小结
好了,由于篇幅原因,我们这一篇就先到这里。这一篇中我们介绍了PCIe的协议栈,并且详细的介绍了事务层(Transaction Layer)和数据链路层(Data Link Layer)是如何工作的,包括事务的分类,各种消息的格式,数据链路层的作用和封装,以及PCIe基于TC和VC的流控机制。
在下一篇中,我们会继续介绍PCIe协议栈中遗留的部分 —— 物理层(Physical Layer)。
5. 参考资料
出处:Soul Orbit
- http://r12f.com/posts/pcie-3-tl-dll/
- PCI Express Base Specification
- OSDev WIKI - PCI
- Mindshare - An Introduction to PCI Express
- Wikipedia - PCI Express
作者:Soul Orbit
文章来源:TrustZone
推荐阅读
- ISSCC 2024:中国首次!北大团队获年度唯一最佳论文奖!
- AI芯片杂谈~~
- IC设计错误案例:可读debug寄存器错误跨时钟
- ISSCC 2024: 三星利用对称马赛克架构将 DDR5 容量翻倍
- IC最新最全EDA虚拟机分享(RedHat7.9)
更多IC设计干货请关注IC设计专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。