Re: [10GBASE-CX4] Working Paper Available on IEEE site
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