Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎11-01-2017

PC communication with KC705 using ethernet GMII Marvell m88e1111 without IP : Packet Loss



Sorry in advance for the details, I tried to make it as synthetic as possible. Thanks in advance for your time.



  • Established a reliable 1Gbits connection PC <=> KC705 FPGA with a fully handcraften VHDL code inside.
  • This connection is made of Ethernet GMII (using Marvel m88e1111 PHY on the KC705 + some MAC code on the FPGA), IPv4 (on FPGA, minimum implementation) and UDP (on FPGA).


Use case:


Sequence in "Test mode 1":

  • 1) A python script sends the UDP frame (for exemple: "abcdef")
  • 2) The FPGA send a UDP reply (for example: "cdefgh", simple +2 on ascii data)
  • 3) A python catch this reply on PC and check it against a reference (to verify the reply is correct).

In "test mode 1", PC waits each reply (or until a timeout occurs if no reply) before sending the next UDP frame.


Sequence in "Test mode 2":

  • Same principle as in "test mode 1" but this time, PC doesn't wait the FPGA's reply before sending the next UDP frame to the FPGA. (more intense exchanges).



  • In "test mode 1" with 1400 bytes frames, the connection is reliable (no packet loss over 10 million of exchanged frames)
  • In "test mode 1" with 140 bytes frames, the connection is reliable (no packet loss...)
  • In "test mode 1" with 14 bytes frames, the connection is reliable (no packet loss...)



In "test mode 2" a massive loss (between 1% and 60%) of packet occurs. This problem is more obvious for small frames (ex: 14 bytes) for wich the loss is between 30% and 60%. For big frame (1400 bytes) the ratio of packet loss is around 1%.


Note: The python scripts mesures the number of frame sent/received. And I also monitore network trafic using windows Task Manager (where, in this case, I see big differences between rates PC->KC705 and KC705->PC).


This is where I need some help :)


More info:

  • link status of m88e1111 stays correct.
  • the registers of m88e1111 aren't modified (default configuration). There are periodically read every second (for monitoring).
  • Rates mesured using Chipscope/Vivado ILA on the FPGA at gmii tx/rx level (just at the interface with the m88e1111) suggest that rate rx = rate tx => Thus the FPGA does not slow down stream.


  • I'm not sure about the timing constrains at the GMII interface with m88e1111; but has for single frame it seems good I haven't investigated more in it.
    • On the RX side (Marvel-> FPGA) I used a Xilinx FIFO dual clock (125mhz) for resynchronization.
    • On the TX side (FPGA->Marvel) I used a ODDR ('0','1') to shift gmii_tx_clock compared to the gmii_tx_en/data/er (with set_property SLEW FAST).
    • That's all (no input/output delay, no multicycle, nor false path or else). If you have advices for this specific point I ll be happy to ear from you :)


  • IPv4/UDP frames and checksums seems correct too.


  1. Does the KC705 is able to provide a reliable Ethernet Gigabit connection full duplex (as the m88e1111 seems to support, according to the datasheet) ?
  2. What are the timing constrains to set for gmii tx (clock/enable/data/er) and gmii rx (clcok/valid/data/er) in Gigabit only mode (100Mbits and 10Mbits are not used) ?
  3. Does the PC ethernet card shall have specific parameters to work with the KC705? (Realtek PCI GBE Familly Controller)
  4. Does some m88e1111 need to be tuned against default configuration?


Thanks much for help

0 Kudos
3 Replies
Registered: ‎02-01-2013

Still working on this?


With "some MAC code", are you saying that your MAC code is home-spun--or are you using a Xilinx IP?  The MAC IP should have come with constraints for the IO, based on your platform.


Are there any stats being acquired by the FPGA MAC? 


-Joe G.




0 Kudos
Registered: ‎02-02-2021

I am also working on such a project recently, UDP communication If it is convenient, can you refer to your program? Mail Thank you very much

0 Kudos
Registered: ‎08-25-2009

Hi @xushuqin 

Our Community Help has a tip that might help you : Tip: If the message is older than 6-12 months, please post a new message rather than adding to the existing thread. Your inquiry will have a better chance of being picked up by an expert if it is a new topic.

I would suggest you create a new topic on the appropriate board.

Thank you!


Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

0 Kudos