Re: [BP] EIT Fun
John,
Yea, to bad you were sick when the initial thread from my email started,
oh well let's go through this again.
First I didn't ask to dump the initial simulation condition set that
Charles published. I saw one item not spelled out, transition time, and
asked what everyone thought about using 42ps at the output of the
package model. Didn't see any objections to this. Second I asked if
other doing simulations would join in and do a more worse case example
per the current draft giving the conditions that we are going to use for
this second simulation set. Why ask for this? Because it is a real
scenario. How is it a real scenario?
1) The transmitter for each link gets tuned independantly from any and
all other links, including the paired receiver that it more than likely
shares silicon with.
2) A given transmitter cannot be guaranteed it will be tuned when any
others are being tuned, except for its far end transmitter who's
receiver it shares Si with.
3) A receiver has no clue what its link partner's transmitter output
level is being set to. It only knows that when its link partner's
transmitter is told to go to the preset condition that its Vpk is at
least 800mVpp, but it could be as high as 1200mVpp.
4) A receiver aslo has no clue what algorithm any other receiver has
used to set its LP transmitter.
5) A receiver does not have to have its LP transmitter start for the
preset state, it could have it start from the initialize state, which
has no Vpk limit on it other than Vpk can't be greater than 1200mVpp.
6) A valid transceiver implementation is one where the receiver wants
its LP transmitter to have the highest possible amplitude with no
equalizaiton leaving all equallization to be done by the reciever.
7) Another valid transceiver implementation is where the receiver wants
its LP transmitter to minimize its output amplitude and maximize its
equalization leaving the final gain and minimal equalization to be done
by the receiver.
For all these reasons one receiver will not know, cannot know, what
state any other link settles to and can't know what Vpk is coming out of
its LP transmitter. Therefore it is possible to hit the extremes of the
draft. Also the starting transmitt level will not be the same for each
link, thereby causing different transmit levels for the victum and the
crosstalk aggressors. Setting them to the same value for simulations is
fine and will show us a middle ground for opperational entitlement.
Howard
DAmbrosia, John F wrote:
> All,
>
> Wow, you get sick for a few days and stay offline and you get to miss
> all of the fun!
>
> I will try to go through all of the email and comment –
>
> Howard’s initial email suggested using 800mv for the Tx amplitude of
> the victim and 1200mV for the aggressors. I disagree with this for
> several reasons.
>
> First, per the continuing discussions we have had
> regarding the Tx amplitude, it was agreed that 800mV was
> the “minimum” maximum that could be counted on from
> devices. The suggestion to use 1200mV for aggressors
> suggests that a higher launch amplitude is available.
> Being able to boost the launch amplitude of the victim
> would most certainly help.
>
> Second, I have long been against these “synthesized” test
> cases as they fail to take into account the realities of
> channel synergy. This is especially true for xtalk
> aggressors. Take for example the use of Tyco Case #7. Tyco
> Case#7 is a 13” total length channel (6”LC +1”BP +6” LC).
> So why would this be used as a noise source for a longer
> channel at 1200mV? In terms of FEXT there is already an
> approximate 8 to 10 dB difference at Nyquist. This is then
> being exasperated by increasing the Tx amplitude to its
> maximum (where others have already said that is where they
> would expect the Tx amplitude to be lower. Also, because
> of the shorter distance you have significant ringing over
> a large number of bits that just doesn’t exist in a long
> channel FEXT aggressor.
>
> Third, Rich suggested Next should be the same as victim
> and Fext should be higher. If we were looking for the real
> world worst case scenario, I would expect that the NEXT
> would be different than the victim, as it is originating
> from a different device, and that for FEXT it would be
> dependent on the link being looked at. For FEXT signals at
> the line card I would expect the amplitude of the
> aggressors to probably be the same as the victim, while
> for victims at the switch, the launch amplitude would be
> dependent on whether the signals are originating from the
> same line card or not. However, from the switches we were
> looking at in this study, we saw that neighboring channels
> were similar to the victim channels. (Typically we saw the
> blocks at the switch go from extreme to the other, not
> intermixed). This is not to say that all designs are done
> intelligently, however.
>
> Fourth, I don’t believe we can arbitrarily assign a
> maximum amplitude to a channel. If the receiver needs it,
> it will request that of the Tx. This goes back to my point
> about Tyco Case #7 again. I doubt the forward channel
> response of this channel would require the Tx output
> amplitude to be at maximum output voltage. The amplitude
> that is appropriate is dependent on the needs of that
> specific channel.
>
> Lastly, Pat raises an interesting point – “In the past
> standards I've worked on, we have usually assumed that
> implementations could be running at the limits because we
> don't have a basis for assuming a distribution.” We have
> been judging channels to be working, based on simulation
> results that assumed a max Tx amplitude of 800mV for the
> victim and aggressor. So if a channel needs 1200mV to
> work, but the subsequent crosstalk causes a neighboring
> channel that worked based on 800mV launched amplitudes to
> now fail – which channel is actually the problem? I would
> have to point to the 1200mV channel, as receivers are
> tested to a normative Tx max peak to peak amplitude of
> 800mV in the EIT test.
>
> My two cents.
>
> John
>
>
>
> Cheers!
>
> John D'Ambrosia
>
> Architect, Ethernet EcoSystem
>
> Business Development, Global CC&CE
>
> Tyco Electronics
>
> Tel 717.986.5692
>
> Fax 717.592.2470
>
> Cell 717.979.9679
>
> Email - john.dambrosia@tycoelectronics.com
>
>