RxBdAddress does not wrap around under some conditions :: Bugtracker

部分翻译

RxBdAddress does not wrap around under some conditions

Information:
Type :: BUG
Status :: OPENED
Assigned to ::

Description:
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.

Comments:

Lopez Lorenzo, Victor	Jul 16, 2008
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 :)

Lopez Lorenzo, Victor

Jul 16, 2008

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

Browse

Tools

RxBdAddress does not wrap around under some conditions