Re: [BP] [SPAM:42%] Re: [BP] Question regarding Channels
All,
For 802.3 serdes products (1000BASE-X, 10GBASE-X4) there have only
ever been two channels defined and they are both cables (1000BASE-CX and
10GBASE-CX4). XAUI never defined a channel to work on, it only defined
an insertion loss comliance point similar to how one defines a comliance
load for an output buffer. 802.3ap is blazing new grounds in defining a
channel without stepping up from a prior channel that has already been
defined. In essence this task force is defining the first backplane
channel for 802.3. So the question we need to ask ourselfs is: Do we
want to define a set of channel limits without any definition (direct
or indierct via a reference to some other standard) of the physical make
up / construction of the channel or not? I don't recall anything in
the objectives that forces us one way or the other. The objectives only
state that it should support opperation .... on improved FR-4 ...
lengths up to at least 1m. To me this means any limits the task force
comes up with need to allow a connection using improved FR-4 to be
built. I think everything else is up for grabs at this point.
Everyone needs to ask themselves: How much of the physical
requirements should .3ap define for its channel?
Howard
Booth, Bradley wrote:
> Joel,
>
> I'm not absolutely sure how TIA does it, but in ISO/IEC, JTC 1/SC
> 25/WG 3 defined cabling (cable + connectors). There are other ISO
> bodies that define the cables and the connectors, and WG3 combines
> them for various cabling environments. The environment that 802.3an
> cares about is the horizontal copper cabling portion. 802.3an uses
> the 11801 specification as a reference to create channel models. The
> Task Force doesn't specify cabling, but does use cabling
> specifications to pick a channel model.
>
> This seems to be the "hole" for 802.3ap, especially considering that
> the 1-lane 10G is such a new market. The Task Force could consider
> that the 1-lane 10G has to be able to run over the same channel that
> 1-lane 1G and 4-lane 10G operate on. If that was the case, then those
> channels would have to be characterized out to the 10G rate. If the
> Task Force doesn't believe that 1-lane 10G will operate on the same
> channels as 1-lane 1G, then I would say that the scope of this effort
> has changed and the need for auto-negotiation would disappear. I
> would also be concerned that the elimination of multi-speed capability
> would severely limit the market potential for this technology.
>
> As for the battles, I don't think there is going to be anyway to avoid
> it. 802.3an is going through some because of the market potential for
> a new form of cabling. 802.3ap is going to have a larger set of
> issues because there is no ISO/IEC specification for backplane
> channels. I guess the question comes back to being a chicken and egg
> story. Can you create a model without an implementation to verify
> against? Can you create an implementation from just a channel model?
> Until there is some stake in the ground, I think it will be very
> difficult to develop consensus. To me, it comes back to the question
> of whether or not this channel must support 1-lane 1G and 1-lane 10G.
> If so, then you probably want to use existing 1-lane 1G channels as a
> starting point. Either that or form a standards body to specify
> backplanes. ;-)
>
> Cheers,
> Brad
>
> ------------------------------------------------------------------------
> *From:* owner-stds-802-3-blade@listserv.ieee.org
> [mailto:owner-stds-802-3-blade@listserv.ieee.org] *On Behalf Of
> *Joel Goergen
> *Sent:* Thursday, October 07, 2004 8:58 AM
> *To:* STDS-802-3-BLADE@listserv.ieee.org
> *Subject:* Re: [BP] [SPAM:42%] Re: [BP] Question regarding Channels
>
> Brad,
> The issue I have with specifying ATCA as the back plane is that
> what do the rest of us telecom users do when the silicon doesn't
> function on our back planes and the vendors say "it isn't an ATCA
> back plane even if the channels look good, so therefore I can't be
> certain the parts will work".
>
> We define cabling to a point, and then we stop. I don't recall
> TIA defining the jacket material specifically, or max wire count.
> TIA does specify twist, attenuation, and all the nulti flavors of
> xtalk, etc. We need to define a channel that is as independent of
> physical implementation as possible. We should not constrain
> layers or total number of routes. If you specify physical
> mechanical implementation, then what do the rest of us do that
> want to use this? With exception of length, connector count, and
> possibly best design practice in some limited way, not even xaui
> specifies physical mechanical implementation on a board. I'll
> grant you that cx-4 goes much further in specification, but do you
> really want to invite a war among connector vendors and mechanical
> implementations such as slot width and cooling, etc ???? The
> battle would be terrible. Not to mention the ATCA design format
> is inefficient for high port count designs employed by the top
> 10gigE providers.
>
> I have no issue including design practice used within the confines
> of ATCA. I honestly didn't realize it was an inherent
> requirement. We will have to decide if we want to include xaui
> as part of that inherent requirement, as well. Once we define the
> level of design practice/architecture we want to tolerate for the
> channel, we can move forward with great speed and progress.
>
> take care
> -joel
>
> DAmbrosia, John F wrote:
>
>> Brad,
>>
>> Part of the problem is that even within the ATCA form factor, one
>> will be able to find all sorts of channel performance pending
>> implementation.
>>
>>
>>
>> John
>>
>>
>>
>> -----Original Message-----
>> *From:* owner-stds-802-3-blade@listserv.ieee.org
>> [mailto:owner-stds-802-3-blade@listserv.ieee.org] *On Behalf Of
>> *Booth, Bradley
>> *Sent:* Wednesday, October 06, 2004 7:31 PM
>> *To:* STDS-802-3-BLADE@listserv.ieee.org
>> *Subject:* Re: [BP] Question regarding Channels
>>
>>
>>
>> Joel,
>>
>>
>>
>> ATCA was heavily quoted in the CFI for this effort. As a matter
>> of fact, a lot of the market numbers used were based upon ATCA.
>>
>>
>>
>> That being said, personally I don't care if the Task Force
>> decides to consider ATCA or not. My employer might, but there
>> are others within my company that will voice their opinions. My
>> concern is that the Task Force is trying to specify a channel and
>> wants to avoid specifying a backplane. This is not that
>> different than what P802.3an has been going through. The only
>> advantage that P802.3an has is that there are cabling
>> specifications that we can reference. The P802.3an Task Force
>> has used ISO/IEC 11801 Class E and F cabling as the basis for its
>> link segment (channel) model specification. Once the Task Force
>> was able to make that choice, then the PHY vendors could have a
>> level playing field for developing the signaling proposals.
>>
>>
>>
>> From my point of view (on the other side of the fence), is that a
>> channel model based on existing ATCA platforms would provide a
>> more level playing field from which to start, either for
>> signaling or from which to develop another channel model. Until
>> then, it would seem to me that channel models could literally be
>> all over the map.
>>
>>
>>
>> But like I said, personally I don't care. I'd just like to see
>> the Task Force make some forward progress on what appears to be a
>> very contentious issue.
>>
>>
>>
>> Cheers,
>>
>> Brad
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* owner-stds-802-3-blade@listserv.ieee.org
>> [mailto:owner-stds-802-3-blade@listserv.ieee.org] *On Behalf
>> Of *Joel Goergen
>> *Sent:* Wednesday, October 06, 2004 4:09 PM
>> *To:* STDS-802-3-BLADE@listserv.ieee.org
>> *Subject:* Re: [BP] Question regarding Channels
>>
>> Brad,
>> I thought the objective was to define a tx, rx, and channel
>> we could use in a back plane design. The objectives don't
>> state that we define this for an existing back plane
>> standard. Isn't ATCA an MSA?? To get the spec, I have to
>> pay a membership?? I'm not trying to be dis-respectful, but
>> the ATCA spec defines pinouts and mechanical placement ...
>> that's what tells people what to do. You are still free to
>> develop the channel, tx, and rx, from my point of view.
>>
>> To be more exact, I believe you are missing my points .... if
>> we are developing a standard to operate on the ATCA, then why
>> has ATCA not given us the full specifications to work with?
>> If the objectives said we have to desing this for ATCA, then
>> I would have read the spec. Now I am hearing for the first
>> time (last week) that we HAVE to include ATCA. Fine, I'll
>> find a spec and see what the issues are. But lets not forget
>> that there will be other users then ATCA. Is IEEE in the
>> business to develop standards for MSA? IEEE has not been
>> kind to some of the work done in OIF.
>>
>> Brad ... I was completely blind-sided last week. Never in
>> any of the emails or minutes of any meeting did we say that
>> we HAVE to run on an ATCA platform. You, like others last
>> week, are saying it is implied. Forgive me for being dense
>> because I was trying to design a tx, channel, rx solution
>> .... I didn't know we are designing one to run on a legacy
>> back plane.
>>
>> Now that that is clear, how about pointing people to the MSA
>> page for ATCA so we can become members, get the specs, and
>> see if we want to continue our individual efforts in this matter.
>>
>> -joel
>>
>> Booth, Bradley wrote:
>>
>> Joel,
>>
>>
>>
>> I want to touch on your point #4. While I agree that this is
>> not an ATCA standard, let's not forget that this effort
>> wouldn't have happened if ATCA hadn't adopted 1G and XAUI.
>> The primary concern that I have is that if I want to build a
>> backplane, the only "standardized" backplane out there is
>> ATCA. I feel that if the Task Force ignores this backplane
>> standard, then the Task Force is limiting its broad market
>> potential. This would be paramount to 802.3 standards (that
>> use cabling) saying "we've specified a channel model, but
>> there is no cabling specification for this in the market."
>> The end user is left to guess how to build the channel, and I
>> can surely bet that in a competitive market, the story they
>> get from each vendor will be slightly different. It is not
>> that the Task Force has to use ATCA, but it does make for a
>> good reference point to start from. This is what 802.3 has
>> done in the past with all our 10G efforts: start with a known
>> channel.
>>
>>
>>
>> Cheers,
>>
>> Brad
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* owner-stds-802-3-blade@listserv.ieee.org
>> <mailto:owner-stds-802-3-blade@listserv.ieee.org>
>> [mailto:owner-stds-802-3-blade@listserv.ieee.org] *On
>> Behalf Of *Joel Goergen
>> *Sent:* Wednesday, October 06, 2004 9:34 AM
>> *To:* STDS-802-3-BLADE@listserv.ieee.org
>> <mailto:STDS-802-3-BLADE@listserv.ieee.org>
>> *Subject:* Re: [BP] Question regarding Channels
>>
>> I couldn't disagree with you more!
>>
>> Point one ... How can you discuss including or not
>> including channels when you haven't even picked out a
>> channel base line that altimately determines the design
>> criteria used within the channel! How about putting the
>> horse before the cart rather then drag the poor thing
>> along the side.
>>
>> Point two .... You can not pick signaling until you know
>> what kind of channel you want to run on. If you want to
>> run on legacy stuff, or channels with open design
>> practices, then don't you think nrz at 10gbit is out of
>> the question? You can not run 10gig nrz over a channel
>> the barely meets xaui without using a LOT of power and
>> die space ... and then I don't know if it can be done - I
>> have done a lot of testing on it. We don't even know if
>> duo-binary will run on an open design practice channel.
>>
>> Point three .... We need to have a channel defined that
>> includes the types of design practices we want within
>> it. Then we can sort out test cases and signaling. It
>> would be nice to have a channel with such design practice
>> that you could run several types of signaling ... makes
>> for fair choices.
>>
>> Point four ... the last time I checked, the telecom
>> market was still a bigger user of xaui and fiberchannel
>> across back planes then ATCA. The last time I checked,
>> telecom as a whole is shipping more custom back planes
>> then ATCA. So how about focusing some of the marketing
>> thoughts towards this group and satisfying their needs!
>> I don't recall ever in the objectives seeing that 802.3ap
>> is an ATCA standard.
>>
>> Joel Goergen
>> -----------------------------------------------------
>>
>> Riccardo Badalone wrote:
>>
>> I agree with John that short is not always better, and
>> the SDD12 is not the only criteria that defines if a
>> channel can be equalized correctly or not.
>>
>>
>>
>> Since we have not converged on a signalling and
>> electrical specification for TX and RX devices, I think
>> it may be counter-productive to spend too much time
>> debating the informative channel, especially if it
>> excludes many of the existing, measured channels that
>> have been presented. Since the data presented by John and
>> Peter can easily be reproduced in other
>> practical systems, I feel it is a mistake to discard it
>> because it does not meet the informative mask for SDD12.
>>
>>
>>
>> I really think the signaling commitee should continue
>> work related to defining an objective simulation
>> methodology. This would not only allow us to compare
>> signalling methods, but it would also give everyone
>> involved a clearer picture of what channels are
>> "solvable". The signalling ad hoc should simulate as many
>> channels as possible, with the goal of objectively
>> picking the best signalling approach.
>>
>>
>>
>> Once a signalling approach has been selected, the next
>> step can be to extend the simulation models to take into
>> account implementation specific limitations that may
>> further reduce the number of channels that can be
>> supported, but at the same time it should give some
>> guidance to the channel ad hoc with respect to where the
>> limits on the masks should be. Hopefully, we will emerge
>> with a robust signalling approach and a clearer picture
>> of what the reasonable limits of the channel are. This
>> will include loss, xtalk, reflections, and anything else
>> that is considered an impairment.
>>
>>
>>
>> In summary, let's accelerate discussion around
>> what assumptions to include in simulations, how to define
>> a common simulation methodology, and which signalling
>> techniques we want evaluated. I'd like to see less talk
>> about limiting the channels we will simulate with until
>> we know that none of the signalling schemes proposed can
>> solve them.
>>
>>
>>
>> Riccardo
>>
>>
>>
>> -----Original Message-----
>> *From:* owner-stds-802-3-blade@LISTSERV.IEEE.ORG
>> <mailto:owner-stds-802-3-blade@LISTSERV.IEEE.ORG>
>> [mailto:owner-stds-802-3-blade@LISTSERV.IEEE.ORG]*On
>> Behalf Of *Booth, Bradley
>> *Sent:* October 5, 2004 6:19 PM
>> *To:* STDS-802-3-BLADE@LISTSERV.IEEE.ORG
>> <mailto:STDS-802-3-BLADE@LISTSERV.IEEE.ORG>
>> *Subject:* Re: [BP] Question regarding Channels
>>
>> John,
>>
>>
>>
>> I've been sitting on the fence watching this, and I
>> wonder if this is more about whether or not to
>> support legacy vs. greenfield channels. If that is
>> the case, the answer may be harder to achieve, but
>> there may be some room for a compromise. Something
>> that came to mind recently is that this could be
>> similar to the existing Cat 6 and augmented Cat 6
>> discussion going on in 10GBASE-T. The interesting
>> thing is that the model of a 55m channel of Cat 6
>> (legacy) is very similar to a 100m channel of
>> augmented Cat 6 (greenfield). If there is a desire
>> to support legacy back planes (primarily ATCA which
>> would support the Broad Market Potential
>> requirement), but the reach on those back planes is
>> less than the 1m target objective, then is it
>> possible that the legacy channel model (for its
>> specified reach) could be equivalent to greenfield
>> channel model at the 1m reach?
>>
>>
>>
>> In other words, if the ATCA max. reach is 32", then
>> could the channel models for that reach be equivalent
>> to a greenfield channel that is achieving ~40"? So,
>> if you specify the channel model based on the
>> existing ATCA channel at 32", vendors should be able
>> to use better materials to achieve the required 1m
>> reach. This would permit support for legacy ATCA
>> platforms while permitting better materials to be
>> used for greater reaches.
>>
>>
>>
>> Thoughts? Or should I just go back to sitting on the
>> fence?
>>
>>
>>
>> Thanks,
>>
>> Brad
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* owner-stds-802-3-blade@listserv.ieee.org
>> <mailto:owner-stds-802-3-blade@listserv.ieee.org>
>> [mailto:owner-stds-802-3-blade@listserv.ieee.org]
>> *On Behalf Of *DAmbrosia, John F
>> *Sent:* Tuesday, October 05, 2004 1:46 PM
>> *To:* STDS-802-3-BLADE@listserv.ieee.org
>> <mailto:STDS-802-3-BLADE@listserv.ieee.org>
>> *Subject:* Re: [BP] Question regarding Channels
>>
>> All,
>>
>> The reflector appears to be very quiet. I would
>> really like to have this discussion so we can try
>> to move forward.
>>
>>
>>
>> John
>>
>>
>>
>> -----Original Message-----
>> *From:* owner-stds-802-3-blade@listserv.ieee.org
>> <mailto:owner-stds-802-3-blade@listserv.ieee.org>
>> [mailto:owner-stds-802-3-blade@listserv.ieee.org]
>> *On Behalf Of *DAmbrosia, John F
>> *Sent:* Tuesday, October 05, 2004 10:39 AM
>> *To:* STDS-802-3-BLADE@listserv.ieee.org
>> <mailto:STDS-802-3-BLADE@listserv.ieee.org>
>> *Subject:* [BP] Question regarding Channels
>>
>>
>>
>> All,
>>
>> Since time did not allow the conversation last
>> week, I would like to talk further on the
>> reflector to understand the opposition to the
>> different channels that were proposed.
>>
>> I will point to my test cases as a starting
>> point, but the conversation really applies to all
>> of the channels.
>>
>> As I see it, we have the following types of
>> impairments in the total system-
>>
>> 1. Loss dominated
>> 2. Significant stub effects that cause deep
>> nulls
>> 3. Ripple in the channel
>> 4. NEXT
>> 5. FEXT
>> 6. Return Loss
>>
>> I believe most of the opposition arose from 1, 2,
>> 3 and 6, but would like to have this conversation
>> now.
>>
>> The comments that I heard regarding my channels
>> were the following -
>>
>> · The data is not freely available. - This
>> is no longer true, as I indicated last week.
>> · The data violates the informative channel
>> model. I believe there were different cases
>> where this happened.
>> o Case 1 had minor ripple below the mask.
>> o Cases 2 and 3 were margin cases that the
>> Signaling Ad Hoc had requested.
>> o Case 6 came from a 22" link with top
>> layer backplane connections. This channel was
>> justified for its potential appearance in systems
>> where all cost was being minimized, so
>> counterboring was not assumed.
>>
>> o Case 7 had a resonance ripple at
>> approximately -55dB at 11 GHz. Once again this
>> was a test case asked for by the Signal Ad Hoc to
>> examine channel ripple. Otherwise up to 11 Ghz
>> it is 5 to 15 dB above the informative mask
>>
>> · Return loss is too high. In my opinion,
>> this is a contradictory statement. The mask that
>> I proposed that fit my data was not as aggressive
>> as Joel's channels (#1,2,3,6,7,8,14,17,18).
>> All of these models violated the proposed SDD11
>> mask in the lower frequency region, which I
>> proposed.
>>
>> · The data hadn't been seen. This is a
>> partially true statement. Tyco has been diligent
>> in presenting the data as quickly as gathered and
>> processed. The SDD21 channel data for Cases 2,
>> 4,5,6, and 7 was posted to the Signaling Ad Hoc
>> reflector for the Sept 9 meeting.
>>
>> So I reviewed Joel's data that was proposed
>>
>> Case #1 - 4_3_4 (4000-13) Total 11"
>>
>> Case #2 - 7_3_7 (4000-13) Total 17" has xtalk
>>
>> Case #3 - 10_3_10 (4000-13) Total 23"
>>
>> Case #6 - 4_10_4 (4000-13) Total 18"
>>
>> Case #7 - 7_10_7 (4000-13) Total 24" has xtalk
>>
>> Case #8 - 10_10_10 (4000-13) Total 30"
>>
>> Case #14 - 3_3_15_7 (4000-13) Total 29"
>>
>> Case #17 - 7_20_7 (4000-13) Total 34" has xtalk
>>
>> Case #18 - 10_20_10 (4000-13) Total 40"
>>
>> All of these test channels are well above the
>> channel model. We will still need a test case
>> that falls very closely on the informative
>> channel model, which is where the Tyco channels 1
>> - 3 are falling (with included margin cases).
>> From both IBM and LSI's analysis these channels
>> were solvable. The StatEye analysis results were
>> much more pessimistic (which is an on-going
>> problem with StatEye that is being investigated)
>> than the analysis of these companies and the
>> crosstalk was not applied properly.
>>
>> So to me it looks like overall loss isn't
>> necessarily the big problem. Loss can be very
>> advantageous, as was demonstrated at last week's
>> meetings, as to how it can actually help reduce
>> xtalk and return loss. Ripple and nulls on the
>> other hand appear to be the bigger problem.
>>
>> So I would like to open up discussion as to which
>> Tyco channels people were most concerned about.
>> Also, I do not know what to propose for a
>> "weighting" scheme, so any suggestions on this
>> would be of extreme use in helping us to reach
>> consensus and move forward.
>>
>> Cheers!
>>
>> John D'Ambrosia
>>
>> Manager, Semiconductor Relations
>>
>> Global CC&CE
>>
>> Tel 717.986.5692
>>
>> Fax 717.592.2470
>>
>> Cell 717.979.9679
>>