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推荐对这些包的优先级做如下的设置：（当然这只是推荐，并没有强制厂商一定要这要去实现）

1. Completion of any TLP or DLLP currently in progress (highest priority)
2. Ordered Set
3. Nak
4. Ack
5. Flow Control
6. Replay Buffer re‐transmissions
7. TLPs that are waiting in the Transaction Layer
8. All other DLLP transmissions (lowest priority)
注：这里说的优先级和QoS中说的优先级是两码事，千万不要搞混了。

注：原文最早发表于本人的ChinaAET博客（http://blog.chinaaet.com/justlxy/）