SAS PHY call today (7/6), 10 am CDT
Alvin.Cox at seagate.com
Alvin.Cox at seagate.com
Thu Jul 6 06:07:32 PDT 2006
Formatted message: <A HREF="r0607062_f.htm">HTML-formatted message</A>
Below are the minutes from the 6/29 call. Rob Elliott should be resent
today to have additional discussion on the proposals and the concerns that
have been noted. Due to the holiday week for the US, this posting is late
and participation may be low.
Toll Free Dial in Number: (866) 279-4742
International Access/Caller Paid Dial In Number: (309) 229-0118
PARTICIPANT CODE: 3243413
Topic: SAS-2 PHY WG
Date: Thursday, July 6, 2006
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago)
Meeting number: 826 515 680
Meeting password: 6gbpsSAS
1. SAS-2 PHYSICAL address frame
* Is the frame too big or otherwise unwieldy?
Okay. Standard address frame size.
A concern was voiced that G1 rate must be supported to read the frame.
Some feel this is a mistake for future generations. Page 9 of 05-397r4
illustrates a case where one PHY does not support G1 speeds, however, the
G3 frame requires support of G1 to transfer the payload of the address
frame. This is a contradictory situation. In other words, for the G3
window to work as defined, G1 shall always be supported. This may be a
problem several generations down the road.
An alternative is to keep existing frame structure for each speed
supported and use the final window for training and locking. Not that much
time is lost for the multiple 600uS windows.
New bullets were not discussed in detail as the information is too new.
Plan to have input on the next call.
* Is a 1/(non-power-of-two) ALIGN rate a good idea?
* Separate ALIGN rates to optimize performance or just one rate for all
* What is the best term to replace "clock skew management" in 7.3?
* The average up-spreading cannot exactly match the average down-spreading
in an SSC profile. How do we specify the accuracy? Does the ALIGN rate
of 1/2048 provide enough extra ALIGNs to account for the inaccuracy?
Comment: The 100 ppm reference clock accuracy has the same affect. Round
up for the buffer, but there still needs to be a reasonable limit on the
upper side. Rob needs to explain what problem the question is trying to
* Make sure everyone agrees with the math on the last page, and that we're
not off by a factor of 2 anywhere.
Are definitions for down spreading and center spreading acceptable?
ST indicated that they would rather train on an SSC signal rather than a
non-SSC signal. Agere and Vitesse indicated that it is better to train on
non-SSC, but there would be a need to verify signal integrity after SSC is
turned on. Training with SSC enabled is probably possible, but this has no
data to support that it can actually be done. It was suggested that it be
assumed on for now and if it has to be changed later, then it can change.
To change it later could be a significant design impact for drives.
Expanders are expected to have independent control of SSC on PHYâs
already, so the impact would be less for them.
SSC can be enabled and disabled without significant impact to the
transmitted signal if done at the zero-crossing but it may take several
microseconds to make the change from SSC to non-SSC.
Should a minimum SSC range be specified? Rob indicated he wants a minimum
specified, but most who voiced an opinion did not support a minimum
setting. SATA initially had problems with SSC but these seem to be getting
better over time. One comment made indicated that the SATA ranges seen by
that person typically from 1000 ppm to 3000 ppm rather than the full 5000
ppm allowed. Many thought it best to be a purchase specification
requirement rather than a standard if a minimum value is desired.
Several comments were made regarding EMI and the SSC pattern. The pattern
requirements still need some sort of clarification so that an issue of
overrunning buffers is not caused, but also that the pattern is effective
in reducing EMI. The âarea under the curveâ approach was mentioned. But
in itself can permit a square wave implementation that would cause a
buffer overrun issue. Ideas on how to define should be posted to the
reflector or sent to Rob.
3. Speed negotiation sequence
Â· Reviewed the new presentations and had some concerns about the
final negotiation window RCDT. Do expanders with many PHYâs need more than
300uS to process the information? Is 500uS enough?
Â· Should there be a fixed value or just start sending training
pattern when ready?
Â· How should the configuration data be sent? Should it be a 32-byte
packet, handled by new primitives, or some other option?
Â· What information should be included?
How do we know that the address frame was correctly received and
processed? Can there be some sort of handshake to verify?
Do we need to specify how options are downgraded after a failed speed
negotiation? Alvin suggested that the system determine what to change
rather than the target device since the system is more likely to be aware
of what can be changed for improvement. It was mentioned that turning off
SSC is one possible option, but if this made a system non-compliant, then
the device should not be trying to turn off SSC for that application.
There should be some sort of control specified, as if both ends are trying
to make changes, a conflict may result.
Page 9 of 05-397r4 illustrates a case where one PHY does not support G1
speeds, however, the G3 frame requires support of G1 to transfer the
payload of the address frame. This is a contradictory situation.
Additional items needing investigation/comment:
Â· Should SSC be on or off during receiver equalization setting?
Todayâs comments indicated that there are both advantages and
disadvantages to having SSC active during the initial setting process.
Having it on while setting equalization is an untested item, but is
probably possible. If setting is done while it is off, then the signal
reception needs to be verified after it is turned on.
Â· Is it viable to make a drive have independent SSC control on the
transmitters of its two ports? Independence is required to set the
receiver equalization without SSC since one port may be operating prior to
the other one performing speed negotiation.
It is possible in some designs, but an alternate suggestion of turning off
SSC at a zero-crossing for both PHYâs was proposed as an alternative.
There may be some timing issues with a smooth disable of SSC.
Â· In the beginning of the final speed negotiation window, does there
need to be an idle time or can both devices immediately start transmitting
the training pattern? It is assumed that if G2 is required, the sequence
would follow the SAS 1.1 standard.
A 300uS window was suggested in the 06-295. Since this is close to the
existing RCDT of the other windows and minimal compared to the training
interval maximum time, it was suggested to just use the existing RCDT
time. Some indicated they would like to go ahead and start the training
pattern when they were ready rather than at a set time. Additional
feedback is needed regarding this. It was also stated that some expanders
with many PHYâs may have a problem getting the information processed in
that amount of time if all the PHYâs were trying to communicate with the
processor at the same time.
Â· It is assumed that all expanders and initiators are capable of
receiving downspread SSC. Are there any know exceptions?
LSI, Vitesse, Marvell: None
Seagate Technology, LLC
E-Mail alvin.cox at seagate.com
More information about the T10