To SAS PHY WG: Reference Channel for 12G SAS

mickey.felton at emc.com mickey.felton at emc.com
Wed Nov 24 11:19:28 PST 2010


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1011240_f.htm">HTML-formatted message</a>

On #3 below I have some comments:
A.	A set of maximum channel requirements I believe should be the
first step in the process:
*	  Maximum channel loss for example 25dB
*	  Maximum deviation of channel loss +/- 2dB?
*	  Maximum insertion loss to crosstalk ratio for example 15dB
*	  A maximum Scd or Scc or equivalent specification.
*	  A defined set of criteria for ANY connector used in SAS system
(as defined by 10-123)
B.	After A above is met, the whole channel would need to be
simulated for BER using a simulation tool, for example like was
suggested by either:
*	  PMC's 10-361
*	  Maxim 10-362 
C.	Measurements :	(definitely just a few possible ways of doing
this)
*	  (For anything without a compliance connector) - The channel
model would need to be done from TX footprint of the SAS ASIC to the RX
footprint of the other SAS ASIC. The ASIC's would be removed for the
measurement. And added in during simulation with their associated
package models, etc..
*	  (For cables) - Something similar to what was done on SAS 2.0
with a 10M cable setup being defined and used as the reference. (or just
do the above)
*	  (for disks) - a maximum set of criteria to be used on any disk
such as defined in 10-123, but extended to disk drive lengths. (or have
disk guys provide models for use in SAS?!?!?)
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Alvin
Cox
Sent: Friday, November 19, 2010 4:49 PM
To: T10 Reflector
Subject: To SAS PHY WG: Reference Channel for 12G SAS
The drive connector mated pair was identified as an issue at 12G due to
the crosstalk peaking near 6GHz. Simulations from multiple connector
suppliers indicate that this peak can be moved to a higher frequency and
thus, result in a connector mated pair enhanced to work at 12G.
Channel simulations on existing s-parameter files indicate that not all
6G channels are acceptable for 12G operation. I don't consider this an
unexpected result. 12G brings new challenges and it should be expected
that optimization is needed to double the transfer rate. In an ideal
world, all of these 6G channels should work at 12G, however, the added
complexity, power, and expense of implementation does not necessarily
support that goal with reality.
We have been looking at the 10 meter Mini SAS HD cable as the possible
reference channel. There is confusion as to what the correct version is
since there have been a few iterations of the HD connector design. 
SAS 3.0 needs the reference channel defined so that we can move forward.
Based on where we are at in the development and with the progress we
have made as a group, I see the following as a minimum set of items we
need to work on to move forward:
1.	Post a fresh set of Mini SAS HD cable s-parameters for 10 meter,
8 meter, and 6 meter cables. This will make sure that the same set of
parameters is being used and let us know if 10 meters is achievable.
Some early investigation indicated that we may need to reduce the length
to 8 meters. This will give us the data available to determine what the
capabilities and trade-offs are.
2.	The drive connector mated pair simulations appear to be very
similar. The means to achieve this performance has not been openly
shared. If IP is involved, that can be resolved as a separate issue. We
need to see actual test data that supports the simulation data. This
means that real s-parameters from real hardware needs to be supplied. We
should move forward with the simulated data in parallel with actual
connectors being built to provide verification that the simulation
results are actually achieved.
3.	The channel requirements should include more information than
currently used for 6G. One thing mentioned during the last meeting was a
crosstalk to insertion loss spec. Crosstalk is definitely a major
consideration, but in simple terms, are we not talking about SNR? How
should we address this? I believe it is the right direction, but what
would be the best way to approach it from a specification standpoint?
Comments are welcome and encouraged. 
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com 



More information about the T10 mailing list