Overview :: Links :: News :: Downloads :: Tracker

Ethernet MAC 10/100 Mbps: Tracker : RxBdAddress does not wrap around under some conditions Monitor this item You will be notified via email when status of this item is changed or if somebody adds a comment. Your email   RxBdAddress does not wrap around under some conditions Type BUG Status OPENED 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.   Stats Nobody is monitoring this item Progress   Submited date 19-May-2007 Submited by maxi@u...   Assigned date Assigned to   Closed date Closed by Comments by Victor Lopez Lorenzo on 16-Jul-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 :)   Add your comment Your email: Retype key: