Jump to content
  • 0

Sendiing IPv4/UDP packets through RGMII interface


Zhargal
 Share

Question

Hello, everyone!

I want to send some data from ADC using UDP protocol using ethernet on Genesys 2 board, but I don't see anything on Wireshark. Even though, I tried to sent example packet from here:

https://www.fpga4fun.com/10BASE-T2.html

And even my checksum at the end is calculated properly. I tried 125 MHz at first, then shifted to 25 MHz and still don't know how to handle this. What should I do and how to find my mistake? Even LED on board is blinking and firewall is off in Windows.

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0
The Genesys2 board Ethernet PHY comes out of reset all ready to rock at 1 GbE mode. You'll need a 125 MHz reference clock. If you want to do 10BASE-T rates you'll need to change some of the the PHY registers through the serial management interface, and use a 25 MHz reference clock. If you want to support multiple data rates then you need a clock switch to work with 10/100/1000 Mbps data rates.

Windows is not the easiest OS to work with for connecting external devices to using Ethernet.
Link to comment
Share on other sites

  • 0
1 hour ago, zygot said:

The Genesys2 board Ethernet PHY comes out of reset all ready to rock at 1 GbE mode. You'll need a 125 MHz reference clock. If you want to do 10BASE-T rates you'll need to change some of the the PHY registers through the serial management interface, and use a 25 MHz reference clock. If you want to support multiple data rates then you need a clock switch to work with 10/100/1000 Mbps data rates.

Windows is not the easiest OS to work with for connecting external devices to using Ethernet.

Thank you very much for answer! Unfortunately even with 125 MHz and 2 ns data to clock skew, I don't see anything on Wireshark. The last thing I can do is to try values in register to be able using 25 MHz clock. Anyway, why 125 MHz doesn't work is still mistery for me.

ila2.png

Link to comment
Share on other sites

  • 0
If your FPGA application can't communicate with the Ethernet PHY then trying to see packets on an external device is a waste of time.

The Genesys2 Ethernet PHY uses RGMII. You'll need to convert DDR data to 8-bit GMII SDR data before any application in the FPGA can talk to the PHY. You'll need to provide good timing constraints to get RGMII working, especially at 1000 Mbps.

First thing to do is verify that your Ethernet PHY interface is working properly. The best way to do this is to change the PHY register that puts the PHY into loop-back mode. This will echo any data that your FPGA application is writing to the interface. An ILA capturing the GMII data might help.
Link to comment
Share on other sites

  • 0
On 11/21/2022 at 4:45 PM, zygot said:

If your FPGA application can't communicate with the Ethernet PHY then trying to see packets on an external device is a waste of time.

The Genesys2 Ethernet PHY uses RGMII. You'll need to convert DDR data to 8-bit GMII SDR data before any application in the FPGA can talk to the PHY. You'll need to provide good timing constraints to get RGMII working, especially at 1000 Mbps.

First thing to do is verify that your Ethernet PHY interface is working properly. The best way to do this is to change the PHY register that puts the PHY into loop-back mode. This will echo any data that your FPGA application is writing to the interface. An ILA capturing the GMII data might help.

Well, I changed values in register to Loop back mode and changed the speed to 100 Mbps. Still don't see anything. The intersting thing that I am capable to read correct PHYID1 and PHYID1 values and catch data from laptop but I still don't know why I can't see anything on laptop side.

ila_mdio.png

Link to comment
Share on other sites

  • 0
Well, for one, if the PHY is in loopback mode mode, nothing will be happening on the cable attached to the RJ45 connector.

While you are in loopback mode you can verify that the data being sent to the PHY is the same as being returned. If that's the case, then you are on a different level of things to check.

I don't know anything about the tutorial that you are following or that you implemented. What I do know is that Ethernet doesn't work unless you packetize your data and every packet starts with the correct preamble. You should see this in loopback mode using your ILA.

If everything checks out in loopback mode there still might be hurdles. PC and switches keep a list of active IP addresses for connected Ethernet devices. If they send an ARP packet periodically to discover who's on the other end of the Ethernet cable and get no response this could be a problem. Your FPGA application might have to provide ARP packets to advertise your IP address and reply to ARP requests. An Ethernet switch between your FPGA and your PC would simply not forward any traffic if you don't do this. Connecting your FPGA directly to your PC using Wireshark or other diagnostic software should work, as long as you properly calculate the CRC and populate the packet headers. Of course you need to set up your Ethernet port properly in any modern OS or you will have problems communicating or even seeing the FPGA packets.
Link to comment
Share on other sites

  • 0
On 11/24/2022 at 2:19 PM, zygot said:

Well, for one, if the PHY is in loopback mode mode, nothing will be happening on the cable attached to the RJ45 connector.

While you are in loopback mode you can verify that the data being sent to the PHY is the same as being returned. If that's the case, then you are on a different level of things to check.

I don't know anything about the tutorial that you are following or that you implemented. What I do know is that Ethernet doesn't work unless you packetize your data and every packet starts with the correct preamble. You should see this in loopback mode using your ILA.

If everything checks out in loopback mode there still might be hurdles. PC and switches keep a list of active IP addresses for connected Ethernet devices. If they send an ARP packet periodically to discover who's on the other end of the Ethernet cable and get no response this could be a problem. Your FPGA application might have to provide ARP packets to advertise your IP address and reply to ARP requests. An Ethernet switch between your FPGA and your PC would simply not forward any traffic if you don't do this. Connecting your FPGA directly to your PC using Wireshark or other diagnostic software should work, as long as you properly calculate the CRC and populate the packet headers. Of course you need to set up your Ethernet port properly in any modern OS or you will have problems communicating or even seeing the FPGA packets.

That is the point that I don't see anything coming back. Well I generate the same sequence from there:

https://www.fpga4fun.com/10BASE-T2.html

And I still don't see anything coming back in loop mode. Also I manually put ip address and mac address to ARP table. And checksum at the end calculates properly.

Link to comment
Share on other sites

  • 0
It's hard to tell what's going on from your ILA screenshot. The first problem is that you are capturing 4-bit DDR data on the RGMII interface. You need to be converting that to GMII 8-bit SDR data, as I mentioned before. So your Ethernet PHY data interface isn't working. Don't even try doing anything until you are capturing 8-bit data out and 8-bit data in that matches what's going to the PHY.

There were some older FPGA boards with GMII Ethernet PHY interfaces, like the ATLYS and original Genesys. These are better platforms for getting started. RGMII and SGMII are good projects if you've already mastered the GMII SDR data interface.

I did look at your project. The 8-bit data sequence makes for an easy way to get started. But that's your problem. You need to do conversions between 8-bit SDR and 4-bit DDR. Unfortunately, this is a pretty old tutorial. I didn't bother to see if it had any advice on how to create a PHY interface; but this is the first step. You're trying to start swimming before leaping into the pool.

So, stop what you are doing and start doing some research. If you can find older tool versions for Quartus or ISE that we of the AT:LYS and Genesys era you can find some guidance about how to do GMII-RGMII data conversion.
Link to comment
Share on other sites

  • 0
19 minutes ago, zygot said:

It's hard to tell what's going on from your ILA screenshot. The first problem is that you are capturing 4-bit DDR data on the RGMII interface. You need to be converting that to GMII 8-bit SDR data, as I mentioned before. So your Ethernet PHY data interface isn't working. Don't even try doing anything until you are capturing 8-bit data out and 8-bit data in that matches what's going to the PHY.

There were some older FPGA boards with GMII Ethernet PHY interfaces, like the ATLYS and original Genesys. These are better platforms for getting started. RGMII and SGMII are good projects if you've already mastered the GMII SDR data interface.

I did look at your project. The 8-bit data sequence makes for an easy way to get started. But that's your problem. You need to do conversions between 8-bit SDR and 4-bit DDR. Unfortunately, this is a pretty old tutorial. I didn't bother to see if it had any advice on how to create a PHY interface; but this is the first step. You're trying to start swimming before leaping into the pool.

So, stop what you are doing and start doing some research. If you can find older tool versions for Quartus or ISE that we of the AT:LYS and Genesys era you can find some guidance about how to do GMII-RGMII data conversion.

Thank you that you are trying to help. But I don't have time and opportunity for buying another board and don't see any sense for making conversion from GMII-RGMII, since I already see how signal is look like in testbench and ILA.

Link to comment
Share on other sites

  • 0

Hi @Zhargal

Getting RGMII to work is a bit of a rite of passage --  any of a dozen small mistakes can mean you don't see anything.

