[参考译文] AM625：我想让 PRU 在 AM625中以333MHZ 运行

我按照建议尝试了这些设置。 PRU 时钟确实切换到了333MHz、但对从 DDR 进行读取的 LBBO 调用显著增加。 是否有详细介绍寄存器和值的文档？ TRM 非常模糊。

				pruss_coreclk_mux: coreclk-mux@3c {
					reg = <0x3c>;
					#clock-cells = <0>;
					clocks = <&k3_clks 81 0>,  /* pruss_core_clk */
						 <&k3_clks 81 14>; /* pruss_iclk */
					assigned-clocks = <&pruss_coreclk_mux>;
					assigned-clock-parents = <&k3_clks 81 14>;
					assigned-clock-rates = <333333333>; 
				};

对于未来的读者、这位之前的客户能够使用与 D Anthony 所发布的相同设置来设置333MHz 时钟：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1450236/am625-help-setting-pruss-clock-to-333mhz-on-am6254/5566801#5566801

我们是否能够让您发布测试代码以及默认时钟频率和更新后的333MHz 时钟频率的测试结果？

此致、

Nick

使用上述设置、PRU 指令以333MHz 的频率运行。 然而、在采用默认设置(250MHz)的情况下、以下指令的时间~600ns。 通过建议的333MHz 时钟设置、指令将接管3us。   似乎建议的设置会影响 DDR 读取速度。 希望它能做到、如果可能、我希望减少600ns 的读数。  

  	set R30,R30,PRU_TEST_1
  	NOP
  	clr R30,R30,PRU_TEST_1
	LBBO &r5, ddr_mapped_addr,0,50
  	set R30,R30,PRU_TEST_1
  	NOP
  	clr R30,R30,PRU_TEST_1

采用"默认250MHz"设置时的 DDR 50字节读取时序

使用"333MHz 建议设置"的 DDR 50字节读取时序  

Anthony、您好！

我们将在下周左右对您的线程进行标记分组-我将 提供一些意见、我的一位团队成员将研究实际运行的测试。

一般读取延迟想法

首先、我之前针对读/写延迟完成的所有工作都可以在本常见问题解答中找到。 如果您尚未通读、请查看：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096933/faq-pru-how-do-i-calculate-read-and-write-latencies

在撰写该常见问题解答时、我没有考虑以下一点：当 ICLK/VCLK 频率(固定为250MHz)与 PRU 内核频率(在您的示例中为333MHz)不同时异步电桥的影响。 目前、我不确定 TI 的任何人是否对这种潜在影响进行了全面分析、因此我无法为您提供预测读取命令影响的准确公式。 我希望写入命令不受影响、并且仍然应如常见问题解答中所述的那样工作。

AM64x PRU 以太网固件开发人员提到、他们必须权衡较长读取时间的利弊、但以更高的频率运行固件。 至少对它们来说、每个 ICSSG 在6个内核上扩展的速度提高了33%(每个指令增加3ns、而不是每个指令增加4ns)、抵消了 访问外部存储器的延迟增加的影响。

其他想法- DDR 不适合低延迟访问  

DDR 是您可以访问的最慢存储器、因为信号必须从物理上离开处理器才能到达。 您的应用需要多大的存储器容量？您希望使用它实现什么功能？

如果您有足够的空间、则可以使用 PRU 子系统的本地内存获得最快的性能。 下一个最快的访问将是对片上 SRAM (在 AM62x 上相当有限、仅64KB 用于访问)。

此致、

Nick

你(们)好 感谢您的响应。 对于我们的用例、从 DDR 读取的速度比 PRU 指令的速度更快更重要。 读取的数据量是 PRU 数据 RAM 大小的10倍、因此我们需要继续使用 DDR。 如果不是这样的话、我们可以在333 MHz 上运行时减少读取时间、也许有一个解决方案能够在250 MHz 上运行。

Anthony、您好！

Unknown 说：

也许有一种解决方案可以缩短在333 MHz 下运行时的读取时间、如果不是这样、我们就可以在250 MHz 下运行了。

