This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] DP83826I:DP83826I:偶尔接收截断的封装、PHY 中未指示错误

Guru**** 1791630 points
Other Parts Discussed in Thread: DP83826I, USB-2-MDIO
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1421756/dp83826i-dp83826i-sporadically-receiving-truncated-packages-no-error-indicated-in-phy

器件型号:DP83826I
主题中讨论的其他器件: USB-2-MDIO

工具与软件:

您好!

我们在 Spartan-7 FPGA 中使用具有软 MAC 的 DP83826I、并遇到零星的数据包接收错误。 MAC 有时仅接收551字节数据包的第一部分。 完整接收前一个和后续的数据包。 我们只会在接收方向上看到错误 并且仅当我们同时传输流量时 (每3ms 192字节数据包)。 如果我们停止传输、则所有数据包都将被完整接收。

RX 流量来自通过板对板连接的独立电路板上的嵌入式交换机。
我们认为这种流量是好的(请参阅下面的详细信息)、但是当 PHY 将截断的数据包转发到 MAC 时(这显然会产生 CRC 错误)、PHY 不会报告任何错误、低链路质量或类似情况。

我们忽略了没有正确的解释来解释 PHY 中的此行为吗?


更多详细信息:
PHY 是 MII 主模式、我们使用固定链路100Mbit 全双工模式。
在 MDI 侧、有一个板对板连接、连接到带有嵌入式漫威开关的主板(mv88e6290)。
                                                           
┌────────────────μ A ┐                  ┌────────────────────μ A ┐μ A
│CPU <->开关│<- Board2Board ->│PHY <->具有 MAC 的 FPGA│
└────────────────μ A ┘Ω    连接器    └────────────────────Ω ┘μ A

我们的理解是、RX_DV 信号显示了25MHz MII 接口上数据有效时的周期、从检查该信号置为有效时的长度可以看出 PHY 向 MAC 发送的数据包过短。 发生错误时发送的字节数不是恒定的(我们已经看到从120个字节到500个字节的任何内容)。

我们一直在检查 PHY 状态寄存器、没有发现 PHY 报告错误的迹象:
   -良好的链路质量,即使发生错误: MSE_Val (reg 0218h ):小于0030h (48)。
   -无接收错误(RX_ER 线路从未被置为有效、RECR = 0、PHYSTS 中的 ReceiveErrorLatch 为0)
   -链路质量、状态等无变化(MISR1=0)
   -无远程故障,解码器锁激活,检测到信号,没有错误载波发生(PHYSTS=0605)

事实上、该错误仅在同时传输时发生、我们认为可能存在噪声/串扰问题、但随后我们会预期收到一些完整的数据包、其中会出现位错误(在 MAC 中报告为 CRC 错误)。 我们还没有看到、只有短数据包位于 RX 方向。

另外、如果在 PHY 的 MDI 侧接收符号时出现错误、我们预计会看到链路错误或接收错误。 这两种情况都看不到。

由于我们无法轻松地直接分析 Board2Board 连接上的信号、因此我们使用一个小的调试接口板来代替 FPGA 板进行连接、使我们可以在 PC 上的软件中运行数据、从而模拟 FPGA 功能:
                                                                             
 ┌────────────────μ A ┐                  ┌─────────────────μ A ┐            ┌────────────────μ A ┐μ A
 │CPU <->开关│<- Board2Board ->│接口板│<- Cat5e ->│PC w/FPGA sim│Ω
 └────────────────μ A ┘Ω    连接器    │Ω、    带 RJ-45    │            └──────────────── ┘μ A
                                     └─────────────────μ A ┘μ A                     
使用此设置时我们没有看到任何错误(FPGA sim 还会仿真 TX 流量)、因此我们认为 CPU 板上的嵌入式开关发送的数据是可以的。


侧边注释:
奇怪的是、当没有以太网流量流经 PHY 时、RX FIFO 溢出(RCSR = 0x41)被置为有效。 当我们启用流量(无论方向是 RX 还是 TX)时、溢出状态会在短时间后取消置位。 溢出断言似乎与我们看到的接收错误没有链接、但我们不确定该断言的作用、因为我们的 PHY 是 MII 主器件。
在主模式下、什么会使 PHY 使 RX FIFO 溢出生效?


此致、
Mikael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    请允许我一直到星期三 在这里查看和分享反馈。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    很抱歉耽误你的时间。 我仍在尽快与团队审查此问题以获取反馈。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    感谢更新,我很高兴听到你还在看这个:-)

    我可以补充一点、我们一直在测量 Board2Board 连接器上的信号、它们看起来很好、因此看起来不像是一般的信号完整性问题。

    感谢您对此提供的帮助、

    Mikael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    此问题似乎与 PHY 端的行为无关、但我们需要检查一些测试来确认:

    1) 1)如果可能、增加数据 IPG。 0x456[3]="1"会将 PHY 设置为预期200ns IPG。 您在发送和接收时是否看到类似的错误率?

    2)使用 PHY 的 PRBS 发生器模拟到 FPGA (而不是 CPU)的流量。 这可以通过0x16[13:12]='11"来启用。 在 PHY 生成 PRBS 流量时、您是否看到类似的错误?

    在本例中、RX FIFO 溢出的原因尚不清楚、但我同意它似乎与该问题无关。

    在此中断标志时、您可以确认 FPGA 没有向 PHY 传输任何数据吗? PHY/FPGA 时钟或 MII 线路上处于空闲状态的数据之间可能存在 PPM 偏移。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    1) 1)我们之前考虑过 IPG、但没有进一步追求它、因为来自 CPU 的数据包之间存在50ms 的时间、而 TX 方向(到 CPU)的数据包之间存在3ms 的时间、因此数据包之间存在很大的间隙。 因此,我们不认为 IPG 有任何问题,但请告知我们是否得出错误结论,我将研究如何调整漫威开关上的 IPG。

    2) 2)我曾尝试关闭来自 CPU 的所有流量和 FPGA 生成的流量、因此仅启用了 PRBS -通过将0x16设置为值0x3100、现在 FPGA 不会注册任何接收到的流量、而且我也没有在 RX_DV 线上看到任何活动、这是我预期的。 启用 PRBS 后读取 BISCR 时、我得到的是0x3300、因此数据包生成器状态=已启用、因此它确实正在运行。 当阅读数据表时、我不能完全清楚 PRBS 发送生成的流量的方向、例如、如果我需要在某个位置启用环回以使流量进入 FPGA/MAC。 显然、我缺少需要配置的其他内容。

    关于 FIFO 溢出、我可以确认、当溢出发生时、FPGA 不会向 PHY 发送任何流量。 如果我开始流量(在任一方向)、溢出标志会在很短的时间后取消置位。 只要在任何方向上有流量、溢出标志就会取消置位。

    PHY 和 FPGA 都连接到同一主时钟(仅涉及时钟分频器)、因此我们不希望出现任何"PPM 偏移"。

    谢谢!
    Mikael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    感谢您确认这些测试-我同意这里不会出现 IPG 问题。 如果 FPGA 需要标准以太网帧、则 PRBS 可能不是可行的测试。

    相反、我们可以尝试在 FPGA 传输到 PHY 且启用 PHY 环回的情况下进行测试。

    请从 FPGA 发送数据、并通过 PHY 的 MAC 侧环回:

    0x0[14]='1'

    0x16[2]="1"

    我的目的是通过将 CPU 作为变量删除来进一步查明该问题。 由于在同步 TX/RX 期间 PHY 端没有错误、因此我的假设是 FPGA 的引擎在发送期间处理 MAC 数据会存在问题。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    当启用 MII +数字环回(00h=6100、16h=0004)时、FPGA 每3ms 发送1200字节封装
    我们仍然会看到 MAC 错误、因此我认为我们可以排除 CPU 方面的错误。
    (注意:这与我先前错误地报告的同一个 TX 有效载荷仅为192字节。)

    查看 RX_DV 时、我看到 FPGA 已发送数据包的环回版本(RX_DV 被置为有效时间~99.36us)。 每3ms 一次)、但有趣的是、在来自 FPGA 的数据包之间的时间内、我看到 RX_DV 以5.76us 重复置位、相当于64字节的数据包。 我想这是环回机制的干扰、因为在禁用环回时、我在真实流量中看不到这种情况。 在正常情况下、RX_DV 仅对接收的流量置为有效。

    当 FPGA 报告 MAC_ERR 时、RX_DV 的置位时间也比环回模式下的预期短、但使用数据流中的64字节"填充"数据包时、我现在可以看到 RX_DV 保持置为无效的时间约为70us。 在截断的数据包之后、"填充"数据包再次出现之前。 这就像 PHY 在数据包中间停止发送、并在数据再次开始流动之前恢复了一段时间。 请参阅屏幕截图:

    启用环回后、MAC 错误通常在64字节"填充"数据包中置为有效、但我认为这只是因为这些数据包与来自 FPGA 的"实际"数据包相比比率较高。 这一情况得到了回送模式下错误率上升的支持(我看到实际流量下错误之间多达10秒、启用回送时仅为~2秒)。

    我当前的观点是、我们已经排除了 CPU 侧、因为我们在环回模式下仍然会收到错误。
    我们在任何时候都没有在 CPU 上看到任何接收错误、因此我还认为 MAC 传输是可以的。
    由于 RX_DV 取消置位的速度对于所发送的数据包大小来说太快、因此我也认为我们可以排除 FPGA MAC 接收。 phy 只是在 MII 接口上输出太少的字节。
    根据我们的观察结果、PHY 正在停止中间数据包、然后在短时间后自动恢复。

    你对这些观察结果有什么看法?

    谢谢!
    Mikael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    感谢您分享详细的观察结果。

    由于 PHY 中没有 RX 错误、信号质量问题或故障中断、此问题与 FPGA 在同时 TX/RX 期间处理数据的方式无关。

    我们可以执行几项额外检查来确认这一点:

    1)硬件检查-请分享原理图、以便我可以查看 MAC 连接(可以通过电子邮件发送至 e-mayhew@ti.com 以进行私人共享)

    2) 2) MAC 时序要求检查-如果可能、请探测同时 TX/RX 期间的 MAC 侧时钟/数据与仅 RX 情况、并确认所看到的设置/保持时间存在任何差异:

    如果这两项检查都通过、则很可能是 FPGA 出现问题。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    AD 1)我已通过电子邮件向您发送了原理图。
    AD 2)我们检查了 RX_CLK/RX_D[0]和 TX_CLK/TX_D[0]上的 MII 时序、所有这些都处于由 FPGA 生成的 TX 流量和启用数字环回的限制范围内。 它们看起来相同。
    为了进一步说明 TX 流量导致 RX 方向错误的原因、我们还研究了在(RX) MAC_ERR 置位前的时间内的 TX 时序。 它们也符合规格。 和预期的一样、因此我们认为 MAC 不符合时序要求。 此外、如前所述、对于从 FPGA 接收的 TX 流量、我们从未在 CPU 端报告任何错误。
    我们在私人电子邮件中添加了一些信号图表、以防您注意到我们遗漏了一些信息。  

    3) 3)只是为了澄清:当 PHY 设置为 MII 接口上的主器件时、我假设 PHY 正在驱动 RX_DV 引脚(当它应该对 RX_D 线上的数据进行采样时、作为信号给 MAC)。 因此、如果 RX_DV 被置为有效的时间太短、这怎么会成为 MAC 问题?

    谢谢!
    Mikael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    感谢您分享原理图。

    连接看起来正常。 我还希望确认 PHY 配置、在发生故障的情况下是否可以共享寄存器转储?

    是否可以使用背对背 FPGA 进行测试、一次仅从一个 FPGA 传输? 在本例中、您是否看到相同的误差、异常的 RX_DV?

    另外据我了解、从 FPGA 端接收错误是什么样的?

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    我使用 USB-2-MDIO 脚本转储发生错误前后的所有寄存器(随附)。 启用了 RX+TX 流量(无环回)、并在错误发生几次后启动了脚本。 由于读取需要很长时间才能完成、因此在脚本运行时状态可能会发生变化、正如在此期间观察到更多错误一样。

    遗憾的是、在 RX 错误条件下、我无法停止来自 FPGA 的 TX 流量、因此无法强制在 MAC 错误之后向任何方向发送数据。 当发生 RX 错误时、我可以做的最好的事情就是停止从 CPU 发送 RX 数据包。 这种情况下的寄存器转储看起来与上面的"after error"转储相同、但一旦我神秘地看到 PHYSTS[14](MDI/MDIX 模式状态位)状态更改为0、但 MISR2中的 MDI 交叉更改中断寄存器未生效。 我已经多次运行此场景、但无法重现 MDI/MDIX 模式状态更改、因此我不知道对此有多关注。


    关于背对背连接两个 FPGA 板、遗憾的是、我们无法做到这一点。 首先、我们需要 CPU 通过串行方式发送 FPGA 映像、然后对其进行配置、这是通过网络完成的。 其次、我们只有 CPU 板上的变压器、而不是 FPGA 板上的变压器。


    我对来自 FPGA 的错误信号的说明是"Ethernet MAC Rx Validate & Last & User"。 我假设这对应于信号 rx_axis_mac_tvalid、rx_axis_mac_tLast 和 rx_axis_mac_tuser、就像我们在这里使用的 AMD TEMAC 所描述的: docs.amd.com/.../Normal-Frame-Receptiondocs.amd.com/.../Frame-Reception-with-Errors。
    最后一个链路包含一个很长的 tuser 信号错误条件列表、其中包括 FCS 错误和小于64字节的数据包、我认为这两个错误和数据包基于 RX_DV 信号置位的测量长度。

    我知道我一直在回到 RX_DV 置位时间、但我仍然缺乏有关这方面的良好说明、特别是 TX 方向的流量为什么会影响 RX 侧。 如果只有在启用了 MII 环回时才发生这种情况、我会同意短帧可能是 MAC 无法发送完整数据包的结果、但由于我们在没有环回的情况下也会看到相同的结果、因此我不认为这就是问题。
    我真的希望你能提供一些这方面的资料、以帮助我们了解这种情况是如何发生的?

    谢谢!
    Mikael

    e2e.ti.com/.../DP83826_5F00_RegisterDump_5F00_output_5F00_3_5F00_after_5F00_fpga_5F00_config.txt

    e2e.ti.com/.../DP83826_5F00_RegisterDump_5F00_output_5F00_4_5F00_after_5F00_mac_5F00_error.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Mikael、

    再次感谢您分享详细的日志。

    我和您一样对 RX_DV 异常感到困惑、我们可以通过几个测试来了解发生这种情况的确切条件:

    1) 写入0x19[15]='0'以禁用自动 MDIX (寻址发生的奇怪 MDI 交叉中断)

    2)如果可能、从 FPGA -> CPU 单向传输、并通过 Wireshark 或在示波器上监听接收的数据包  

    除了 MDI 交叉位之外、我在寄存器日志中看不到任何异常来帮助排查问题。 我将与团队分享、尝试在这里找到其他线索。

    谢谢!

    Evan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Evan:

    好消息,我们终于找到了根本原因:双工不匹配。
    尽管我们将 PHY 绑定到运行100baset/全双工而不具有自动协商功能、但 CPU 端仍然配置为启用自动协商。
    我们错过的是、这导致 CPU 端报告其链路伙伴仅支持100BaseT /半双工、因此运行了半双工。 我们实际上得到了双工不匹配。

    为了进行测试、我们现在可以在 PHY 上启用自动协商或禁用自动协商。 并在 CPU 端强制100baseT/full。 任何一种配置都会使错误消失。

    根据我的理解、双工不匹配模式下发生的情况是、当 CPU 侧(运行半双工)在接收数据包的同时尝试向 FPGA 发送数据包时、偶尔会检测到冲突。
    然后、CPU 侧将发送干扰信号并停止其当前的传输(因此"截断"出的数据包、我们将其视为置为短路的 RX_DV 信号)。 PHY 端忽略卡纸信号、因为全双工配置禁用冲突检测、所以不报告任何错误。

    唯一让我有点意外的是、我预计 CPU 端也会丢弃从 FPGA 接收到的 UDP 数据包、这触发了冲突、但我在 FPGA->CPU 方向没有看到任何缺失的数据包。

    无论如何、问题已经解决、现在可以理解启用/禁用 FPGA 中的 TX 数据如何影响 RX 侧。

    感谢您的所有帮助、
    Mikael