Interfacing with the PHY on Genesys2

[QI109]

There is a PHY (Realtek RTL8211E) on the Genesys 2 FPGA board that is between the Ethernet RJ45 copper pins and the FPGA i/o pins. I am trying to read a register from the PHY using the MDC/MDIO pins, but I could not get it working. 

This is a timing diagram from the Realtek RTL8211 documentation (Page 20):

I created a Vivado project and programmed it on the Genesys2. I also added two additional PMOD pins and probe them with a scope to confirm that this is indeed what was sent to the MDC and MDIO pins. 

As we can see, after the frame has been sent, the PHY does not respond, that pin is still in a high impedance state, so that the PHY could communicate back with the MDIO pin. See the attached source and constraint file for more details on how the FPGA is programmed along with how I have configured the Tri-State buffer for interfacing with the MDIO pin.

Any ideas on why the PHY is not responding to read requests?
 

 

 

genesys2.xdc serializer.v

[zygot]

This is a great example of why no one should throw together some code and try it out on hardware and see if it works. ( not just because you are making this too hard, but because you can actually damage your hardware in this case ).

My suggestion is that you get your MDI interface working in simulation. This means writing at least an RTL testbench, and possibly a behavioral one. It also means writing a Verilog source that simulates how you believe, from reading the datasheet, the MDI on the RTL8211 responds. Obviously, this entails getting the RTL8211 MDI code working before trying to do read and write operations with your interface. It wouldn't be unreasonable to combine the RTL8211 behavior in the testbench, but I'd advise against it. You might have some difficulty with HiZ logic levels in simulation, depending on how you go about coding your design modules, but it's an essential skill.

You may think that all of this simulation effort is a waste of time, but in reality the exercise will illuminate your understanding of what is going on and save you time. More important this is just the proper way to do programmable logic development in a professional manner. It's also the most effective way to develop your skill as an FPGA developer.

There are subtle details that even a decent ( but not quite correct or complete ) simulation effort can trip you up. For instance having the PHY in reset while trying to use it.

You've the start of an idea. You just gave up too soon because you want to bypass correct design processes. I could post working code. You could just find some on your own. None of those would be fair to you because it would encourage bad design behavior. This is a pretty good basic HDL project for someone with low to moderate Verilog skills wanting to advance.

Is there a reason why you need to use the PHY MDI interface?

Edited February 19, 2022 by zygot

[QI109]

18 hours ago, zygot said:

This is a great example of why no one should throw together some code and try it out on hardware and see if it works. ( not just because you are making this too hard, but because you can actually damage your hardware in this case ).

My suggestion is that you get your MDI interface working in simulation. This means writing at least an RTL testbench, and possibly a behavioral one. It also means writing a Verilog source that simulates how you believe, from reading the datasheet, the MDI on the RTL8211 responds. Obviously, this entails getting the RTL8211 MDI code working before trying to do read and write operations with your interface. It wouldn't be unreasonable to combine the RTL8211 behavior in the testbench, but I'd advise against it. You might have some difficulty with HiZ logic levels in simulation, depending on how you go about coding your design modules, but it's an essential skill.

You may think that all of this simulation effort is a waste of time, but in reality the exercise will illuminate your understanding of what is going on and save you time. More important this is just the proper way to do programmable logic development in a professional manner. It's also the most effective way to develop your skill as an FPGA developer.

There are subtle details that even a decent ( but not quite correct or complete ) simulation effort can trip you up. For instance having the PHY in reset while trying to use it.

You've the start of an idea. You just gave up too soon because you want to bypass correct design processes. I could post working code. You could just find some on your own. None of those would be fair to you because it would encourage bad design behavior. This is a pretty good basic HDL project for someone with low to moderate Verilog skills wanting to advance.

Is there a reason why you need to use the PHY MDI interface?

 

I did in fact use the test bench to ensure that both my tristate buffer and the main block that produces the communication pulses work as expected. I also tested the tristate buffers and the communication pulses individually without the PHY involved. I am well aware of the the importance of validation, it is just that I did not add it to the post as it should be presumed that that is already completed. I also ensure that I am following the voltage standards correctly which is the LVCMOS15, you can see that in the constraint files.

I'd like to use the PHY MDI interface to have some customization on the Ethernet interface on the Genesys2 and create some custom cores with higher level stacks like UDP, TCP/IP without using ready-made IP cores. 

[elodg]

It is hard to see in your photo, but it does not seem like you are sending 00001 for PHY address. Also, make sure the PHY is not held in reset. I trust you are outputting the MDIO input on a Pmod output, so that you see driven logic from both the PHY and FPGA.

[zygot]

Read your constraints file again; you've only set constraints for the MDI pins. ALWAYS check the post implementation pin report to ensure that pin location and IOSTANDARD constraints are correct before trying out a bitstream on hardware.

[edit] Always make sure that every signal in your toplevel source file has a valid pin location constraint. The tools will assign random pin locations to anything not explicitly defined. So, perhaps you will "get lucky" and an output will not be assigned to a pin already connected to an external device with an incompatible logic standard, or ground... and perhaps you won't so lucky... Always, always double check to make sure that your FPGA pins aren't assigned to the wrong pins before configuring your device.

"'I'd like to use the PHY MDI interface to have some customization on the Ethernet interface on the Genesys2 and create some custom cores with higher level stacks like UDP, TCP/IP without using ready-made IP cores. " This is a worthwhile project for someone with more advanced skills in Verilog development, something I don't see in your coding samples. There isn't much functionality, other than statistics and status conditions ( none related to packet structure ) in the PHY since it's really just a cable modem. You should be able to implement any packet type that you desire in your custom core sources for 1 GbE speeds without touching the PHY on the Genesis2. If you want to support slower speeds than you will need to use the MDI, but you could certainly develop your ideas without this.

Edited February 22, 2022 by zygot