[参考译文] RTOS/am5728：PCIe 基准测试

RTOS 团队已收到通知。 他们将在这里作出回应。

Tim、

我无法帮助解决此问题的软件配置方面、但我可以确认此系列处理器(AM57xx)的最大 PCIe 出站有效载荷大小限制为64字节。 入站端支持的最大有效载荷为256字节。

感谢确认-我不确定它是128字节还是64字节出站。

现在、我对软件配置没有任何疑问、我认为我相当熟悉这一点。 我可以检查的任何基准测试数据实际上会有所帮助。

您好！

我们在 Processor SDK RTOS AM57x 器件中提供了 EDMA+PCIe 示例。 当您更改为 Gen1或更改为 x1通道时、您观察到吞吐量减少了一半。 这意味着您已正确配置 PCIe GEN2x2通道。

如 Dave 所述、PCIe 出站大小为"最大出站有效载荷大小为64字节(L3互连 PCIe1/2目标端口将大小大于64字节的突发拆分为多个64字节突发)
•最大入站有效载荷大小为256字节(内部转换为128字节-突发)"、TRM 24.9.1.1 PCIe 控制器主要特性。

我们没有手头的基准测试结果、但如果您使用我们的 RTOS 驱动程序、我想您可以在基准测试中添加计时器。 您需要排除 EDMA 设置时间、传输起始点是通过写入 EDMA ESR 寄存器触发它的位置。 如果 EDMA IPR 寄存器设置在这里、则为 finsih 点。 当您使用 EDMA LLD 时、开销可能非常小。

理论上、对于 GEN2X2、TH 为：5.0Gbps x 2通道 x 8/10位编码*(64 /(64+PCIe TLP 接头))。 TLP 头约为24-28字节、具体取决于是否添加了4字节 CRC。

因此、它可能为5.8Gbps = 730Mbps。 实际测量值应更接近此值。 让我们知道您在 OB 写入和 OB 读取方面能得到什么。 如果您的数字低于730 Mbps 的一半、我们有问题需要考虑。

此致、Eric

早上好、

  感谢您的发言、Eric。  

我们将使用 EDMA LLD、并测量从调用  EDMA3_DRV_enableTransfer 到 使用 EDMA3_DRV_requestChannel 调用 EDMA3_RM_Xfer_complete 函  数的时间。 RTOS 应用程序由单个基准测试任务组成、它测试忙循环中的 ISR 调用。

通过此设置、我们可以测量具有以下特性的 PCIe 带宽：OB 1MB 块读取请求382MB/s、 OB 1MB 块写入请求384MB/s

正如您在计算中确认的、它大约比估算带宽的一半多。

我对" 如果您的数字低于730 Mbps 的一半、我们有问题需要考虑"这句话有点困惑。 -在我们的案例中、它稍微多一点。 然而，这确实是一个问题。 我们绝不会在系统设计中依赖完整的理论 Netto 带宽、但优惠50%有点太多。 我们需要大约600MB/s 来实现我们的计划...

此致、

     Tim

Tim、

感谢您提供这些数字。 是的、它应该更接近730 Mbps。 380是一个问题、我 将在下周为测量耳机设置两个 TI EVM。

此致、Eric

尊敬的 Eric：

 有数字吗？

非常感谢、

      Tim

尊敬的 Eric：

 返回一些数字。

感谢您的测试-我们能够将我们的设置"降级"到1个通道、以获得类似的结果。

第一：存在 FPGA 错误、导致底层 RAM 内核无法提供最大带宽。 通过该固定值、我们能够大幅增加我们的读取带宽。 现在、具有1条信道的速率为285MB/s、具有2条信道的速率约为600MB/s。 请注意、对于2个通道、速率是1x 通道的两倍多。

这要好得多、符合我们的最低估计要求。 但是、正如您所说的、应该至少可以再增加10%...

令人不安的是、如果我们对带宽执行写操作、则会上升至345MB/s (1x 通道)/690MB/s (2x 通道)。

与需要完成 TLP 应答的读取请求相比、我了解发布写入请求的好处。 但是、由于 TLPS 正在流水线化、并且由于 PCIe 的全双工特性、这不应占用太多的可用带宽。

我们在 FPGA 方面进行了一些研究、我们看到 Sitara 的 TLPS 读取请求延迟、从而将带宽限制为600Mb/s 我想了解这个失速的来源。

在 FPGA 探针上、我们看到16个请求 TLPS 突发进入。 FPGA 立即从第一个 TLP 打开开始响应。 在16次请求 TLPS 后、传入的 TLPS 之间的时间会更长。

她可以在上三行看到传入请求 TLPS、在下三行看到响应。 以下是显示的所有信号的说明：

请求

高电平：有传入的 TLP 数据等待

2.高电平：最后可用的 TLP 数据已准备好读取

3.高电平：以下管道已准备好接收下一个 TLP

完成

高：存在传出的 TLP 数据

2.高电平：TLP 的最后一个数据字已准备好读取

高：PCIe 内核的发送端已准备好读取传入数据

很明显、对于前16个 TLPS、FPGA 发送侧停止(信号 m_axis _fifo_rx_迎宾 饰为低电平)。 第一个 TLP 会立即得到 Handeld、但会延迟处理以下内容。

但在这些 TLPS 之后、传入的 TLP FIFO 会变干(图中的时钟周期320)。 现在、以下流水线能够立即再次计算 TLPS。 大部分时间都在等待传入的 TLPS。

由于 PCIe 内核是第三方 IP、我们不知道实现细节、但除了图中的探针之外、我们还通过 GPIO 实现了时间相关性、我们可以看到、在开始时传入的 TLP 速率足够高、以确保最大带宽- 约为50ns。

