|
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
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]
On Behalf Of Joel
Goergen
Sent:
Wednesday, October 06, 2004 9:34 AM
To: 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.
-----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: October
5, 2004 6:19 PM
To:
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]
On Behalf Of
DAmbrosia, John F
Sent: Tuesday, October 05, 2004
1:46 PM
To: 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]
On Behalf Of
DAmbrosia, John F
Sent: Tuesday, October 05, 2004
10:39 AM
To: 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
|