PCIe Ack/Nak 机制详解(一)
前面在数据链路层入门的文章中简单地提到过Ack/Nak机制的原理和作用,接下来的两篇文章中将对Ack/Nak机制进行详细地介绍。
Ack/Nak是一种由硬件实现的,完全自动的机制,目的是保证TLP有效可靠地传输。Ack DLLP用于确认TLP被成功接收,Nak DLLP则用于表明TLP传输中遇到了错误。
如上图所示,发送方会对每一个TLP在Replay Buffer中做备份,直到其接收到来自接收方的Ack DLLP,确认该DLP已经成功的被接受,才会删除这个备份。如果接收方发现TLP存在错误,则会向发送发发送Nak DLLP,然后发送方会从Replay Buffer中取出数据,重新发送该TLP。
Ack/Nak机制内部的详细结构图如下图所示:
下面对图中的各个Elements分别做一个简单地介绍。
首先是发送端的Elements:
来个大图特写:
· NEXT_TRANSMIT_SEQ Counter
NEXT_TRANSMIT_SEQ Counter,即NTS计数器,是一个12位的计数器。当数据链路层处于DL-Down状态或者复位时,该计数器会被初始化为0。该计数器只会执行加一操作,也就是说当其到达最大值4095时,在进行加一操作则会变成0(Roll Over)。该计数器用于产生下一个待发送的TLP的序列号(Sequence Number)。每一个序列号都是与一个TLP所唯一对应的,可以说这个序列号正是整个Ack/Nak机制的关键。
· LCRC Generator
LCRC产生器用于产生一个32位的CRC值,其作用于整个TLP和其对应的序列号。
· Replay Buffer
Replay Buffer是Mindshare书中的叫法,在PCIe Spec中,这个Buffer的名称叫做Retry Buffer。Replay Buffer中按照传输顺序,存储了整个TLP、序列号和LCRC,如下图所示:
当发送端收到来自接收端的Ack DLLP时,会将Buffer中相应的TLP(包括对应的序列号和LCRC)移除;如果接收到的是Nak DLLP,则会将Buffer中响应的TLP(包括对应的序列号和LCRC)重新发送给接收端。
· REPLAY_TIMER Count
REPLAY_TIMER是一种看门狗定时器,当该定时器溢出,则表明发送端已经发送了一个或者多个TLP,但是并未收到来自接收端的应答信号(Ack/Nak)。此时,发送端会将Replay Buffer中的TLP重新发送,并将看门狗定时器重启。
只要发送端发送了任何TLP,该定时器便会启动,在接收到来自接收端的应答信号之前都会持续地运行。当收到应答信号之后,定时器会立即被清零。此时如果Replay Buffer仍然有TLP(表明还有TLP被发送,但是仍未得到应答),定时器又会被立即被重新启动。如果Buffer中是空的,则定时器不会被重新启动,直到新的TLP被发送。
· REPLAY_NUM Count
这是一个2位的计数器,用于记录同一个TLP发送失败的次数,当其值从11b变为00b时(溢出了,表示尝试发送某个TLP失败了4次),数据链路层会自动地强制物理层重新进行链路训练(即LTSSM进入Recovery状态)。当完成链路训练之后,便会重新发送之前发送失败的TLP。
当发送端接收到来自接收端的Nak DLLP或者发送端的看门狗定时器(REPLAY_TIMER)溢出时,该计数器都会被加一;当接收到Ack DLLP时,该计数器则会被清零。
· ACKD_SEQ Register
ACKD_SEQ寄存器用于存储最近接收到的Ack或者Nak DLLP中的序列号。当复位或者数据链路层处于无效状态时,该寄存器会被初始化为全1。关于ACKD_SEQ寄存器的具体用法会在后续的文章中,用例子的形式详细说明。
· DLLP CRC Check
接收端在接收到来自发送端的DLLP后,首先会检查其DLLP CRC,如果发现有错误,则会直接将其丢弃,认为其实无效的DLLP。
然后是接收端的Elements:
首先来一张大图特写:
· LCRC Error Check
顾名思义,LCRC Error Check用于检查接收到的TLP是否存在错误。如果存在错误,则将对应的TLP直接丢弃,然后产生一个Nak DLLP发送给发送端,让其重新发送该TLP。
· NEXT_RCV_SEQ Counter
NEXT_RCV_SEQ是一个12位的计数器,即Next Receive Sequence Number,其值为已经成功接收的TLP的序列号加1。主要用于检查当前接收到的TLP是不是应该接收到的TLP。
如果NEXT_RCV_SEQ和当前接收到的TLP中的序列号的值相等,则认为这是一个有效的TLP,但是接收端并不会立即向发送端发送Ack DLLP,而是等到AckNak_LATENCY_TIMER溢出时才向发送端发送Ack DLLP。也就是说,一个Ack DLLP可能会对应多个TLP,接收端不会每成功接收到一个TLP便向发送端发送Ack DLLP。
如果当前接收到的TLP中的序列号小于NEXT_RCV_SEQ(且差值不超过2048),则认为该TLP之前已经成功发送过了,此次是重复发送。需要注意的是,PCIe Spec认为重复发送并不是一个错误,只是直接将该TLP丢弃,并没有Nak或者Error Reporting,但是会返回一个包含有上一次成功接收的TLP的序列号(NRS-1)的Ack DLLP给发送端。
如果当前接收到的TLP的序列号大于NEXT_RCV_SEQ,表明传输过程中漏掉了一些TLP。此时,接收端会返回Nak DLLP,并直接丢弃该TLP。
一个简单的例子如下图所示:
· NAK_SCHEDULED Flag
NAK_SCHEDULED是一个标志位,当接收端产生Nak DLLP时,该标志位会被置位。当接收端成功接收到有效的TLP时,该标志位会被清零。需要特别注意的是,当该标志位处于置位状态时,接收端不应产生其他的Nak DLLP。
· AckNak_LATENCY_TIMER
AckNak_LATENCY_TIMER定时器会在接收端成功接收到有效的TLP,且并未向发送端返回Ack DLLP之前运行。当AckNak_LATENCY_TIMER定时器溢出时,接收端会立即向发送端返回Ack DLLP(携带的序列号为NRS-1,即一个Ack对应多个有效的TLP)。无论接收端返回Ack还是Nak,该定时器都会被复位,但是只有当接收端再次收到有效的TLP时,该定时器才会被重新启动。
该定时器(REPLAY_TIMER)的值是由PCIe Spec规定的和Lane的数量与Max_Payload有关,Gen1的值如下图所示:
Gen2(5GT/s)如下图所示:
注:该定时器(REPLAY_TIMER)的值是AckNak_LATENCY_TIMER定时器值的三倍。而REPLAY_TIMER的值则如下表所示(Gen1和Gen2):
· Ack/Nak Generator
显然,Ack/Nak Generator的功能是产生Ack或者Nak DLLP。其格式如下:
最后,介绍一下PCIe Spec中推荐的包优先级顺序。我们知道,PCIe总线通信中,存在多种类型的包,包括TLP、DLLP和Ordered Sets等。为了能够是总线达到最优的传输效率,PCIe Spec推荐对这些包的优先级做如下的设置:(当然这只是推荐,并没有强制厂商一定要这要去实现)
- Completion of any TLP or DLLP currently in progress (highest priority)
- Ordered Set
- Nak
- Ack
- Flow Control
- Replay Buffer re‐transmissions
- TLPs that are waiting in the Transaction Layer
- All other DLLP transmissions (lowest priority)
注:这里说的优先级和QoS中说的优先级是两码事,千万不要搞混了。