RE: [ethmac] Ethernet status

["Kevin Kay" <Kevin.Kay@espipd.com>]

I have put *portions* of the Ethernet MAC in real hardware with good
results.  My implementation is very, very reduced and application
dependent, so I will summarized the pieces that I have successfully used
and tested.

MIIM interface - I've implemented the MIIM (also called MDIO by some)
almost unmodified.  I hard coded the clock divider to 10 (for my
purposes), and I feed the module differently from the original design
(i.e., I feed the PHY address, REG address, and REG data differently).
I have had great success with this module.  I think I had to combine the
MDI and MDO signals at the top level in my design to create a truly
bidirectional pin (since my target device supported bidirectional pins),
but all of the signals were already present for implementing that.

RX MAC - My application is a TX-only application, so I stripped out all
of the RX MAC modules

TX MAC - I used a highly modified and reduced version of the TX MAC.
Since I don't receive anything, I assume that I'm operating on a full
duplex link and don't monitor any of the signals which would force a
retry at the MAC level.  However, I have successfully sent frames using
the opencores code as a base (appropriate headers left in tact in the
files to give credit).  I captured my frames using a sniffer package and
analyzed the results for accuracy.  Since there has been much discussion
over the CRC algorithm used, I can say that it does work and will be
successfully received by a destination MAC.

Wishbone Interface - I totally redid the interface to my CPU.  As you
can tell from above, my MAC requirements were so reduced that I did not
really need a lot of the complexity contained in the wishbone interface.

Unfortunately, I've only tested a relatively small portion of the code,
but it seems to work.  I did find out that the asynchronous resets are
very important to the code.  I tried converting the asynchronous resets
into pure synchronous resets and quickly found out that the PHY that I
am using does not send out a clock during power-up until after the
board's reset line is released.  Since my MAC design was completely
driven by the PHY's clock, an asychronous reset solution was the only
way to go.

I don't know how much confidence this builds in the core as a whole, but
I only found 1 problem with the lower level modules (specifically in the
RXMAC state machine - which I wasn't using anyway).  I believe Igor has
corrected this problem, and it only became a problem if the attached PHY
did not send out a proper preamble.  I've not done a great deal of study
on the higher-level modules, but the lower modules seem to be in pretty
good shape.

Regards,
Kevin

-----Original Message-----
From: Igor Mohor [mailto:igorm@opencores.org]
Sent: Tuesday, February 26, 2002 5:11 AM
To: Ethmac@Opencores. Org
Subject: [ethmac] Ethernet status


Hi, Guys,

these days I'm putting ethernet to the actual hardware. FPGA 
(VirtexE 1600) is going to contain the following Opencores 
IP cores:
- Ethernet MAC
- UART (already tested in HW)
- RISC (already tested in HW)
- PS2 (already tested in HW)
- Development (debug) interface (already tested in HW)
- Memory Controller

Simulation of the whole design is already working great. 

Next thing that needs to be done is making ethernet core
more popular and worth of trust.
For this reason a good testing environment is a must. I tested
the ethernet core on all module levels, however I don't have a
good testing environment. I'm talking about something that people
can take, run and get a good proof that core is really working.

I know what needs to be tested. My question is if somebody already
built an environment that can share or something like that that's
worth working on it.

Regards,
	Igor
--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml