TLP读处理设计

       对于存储器读请求 TLP， 使用 Non-Posted 方式传输， 即在接收到读请求后， 不仅要进行处理， 还需要通过 axis_cc 总线返回 CplD， 这一过程由读处理模块执行， 读处理模块的结构如图2 所示。

当 axis_cq 总线接收到存储器读请求时， 数据流被转发到读处理模块。读请求 TLP只包含 128 比特的请求报头， 而 axis 总线位宽也是 128 比特， 因此在短时间内可能接收到多个读请求， 为了应对这种情况， 读处理模块采用了带有 outstanding 能力和事务并行处理的结构设计， 能够有效提高读请求事务处理效率和数据传输吞吐量。

首先当读请求数据流到达读处理模块时， 经过解析和地址映射的两级流水后， 放入响应处理单元 outstanding 缓存中， 响应处理单元从缓存中获取事务一一处理， 将 NoP 逻辑加速引擎设计读取的数据打包成 CplD， 并将 CplD 放置到发送缓存中等待 axis_cc 总线的发送。 根据地址的不同， 读请求事务被分为三类， 分别是读队列请求， 读 PRP 请求和读数据请求， 每种请求对应一个响应处理单元。

在实际应用环境中， 由于队列、 PRP、 数据的存储往往在不同的位置， 因此完成读取过程的延迟也不同， 在本IP设计中， 将队列管理与 PRP 都放置在了近 PCIe 端存储，因此读取队列与 PRP 的延迟远远小于读取数据的延迟。 并且当大量不同的读请求交叉处理时， 读处理模块的并行处理结构更能够充分利用 PCIe 的乱序传输能力来提高吞吐量。 为了清晰的说明读处理模块对吞吐量的提升， 设置如图 3 所示的简单时序样例， 样例中 PCIe TLP 的 tag 最大为 3。

在对应图 3 中第 1、 2 行时序的低性能处理模式下， 同一时间只能处理一个读事务， 并且不带有 outstanding 能力， 此时从接收到读请求到成功响应所经历的延迟将会累积， 造成 axis_cq 请求总线的阻塞。 在对应图中第 3、 4 行时序的仅带有outstanding 能力的处理模式下， 虽然可以连续接收多个读请求处理， 但同一时间内只能处理一个事务， 仍会由于较大的处理延迟导致 axis 总线存在较多的空闲周期， 实际的数据传输效率并不高。 在对应图中第 5、 6 行时序的读处理模块处理模式下， 利用多个响应处理单元的并行处理能力和发送缓存， 先行处理完成的 CplD 可以优先发送，紧接着可以处理下一事务， 使总线的传输效率和吞吐量明显提高。