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 

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 

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定时器值的三倍。

Ack/Nak Generator

显然，Ack/Nak Generator的功能是产生Ack或者Nak DLLP。其格式如下：

最后，介绍一下PCIe Spec中推荐的包优先级顺序。我们知道，PCIe总线通信中，存在多种类型的包，包括TLP、DLLP和Ordered Sets等。为了能够是总线达到最优的传输效率，PCIe Spec推荐对这些包的优先级做如下的设置：（当然这只是推荐，并没有强制厂商一定要这要去实现）。