Mohor, Igor

knguyen

Kindgren, Olof

Markovic, Tadej

Unneback, Michael

Ethernet MAC 10/100 Mbps

Hello.  I have discovered 2 issues and have working solutions.
Sorry if this is a double post opencores.org locked up last time I hit submit.

======================================
The first issue is in the wishbone module.

The variable RxStatus gets assigned the value from bd_ram which was supposed to be loaded into RxPointerMSB.  This messes up WrapRxStatusBit causing the RxBDAddress to increment instead of reset.

The way RxStatus reads the RxPointerMSB's value is a badly timed RxAbort from a packet which is coming in before the core is ready for it.  If it activates right when the pointer is getting or about to be read from the ram, RxBDRead activates again and because RxEn is already active for the pointer read, it doesn't take two cycles and it snags the wrong value.

The correction for this first problem is to block StartRxBdRead if RxPointerRead is active.
So change 
assign StartRxBDRead = RxStatusWrite | RxAbortSync3 & ~RxAbortSync4 | r_RxEn & ~r_RxEn_q;
to
assign StartRxBDRead = RxStatusWrite | (RxAbortSync3 & ~RxAbortSync4 & ~RxPointerRead) | r_RxEn & ~r_RxEn_q;

The possible side effect of this change is that the core may pass on a packet which has the wrong mac address, but as seeing that mac's are sometimes configured to be promiscuous and the higher level ip layer should filter out these packets anyways, this does not seem to be a problem.

=====================================
The second issue is in the txstatem and by implication probably the rxstatem.

The state machine is encoded as a one hot encoding with different 1 bit registers being active for different states by passing the bit around depending on what state is active and conditions.  The problem is that sometimes the bit gets lost.  There is currently no logic for dealing with this condition and when it happens the TX core halts.

This issue has been most frequently observed on system boot.  The StateDefer comes up first and tries to pass the bit to StateIPG but I have seen one out of 250 boots for StateDefer to drop and StateIPG to not pick it up.  Perhaps this has to do with the asynchronous nature between when the global reset releases and the external PHY clock.

To correct this problem I defined a new signal which detects when no state is active.
wire NoActiveState;
assign NoActiveState = ~StateIdle & ~StateIPG & ~StatePreamble & ~StateData[0] & ~StateData[1] & ~StatePAD  & ~StateFCS & ~StateJam      & ~StateBackOff & ~StateDefer;
and then include that is a start condition for the reset state StateDefer

assign StartDefer = StateIPG & ~Rule1 & CarrierSense & NibCnt[6:0] <= IPGR1 & NibCnt[6:0] != IPGR2
                  | StateIdle & CarrierSense 
                  | StateJam & NibCntEq7 & (NoBckof | RandomEq0 | ~ColWindow | RetryMax)
                  | StateBackOff & (TxUnderRun | RandomEqByteCnt)
                  | StartTxDone | TooBig | NoActiveState;
									
I have scoped this running with automated reboots and have seen the NoActiveState kick in multiple times and this prevented the problem where our device would randomly come up deaf.  The reboots would happen about every 5 seconds and the signal activated about 24 times overnight.

The corresponding addition to the rxstatem are:
create the line:
wire NoActiveState;
assign NoActiveState = ~StateIdle & ~StateDrop & ~StatePreamble & ~StateSFD & ~StateData0 & ~StateData1;

and append the signal to StartDrop:
assign StartDrop = (MRxDV & (StateIdle & Transmitting | StateSFD & ~IFGCounterEq24 &
                   MRxDEqD |  StateData0 &  ByteCntMaxFrame)) | NoActiveState;

Mac Latchup; 2 issues, solutions found.

Test was run on 
Modelsim Intel (Altera) FPGA Starter Edition 10.5b

Test run to 

MAC FULL DUPLEX TRANSMIT TEST

...

#   Time: 116878335
#   TEST 16: TRANSMIT PACKETS ACROSS MAXFL WITH HUGEN AT 19 TX BDs ( 10Mbps )
# ** Error (suppressible): (vsim-3601) Iteration limit 5000 reached at time 116878669 ns.

and test stuck here

Test with Icarus finished with

 END of SIMULATION
WARNING: ../bench/verilog/tb_ethernet.v:539: invalid file descriptor/MCD (0x1e) given to $fclose.

Test MAC FULL DUPLEX TRANSMIT TEST stuck with Iteration limit error

The clock domain crossing from the mtx_clk_pad_i to wb_clk_i violates the basic rule of syncronous digital design: there is no double-triggering, signal from the mtx-clocked trigger goes through a logic (!) to a wb_clk-clocked trigger. 

In addition there is no syncronization logic, it just relies on the fact that wb_clk is much faster then mtx_clk and will always able to latch these signals, but I am sure that if wb_clk will be 50 MHz or less (with mtx_clk being 25 MHz) system behaviour will be unpredictable.

Irregular clock domain crossing

Problem symptoms:

Disabling the transmitter (writing 0 to the transmitter enabled bit of the MODER register) while the transmitter is working (i.e., there are buffer descriptors marked as ready in the circular buffer) and reenabling it later will cause the transmitter to skip the first buffer descriptor (BD#0) and to start sending from the second descriptor (BD#1).

Probable cause:

The exact sequence of events inside the device seems to be as follows:
* The device is in the process of sending a packet when the user resets the transmitter enabled bit.  The transmitter does not stop until the current frame is transmitted completely.
* Once the transmission is complete, the

Disabling the transmitter while sending data

I have experienced strange problems when using the "multiple Tx and Rx buffer descriptors" functionality of this core, like losing packets or having the core not respond for a few seconds. I respected totally the wrap bit at the last buffer and all the things, but the core worked fine for several hundred packets and then start losing them.
My solution: If instead of using several buffer descriptors you use only the first Tx and the first Rx buffer descriptors, with the wrap bit set, and manually change the buffer address after each Tx/Rx, then everything works fine.

Random lost packets when using multiple buffers

Everyone of Half-Duplex tests is reported failed, either with some MIIM issues. I've tryed different versions of ModelSims(5.6,6.1b,6.2b). Had anyone encountered something like this pls don't hesitate to give me a help. Thanks a lot.

The whole content of the Log file generated is here:
http://timme.u15fans.cn/eth_tb.log.txt

or

http://www.timmemousai.info/eth_tb.log.txt

Testbench Failed in Half-Duplex Issues with ModelSim

Hello,

I am using the OpenCores MAC in a commercial embedded system, and I have discovered that it very occasionally will silently corrupt received packets. That is, the data that it writes to memory is corrupted, but it does not report a CRC error. The corruption seems to be very specific: a 12-byte long sequence that starts on at least a 4-byte boundary is shifted into the future by 4 bytes (thus duplicating the first 4 bytes in the sequence and wiping out the 4 bytes that should've come after). I can easily reproduce the problem with a simple flood ping to my device. This is a particularly subversive bug, as it leaves header information intact and can thus cause undetected errors in higher-level protocols (e.g., HTTP transfers, which is how I discovered this).

I have added software CRC checking as a workaround, so this is no longer a problem for me (the packet loss is not a big issue for my application), but I am posting here so that others will know about the problem (and perhaps someone will investigate?).

Note that the bug at http://www.opencores.org/ptracker.cgi/view/ethmac/283 seems similar, but I have tried the fix suggested there by Jun and it does not help.

My system is a Nios II CPU running in an EP2C35F484C7 FPGA. (I'm using the Avalon version of the core from MaCo.) The OS is uClinux 2.6.17-uc1.

MAC silently corrupts rx pkts

I am using the avalon component from MaCo in a NIOS II system on an altera EP2C20.

I observed corrupted ethernet frames in memory received by the opencores ethernet mac. I changed my driver to fill each Rx buffer with 0xe5 prior to handing it over to the MAC and to do the CRC check in software after a frame is received. I observed, that the data was stored at BdAddress+4, one Dword off towards higher memory locations.

I traced this problem down to being a race condition in eth_wishbone.v. After writing the last word of data to an rx buffer, the status is written to the BD an an new BD is read. 

When the writing of the last dword to memory takes longer than it takes to start the new BD, the final m_wb_ack_i increments the BD address of the new BD. :-(

I changed the following assignment:

old: assign StartRxPointerRead = RxBDRead & RxBDReady;
new: assign StartRxPointerRead = RxBDReady & ~MasterWbRX;

MasterWbRX is active, while the RX DMA engine is writing data to the buffer. This way, reading the new buffers address is delayed until the pending bus transaction has finished.

But now I get BUSY interupts! :-O

BUSY – Busy
This bit indicates that a buffer was received and discarded due to a lack of buffers. It is cleared by writing 1 to it. This bit appears regardless to the IRQ bits in the Receive or Transmit Buffer Descriptors.

My guess is, that it now takes too long to read the new BD, so the new BD is not yet ready, when the Rx has new data. Shouldn't the Rx FIFO resolve this situation?

I have no idea, what to do.

Thanks in advance,

Mario

Race condition in eth_wishbone.v

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.

RxBdAddress does not wrap around under some conditions

After a list of frames is transmitted, all BDs are marked as not ready and the MAC is disabled (r_TxEn=0), a frame is transmitted when the TX BDs are reinitialised (ready=1).
This is because the "TxEn_needed" signal stays '1' when r_TxEn is set to '0'.

I suggest to modify the process the following way (add " | ~r_TxEn" in the second "else if"):

always @ (posedge WB_CLK_I or posedge Reset)
begin
  if(Reset)
    TxEn_needed <=#Tp 1'b0;
  else
  if(~TxBDReady & r_TxEn & WbEn & ~WbEn_q)
    TxEn_needed <=#Tp 1'b1;
  else
  if((TxPointerRead & TxEn & TxEn_q) | ~r_TxEn)
    TxEn_needed <=#Tp 1'b0;
end

What do you think about this?

best regards

Christoph Glattfelder

Zurich University of Applied Sciences Winterthur, Switzerland

Browse

Ethernet MAC 10/100 Mbps