• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 104 subscribers
  • Views 17332 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Connecting two devices through RGMII interfaces directly

Arturs Elksnis
Intellectual 715 points
Other Parts Discussed in Thread: AM3359

Hi,
    I've got two identical boards both using AM3359 with identical Linux kernel compilations loaded. Each connects successfully to ethernet through a standard phy and magjack using RMII1 interface when tested separately. So far so good.

In the final design they're connected to each other via RGMII2 interfaces (TD[0:4] connected to RD[0:4], TCLK to RCLK and TCTL to RCTL) and only one of them is connected to a phy and a magjack and network.

I was kind of expecting them both be able to ping each other and connect to ethernet transparently utilizing the 3-port switch but unfortunately this sort of setup doesn't work. The board that is directly connected to the network can access the network and works fine but the other board which was supposed to connect to ethernet through the direct RGMII connection and 3-port switch has no connectivity.

Has anyone attempted this before? Do I need to tweak the kernel or some network driver? Is there anything special about connecting RGMII2 interfaces directly?

Thanks.

  • 0 in reply to -DK-
    Intellectual 715 points

    Thanks DK,

                The first link doesn't seem to work. It just says "Group not found". Have you got the actual post? I'd be interested to read because all I've heard about such arrangement before is that I'd need to skew the clocks a little so that data on the RD lines arrives before clock signal. I've added a small capacitor on the clock line to skew the signal but unfortunately that didn't do the trick.

                I understand that it's not supported (probably because of this clock issue) but in theory though it should work, shouldn't it?

  • 0 in reply to Arturs Elksnis
    TI__Mastermind 27890 points

    Sorry, I linked an internal-only post. It mirrored my own post, but here is the relevant section...

    "...you can not connect the RMII ports of these devices directly together.  RMII is not a symmetrical interface.  The RMII specification defines one end of the interface to be the MAC and the other end to be an Ethernet 10/100 PHY. RMII on [AM335x operates as] a MAC and expects the connected device to operate as an Ethernet PHY." 


    As for your timing question, some PHY's have configuration registers that allow for adjustment of the clock:data skew internally, but best practices dictate that a timing analysis be done on the interface prior to committing the design to PCB as the permitted skew values in the PHY may not be effective in closing timing. In other words, it's best to account for timing issues on the board itself rather than depend on the PHY to do so.

  • 0 in reply to -DK-
    Prodigy 20 points

    "you can not connect the RMII ports of these devices directly together.  RMII is not a symmetrical interface.  The RMII specification defines one end of the interface to be the MAC and the other end to be an Ethernet 10/100 PHY. RMII on [AM335x operates as] a MAC and expects the connected device to operate as an Ethernet PHY."

    The RMII interface looks, at an electrical level, to be pretty symetrical to me, especially if you use an external 50MHz reference clock. I have probably missed something. Please can you be more specific about why you can't connect a MAC to a MAC over RMII (with the exception of the management interface)?

    Thanks

  • 0 in reply to Rob Gask
    TI__Guru**** 393215 points
    Being "not symmetrical" refers to the protocol. The AM335X MAC does not support MAC-to-MAC protocol, it needs a PHY on the other end. Some Ethernet switches have the ability to configure their MAC in PHY mode. These can be connected to the AM335X.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 20 points

    Just to clarify by protocol do you mean the MDIO interface? Or is there a protocol running over the TX/RX lines between the MAC and PHY?

    Thanks

  • 0 in reply to Rob Gask
    TI__Guru**** 393215 points
    The exchange over the TX/RX lines.
  • 0 in reply to Biser Gatchev-XID
    Genius 3825 points

    Hi,

    I am sorry to ask the same question,
    our customer needs some clarification about this topic.

    As you say "AM335X MAC does not support MAC-to-MAC protocol"
    is this applied only for the AM335x or is this a general limitation?

    If there is any reference document of AM335x or any pointers
    it would be helpful for us to explain our customer.
    Could you please let us know if there is any details we could refer regarding
    connecting MAC-to-MAC without PHY.

    Best Regards,
    Prad

  • 0 in reply to Prad1
    TI__Mastermind 27890 points

    Hello,

    The RGMII specification specifically describes the interface as a MAC-PHY interconnect. This specification is available on the web and should help clear up any questions your customer may have. From an AM335x perspective, I would not consider the inability to directly connect MAC-to-MAC as a limitation as the device connection meets the relevant specification requirements.

  • 0 in reply to Prad1
    TI__Mastermind 26205 points

    Please avoid posting the same question is two different places...

    for those following, the other post is here: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/212517/995488.aspx#995488

  • 0 in reply to Biser Gatchev-XID
    Prodigy 205 points

    Could you be more specific about the issue ?

    I have been designing FPGA based interfaces which connect to PHy via RMMI.

    And  the data which comes out  on RMII TX_EN/TXD0/TXD1 is mirrored on CRS_DV/RXD0/RXD1 ( at least in my implementation). So I cannot imagine what could be the issue once I skip management interface ( and use external 50MHz reference clock)

    I my design I want to save cost taking away switch and would like to know to obstacle.

    We do have FPGA and could route RMII signals through, but I would need to know what should be done to make sch connection running.

  • 0 in reply to Rogerio Almeida
    Prodigy 40 points
    Good day to you all.

    I'v had some practice with verilog description of MAC controller.
    That one had a "LOOPBACK" feature and it was implemented just by interconnecting output and input lines inside MAC controller right before output pins.
    So I am pretty sure that it could be done outside of the die (I never saw a PCB with such possibility).
    Interconnecting two RGMII buses of different dies txd1->rxd2, txd2->rxd1.
    Thus all you need is GCLK 125MHz sourse (that could be found on am33.. maybe) and a delay line, to add 90 phase degree shift for that GCLK. Normally you can route clk line a bit longer than others: 6.5ps per mm(4mil).
    That is about 1inch to get 2ns delay :-)
  • 0 in reply to Vladimir Melnikov
    Prodigy 205 points

    Hi,

    Thanks for info. I believe it would work. I had to modify my design to accommodate additional requirements and I ended up with ordinary switch chip from micrel, so unfortunately I cannot confirm that my ideas were actually tested.

  • 0 in reply to Jaroslaw Karwik
    TI__Guru 62855 points
    There is 25.4mm/inch. Based on the delay quoted above (6.5ps/mm), you only get 165.1ps/inch. So you would need to add 12.11 inches of trace to get 2ns of delay.

    Regards,
    Paul
  • 0 in reply to peaves
    Prodigy 205 points

    Well, if it comes to that I have a lot of gates around - mostly from NC7SZxx familiy - I use them as separation buffers as most of my circuit starts earlier then Sitara and I need to be sure it will not sink into Sitara's ports

    E.g. https://www.fairchildsemi.com/datasheets/NC/NC7SZ04.pdf 

    Two of these, maybe some load between. Really cheap ( around 7 cents/pcs).  The only drawback is that it is not really precise ( 0.5 .. 4.5ns )