Packet reception stops after some time?

[Paul Bar]

Hi All,

I have been working with this core for some time now. I have only one problem with it. It seems there is a problem in the receiving of the packets.

1) After some time, all packets are rejected because of the Fifo_full is asserted in the MAC_rx_FF module.
2) Some packets are completely lost. I send them, but I am not receiving any Rx_mac_ra.

My guess is that those packets that I received get added into the Receive Fifo and when there are many of them, I get the fifo full error.


Does anyone know what could cause this problem?

Thanks

[M@work]

Hi Paul,

I am currently having the same problem as you described under 1). Did you find a solution?

For problem no. 2) , is it dependent on 1) or is it just one packet and the next packets are received correctly? Under which circumstances do you loose it? Does any Rx error counter increment? Have you monitored that the packet is sent correctly (i.e. using wireshark)?

Best regards.

[Paul Bar]

I have used wireshark.

I found the solution, but the problem seems to be metastability related, because when I used 62.5MHz as the user clock (125MHz/2), the problem went away.

If you find anything on this.. post it here. 

Paul

[M@work]

I use 62.5 MHz from the beginning but I will check if there is still a metastability issue. Thanks for the hint.

I fixed another bug which may explain your problem 2) that "some" packets get lost. Have a look here http://opencores.org/bug,view,1970 .

[Paul Bar]

Thanks. I will look at it. Are you sure that Rx_mac_rd does not get stuck to 0?

[M@work]

The problem 1) you described (which includes that Rx_mac_ra is stuck at 0 after some packets) still exists for me, also with this bugfix. This bugfix only solves the problem that rx_err was not aligned with rx_dv and so some packets got lost (as you described with problem 2) ).

When I go back the trace of the Rx_mac_ra signal, I also come to the wrong fifo full signal. This signal is calculated from the difference of write and read pointers. According to this bug entry http://opencores.org/bug,view,387 , this is not implemented 100% correctly so I will have a look at this next. It would be strange to have this metastability issue at these low frequencies but you never know... .

By the way, it seems there is no public active repository where to feed back bugfixes?

[Paul BBareil]

I remember having added 2 FF to align the rx_dv with the rx_err. So as you say my two problems might be unrelated.

I also saw the discussion on this bug entry, but did not go deeper into the gray code to find a possible mistake. The only thing I changed inside the Rx_fifo was the clock for 1 or 2 module for the clock domain crossing. I will post the details when I am back in front of my PC.

--
You received this message because you are subscribed to a topic in the Google Groups "opencores-tri-mode eth MAC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opencores-tri-mode-eth-mac/bp3o31qXzNQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opencores-tri-mode-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.