TSE "small MAC" isn't asserting fifo_rx_dsav signal for min size Eth frames

[Altera_Forum]

I have a "Small MAC" instantiation of the TSE for a 100 Mbit link. It appears that it isn't asserting the fifo_rx_dsav signal for small messages. When we try to ping our DUT (device under test) from a PC, it times out on the first attempt (sends out an ARP but not ARP response received), but the ping is successful the next time. Using SignalTap, we can see that nothing comes out of the Rx FIFO because the fifo_rx_dsav signal is never asserted (which is what my state machine uses to start pulling an Ethernet frame out of the FIFO). When the ARP from the second Ping attempt comes in, the MAC finally indicates frames are pending and I'm able to pull them out.  

 It seems as though the ARP frames (minimum size frames in general) aren't big enough to trip the FIFO threshold logic. The small MAC has this threshold stuck at a fixed value 16 words, or 64 bytes, which is the minimum allowable Ethernet frame size. The ARP is 42 bytes, but per protocol, is padded out to 64 bytes by the PC before sending to my DUT. Does the logic for this threshold work such that the FIFO fullness has to EXCEED the threshold or just reach it (be equal to it)? What else might be causing this behavior? I even enabled the option to pass the CRC on to the user application to ensure it is big enough to reach the threshold.   I tried using the almost empty flag instead (set to a static value of 3 words for the small MAC), but my state machine got stuck at startup when an erroneous frame came in from the PHY. My state machine looks for the end-of-packet signal and checks the error signal on that cycle, throwing away the message if both are asserted. Signaltap indicated that an erroneous frame came in from the PHY (RX ERROR signal was asserted) and I could see my state machine eventually start pulling it out of the Rx FIFO. But my state machine never returned to the idle state because the end-of-packet signal was never asserted. This is probably unrelated and is a separate issue. That issue prevented me from using the alternate signal (fifo almost empty) as my work-around to this issue.  Any ideas, suggestions, or questions? This is killing me and our integration schedule!

[Altera_Forum]

IIRC the minimum size is 64 bytes including the CRC. 

Does the 'small mac' put the CRC into the rx fifo? Does it have an option to? If the crc is supressed, enabling it might get you to the rx threashold.  However I'd have thought there was another 'frame status available' signal. Otherwise rx runts (packets less than 64 bytes) are difficult to remove from the fifo.

[Altera_Forum]

yes, minimum frame size is 64 bytes. yes, there is an option to forward or drop the CRC, and I've ran both configurations (currently leaving the CRC in tact and forwarding on user). 

 The only other signals I can find are RX FIFO "almost empty" and "almost full" flags. I tried to use the almost empty flag at one point, but it gave my state machine problems. I'm currently trying to find a way to make this work, but I'd really like to know why the intended signal usage (ff_rx_dsav) isn't working as advertised. I'd hate to use a "hack" fix long term.

[Altera_Forum]

Hi jehodny, 

 I have the same troubles as you! Using "arp -s " to set the MAC address of each, ping, telnet, ... are working. I though on first that it was a SW problem (ARP filtering), but I've just discovered that a "ping -s 22" that sends 22 + 8 ICMP data are not received, when "ping -s 23" are. Did you found a solution? Can one use the full version with a 10/100 design?  -- Fred

[Altera_Forum]

Finally, I've rework my design to use the full variation of the core. 

The good point is that I have the statistics now, which is not the case with the Small Mac variation. Strangely, thanks to the statistics, I can see that every frames are now dropped (ifInErrors=etherStatsPkts, RX pakets=RX errors). I can transmit but not receive. Help !

[Altera_Forum]

I didn't figure out why it isn't working as advertised, so I unhappily resorted to using the "almost empty" FIFO flag instead. 

 Do Altera support representatives read posts to this forum, or are we dependent on the good will of others to get answers here? Does a technical support ticket need to be filed to get their attention?

[Altera_Forum]

This forum is mostly user driven. So if you need official support, you should either contact your FAE or file an SR with Altera support. 

If you don't get any answer here it most probably means that no one here has run into the same problem or has an idea of what's wrong.

[Altera_Forum]

Finally, my RX problem is solved: a resistor was missing between the signal m_rx_err of the PHY and the MAC. This last one was thus not connected, resulting in the information "sometimes good" but most of the time "wrong"...