RE: [ethmac]

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

I've done a 1000base FX interface that is currently working in a
project.  To sum it up, the PHY/MAC break is at a slightly different
point in a fiber application (well, in terms of the standard it's the
same, but the commercial component support breaks it at a different
point - at least in my application).  In a fiber application, you come
off your fiber into an optical transceiver such that you have a 1.25Gig
serial stream (8b/10b encoded).  From there, you go into a SERDES
(Vitesse and HP make a couple of the standard IC's) chip to deserialize
and synchronize to the data.  The deserializer does the clock recovery
and looks for comma characters to get your parallel data properly
aligned to the even/odd timeslots.  The SERDES chips typically put out a
bi-phase clock (each phase running at 62.5MHz, which is half of 125MHz
if I did my math correctly) for the receive data.  On the parallel side
of the SERDES chip, the data is still 8b/10b encoded (10-bit PCS data
coming in at 125Mhz effective rate, but synced to a recovered bi-phase
clock as explained above).  In my application, the MAC takes care of the
8b/10b decoding, running disparity issues and monitors for
synchronization errors.  Actually, it's not really called a MAC in my
case, but it's called the SERDES interface.  But the upshot is that
you're used to seeing raw data on the lines between a MAC and the part
that hooks to your transmission medium.  In 1000base FX that's not the
case, you see 8b/10b data (10-bits wide) with running disparity, so the
10b code word may be true or inverted (makes debug very fun at times).

In a copper interface, the PCS decode (8b/10b decode) and other such
issues are handled before you ever see the data on the GMII interface.

Hope this helps clear it up.  I'm not an expert by any means, but I've
suffered through some problems.

The #1 problem in getting a 1000base interface going (yes, I fell into
the trap as well) is the quality of your reference clock.  In my case,
the reference was 125MHz.  If you a 125MHz oscillator as your reference,
the embedded crystal MUST be running in overtone mode (with as low a
multiplier as possible - e.g., 2x) in order to meet the 1000base jitter
spec.  Typically, oscillator manufacturers will have a series
specifically designed for 1000 base applications (Raltron, Abracon,
Vite, etc.).  If you use a standard 125MHz oscillator with a 4x or
greater multiplier, you will probably not be able to achieve consistent
link (it's literally that bad).  You don't need a fancy jitter analyzer
to get a feel for whether or not your clock is a problem, a good
high-speed digital scope can do the job if you use the right trigger
technique (you need a 1-3GHz scope to properly probe these signals
anyway).

Regarding your question about documentation on the receiver, I've not
looked at the current set of documentation in a while, so I'm not sure
of its state.  From what I remember, the receiver was discussed in broad
strokes from a high-level standpoint (like what happened during a
collision during half-duplex, etc).  I mainly learned how the receiver
worked from diving into the code.  If you leave out the states
associated with half-duplex operation, then the receiver becomes much
easier to dissect.  My opinion is that the code is the best reference,
and the document tells you how the code is structured and what the
register bits mean.  The opencores design is/(was when I grabbed it)
structured such that you could easily unbolt the MAC from the Wishbone
interface.  In my case, I went through the whole MAC portion to
understand how things hooked together, but I was doing a transmit-only
design.  I needed to be sure I could separate the portions of the MAC
without too much trouble in order to minimize my design.

Regards,
Kevin

-----Original Message-----
From: colin.renfrew@sli-institute.ac.uk
[mailto:colin.renfrew@sli-institute.ac.uk]
Sent: Monday, July 29, 2002 2:39 PM
To: ethmac@opencores.org
Subject: RE: [ethmac]


Thanks Kevin, sounds good.

My design is for full-duplex only - most if not all current GbE products

I've seen around are full-duplex only. It avoids a LOT of problems that 
you only get with half duplex! 

I guess my main concern with the opensource code is that it is designed 
for half-duplex operation and therefore contain much that I don't need, 
but it's much easier than starting from scratch! 

Does it make a difference what media is being used? I thought the MAC 
interface would be generic i.e. for copper or fiber. 

I've had a glance at the documents for the MAC designed here. Is there 
anything that details the architecture of the receiver? The most
detailed 
I've found (for any MAC anywhere) is a diagram of the entire MAC. I 
have a reasonable idea of what the Rx unit should look like, but I'd
like 
to know if I'm on the right track!

Cheers,
Colin



----- Original Message ----- 
From: "Kevin Kay" <Kevin.Kay@e... > 
To: <ethmac@o... > 
Date: Mon, 29 Jul 2002 10:28:28 -0400 
Subject: RE: [ethmac] 

> 
> 
> I assume that you are doing a copper interface, so your MAC would 
> have a 
> GMII interface (8-bits wide) to the PHY rather than a SERDES 
> (10-bits 
> wide, 8b/10b coded) interface (fiber).  While the gig-E mac is 
> similar 
> in principle, I think it is slightly different in implementation 
> due to 
> real-world timing constraints (8-bits wide MII, collision timing 
> different, etc). 
> 
> I'm not a gig-E expert, but I seem to remember some minimum packet 
> length requirements in half duplex mode in order to reliably detect 
> a 
> collision in the high data-rate environment of gig-E.  If the 
> packet to 
> be transmitted was not large enough, it had to be padded.  The gigE 
> requirement was larger than the 64 bytes for 100MBit stuff.  This 
> larger 
> min packet requirement did not apply in full duplex (since there 
> would 
> never be a collision). 
> 
> I'm sure there are many more differences than the 8-bit wide 
> interface 
> and the half-duplex packet size. 
> 
> I'm not an author of the opencores code, but I have studied it a 
> great 
> deal, and I think much of the MAC code would apply if you are doing 
> a 
> 10/100/1000 MAC (you would be using the 10/100 code and adding 
1000 
> support). 
> 
> In a nutshell, my opinion is that the opencores code would be a 
> great 
> place to start (especially if doing 10/100/1000), but it will take 
> more 
> than a few hours to modifiy for 1000 support (no free lunch). 
> 
> Regards, 
> Kevin 
> 
> -----Original Message----- 
> From: Colin 
> [/cgi-bin/post.cgi?cmd=new&to=colin%20dot%20renfrew%20at%20sli-
institute%20dot%20ac%20dot%20uk&msg=/ml-
archive/ethmac/msg00013.shtml] 
> Sent: Monday, July 29, 2002 12:43 PM 
> To: ethmac@o...  
> Subject: [ethmac] 
> 
> 
> 
> Hi, 
>   I'm completely new to this forum. I'm currently working on a 
> project, 
> the focus of which is to design the MAC Rx for Gigabit Ethernet, in 
> Verilog. At the moment, I have still to begin actual implementation 
> and 
> coding. 
> 
> I stumbled across this mailing list and some of the information 
> I've 
> picked out so far looks invaluable to my project. I was wondering 
> if 
> anyone has general advice/can help me out with this. The main 
> question 
> I have on first glance at this mailing list is: Can all of this be 
> applied to 
> Gigabit Ethernet? If so, what are the main differences? 
> 
> Ok, any feedback would be greatly appreciated, 
> Cheers, 
> Colin 
> 
--
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