Re: [BP] EIT Fun
john,
Sounds like we have basic agreement if not full agreement on degree
and details. Do keep in mind that when all the simulations are done
they will not give exactly the same results and we will have to get
together and determine, somewhat subjectively, what actual value to use
for EITbase or equivalent. Simulations which the majority feel
represent more realistic cases will get more weight and if we feel that
the simulations are not stringent enough, we may add margin, or back off
if we think that the simulations pile on too much.
charles
DAmbrosia, John F wrote:
>Charles,
>After long thought and discussion, I will concur some of your points and
>hold my ground on others.
>
>1. First, I disagree with your statement that any channel next to any
>channel can be assumed to have any voltage. The Tx voltage that will be
>launched will be what is needed for that channel. Too much or too
>little can be bad. Across the system your assessment is correct.
>
>If we are going to assume worst case, then I suggest that not only do we
>use the maximum amplitude, but the maximum amplitude with no
>equalization, i.e. square wave. This may be understood but has not been
>explicitly stated.
>
>2. Synthesized test cases can have value, I agree, but more times than
>not I have seen them mis-used, especially as I have pointed out for
>crosstalk. As far as transceivers working on unrealistic channels,
>while there is an informative channel model that will help to limit
>these, the sad truth is that you, as an ASIC vendor are correct about
>expectations.
>
>3. The specification itself does allow for a certain level of control of
>the Tx amplitude. This will be bounded by the limitations of that
>device. It would seem to me that it is fair to expect that a Rx could
>request that the Tx lower its maximum voltage, but not to expect it to
>be able to output more than it is capable of providing.
>
>I recognize that what is being proposed is a worst case scenario that
>does not really take intelligent design into consideration. Different
>scenarios will exist for full mesh versus dual star fabrics; for a dual
>star architecture driving from the line card to the fabric will probably
>have different constraints than driving from the fabric to the line
>card. Different devices, different line cards, etc will make this very
>challenging, and the specification does not allow for any communication
>short of link failures to start re-training. Thinking about how we
>would even do something like that makes me think of battleship.
>
>I have to think further on some things, but in general - will have to go
>along with what Howard is proposing (plus my suggestion that we use max
>amplitude with no equalization); and think further about my concerns
>with "Frankenstein" channels.
>
>John
>
>-----Original Message-----
>From: Charles Moore [mailto:charles.moore@avagotech.com]
>Sent: Monday, March 20, 2006 8:15 PM
>To: DAmbrosia, John F
>Cc: STDS-802-3-BLADE@listserv.ieee.org
>Subject: Re: [BP] EIT Fun
>
>john,
>
>You bring up some important points and i would like to give my take on
>them:
>
>1. (first) Usually a range of allowable amplitudes are specified for a
>transmitter to allow for normal variations in manufacturing and
>operating conditions. In additions, if the manufacturer who has good
>control may want to use some of that range to enhance his
>specifications, for instance power consumption or ability to blast
>through marginal channels. All in all this means that we can count on
>any particular amplitude for any transmitter and if we want to be
>conscientious we should assume the worst case: min spec amplitude for
>the thru channel and max for all aggressors.
>
>2. Synthesized test cases have value: they better represent the
>boundaries of the channel specs than real channels can at any reasonable
>
>cost. You complain that they are un-realistic but i have customers
>demanding that my Transceivers work on channels which look pretty
>un-real to me and i expect that this tendency will continue in the
>future. If there is really a useful relationship between thru and xtalk,
>
>beyond ICR, which all "reasonable" channel will have, lets add it to the
>
>channel spec.
>
>3.
>
>4. I think howard covered this pretty well
>
>5. Again you assume a control over Tx amplitude which probably will not
>exit.
>
>
>charles
>
>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
>>
>>
>>
>>
>
>
>