OpenCores

* Ethernet MAC 10/100 Mbps

Issue List
RxBdAddress does not wrap around under some conditions #3
Open ocghost opened this issue over 17 years ago
ocghost commented over 17 years ago

I've been using opencores Ethernet module in my project and observed problems similar to what was reported here:

http://www.nabble.com/bugs-in-ethernet-MAC-tf1043922.html

Problems were more pronounced on a half-duplex link, with many collisions. I think I identified the problem with SignalTap on Altera, and fixed it. I was wondering how I can submit the fix.

Basically, the problem is that sometimes RxBdAddress does not wrap around but rather goes outside the range. That is caused by improper RxStatus/RxBdReady being latched in. Depending on sequence of events, what can happen is that RxStatus/RxBdReady will be read in on the cycle immediately before RxBdAddress gets incremented, and then the pointer will be read with respect to the next BD. So RxStatus/RxBdReady will be from a different BD then the pointer; furthermore they'll be incorrect for the current BD. If this happens on the transition to the last BD, RxStatus will be latched without wraparound bit, and RxBdAddress will be incremented rather than wrapped around.

The fix that works for me is this change in eth_wishbone.v:

1865c1865

< if(RxEn & RxEn_q & RxBDRead)

if(RxEn & RxEn_q & RxBDRead & ~RxStatusWrite)

Thanks

Maxim Adelman


E-mailed this to Igor.

galland commented over 16 years ago

I have to disagree with this solution as RxStatusWrite (line 1967) is always '0' but in ONE CYCLE, and after it becomes '0' again (because ShiftEnded is driven low when RxStatusWrite becomes '1', line 2266), but what renders the solution useless to my point of view is that RxBDRead is '0' anyways in the cycle when RxStatusWrite is '1'! because RxBDRead becomes '1' ONLY some cycles AFTER the RxStatusWrite has become '1', see the sequence: RxStatusWrite becomes '1' during one cycle as shown before (because of lines 2266-2270), after it StartRXBDRead becomes '1' in line 1837, and after it then RxBDRead becomes '1' in line 1846 and then and only then (at least 3 cycles after RxStatusWrite does RxBDRead become '1')

So the core should work exactly the same with or without this solution. Maybe your problem was somewhere else. I hope it helps and please don't take this comment bad, I meant it for constructive criticism :)

Joshua5526 commented about 5 years ago

I see that this post is 11 years old, but I am submitting this just in case it helps someone else trying to fix there problem.

I have observed a similar issue if not the same issue. What I discovered was that it was from RxAbort coming in causing RxStatus to reload and accidentally read the value from ram intended for RxBDAddress.

I submitted my own issue report for this at https://opencores.org/projects/ethmac/issues/13.


Assignee
No one
Labels
Bug