PCIe中的Elastic Buffer

• Elastic Buffer的设计意图是为了实现源同步时序（数据和时钟一起发送出去，对应的还有系统同步即收发两端是同步时钟）中发送和接收时钟之间的时钟频率偏差补偿。
• 为什么要把eBuffer放在decoder之前：
  • 确实将eBuffer放在decoder之后会节省资源（10b --> 8+1b）且不需要考虑校验的问题；
  • 但是spec中规定的Loopback Slave过程中不允许对接收到的数据解码&再编码然后发出，而是需要将接收到的数据直接原封不动的发送出去，但是loopback的过程需要进行时钟补偿，因此必须将eBuffer放在decoder之前；
• 在8b/10b编码方案下 SKP OS = COM + SKP *3，Elastic Buffer补偿过程中删减的就是SKP Symbol；
• 在128b/130B编码方案下 SKP OS由8或12或16或20或24个symbol组成（一般情况下是16个，但是在retimer的时候可能会变），Elastic Buffer补偿过程增删的是symbol 0 之后的一个或两个symbol（具体几个见后面解释）；

• 由于PCIe协议规定收发两端的时钟偏差在±300ppm之内，最差的情况就是600ppm,这种情况下每1666个时钟周期（因为在数字处理中一般按照symbol来处理，所以这里直接替换为symbol clock比如8b/10b其实就是10个回复时钟时钟的周期）就会出现一个symbol时钟的误差；一般为了保险起见PCIe spec规定要求至少每间隔1538个symbol发送一次SKP OS用来做时钟周期补偿。补偿的具体方式是在Ebuffer中增加或删除一个或两个SKP symbol；
• 由于spec要求在发送一整个TLP的过程中不允许打断传输从而在中间插入SKP OS，但是当TLP发送完成之后需要立马补发，并且所有发送的symbol都需要计数进去用来决定是否需要发送SKP OS;
• 如何计算可能的最大失配symbol数：
  • 首先考虑最坏的情况：当发送1538个symbol之后正准备发送SKP OS,此时来了个Max_Payload_size 的TLP，这时候就需要等待整个TLP发送完了才能补发SKP OS;
  • 那么在上述情况下接收端的buffer中的数据移位的计算方式为：

其中MPS是max payload size, TLP_over_header是从TL层到PL层的所有打包数据（如header、SDP、CRC、EDP等）的symbol数量，一般为28；

由上述公式可以知道当Lane_num = 1的时候情况最极端，可以计算得到在MPS为各长度的时候Max_shift的表格：

• 如何确定eBuffer的深度：
  • 对于half-full机制的eBuffer来说，一般需要保持buffer的状态是半满，所以考虑到偏差的两个方向eBuffer的深度为应该为2*floor(Max_shift)；

• 对于Flow Control机制的eBuffer来说其允许Buffer读空此时会关闭后端逻辑。但是其不允许Buffer溢出，对于溢出的情况其处理方式和half-full机制一样，所以它的深度应该是floor(Max_shift) + 1；

• 问题与思考：
  • 在half-full机制的eBuffer的具体实现中，reset之后buffer必然是空的，那么是否意味着第一个进入buffer的symbol需要等到half-full之后才能开始读出？
    • 从参考代码看来确实这里需要等到half-full之后才开始读，毕竟PCIe中不存在某次传输还没达到half-full就结束了的情况，从这里也能看出来改机制会增加几个时钟的时延；
  • 接着上面的问题，那么最后一个symbol读出的时候必然将buffer读空，此时用什么条件来bypass half-full这个要求呢？
    • 这里可以使用一旦满足half-full条件从而发起对eBuffer的读取任务便直到读空才结束；

参考文献：

 [1] Mindshare, Elastic Buffer Implementations in PCIe Devices

[2]【理论篇】IC间通信的时序模型——系统同步、源同步和自同步_源同步和系统同步-CSDN博客