Joe,
I partially disagree with your statement
regarding Joel's definition for the channel. First, Joel said his model
is based on an 0.030" stub, thus requiring counterboring. Not
everybody has done counterboring, and not everyone has done it to that degree. Thus,
for some vendors counterboring would be a Greenfield thing, and I guarantee
that there are vendors out there who will consider counterboring to be Greenfield, simply because they don't
do it internally. Second, Joel's channel is based on "improved
FR'4". However, I believe 4000-13 is about as low a grade as
you can go. Unfortunately, the current definition restricts the ease of
use for -13 being used. I ran into that earlier in the summer, and the
new proposal that Joel had suggested at one point would have enabled more
constructions of -13 to be used. Unfortunately, this was voted down. I
say unfortunate, because -13 looks to be the next main "FR-4" to be
used, and I would like our customers to have as much freedom as possible in
using this material. I have heard from a number of system vendors that
they are going to -13 next. Use of grade beyond it become limited due to
relative cost differences, and that is for the backplane. For the line
cards the relative cost difference accumulates even quicker, and it is easy to
envision that the relative cost difference will keep the material grade down to
the lowest grade material solution. Different applications will be sensitive
to relative cost in different ways. This is why I had to do line cards in
-13 and -13SI. Thus, while you are entitled to your view, so are a lot of
other people, and that fact needs to be observed. Just because we can
build it, does not mean that they will come.
One other thing that I wonder about is the
use of 6 mil traces on the daughtercards and backplane. At 40 inches skin
effect is an accumulate pain. Will all applications be able to support
the use of 6 mil wide traces on line and fabric cards. I think this is a
key question from system vendors, and ultimately will impact the channel model.
I am assuming from Joel's use of it on his test boards that he can
support it. I would like to hear other vendors confirm this or argue with
it.
The big thing in my mind comes to the stub
effect. If you look at our objectives it merely talks about 1m of
improved FR-4. It does not say anthing at all about stub effects. There
are a number of customers who do it, and a number who don't want to do
it. I believe as part of the process, we need to examine it, and rule it
either possible with consequences or rule it out because of those consequences,
but the point is we still have to do it. The industry expects it of us. The
case #6 I proposed was a very mild stub effect, compared to other channel
data. Having a test case in like that is imperative for both marketing
reasons and allowing the industry a fair chance to select the best solution.
At the last meeting, you had questioned me on the weighing scheme, and I have
no answer to that. I do not believe whether you can get it to work is the
ultimate weighing factor. There are surrounding questions that need to
support that fact, such as the things you talked about - power, ease of
implementation, etc All of these things will go into the weighing by each
individual as to what is the best solution. .
My two cents.
John
-----Original Message-----
From:
owner-stds-802-3-blade@listserv.ieee.org
[mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Joe M Abler
Sent: Monday, October 18, 2004
10:46 PM
To:
STDS-802-3-BLADE@listserv.ieee.org
Subject: Re: [BP] Question regarding
Channels
In the context of my original note, which was
addressing issues of the signaling ad-hoc, the line is as defined by the
channel ad-hoc which is where and how the line should be defined. Some
appear to have taken exception to what's been defined and rather than working
to address it in the channel ad-hoc the issue has been opened in the signaling
ad-hoc, which I don't think is appropriate.
So
as not to skirt your question let me comment on the legacy issue that's been
raised. In my view, there's nothing in Joel's definition that exclusively
requires greenfield design. The definition he put together does not
require exotic new materials or breakthrough manufacturing techniques from what
has been available in the past. I would very much like to see someone
bring in a legacy design that was done for an initial system release at a lower
speed, but at the time the system specifically took on the objective of
designing for a future upgrade to 10Gbps. There are systems that have
done this, where they have used generally recognized high frequency design
techniques, made reasonable assumptions on where the signaling technology would
be, analyzed their system to those assumptions, and are now well positioned to
meet their objectives. If system vendors were to bring those designs in
and recommend potential ! changes to the channel model to consider limitations
we may have missed then I would be very willing to look at changing the model. What
I don't think should be brought to the group is someone's Johnny on the spot 1G
or 3G design that was never engineered with the intent of upgrading to 10G. If
in the past Vendor A took on some additional system cost and took additional
time to market to properly engineer their system for future upgrade, and Vendor
B went for lowest cost and forego engineering for the future in order to rush
their product out the door then I don't think we should be penalizing Vendor A
with additional power and silicon area in order to service Vendor B. That's
not to say either vendor made a bad initial business decision or that Vendor B
is now out in the cold. There will always be chip vendors who are willing
to provide more advanced technologies to service these problem systems. It's
simply a matter of Vendor B taking the eas! y road initially and now it's time
to pay the piper. Of even mor e significance than penalizing hypothetical
Vendor A is the fact that we'd be penalizing all vendors going forward who plan
to properly engineer their systems for 10G - and power is critical for all
these vendors that I know of.
Thanks, Joe
Joe Abler
abler@us.ibm.com
IBM Microelectronics Division
919-254-0573
Technical Marketing & HSS Applications 919-254-9616 (fax)
3039 Cornwallis Road
Research Triangle Park, NC 27709
|
|
"Booth, Bradley"
<bradley.booth@INTEL.COM>
Sent
by: owner-stds-802-3-blade@listserv.ieee.org
10/14/2004 01:35 AM
Please
respond to "Booth, Bradley"
|
To: STDS-802-3-BLADE@listserv.ieee.org
cc:
Subject: Re: [BP] Question
regarding Channels
|
Joe,
I wanted to touch on the following statement you made:
Note
that when I use the term "line," I'm using it figuratively to refer
to channels that fall within all aspects of the channel adhocs definition of a
compliant channel. I'm not solely referring to the SDD21 line.
This is the area that I think is the heart of the problem.
Where does that line exist? What makes a channel compliant?
Compliant with a signaling approach? Compliant with an installed
base? These questions are rhetorical. I know that everyone is
likely to have a different point of view of what the line is for being
compliant. How can the TF get to 75% consensus while satisfying the
Objectives and 5 Criteria? (Again, another rhetorical question.) :-)
Thanks,
Brad
From: owner-stds-802-3-blade@listserv.ieee.org
[mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Joe M Abler
Sent: Wednesday, October 13, 2004 12:03 PM
To: STDS-802-3-BLADE@listserv.ieee.org
Subject: [BP] Question regarding Channels
Let me finally add my views on the subject. I haven't been purposefully
silent, just swamped lately.
So we have this great debate about channels above the line and those below. Assuming
everyone agrees we evaluate all the channels above the line, let's look at the
reason for also considering those below the line. The primary reason is
to assess that the signaling methodology has sufficient margin for the given
channel definition. We must do that, but I would claim the starting point
for that is not with use of channels below the line. The standard is
likely to be defined for a BER of e-12, but most system vendors have a
backplane requirement of e-17 or better. We should start by evaluating
that the signaling approach has this amount of margin or some other agreed to
metric (the performance criteria) for channels above the line . That's
still only a starting point. I'm much more concerned about potential
channels that have severe discontinuities that may all be fully above the
defined line, along wi! th xtalk, return loss and other c! haracteristics that
are also within the compliant definition. Any of the signaling
methodologies we're looking at could well have a problem with some potential
killer channels before they have problems with some of the rather well behaved
channels below the line (like several of John's). We need participants to
bring in these potential killer channels as part of validating that we have a
robust signaling methodology as well as a comprehensive channel definition. Anyone
that has a view that looking at channels below the line is a comprehensive way
of evaluating margin is kidding themselves. The well behaved ones
somewhat below the line won't show problems, while the ugly ones well below the
line will simply be dismissed because they're well below the line.
I don't have a problem per se with including channels below the line in our
simulation and analysis, and certainly agree we need to do some of it. However
I believe the group has various views as to what it means to include channels
into the signaling adhoc evaluation. In my view, the group should first
evaluate the signaling methodology for channels above the line against it's
metrics. I expect many in the group believe we should look at some
channels below the line for margin purposes, a view I would agree with. I
also believe some in the group have the view that all channels which are
accepted into the signaling ad-hoc need to be solutioned. I don't agree
with this. Solutioning channels well below the line penalizes those above
the line in terms of power, area, complexity (time to market risk), etc. Issues
with definition of where the channel line is drawn need to be dealt within the
channel adho! c, not the signaling. So if! we're going to include these
channels into the evaluation set, we need to get the group in sync as to how
they are used relative to the analysis of the signaling methodology. Options
I see are:
1.
Properly margin the analysis of channels above the
line, and don't consider any channels below the line.
2.
Make the channels below the line available but leave
it optional as to whether a vendor includes them in their simulation set or
not. Results from these channels would only be used if there is a
tie-breaker need of results from channels above the line. I think the
group is self-policing enough that all vendors will bring in results for a
reasonable set of these channels, but no one would be discounted for not doing
all of them because the simulation and analysis does take a considerable amount
of time.
3.
Select a set of channels that are within a
reasonable deviation from the line and require they be used as part of the
evaluation set in order to show margin. The problem with this approach is
that it requires us to draw another line. Need I remind anyone that we
haven't succeeded in drawing a first line yet?
4.
Require that all channels be used in the evaluation,
but somehow weight the results of ones below the line such that they won't
overly influence the evaluation and lead to a methodology that is way
overdesigned to the objectives and therefore penalizes systems with additional
power, area, cost, and risk. To propose a specific mechanism to do this
we'd first need to complete the work of defining the base evaluation metrics. I
believe we'd also need to do #3 because I expect some channels would be
weighted differently than others. Needless to say, this would be a
difficult and cumbersome approach.
5.
Require that all channels be used in the evaluation,
and require that a signaling methodology be identified (or perhaps invented)
that would adequately solution all channels.
My preference is option 2. I'm deadset against option 5. Note that
when I use the term "line," I'm using it figuratively to refer to
channels that fall within all aspects of the channel adhocs definition of a
compliant channel. I'm not solely referring to the SDD21 line.
Thanks, Joe
Joe Abler
abler@us.ibm.com
IBM Microelectronics Division
919-254-0573
Technical Marketing & HSS Applications 919-254-9616 (fax)
3039 Cornwallis Road
Research Triangle Park, NC 27709