Here's a quick checklist. I didn't read your entire exchange so far in detail, so some of these may have been covered already:

* Make sure your PHY chip is in a mode that allows autoconfiguration of a connection at 1 gigabit. To verify this, the practical thing to do is hook up 1-to-1 to a computer with an Ethernet port (without a switch in between) and some tool to inspect the status of the ethernet transceiver; I recommend linux and "ethtool". Using your tool, make sure both sides see each other and establish a gigabit link. If yes, then at least the PHYs on both sides like each other. If not, you will first need to do some MDIO programming.
* make sure you properly lead both your 125 MHz clock and data bits through the appropriate DDR transmitters.
* make sure you have the appropriate timing offset between the CLK and DATA bits. RGMII is very picky about this and specifies a mandatory offset between CLK and DATA bits. I personally have had success by generating two 125 MHz phase-shifted clocks, using 1 for the four DATA signals and ENABLE, and the other for the CLK signal. This step may take some trial and error.
* Make sure ENABLE is set from the first preable octet all the way to the last FCS octet.
* Make sure you have the bit order right, both in terms of time and in terms of endianness, as you push octets into the DATA DDR blocks. It's easy to make a mistake! My approach in cases like these is to simply try all possible combinations until you find the one that works, and then retroactively convince myself that it was the correct choice ... :)
* Make sure you send a valid packet. I hope the fpga4fun packet generator is correct there, including the FCS. Also, make sure you honor standard Ethernet payload lengths (min 46, max 1500 Ethernet payload octets, if memory serves).
* I would recommend for your first experiments to use both Ethernet and IPv4 broadcast addresses, as this increases the probability that you will at least see something.
* When sending out packets, honor the mandatory inter-frame gap (12 cycles at 125 MHz between successive packets, at least).

 

 

Link to comment
Share on other sites

  • 0
I'm not trying to sell you anything; just pointing out that starting with a complicated hardware interface is more difficult and requires more preparation.

Thinking that you understand what your design is doing by looking at the ILA is part of your problem. I don't think that you understand the terms that I've been using, like RGMII, GMII, DDR and SDR. Start there. Logic is almost never DDR, it's too hard to conceptualize and meet timing. The ILA doesn't support DDR clocking.

Since you need to start off with RGMII things would be simpler just doing 1 GbE as that's what the Genesys2 PHY wants to do out of reset; it does all of the thinngs necessary for 1 GbE without any register setup changes.

Your statement that you don't see a need for RGMII-GMII conversion make me think you aren't ready to tackle this project yet.

Look over this: https://forum.digilent.com/topic/16802-ethernet-phy-test-tool/

It has source for the Nexys Video Ethernet PHY that is also RGMII. This might help, but I'm thinking that you need to do more preparation work before you're ready for that as well.

[edit] I've been using Ethernet PHYs on FPGA boards for as long as 1 GbE PHYs have been on such platforms. Whenever I do a new design for a new platform or device I use my ATLYS or GENESYS as a tester to verify that the PHY interfaces are working. It doesn't always go as smoothly as I anticipate. That's the story behind the project link that I just posted. I can run many hundred of GB through 2 Ethernet PHY devices connected by a cable in a coupe of hours at very near 125 MiB/s. It's the only test that I'm comfortable with before going on to use a new design.
Edited by zygot
Link to comment
Share on other sites

  • 0
It's been quite a while since I posted the Ethernet PHY test tool project. There's been no response so I've kind of forgotten about it. I downloaded it to refresh my memory and discovered a silly error with the receiver ILA. But this brings up a subject that I didn't mention before. The Ethernet PHY has 2 clock domains. One is the transmit reference clock and the other is the receiver clock. If you want to capture data and control states you need 2 different ILA instances, one for transmit and one for receive. In ETH_DUT I have a receive side ILA but use the wrong clock... it should be rxclk, not clk125 as shown. The fact that they are the "same" frequency doesn't change the fact that rxclk and clk125 represent two different clock domains.

The project code posted for the Nexys Video DUT was modified from what I actually used to test the board because I didn't want to publish my UART source at the time. In fact all references to the UART should have been removed, as all they do is confuse the reader. The printout of an actual test session output is real.

For a number of reasons a 1 GbE RGMII Ethernet PHY involves concepts that are complicated enough that put it beyond beginner HDL skill levels. DDR and clock domains are two of those concepts. Edited by zygot
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...