我们在 FPGA 端对流控制/TLP 凭据进行了一些诊断、我们看不到任何异常/可疑的情况。 我们无法确定 Sitara 以如此低的速率发送以下 TLPS 的原因-每个 TLP 约为200ns。

你有什么想法吗？

另一个问题是流量控制凭据和链路层 ACK 与 TLP 比率的使用。 该标准支持多种比率。 Sitara 在这里使用什么？

提前感谢您、

    Tim

您好！

 到目前为止还有什么新的东西吗？

与此同时、我们正在努力使 FPGA 端能够处理写请求。 请参阅我  的文章。

最棒的

   Tim

Eric、

您能对我的调查结果做一个陈述吗？

提前感谢、

Tim

Tim、

很抱歉耽误你的回答！ 在这种情况下、AM57x 是向 FPGA 发送读取请求 TLP 的请求者。 您看到、在16次突发 TLP 后、TLP 间隔更大、从而降低吞吐量。 我联系了我们的硬件团队、我不知道。 在您的耳塞中、"现在、1条信道的速度为285MB/s、2条信道的速度约为600MB/s。 请注意、对于2个通道、速率是1x 通道的两倍多。 这要好得多、符合我们的最低估计要求。" 因此、我希望这个数字在您的系统要求中仍然可以接受。

TLP ACK 频率由表24-871控制。 PCIECTRL_PL_ACK_FREQ_ASPM (偏移量0x70C)。 默认情况下、此值为0。 您可以将其编程为一个小数 N、以查看是否每个 N TLP 生成 ACK DLLP、并查看增大到更大的 N 有任何好处、可以更快地在 AM57x 上生成读取 TLP。

此致、Eric

Tim、

此外、该表24-875。 PCIECTRL_PL_Ln_SKW_R、位24和25可禁用流控制并尝试 ACK。

此致、Eric

非常感谢、这对我们有很大帮助！

是的、我们可以了解这些数字-但请求者/完成者角色的切换仍在讨论中、为了确定这一点、我们必须证明我们已达到带宽限制。

我只是没有找到您提到的表中描述的寄存器。 如果带宽受到 ACK/流量控制的影响、我将进行尝试。

最棒的

Tim

您好！

我提到的寄存器来自文献编号：SPRUHZ7C AM571x TRM、也许表编号对于 AM572x TRM 是不同的或不同的修订版本。 但是、如果您搜索偏移量或寄存器名称、则应该会找到它们。

由于前16个 TLP 速度更快、您是否能够通过数学方法计算前16个 TLP 的吞吐量？ 正如您知道的、它是320us、还有多少字节？ 然后、在16个 TLPS 之后、具有较低步速的吞吐量是多少？

此致、Eric

尊敬的 Eric：

  我在 AM572x 的 TRM 中找到了这些表。 感谢您指出这些内容！ 我很快会做一些测试。

我发送的图中的时间轴以 FPGA 时钟周期为单位进行测量。 一个周期为4ns、前16个 TLPS 需要大约310个周期。 这导致一个 TLP 需要大约77ns。 对于每个 TLP 64字节、理论带宽为787MB/s

在前16个 TLPS 之后、一个 TLP 需要大约50个时钟周期-> 200ns、这会导致理论带宽为305MB/s

实际数据速率取决于慢节奏和快节奏 TLPS 之间的比率。 由于我们只能探测有限的时间片、因此我们不知道稍后是否有更快节奏的 TLPS 以及它们的发生频率。 但是、我们看到在600Mb/s 的巨大请求上具有稳定的带宽 该图显示了一个提示、即可能存在大约780Mb/s 的带宽。

这里的数字或多或少都是粗略估算、但它们的幅度应该是正确的。

最棒的

    Tim

您好！

谢谢！ 因此、我们可以看到以787Mb/s 的速率实现高速度、以305Mb/s 的速率进行低速度读取、从而实现稳定的600Mb/s PCIe 读取。 我不知道为什么会发生这种情况、也不知道我们是否可以像 PCIe 写入那样维持更高的速率。 我猜测 AM572x 上的 PCIe 具有一些接收器缓冲区、在 EDMA 从 FPGA 请求更多数据之前、需要将中的数据读取移至指定的存储器区域以释放缓冲区。

您可以尝试读取 DDR 或 OCMC 中的数据是否有差异、流控制和 ACK 频率也有帮助。

此致、Eric

尊敬的 Eric：

我尝试了流控制和 ACK freq。 我在配置 Gen2和开始链路训练之前设置它。 在发送之前增加缓冲 ACK 的数量不会影响带量。 禁用 ACK/NACK 和/或流控会导致 PCIe 连接出现故障。 无论如何、至少我尝试过。 )
读取/写入 DDR 或 OCMC 似乎也不会影响带宽。 这对我来说是合乎逻辑的、因为我的测试表明两者都具有相似的 DMA 带宽。 但即使使用 L2 RAM 也不会影响带宽。 瓶颈似乎在数据到达 L3-Main 之前的某个位置。

最棒的
Tim

您好！

Tim、

您是否介意共享 DSP PCIe 代码？我正在这样做。

谢谢！

Vefone  

Eric、

 是的、感谢您的努力！

      Tim

Tim、

您是否介意指导我如何设置 am5728和 FPGA 之间的数据交换。 我现在正在处理它、连接火车是可以的。

Vefone、

 我不知道如何帮助我。 因为您必须配置的内容取决于 FPGA 端和您的用例、我不熟悉这种情况。 我在 这里找到并记录了与此无关的任何内容。

希望这有所帮助、

    Tim

Tim、
非常感谢！ 您提供的链接非常有用。现在、DSP 可以将数据写入 FPGA 条形空间。