RE: Interface reality check
Rich:
Thanks for spending lots of time developing multiple examples of XGXS, XAUI,
XGXS applications. It helps to appreciate more the XAUI options.
Since we like to keep XAUI as an option depending on 3" XGMII pc length, or
20" XGMII pc length, for flexibility, I believe we should keep RS interface
independent from XGXS, XAUI XGXS combination. Furthermore, the RS and PCS
interface should be kept the same.
In addition, the /I/, IDLE, signal circulating along the media (or fiber) is
very powerful debugging tool in a field to test the whole link, as I
mentioned several times. I will be disappointed to see this tool taken away
by a scrambled code. Although the repetitive /A/K/R/ but not actually
scrambled code is manageable. For an optical link, the IDLE should not
cause EMI problem for us. I may bring the GbE optical link EMI test at next
meeting.
With the above preferences, I like your configurations on page 2, or page 5
(reversed direction), but not those on page 3, or 4.
Regards,
Edward S. Chang
NetWorth Technologies, Inc.
EChang@xxxxxxxxxxxxxxxx
Tel: (610)292-2870
Fax: (610)292-2872
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Rich Taborek
Sent: Friday, March 31, 2000 6:55 PM
To: HSSG; David Law; Benjamin J. Brown
Subject: Re: Interface reality check
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