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
|