I am posting this as a seed for reflector discussion. We are making great progress on the speed negotiation sequence and I would like to see things worked out for our meeting on September 12th. I believe we have the proposals in place, but we need some significant editing to make sure we cover the details and uncover the holes.

Per our discussion yesterday, there was much concern that the final speed negotiation window completion is not well-defined. I am concerned that this is an area of hardware impact, so we need to consider what is going on and how to make this robust.

How many TRAINDONE primitives should be sent at a time? The present proposal shows 4. It was mentioned that this is an arbitrary number and some suggested that there should be 6. How many are detected to acknowledge that the sequence is actually over? (Remember that this is not OOB bursts.)

The current proposal has two consecutive TRAINDONE sets around a scrambled data payload sent by both PHY's as completing the training sequence. What if the payload received after the first TRAINDONE is corrupt? Can the PHY transmitter switch back to the TRAIN primitive to get additional time since it saw an error in the data and may need additional training? I don't see anything preventing this, but I don't want the option overlooked.

Any other ideas? This window is significantly different from the other speed negotiation windows so let's think it through and share the thoughts so we can all think about them before our next call.

Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809
E-Mail  alvin.cox@seagate.com