我将与团队讨论更多这方面的内容并回复给您。

此致、

Nitika

是否有解决办法？  我也会看到相同的问题。   通过使用 LBBO 访问使用32字节读取的各种存储器位置、我看到当 PRU 时钟增加到333MHz 时速度严重放缓。  

我能够验证 PRU 本地/共享 RAM 的 LBBO 是否保持在一致的11个时钟节拍。  非常相似。  然而、对 DDR 的访问从大约83个时钟周期(平均)下降到大约690个。  对片上 SRAM 的访问从24个周期下降到大约143个周期。   对 M4F SRAM 的访问(我们不使用 M4F、因此我正在考虑使用它的 RAM)从47个时钟周期下降到363个时钟周期。   随着时钟速度加快、我们期望读取的时钟节拍数略高、但不会太高。   

Daniel、您好！

如果可以、我可以请您为我测试您的设置并分享结果。

您是否也可以尝试以200MHz 时钟频率进行相同的存储器读取并记下这些值。

此致、

Nitika

在200MHz 下运行还会导致访问非常慢。  因此、我决定尝试在250MHz 下运行、但实际上将其配置为250MHz、而不是默认值。  使用：

pruss_coreclk_mux: coreclk-mux@3c {
reg = <0x3c>;
#clock-cells = <0>;
clocks = <&k3_clks 81 0>, /* pruss_core_clk */
<&k3_clks 81 14>; /* pruss_iclk */
assigned-clocks = <&pruss_coreclk_mux>;
assigned-clock-parents = <&k3_clks 81 14>;
assigned-clock-rates = <250000000>;
};

这也导致它的访问速度非常慢。   因此、任何配置时钟的尝试都会导致对外部 RAM /存储器的访问缓慢。  是否有任何说明介绍如何在输出影响外部 RAM 速度的情况下、获得配置为333MHz (或200MHz 或250MHz)的时钟？

Daniel、您好！

感谢您运行测试并分享您的观察结果。

我将提请我们的 Linux 专家注意这一点、以便获取更多评论。

此致、

Nitika

Daniel、您好！

此外、如果您的主要目标是提高  DDR 的读取速度、我也建议查看 xfr2vbus_rd 小工具(请参阅 TRM 第 7.4.5.3.1 PRUSS XFR2VBUS 硬件加速器)。

TRM 中提供了该 代码的编程指南、您也可以参阅此主题。

此致、

Nitika

我确实尝试了 xfr2vbus 以及,并得到了类似的减速相比 LBBO。  如果我能够在两个读取单元之间交替、xfr2vbus 会更好一点、但与默认值相比、如果 PRU 以333运行、速度仍然会明显变慢。

xfr2vbus 还具有其他复杂性。  一般而言、每次读取时需要48字节的数据、因此我需要读取64字节、并将一些数据转移到暂存区、等等。   然而,如果速度不是任何更好的333 (这不是),那么它仍然是不可用的。

从 DDR 读取的时序绝对没有变化。   它看起来正在分配时钟并且频率在变化、但从 DDR 读取数据的时间仍然比默认(pruss_iclk)时钟要长几乎一个数量级。

Daniel、您好！

设置 PRU 时钟频率

即使使用"已更新"的 devicetree 设置、我也预计在使用接口时钟以外的其他时钟时读取会花费更长的时间(确切时间待定)。 如果使用的不是默认的250MHz ICLK、这项工作的主要目的是确保代码可转发可移植。

请发布您正在测试的确切 devicetree 设置以及每个设置下观察到的结果。

我假设如上所述、当您设置 PRU 内核时钟= ICLK 时、DDR 读取不会花费额外的周期、对吧？

您可以通过使用 devmem2检查这些寄存器来验证您在硬件中的更改：

在 PRU 子系统内：  

ICSSG_CORE_SYNC_REG (偏移0x26000、寄存器0x3C)
位 CORE_VBUSP_SYNC_EN：0h = ICSSGn_CORE_CLK 是源、1h = ICSSGn_ICLK 是源

在控制 MMR 寄存器中：

