|
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
-
Mike A calls for group to now consider how to include
xtalk (random vs deterministic).
-
Adam H. asks for clarification on how to include xtalk
both deterministically and randomly at the same time.
-
Mike A also asks for suggestions to this point.
-
Vivek responds that the two are not mixed, but rather
there is a deterministic simulation and a random simulation.
-
Mike A. This is not evident from
the meeting minutes. Are you proposing two simulations both as deterministic
and as random?
-
John S. asks Vivek to clarify the 2 simulations.
-
Vivek replied that deterministic means that the source of
the xtalk is a data signal that is similar to the through channels signal.
Ransdom means using white Gaussian noise that has been spectrally shaped to
match the real data . 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. asked if Stat-eye does random and
deterministic.
-
Brian V. said he thought it had deterministic and random
components.
-
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
-
Rich M. asked how the randomness was handled.
-
Bryan V. was not sure
-
Mike A. then asked what the input was for the xtalk in
stat-eye. He then generalized this to ask for a volunteer to find out
exactly how stat-eye handles xtalk. Bryan V. volunteered to check on this.
-
Bryan V and Mike L. both answered that stat-eye does not
differentiate between next and FEXT, it is all just xtalk.
-
John S. asked Vivek why shaped white noise is different
than the deterministic case.
-
Vivek replied that the the deterministic xtalk source is
cyclo-stationary while the white source is stationary. He went on to say
that the white noise case modeled many sources passing through the xtalk
channel.
-
Mike A. asked how scaling works in this case.
-
Vivek replied that the filtered white source is scaled to
have the same power as the normal input signal.
-
Mike A then asked the rest of the group if everyone
thought that last weeks straw polls use of random and deterministic meant
running the 2 sims as Vivek described them. (A couple of yes's but mostly
silence).
-
Mike A. then asks Vivek to put together a presentation
outlining the two approaches so that we can have a straw poll on their use.
-
Vivek agrees to do this and asks if it will be for the ad
hoc at the next plenary meeting.
-
Mike A. indicated that he was not planning on having an
ad hoc at the next meeting and suggested placing the presentation on the
reflector for discussion. He then asked if having an ad hoc during the
plenary made sense.
-
Adam H. indicated that there was probably no available
time during the plenary since the evenings were already filled. Possible
that there may be time for breakout sessions if the presentation schedule is
light.
-
Mike A. then decided that handling via the reflector was
the proper course of action and offered to help Vivek put the material
togeher.
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.
|