Jump to content

QI109

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by QI109

  1. 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. 

  2. 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):

    image.thumb.png.2a1502729bede642cc3dd657d608a492.png

    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. 

    image.thumb.png.3c88937c099df9a6fb4e0d2bc930dd5b.png

    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

  3. On the Genesys 2 FPGA board, we can program the FPGA using a microsd card by putting the bitstream onto the card, switching the jumper to SD, then pressing on the PROG button on the board. 

    However, if my FPGA design includes a Microblaze design, there does not seem to be a way to program the memory of the Microblaze CPU using the SD card. All I can do is again, add a bistream onto the card which only programs the FPGA fabric. The Microblaze itself is not programmed.

    If I want to also program the Microblaze CPU from the SD card, is there a way to do so?

  4. The Genesys Zu board comes with DDR4 RAM which I have tried to use integrate with DMA but without any luck. My end goal is to send binary data from the PL fabric into the DDR4 RAM independent of the APU. May someone provide me with a list of things that need to be changed for the AXI DMA IP Core and the Zynq UltraScale+ MPSoC in order to accomplish this?

    I especially need instructions on how to configure the SoC for DMA because there is clear documentation on the AXI DMA IP Core but not the SoC for DMA purposes. I have already set up the AXI DMA register space correctly, but I do not know the SoC's AXI ports well. They only show up on Vivado Re-customize IP as highly abstracted out ports.  I am guessing the main issue is not having the right high performance AXI interfaces enabled on the SoC.

    Edit 1: I came back to clarify that I am running bare metal C programs, if it matters.

×
×
  • Create New...