4.4 PCIE链路层接收端Ack/Nak机制的组成要素

    这里主要描述接收端对TLP的响应处理，包括接收TLP和发送Ack/Nak数据包，但不是说PCIE的链路层只做这些事情。

大致的处理流程如下：

    要实现这些处理流程，就需要具备相应的功能模块，入下图是对接收端数据链路层的描述。整个处理流程是被动触发的，就好像打游戏里面的被动技能一样，在收到TLP后才会启动处理流程。整体来说就是收到TLP做校验和序列号的判断，根据判断结果做出相应的动作。

    校验模块，来确定接收的TLP包是否存在传输错误，例如bit反转。如果校验失败就会给发送端发一个Nak数据包告知发送端接收有问题，如果校验通过就做下一步判断，但不一定会立即给发送端发个Ack，这是PCIE的机制决定。

这里面存放的是序列号，序列号的值是接收端期待发送端接下来送过来的值。接收端每正常收一包TLP都会加一。例如当前记录的序列号值为6，发送端此时来了一个TLP，这个TLP所携带的序列号理论上应该为6，如果不是6就是有问题的，需要触发相应的动作。

    这个就是检查序列号匹配情况的，这种检查只会在LCRC检查通过后触发。如果检查发现匹配就认为是个状态良好的TLP包，会发送给事务层。

 这里还有一个缩略词NRS，即Next Receive Sequence Number，表示下一个接收的序列号，锁存的序列号与之比较，比较结果无非是相等，大于或小于，对于这三种情况，会有不同的处理结果，下面分别说明：

    这是正常情况，因为序列号比较的前提是校验通过，所以这时候认为这就是一个没问题的TLP包，会直接给到事务层，NRS也会加一。接收端也会通过Ack来告知发送方，但不会立即发送。接收端会有一个定时器计数，到了一定时间会把最后收到的一个TLP包的序列号放到Ack中反馈回去。这样减少了对链路的挤占。

说明这个TLP包已经收到了，发送端发重了。由于序列号不是无限递增的，是个循环数，所以只要期望序列号与收到的序列号之差小于2048，就认为不是错误数据包，是发重了。接收端会丢弃这个数据包，并给发送端一个ACK，告知我这边当前最新的序列号是多少，该丢弃的就丢掉吧，别再给我发了。

为什么会出现这种情况？发送端可能没有收到以发送的Ack，因此REPLAY_TIMER超时触发了重传，会把Replay Buffer里面的内容都重新发送一遍。

    这说明丢包了，如果我们期望的是30，结果来了31，那肯定在链路上丢掉了。PCIE是要保序的，发送放必须按序发送，接收方必须按序解析。接收端的解决办法就是给发送方发个Nak，并包含序列号30，告知发送方我没有收到这个数据。接收端也会丢到序列号为31的TLP，因为我要按序给到事务层。

之前说不会来一个好的TLP就给个ACK，那啥时候给呢？就用这个东西来控制。当成功接收一个TLP包后就会启动这个定时器，但计数到指定值后会重置，并发送一个Ack数据包，这个数据包的序列号是NRS-1，等再次收到有效的TLP包，重新启动计时。Nak也会用这个计时器，但时间上有所区别。

    Ack或Nak数据包的生成模块，二者包格式是固定的，都包含一个12位的序列号，指示最后收到的没问题的TLP包的序列号。