|
Meeting notes for IEEE signaling ad hoc call 5 November
2004.
Chair: Mike Altmann
Secretary: John Stonick
Mike A. opened the meeting and requested a volunteer for
secretary. John Stonick volunteered to act as secretary of meeting.
Presentation material found in:
http://www.ieee802.org/3/ap/public/signal_adhoc/altmann_s1_1104.pdf
http://www.ieee802.org/3/ap/public/signal_adhoc/stonick_s1_1104.pdf
Mike A. started meeting off by
discussion agenda for the meeting which involved dealing with item 2 on page 2
of his slides, definition of aggressors. He also brought up item 3 on slide 2
which deals with sources of impairment that are outside the scope of the channel
ad hoc committee: AC coupling caps, package modeling and anything else between
TP4 and TP5. He requested input, but none was forthcoming
Mike A. then went on to discuss
the fact that we would need to revisit the straw polls of last week since they
seemed to be somewhat contradictory
John S. gave his presentation on
scaling Xtalk to the Xtalk mask. Discussion followed both during and after
the presentation.
-
Charles M. offered suggestion of taking the scaling of
the xtalk further and find scaling factor for xtalk that "breaks" the system
Breaking determined to mean not meeting the BER criterion.
-
John D. offered support indicating the xtalk mask was
something that needed to be validated. Proposed scaling methodology offers
this.
-
Mike A. raised question as to whether we were punishing
channels by scaling xtalk.
-
John S. replied that we are, but that it is necessary
since channels with xtalk up to the scaled level are "legal" and system
vendors need to know if they can
design to that level
-
Charles M. noted that in some instances we may have to
scale the xtalk down.
-
Mike A. noted results from scaling were interesting in
general but asked if useful (helpful) in selecting a signaling methodology.
-
John S. answered yes it is useful since the availabe
margin left when the xtalk is at the mask level is what needs to be
compared.
-
Richard M. raised question of how to include xtalk into
simulation. Concern over phasing to guarantee worst case.
-
John S. proposed running each xtalk source asynch to
itself and to the victim.
-
Vivek proposed pushing the S21 of the through channel
down to the mask along with the xtalk scaling. He indicated this was done in
twisted pair sims. It is better to use measured data instead of masks,
because of the simulation ease. Prefer a worst-case number
-
John S. To clarify : scale both the S21
and Xtalk to the masks
-
Fulvio voiced concern that:1. Scaling the S21 was
fundamentally changing the channels. 2. You could create degenerate cases,
and also noted that this is similar to simulating with a synthesized channel
and use the mask limits. This loses sight of the relationship between the
losses and Xtalk
-
Vivek T. Aren't we trying to get to a w/c
simulation?
-
Mike A. asked Vivek how to scale through S21
-
Vivek said that he changed his mind on the scaling. He
said that twisted pair was not a good parallel to draw from since in twisted
pair length is a variable. Here we are using a given set of channels. He
retracted his suggestion, but left it out there as food for thought.
-
Mike A asked if there were any more questions.
-
John D. asked what happens to phase during scaling.
-
John S. replied that scaling is to be done via
multiplying in the time domain by a gain factor and thus does not change
phase. Basically this makes a louder aggressor. We are not changing
the characteristics of the Xtalk itself.
-
Petre P. asked how we can select the alignment of the
phase.
-
John S. said to use asynch xtalk and thus alignment was
not an issue.
- Petre P. said that we need to make sure that simulation was long enough
to make sure that peak alignments happened
- John S. agreed sims need to be long enough
- Petre P. indicated that he had a shorter and safer way to do this
- Mike A. asked if basic scaling was OK
- Petre P. said yes we need to cover worst case noise
- Mike A. proposed 2 straw polls
STRAW POLL #1:
Should we linearly scale NEXT/FEXT to meet the NEXT/FEXT mask as defined by TF?
Yes - 13
No - 4
Abstain - 4 (silent)
STRAW POLL #2:
Should we linearly scale NEXT/FEXT until a given solution breaks (fails to meet
the BER requirements) and report the result?
Yes: 9
No: 6
Abstain: 6 (silent)
After the straw polls followed a discussion on NEXT/FEXT
-
Vivek T. I thought that original
discussion was to have two simulations
-
Mike A. This is not evident from
the meeting minutes. Are you proposing two simulations both as deterministic
and as random?
-
Vivek T. NEXT/FEXT would be as a
transfer function. - deterministic sim data source is real data, same as Tx
OK (10Gb serial with same spectrum). Random simulations would use
white noise shaped to have same spectrum as 10Gb serial. Don't need to
specify Rx phase
-
Charles M. I thought that StatEye used a combination of
statistical and deterministic methods. Is this true, and we should not rule
it out
-
Brian V. StatEye has both
deterministic and random models. Multiple aggressors sum linearly,
-
Mike A. This sounds like a
deterministic treatment. Can someone find this for Charles?
-
Charles M. We were told that statEye uses combination of
deterministic and random methods for NEXT/FEXT handling. This is why I voted
for it
-
Brian V. I will find a response
for Charles' question.
-
John S. Under random noise
excitation why do we not need to worry about phase? Low-pass filtering will
look similar to data, this might need phase alignment
-
Vivek T. Real data signal will be
cyclostationary, and statistics will not be repetitive. White noise will
have flat statistics, PDF will be the same. So a white noise will
representative of multiple aggressors.
-
John S. Forcing the same
spectral components will force the same time relationship
Vivek T. Autocorrelation will not be
the same.
-
Mike A. How do we scale the
random source?
-
Vivek T. Scale the random signals to
have the same total power as Tx signal.
-
Vivek T. I will put together a
proposal on the treatment of these
Mike A. then moved on to the discussion of thermal and
environmental noise. He suggested as outlined on page 3 of his presentation that
the noise from the resistor is 1.3nV/root HZ which yields 90uV in a 5GHz BW. He
suggested using a 12db NF for the receiver which results in a noise of 365uV
over 5GHz at the receiver.
-
Charles M. stated that last week a number of -140dBm
was put forth by someone.
-
Vivek replied that he had put the number forth to cover
thermal and environmental noise. It was not meant for only thermal noise.
-
Mike A. stated that we wants to keep thermal and
environmental separate. There is not opposition.
-
Mike A. then asks if people like his number.
-
Charles M. thinks that 12 dB is too low for the noise
figure for the Rx.
-
Mike A. asks if anyone has measured the noise figure
for a 10G receiver.
-
Charles M. offers that most of the noise is the 1/f
noise from the short
channel devices.
-
Mike A. then offers 24dB as the noise figure.
-
Charles M. agrees that 24dB is suitable.
-
Mike A outlines that 24dB is 4x what he originally
proposed. This yields noise of 4*365uV (=1.46mV) RMS in a 5GHz band. The
(1e-12) pk-pk is 20.44mW
-
Mike A. then moved to consolidate the two straw polls
in his presentation into a single straw poll
STRAW POLL #3:
Should we use a value of 4*365uV (1.46mV)RMS in a 5GHz band as the random,
thermal noise input for our simulations?
Mike A then asked that we make an
effort to wrap up all the remaining noise issues via discussion on the
reflector. Mike then asked Adam if we could straw poll on reflector.
Adam H. replied straw polls are
not binding and are performed to offer guidance and thus it is OK to ballot on
the reflector.
Meeting was adjourned 2 minutes early.
|