Mike Altmann opens the meeting going over the Agenda ( http://ieee802.org/3/ap/public/signal_adhoc/altmann_s1_1204.pdf ) and continues reviewing deadlines and dates agreed upon at the San Antonio plenary meeting and gives an update on the Signaling Spreadsheet (slide #6). Changes to the spreadsheet are outlined on slides #7 and #8 and after reviewing them, Mike introduces a list of proposed straw polls (slide #9, #10) which will be used to finalize the spreadsheet. The floor is opened for discussion.

[Fulvio]              Would it not be better to discuss these changes in the context of the straw polls listed on slides #9 , #10 ?

This is agreed and the discussion begins on the first straw poll : “Should we fix a required data pattern?”

[Joe A.]             We should have at least a common data pattern. This should be a long pattern since the best way to simulate crosstalk is to have long patterns with frequency offsets.

[Mary M.]          Short patterns are misleading …

[Jeff S.]             Spectrum of short patterns is to sparse to effectively evaluate a channel. PRBS15 is a nice compromise in terms of frequency resolution and simulation length

[Charles M.]      When we use the same data sequence to compare NRZ and Duobinary it seems clear what it is that I am doing. The same is not true when we compare PR4 and PAM4. I also would like to specify the pattern before mandating that we need to have a common pattern.

[Mike A]            Maybe we should ask what is the max simulation length that we can deal with. Also should these PRBS sequences be coded or uncoded?

[Charles M.]      I do not think that the encoding is necessary

[Brian]               Do you want to establish BER capabilities ?

[Mike A.]           We have decided to report timing and voltage margin at three different rates. How we compare the BER may have some bearings on the PRBS pattern. My preference is to use short patterns because most of the channel response are limited to 10 to 15 UI. Eye diagrams obtained from simulating longer patterns would not necessarily differ.

Straw poll 1: Should we fix a required data pattern?

 passed by acclamation: (20 people on the call)

The discussion resumes on straw poll #2 : “What forward channel data pattern should we simulate with as a common data pattern?”

[Jeff S.]             is this also the crosstalk pattern?

[Joe A.]             that is my point: simulation length and pattern go together.

[John d'Ambrosia]         did we not specify the aggressors to be the same as the main?

[Fulvio]              no, just the equalization characteristics.

[Joe A.]             … but if you take them to be different then you are saying that the pattern is really no representative. I would like to see the same pattern for the forward path and for crosstalk..

[Mike A. ]          is there any other candidate we want to add to the list of potential patterns?

[Steve A.]          as a data point, ADS takes 30 minutes to simulate a PRBS15 sequence.

Straw poll 2 : What forward channel data pattern should we simulate with as a common data pattern?

            PRBS7: 0             PRBS9: 0             PRBS15: 19                 No Preference: 2

Editor comment: it was requested to include in the minutes  the primitive polynomial associated with PRBS15. This is (15, 1, 0).

The discussion resumes on straw poll #3 : “Do we want to use the same data pattern for crosstalk pattern.”

[?]                    are we going to specify the phase arrangements for how to link the patterns

[Mike A.]         that would still be open. This straw poll is only to assess whether we believe or not that equal patterns should be used as source in all cases.

[John S.]          we are not considering the fact that the 64/66 scrambler will have a very long length which will sufficiently randomize the data sequences.

[Petri]               could we specify the pattern?

[Charles M.]     also, we should ask ourselves whether what we propose helps the simulation accuracy and/or causes bias in the results

[Mary M.]        pathological cases are not going to show up in simulation

[Mike A.]         certainly not

Straw poll 3: Do we want to use the same data pattern for crosstalk pattern?

            Yes: 16             No: 3                 Abstained: 1

The discussion resumes on straw poll #4 : “Should we add RJ and DJ parameters for the Tx output?”

[Fulvio]              How would DJ be defined? Is it defined in the absence of equalization?

[Joe A.]             Worst case DJ and RJ need to be defined. As for DCD (duty cycle distortion) the issue is whether people is going to simulate what is called phase noise amplification.

[Mike A.]           maybe I should have said RJ, DDJ and DCDJ. We shall discuss values for these parameters at next meeting.

Straw poll #4 : “Should we add RJ and DJ and DCD parameters for the Tx output?”

            RJ:              Yes: 19             No: 1                 Abstained: 2

            DJ:              Yes: 18             No: 2                 Abstained: 2

            DCD:           Yes: 16             No: 3                 Abstained: 3

[Mike A.]           I realize I dropped a straw poll. There needs to be a discussion on Rx input parameters (RJ and DJ). What I would like to is see whether we should drop them from the spreadsheet. Is there anybody who feels they should be kept?

[Joe A.]             You will still need RJ and DJ but that is not what you meant.

[Mike A.]           Right.

By acclamation it was agreed to drop the Rx RJ and DJ parameters.

The discussion resumes on straw poll #5 : “Should we require a minimum input-referred offset?”

[Adam H.]         I do not see what offset does for us.

[Fulvio]              agreed

[Brian]               I am the one who requested it and thought this would exacerbate marginal situations

[Mike A.]           I also see a problem in coming up with a number which can vary an order of magnitude depending on assumptions

Straw poll #5 : “Should we require a minimum input-referred offset?” 

            Yes: 3             No: 9                 Abstained: 8

 

[Mike A.]           I would encourage the abstain votes to continue the discussion on the reflector to better clarify their position.

The discussion resumes on straw poll #6 : “Should we require an input-referred environmental noise?”

[Brian]               I do not know what to do about values but system vendors guys need to accommodate interference which we are bound to pick-up.

[Aniruddha K.]   why input referred?

[Mike A.]           for consistency in simulation.

[?]                    is there some intelligent way to represent it?

…. discussion ensues …

Straw poll #6 : “Should we require an input-referred environmental noise?”

            Yes: 9             No: 6                 Abstained: 4

Next meeting will be on December 17, 2004.  It will be extended to three hours to cover the remaining discussion from this meeting plus values for the spreadsheet parameters.