Re: [10GBASE-CX4] Working Paper Available on IEEE site
Howard, Steve
> 4. Should the receiver level and jitter even be specified?
> The reason not to is: (1) If the xmt is specified, and if
> the channel is specified, then the signal at the receiver
> is already determined, no further specs needed on rcv,
> and (2) By specifying the receiver, doesn't this preclude
> equalization in the cable itself if someone chooses to do
> that?
Instead, I believe, the RX and the Channel should be specified (with TX
implied). Current XAUI specs have RX sensitivity and jitter tolerance
numbers. This implies that the burden is on the TX to deliver a "clean" eye
at the RX. At the Roseville meeting, general consensus was that we should
go with TX de-emphasis. This is similar to most current implementations of
XAUI; ie. burden is on the TX to deliver a clean eye at the RX. If we
specify the channel along with RX sensitivity and jitter tolerance, vendors
would be free to choose the method of de-emphasis that they like.
Given this, I would say, 54.7.3.6 should be removed. The 800mV should be
clarified as the base min amplitude (with lower amplitude allowed for
de-emphasis). This, along with channel spec and RX specs, is sufficient and
not too restrictive.
Also, plugging 800mV into the equation at 1.56GHz results in an output
amplitude of 86mV. Therefore, it is inconsistent with the 100mV number. I
believe, we should squeeze some juice out of all the possible places - 1)
TX, 2) RX and 3) cable - to reach the happy medium. The worst case cable
looks fairly lossy. It seems that there is some room to improve the cable
specs.
Regards
Kamal
===============================
KAMAL DALMIA
Technical Marketing Manager
Marvell Semiconductor
700 First Av.
Sunnyvale, CA 94089
Phone: (408) 222 8979
===============================
"Howard A. Baumer"
<hbaumer@broadcom.com> To: stds-802-3-10GBCX4@ieee.org
Sent by: cc:
owner-stds-802-3-10gbcx4@majordo Subject: Re: [10GBASE-CX4] Working Paper Available on IEEE site
mo.ieee.org
01/02/2003 09:14 AM
Steve,
See responses below deliniated with <HAB>
Howard
"Dreyer, Steve" wrote:
>
> Howard,
>
> Took a quick look at the proposed draft and have the following
> top level comments:
>
> 1. The min xmt amplitude of 800mV is probably not doable on a
> chip with 1.2V only supply when all worst case conditions are
> considered, it probably needs to be dropped another 50mV
> or so. I plan to have a quick presentation showing
> this next week. For reference, the min XAUI level is
> a lot lower than 800mV using the far end method.
<HAB>
The 800mVpp is for a differential signal so that is only a
400mV single
ended swing at the driver output, this is attainable with a 1.2V
supply. Also the 800mVpp min is not the minimum the driver puts out, it
is the minimum for the lower limit of the peak in the transmit output
template you reference in #3 below. This will have to be clearified in
the text.
<HAB>
>
> 2. Given a 800mV min xmt level, worst case cable model, and
> all other worst case conditions, the input to the receiver
> will probably be less than 100mV spec. We are trying to
> complete some simulations to prove or disprove for
> next week mtg, but others should also take a look at this.
<HAB>
All the current numbers, at this time, are to solicit this
type of
feedback. we anxiously await the presentations that will clearify and
make our specifications consistant.
<HAB>
>
> 3. There is a xmt template specified for the long pulse.
> Shouldn't there be one for the short pulse as well to
> guarantee ineroability?
<HAB>
All the through information about an output drive is contained
in its
step response (i.e. its long pulse) therefore a short pulse template is
redundant and not needed
<HAB>
>
> 4. Should the receiver level and jitter even be specified?
> The reason not to is: (1) If the xmt is specified, and if
> the channel is specified, then the signal at the receiver
> is already determined, no further specs needed on rcv,
> and (2) By specifying the receiver, doesn't this preclude
> equalization in the cable itself if someone chooses to do
> that?
<HAB>
I agree with you here 100%. The receiver specification can be
reduced
to just section "54.7.4.1 Bit error ratio".
<HAB>
>
> 5. I thought it was agreed at last meeting that Chris D cable model
> was going to be the worst case. But the worst case model in
> section 54.8.2 is Chris D model with an additional 10%.
> This seems more worse case than before, what is rationale?
<HAB>
The intent of the statement "The cable assembly insertion loss
shall
not deviate by more than 10% from equation 54.3" was meant to mean that
if you were to plot the cable loss and fit the equation:
a*sqrt(f)+b*f+c/sqrt(f)+d to the data then the data points would be
within 10% of this model. I know this wasn't that clear, I just wanted
to pointout that we need some limit on what acable transfer function can
be.
Maybe we don't limit it, maybe we do. If we don't limit it
the some
passive equalization can be put into the cable and still be compliant.
If a receiver has some fixed equalization it too can be be compliant but
when these are brought together the system might not work. We need to
make sure this won't happen.
<HAB>
>
> 6. Should cable model include phase vs frequency response?
<HAB>
Yes it should as well as the return loss, NEXT and FEXT.
<HAB>
>
> 7. For signal detect, it seems that a single noise pulse >100mV
> would cause a signal detect OK condition. It may be useful to
> have an algorithm with improved noise rejection.
<HAB>
If you look at other Signal detect functions in 802.3 you'll
find this
same issue. The purpose is not to detect a signal but rather to detect
that there is no signal. The name is misleading so pay very cloase
attention to the wording and you'll see it actually describes detecting
the absense of the signal.
<HAB>
>
> Good first draft!
>
> Steve
<HAB> Thanks