Ethernet : MAC vs PHY

I have a 10BASE-T MAC/stack design (using PicoBlaze, BTW) which I'm trying to bring up on the Avnet/Memec S3MB Spartan3 1500-based board. I've got the board connected to a PC, nothing else, running "ping" and Ethereal. The S3MB board pins-out the Rx and Tx lines the reverse of the PC, so I am using a straight-thru cable. My design receives ARP and ICMP ECHO frames from the Broadcom BCM5221 (jumpered to not autonegotiate, and keeping it at 10Mbps) quite happily (haven't noticed any dropped frames, and it even properly ignores test frames with the incorrect IP address).

But the PC appears to reject most of the frames with which my design replies. I can see my response frames at the MII, and I see the wire wiggle with Manchestery goodness (voltage levels for receive and transmit frames are about the same). But 80-90% of the time, my transmissions are not detected, both by ping (timeout) or Ethereal. I've checked my checksums and FCS, and they appear correct. In fact I don't see much besides header checksums and seqs or idents that are different between accepted and rejected frames. I limit the changes on the MII TxD and TxEN lines to when TxC is low.

What else can I be doing wrong at this level? Does anyone have a reference design that responds to pings that I can pop into this card to see how it behaves?

twv@

Dear Tom,
Are you using Picoblaze to do the MAC ?
Few times ago I designed the back end of a "Small C" compiler for
Picoblaze, it may be usefull for you you can download from
www.poderico.co.uk

At moment (at work) I'm doing some reserch to see what is the cheapest
way to implement a tri mode ethernet MAC
What I found is:
1) if you go on www.opencores.org and you download the tv80 then one of
the application is a simple GMII Interface.
Now MII is half/full duplex and GMII is full duplex only, but iff you
can set up your PHY to be full duplex, then it should be easy to go
from GMII to MII.
2) on www.opencores.org you can download a free 10/100 MAC, why you
don't use this core? (also tri mode MAC and 10 G not tested yet)

3) here http://www.sics.se/~adam/uip/index.html you can download the
smallest TCP/IP stack it has been ported on... (Xilinx Ultracontroller)
AVR, PIC etc. is very good, and I reccomend it...

good luck,
Francesco

Well, my design really needs only ARP, ICMP ECHO, and UDP. My MAC/stack, instead of handling the various layers of the OSI model, treats each frame as simply having one really long header. So my "MAC" isn't separable from the code that handles the IP, UDP, and application headers (the ultimate datagram payload). I didn't use some open core MAC because I didn't want to build a whole stack of software to support it -- the Spartan3 PicoBlaze only supports a 1K instruction space. I just wanted to develop a simple peripheral that treats the UDP/Ethernet as a complicated serial port. I have one PicoBlaze handling Ethernet receive (through UDP), one handling application headers and payload (that doesn't even get involved in ARP and ICMP ECHO), and one handling Ethernet Transmit (UDP down through collision detect/backoff). Dedicated hardware computes FCS checksums and residues.

For your research, Francesco: I'm only interested in 10BASE-T, where the PicoBlaze running at about 40MIPS was fine to handle everything including shooting the nibbles out the MII. For 100BASE-T, I would have to add more hardware to manage that. At only maybe 400 instructions in one processor and 700 in another, assembly programming was fine.

Anyway, the board already exists; I'm not in a position to add AVRs or PICs. Anyone know if Avnet/Memec have an example design (already verified) that I can pop into their S3MB card to simply handle 10BASE-T ICMP ECHOs? Or are there other considerations of the Broadcom 5221 PHY or known bugs I should have to deal with to resolve this? Can a Windows PC accept my reply frames sent within 40us of the end of the requesting frame? Thanks.

twv@