Re: [BP] Question regarding Channels

["DAmbrosia, John F" <john.dambrosia@xxxxxxxxxxxxxxxxxxx>]

Joel,

From my perspective, it would be nice if it works across ATCA, and there are a lot of people and companies that want to see it happen.

 

My use of the ATCA backplane was simple - people have faulted channel efforts in the past that I have done, because they are not real system backplanes.  Using the ATCA backplanes allows me to avert that criticism.  I do agree with Brad in the sense that having a standard configuration allows us to have some definition which helps.  This is a very difficult area, one which you attempted to do by making a connector-less board, and now have some criticisms aimed at you for a similar criticism as what I have dealt with. 

 

One thing that is very clear is that implementation can still make a very big difference between test data regardless of whether it is an ATCA channel or not, and I agree totally with that.  That is why you get paid the big bucks, right?  J

 

I still hate the use of the word "legacy."  I believe the industry does want to us at least consider if we can come up with a solution that would address the stub effect, as this could potentially help a lot of existing backplanes out there.  Even with counterboring, you might still have some stub effect, depending on how you implement it in your system.  These are the kind of effects that would happen in Cases 6 and 7 that I provided.  Hell, Case 7 meets the channel model out to 11.5 GHz and was still a very challenging channel to get working.  Case 6 is minor compared to some of the stubs that we both know are out there.  If we can't make Case #6 work, then others will be even less likely.  However, some testing (real and simulation) has shown that some channels with these stubs can be made to work.  There will be a trade off, as you pointed out, and I believe that those facts should come out of the analysis, and then that influences the decision process.

 

John

 

-----Original Message-----
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 7: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 backplanes 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]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 backplanes (primarily ATCA which would support the Broad Market Potential requirement), but the reach on those backplanes 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