Re: [BP] Question regarding Channels
Justin,
Case 1 ripples below the channel model. Part of real channels to have
ripple.
Cases 2 and 3 are below the line because of choice of line card materials.
Case 6 goes below the channel because of stub effect.
Case 7 goes below the channel at high frequencies due to ripple effect of
stub.
This was never an issue in my mind. We knew why they were going below the
model.
John
-----Original Message-----
From: owner-stds-802-3-blade@listserv.ieee.org
[mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Justin
Gaither
Sent: Wednesday, October 06, 2004 6:36 PM
To: STDS-802-3-BLADE@listserv.ieee.org
Subject: Re: [BP] Question regarding Channels
Group,
I tend to agree with Joel on Point one and Point three. I also feel
that margin is an implementation issue. We need to draw a line in the
sand for a channel model. We need to simulate as much as we can with
data that falls within the current model and outside the model to prove
that the channel model is robust.
This however has nothing todo with the signaling adhoc. It is a Channel
Model ad hoc issue.
I objected using the data outside the model as criteria to choose a
signaling method; because until we understand why these channels are
outside the bounds and if we want to allow these types of affects to
occur in our channels it could unfairly bias the signaling selection
criteria.
Regards,
justin
Joel Goergen wrote:
> 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
> -----------------------------------------------------
--
Justin Gaither Phone: (512)634-1305
Xilinx, Communications Technology Div. Cell: (512)585-5659
805 Las Cimas Parkway Fax: 512-306-7293
Suite 250 email: justin.gaither@xilinx.com
Austin, TX 78746 WWW: www.xilinx.com