1. Home
  2. Field-Programmable Gate Arrays
  3. Ethernet : MAC vs PHY

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@

Reply to
Tom Vrankar
Loading thread data ...

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

formatting link

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
formatting link
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
formatting link
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

formatting link
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

Reply to
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@

Reply to
Tom Vrankar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.