Slides for meeting in: http://www.ieee802.org/3/ap/public/signal_adhoc/altmann_s2_1204.pdf

Updated signaling spreadsheet in: http://www.ieee802.org/3/ap/public/signal_adhoc/table_v4p1_1204.xls

Slide 3:    Simulation results by 19 January.
Slide 4:  Proposal-driven process
Slide 5: Channel Simulation
Spreadsheet is version 4.2 and posted.
Slide 6:    Grayed out text are already-discussed items
Discussion picks up from slide 9

Slide 9:    Do we want to spec CDR characteristics?

Moore: I thought we were going to report the horizontal eye opening and leave it at that.
Petri:  CDR jitter is not relevant.
Abler:    Jitter varies amongst signaling types.  Multi-level signaling has a compressed jitter budget.
Mellitz:    Jitter can be traded off against other parameters.
Abler:    Even if people use different values, I want to know what they are using.
Abler:    You need to assume that there is a worst case Tx hooked to your Rx.
Altmann:    Do we need to account separately for the Rx jitter?  Or can we roll it all into the Tx?  If we do, we'd need to make the parameter value large enough.
Petri:    We need to account for the .35 Tx jitter.  The channel jitter will occur too.  The CDR jitter is irrelevant.  You can assume zero RJ in the Rx.
Brunn:    We seem to be flip flopping between measures of merit... BER, voltage margin, etc.
Abler:    This all factors into power.  1ps RJ versus 1/2ps RJ are significantly different power requirements.
Altmann:    Doesn't that make it complicated?
Abler:    Yes, it's complicated.
Altmann:    I'd like to see things compared on equal footing, so we can get rid of one source of variation.  What number would you have?
Abler:    The numbers would be similar to those of the Tx.
Altmann:    Straw poll 1:    Should we require a specific amount of Rx-allocated jitter?
???:    Would this be added to the jitter tolerance?
Altmann:    This would be subtracted

 

Straw poll 1: Should we require a specific amount of Rx-allocated jitter (RJ and DJ)?

            Yes: 12             No: 5                 Abstained: 3

Eye sampling point discussions.
Brunn:    Designer has to select either the horizontal center or the vertical center.  He can't
VonH:    What about the Rx equalizers, where the Rx eq is doing a good job?
Altmann:    It would have to be after the Rx eq.  The designer may have to specify his equalizer, but as Joe said earlier, it would get reflected in the power number.
Altmann:    The best case point may be different from channel to channel.
VonH:    People may have to specify a sampling point selection circuit.
???:    How about having an eye mask?
Altmann:    Eye mask may be too simple.
Abler:    ...and we said that we were going to sample at 3 different BER points.
Altmann:    Are the results going to change much if we say we're going to use
Moore:    We are going to have some very asymmetrical eyes with the duobinary.  I propose we put the largest symmetric diamond you can put in the eye.
Brunn:    You still have to decide whether your diamond is bounded by the horizontal or the vertical.  Report your diamond... is it horizontally centered or vertically centered.  You can't report the best of both worlds.
Altmann:    So a symmetric diamond could be put in an asymmetric eye, and it would change from channel to channel.
Mellitz:    You could put many different diamond shapes into a particular eye.
VonH:    Optimal size would drive to symmetric diamond.
Altmann:    The diamond may be off centered.
VonH:    We can assume that the SerDes can do a good job of finding the center.
Seemann:     Until we apply a cost function to horizontal versus vertical sample placement, the shape of the diamond is meaningless.
Brunn:    But if you had an asymmetrical kite eye, there are still only two pathological cases: Max width or max height.
Altmann:  Is the sym diamond the generally agreed?
Abler:    I do not want to re-write my programs to find
How do we want to fix our timing and voltage margin sampling point?
Altmann:    So there are three alternatives we have discussed:
1. Maximized symmetric diamond
2. Optimized:  pick sampling at a single point, 2X the nearest height & 2X the nearest width centered either at horizontal middle or vertical middle
3. Centered:    Centered in the middle of the UI:  Middle of vertical: then 2X nearest height & 2X nearest width
Mellitz:    Do we assume that everyone will do an equal job of actually finding the middle of that eye.