CFG0_ICSSM0_CLKSEL (物理地址 0010 8040h)

位0 ICSSM0_CLKSEL_CORE_CLKSEL (选择 ICSSM0功能时钟源字段值(其他
为保留)：1'b0 - MAIN_PLL2_HSDIV0_CLKOUT 1'b1 - MAIN_PLL0_HSDIV9_CLKOUT)

好的、但我仍然看到较高的延迟。 我还能做什么？  

您是否使用 SRAM 实现任何用途？ SRAM 的访问延迟通常低于 DDR。 我还想了解访问 SRAM 时 ICLK 与其他时钟之间的延迟差异是否与访问 DDR 时不同。

此致、

Nick

对于250MHz、我将使用：

 pruss_coreclk_mux: coreclk-mux@3c {
    reg = <0x3c>;
    #clock-cells = <0>;
    clocks = <&k3_clks 81 0>,  /* pruss_core_clk */
             <&k3_clks 81 14>; /* pruss_iclk */
    assigned-clocks = <&pruss_coreclk_mux>;
    assigned-clock-parents = <&k3_clks 81 14>;
};

对于200MHz 和333MHz、我将使用：

pruss_coreclk_mux: coreclk-mux@3c {
    reg = <0x3c>;
    #clock-cells = <0>;
    clocks = <&k3_clks 81 0>,  /* pruss_core_clk */
            <&k3_clks 81 14>; /* pruss_iclk */
    assigned-clocks = <&k3_clks 81 0>, <&pruss_coreclk_mux>;
    assigned-clock-parents = <&k3_clks 81 2>, <&k3_clks 81 0>; /* DEV_ICSSM0_CORE_CLK_PARENT_POSTDIV4_16FF_MAIN_0_HSDIVOUT9_CLK */
    assigned-clock-rates = <200000000>, <0>; /* 200MHz */
};

(仅更新333MHz 的时钟速率)

这导致时序如下所示：

和我使用的代码：

    RESET_PRU_CLOCK r8, r9
    LDI32    r8,  0x70000000   //  OCSRAM
    LDI      r9,  1024
    LOOP TEST_OCSRAM_DONE, r9
        LBBO &r10, r8, 0, 32
        ADD r8, r8, 32
TEST_OCSRAM_DONE: 
    GET_PRU_CLOCK r8, r9, 4
    SBCO &r8, CONST_PRUDRAM, 16, 4

    RESET_PRU_CLOCK r8, r9
    LDI32    r8,  0x0005040000  // M4 DRAM
    LDI      r9,  1024
    LOOP TEST_M4_DONE, r9
        LBBO &r10, r8, 0, 32
        ADD r8, r8, 32
TEST_M4_DONE: 
    GET_PRU_CLOCK r8, r9, 4
    SBCO &r8, CONST_PRUDRAM, 24, 4


    RESET_PRU_CLOCK r8, r9
    LDI32    r8,  0x8f000000  // DDR DRAM (reserved)
    LDI      r9,  1024
    LOOP TEST_DDR_DONE, r9
        LBBO &r10, r8, 0, 32
        ADD r8, r8, 32
TEST_DDR_DONE: 
    GET_PRU_CLOCK r8, r9, 4
    SBCO &r8, CONST_PRUDRAM, 32, 4


    RESET_PRU_CLOCK r8, r9
    LDI32    r8,  0x00010000  // local shared ram
    LDI      r9,  1024
    LOOP TEST_SHARED_DONE, r9
        LBBO &r10, r8, 0, 32
        ADD r8, r8, 32
TEST_SHARED_DONE: 
    GET_PRU_CLOCK r8, r9, 4
    SBCO &r8, CONST_PRUDRAM, 40, 4

然后、我可以使用 devmem2从 PRU 的 RAM 中查询四个值。

Daniel、您好！

如上面 Nick 所提到的、请确定 频率可用于每个 PLL 时钟源：

PLL2 (父时钟 ID 1)：225和300MHz
PLL0 (父时钟 ID 2)：200,250和333 MHz

此致、

Nitika