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?

• Passed by acclamation: Yes: 18 , no: 0 , abstain: 0

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.

Meeting Attendance