Straw poll 2: How do we want to fix our timing and voltage margin sampling point?

            Maximized*:    4     (*maximized symmetric diamond)

            Optimized:     12

            Centered:        0

            Abstained:       0

Do we want to normalize the eye size to the transmit levels?
Mellitz:    Two simulators need to produce the same results for the same situation.  What is going to get us to that?
Sinski:    You don't want to have one method have an advantage over another because of gain assumptions.
Altmann:    Not sure we are going to get far on this today.  But it needs to be dealt with.
Moore:    Proposal:  Define the gain as the ratio of the Rx input to the Rx output to a 101010

Straw poll 3: Should we normalize the overall path gain?

            Yes: 1             No: 7                 Abstained: 8

Should we report settled equalizer tap values?
Abler:    Define "settled"
Altmann:    ...what the tap values settle to.
Abler:    Consider how we set tap values to be proprietary info.  And don't see what this group is going to used.
VonH:    Maximum values used have significant impact on performance.  Specifically, if you drive off the road with DFE, the size of your taps can have a significant effect.
Sinsky:    And the power can be important too.
????:    If you use BER as a prime indicator, this can have a significant effect.  Why would we report this?
Sinsky:    Different signaling schemes will require different tap values.

Straw poll 4: Do we report settled tap values?

            Yes: 0             No: 9                 Abstained: 5

VonH:    OIF found that the maximum tap value needed to be limited in order to ensure stability.
Altmann:    I encourage a presentation on this, but we need to move on.

Power reporting discussion
Abler:    I don't want to have to report my specific powers, because I consider it proprietary.
VonH:    To keep it from turning into a marketing presentation, we need to make some basic architectural assumptions and assemble the power numbers.
Altmann:    I find it unlikely that people would supply that level of detail.
Mandich:    Power was supplied in OIF.
Kundu:    Let's see what can be provided.  We certainly need a per-serial-link power number.
Altmann:    Do we want to have the power line in the spreadsheet?  Whether someone puts the number in is their decision.
Abler:    How are you going to get reasonable comparison across the vendors?  You are going to get a bunch of numbers that are meaningless.
Lerer:    We are not qualifying parts, we are selecting a signaling method.
Kundu:    I need to know whether I can cool a particular chip.
Abler:    The spreadsheet asks for relative powers of the key building blocks.  It gets around the competitive info and give a balanced comparison.
Altmann:    But that's a complexity question.
Abler:    But complexity drives power.
Altmann:    But so does implementation.

Straw poll 5: Do we report highest, typical and lowest power across all channels?

            Yes: 7             No: 3                 Abstained: 5

Holes in our link elements.
Altmann:    Should we model a real capacitor?  Do we use an idealized cap model?  Is there any real loss of precision using a simplified cap?
Mellitz:    The mounting of the cap can be significant, if not larger than the cap itself.
Abler:    Would like to see someone's model, or just exclude it.  If we don't have it, we can still compare signaling.
VonH:    It may have different effects for different signaling schemes.
Mellitz:    Not sure this is that pertinent.  Some channels are so severe, I don't think this will be the deciding factor.
VonH:    In the lab, caps have substantial effect.  BER ratios of 6 orders of magnitude.
Sinsky:    Lots of caps that will work.  Resonances can be moved around.  So question becomes:  Are you going to tell people what size cap they use?
Seemann:    We voted in the Channel Ad Hoc to allow silicon vendors to not have to use the cap if their silicon didn't need it.
Altmann:    If caps are transparent, why do they matter?
Sinsky:    Transparent means they are (ETC540L) well-designed.  Broadband cap technology has evolved over the last 5 years.

Altmann: Te choices seem to be one of the following:
Freq dependent model
Ideal cap
Nothing
Report what you used

Straw poll 6 : Capacitor use for simulations

        Freq-Dependent Model:        7

        Ideal Capacitor:                    3

        Nothing:                                5

        Open, but must be reported: 6

Shannon Sawyer will post real data for a real cap with 3 different cap sizes.

Discussion on need/timing of next signaling ad hoc.  Likely date is 14 Jan'04

Meeting adjourned