Re: Interface reality check
Hi Rich,
Thanks for the illustration. Two comments:
1. On page 1 you say that RS needs to transport RF and BL codes. In Gigabit
Ethernet, the RF and Break link
was transported using data + combination during
AN phase. In strict sense they should go via MDC/MDIO (if we go via GMII
equivalence). Do
you mean that RF/BL needs to go via management interface associated with
XGMII or
they need to go in band along with other control codes ?
2. Although you clearly specify XGMII interface between RS and (PCS+PMA+PMD) in
example device B, I want to make sure that it will work if the XGMII was
exposed at
chip level (thus RS and rest were in two separate devices).
Regards,
Tripathi.
At 03:55 PM 3/31/00 -0800, you wrote:
>Ben,
>
>Attached to this note is a PDF file containing a proposal to modify the
>Reconciliation Sublayer to enable the transport of data and control codes in a
>PCS and XAUI independent manner. The proposal contains a reference 10 GbE
>implementation and multiple examples of code translation between two 10 GbE
>devices, Device A and Device B. It took too long to draw the figures in ASCII
>and the end result was ugly, so I resorted to PowerPoint. The proposal can be
>described in the following simple terms:
>
>- The XGXS transmitter translates Idle /I/ to XAUI Idle /A/K/R/;
>- The RS receiver translates /A/K/R/ to /I/;
>- The XGMII, XAUI/XGXS, PCS, PMA and medium transport all RS codes
>transparently.
>
>It is likely that the attached file is too large for this reflector, so
>you may
>either not receive this note at all, or the file associated with it will
>not get
>through. If this happens, I'd like to request Mr. David Law to post the
>attached
>file to the "email_attach" directory at:
>http://grouper.ieee.org/groups/802/3/10G_study/public/email_attach/
>
>I'll monitor this reflector for the fate of this note and the attached file.
>
>Additional comments below:
>
>Best Regards,
>Rich
>
>--
>
>Brown, Ben wrote:
> >
> > Rich,
> >
> > See comments below:
> >
> > Rich Taborek wrote:
> > >
> > > The issue is not whether XAUI encodings are required for 64B/66B, the
> issue is
> > > whether either the MAC needs to signal the PHY with anything other
> than Idles or
> > > the PHY itself needs to signal over the medium.
> >
> > Agreed.
> >
> > > I completely forgot about the obvious case of ERROR, where the MAC
> transmitter
> > > or the PHY at any point in the link needs to replace a data or
> control code with
> > > an ERROR code. In order to support this proposed function, 64B/66B must
> > > transport /E/ codes in addition to /I/ codes across the medium.
> >
> > Of course, and don't forget /S/, /T/ and /D/.
> >
> > > Note that Gigabit Ethernet also signals Break Link and Remote Fault
> through the
> > > use of Config words, which are essentially a control encoding
> different than the
> > > GbE idle stream. Several folks including Mr. Howard Frazier and
> myself have
> > > already alluded to the benefit and compatibility of supporting Break
> Link and
> > > Remote Fault for 10 GbE.
> >
> > This is a good example of codes in addition to those required by the
> > MAC/RS. So this means there is precedent to send information across the
> > link other than that information which comes from/to the MAC via the RS.
> > However, these codes are only used as a startup (Auto-Neg) or to
> > signal error conditions (remote fault & break link). They are not
> > present between every packet.
>
>I agree to the first part of the paragraph above. However, the
>architecture and
>implementation for the MAC and PHY to initiate, transport and receive control
>information other than Idle and Packets is intimately intertwined with
>Idle and
>Packet information. In fact, Ethernet can be considered to be an Idle stream
>transport which is rudely interrupted to transport Packets, Initialize the
>link,
>or report Errors.
>
>I'm not sure I understand either the relevance or accuracy of your statement
>that: "They (codes) are not present between every packet." Control information
>may indeed be required between every packet (e.g. Rate Control, Error,
>etc.) The
>fact that control information transport may be required between ANY packet is
>relevant.
>
> > > This makes for a potential requirement to signal at least three
> control codes
> > > besides /I/, /T/, /S/ and /D/ across 64B/66B and the medium. A further
> > > requirement is to support the transport of these codes through the
> optional
> > > instantiations of the PCS Service interface.
> >
> > I agree that these codes may need additional encoding to go across
> > something such as XAUI. I don't agree that this additional coding
> > cannot be removed at the end of the XAUI.
>
>Major disconnect. The "three control codes" mentioned above are: Break Link,
>Remote Fault and Error. These codes cannot be removed at the end of XAUI (I
>assume that you mean by the XGXS) since the codes are destined for either the
>PCS or the RS. In the case that the destination is the PCS, the PCS is
>responsible for transporting these codes over the medium to the remote
>link end.
>In the case that the destination is the RS, the XGXS is responsible for
>transporting these codes over the XGMII, if present, or directly
>delivering the
>codes to the RS. It should be clear that these codes cannot be removed by
>XAUI/XGXS unless a trap for a specific code is specified. Am I completely
>misinterpreting your response?
>
> > > One way I'll propose to do this cleanly is to have the RS receiver
> treat /A/K/R/
> > > the same as /I/. In fact, all codes other than /T/, /S/, /D/ and /E/
> could be
> > > treated as /I/ by the RS receiver until those other codes are defined
> by 10 GbE.
> > >
> > > No translations by the PCS, including 64B/66B, would be necessary.
> >
> > It's not a matter of this translation being necessary. I keep getting
> > the feeling that you're trying to make the PCS "easier" by "keeping"
> > the /A/K/R/ rather than converting them back to /I/. If all
> > implementations used XAUI than this could indeed be considered
> > "easier". However, if we're not going to force the use of XAUI then
> > "keeping" /A/K/R/ is not necessarily "easier". Am I reading you
> > incorrectly? (The above quotes are for emphasis. They are not meant
> > to imply that you've used these words.)
>
>I believe that we both made very good points in this thread about the
>practicality and impracticality of performing code conversion required to
>support optional interfaces. You are reading me to a "tee" by saying that I am
>trying to make the PCS easier. I am trying to make the entire PHY as simple as
>possible by considering the requirements and flexibility of all elements. I
>think you'll find the attached proposal to your liking :-)
>
> > > Whaddya think?
> >
> > I'll reserve judgement until I see the full proposal.
> >
> > Ben
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > Router Products Division
> > Nortel Networks
> > 1 Bedford Farms,
> > Kilton Road
> > Bedford, NH 03110
> > 603-629-3027 - Work
> > 603-624-4382 - Fax
> > 603-798-4115 - Home
> > bebrown@xxxxxxxxxxxxxxxxxx
> > -----------------------------------------
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com
Best Regards,
Devendra Tripathi
Vitesse Semiconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050
********************************************************************
Web: http://www.vitesse.com