Proposal 04-177r1

Cable, Andrew L andrew.l.cable at intel.com
Wed Jun 9 15:49:42 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Cable, Andrew L" <andrew.l.cable at intel.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C44E74.0F446AD2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SAS 1.5 Gbps OOB Requirement

=20

Reference Proposal: T10/04-177r1

=20

All,

=20

First, let me state that I agree with the need to allow future
generations of the standard to have flexibility in regards to the rate
at which OOB is performed. However, I believe there should be a way =
that
the standard can preserve this flexibility without compromising
interoperability and over-burdening a design primarily used to bring a
device out of a powered-down state. As a result, I would like to post a
few comments regarding the 177r1 proposal to stimulate a discussion on
some of the issues I see.

=20

1.)    The wording presented in the 177r1 proposal allows for
interoperability holes in the standard. As an example, suppose there =
are
two 3.0Gbps PHY's physically connected to one another. The first PHY
decided to implement OOB at its lowest supported rate while the second
PHY decided to implement a receiver that supports 1.5Gbps OOB only. =
Both
are compliant and share a common link rate,    yet two 3.0Gig PHY's
cannot interoperate.  The question I would pose to the PHY working =
group
is, do we want to intentionally create the possibility of
interoperability issues on a COMWAKE/COMINIT/COMSAS circuit? Allowing
interoperability issues on fundamental signaling schemes such as OOB
seems dangerous and should not be left to market forces to decide.

2.)    From a technology only perspective, I'm having trouble coming up
with valid reasons to OOB at anything higher than 1.5Gbps. At the last
face-to-face meeting on May 3rd, the PMC proposal was voted on with 6 =
in
favor and 2 against. Design trade-offs were discussed. The only
additional design burden cited against the proposal was always
transmitting OOB at 1.5Gbps. All in the room agreed the burden on the
receiver to support the highest data rate far outweighed the burden to
transmit at 1.5Gbps. Why then would the PHY working group recommend
adding complexity to OOB by supporting this proposal?  From my
understanding, OOB is primarily used to wake sleeping PHY's as a power
management feature. From a technology perspective, I could see a large
benefit to reusing this circuit as opposed to redesigning for each
generation. Please keep in mind the receiver as stated in proposal =
177r1
is required to OOB at 1.5Gbps. In other words, the receiver is already
locked in to supporting 1.5Gbps for all future generations. This may
preclude any future opportunity to change subsequent generations of the
standard. The only issue at hand is whether the transmitter can perform
OOB at 1.5Gbps either by actually clocking at that rate or
doubling/tripling/etc. each bit at its lowest supported rate. I'm =
hoping
someone on this reflector can highlight the technological advantages of
supporting this proposal as I am not able to think of any.

3.)    Looking forward to data rates beyond 10-12Gig, there are several
possibilities which can dramatically change the electrical landscape.
Signaling schemes may be quite different than they are at 1.5Gbps and
could require a serious change to the electrical definitions that are
currently in place. The flexibility highlighted in the proposal needs =
to
remain and should also apply to all of the electrical definitions. The
challenge is to maintain the flexibility while doing the right thing
technologically as well as close any obvious interoperability holes.

=20

Thanks for your time in entertaining the thoughts above and I look
forward to any comments you may have.

=20

=20

Andrew Cable

Intel Corporation

SCD Analog Engineering

480-554-9446

=20


------_=_NextPart_001_01C44E74.0F446AD2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 SAS 1.5 Gbps OOB Requirement   Reference Proposal: T10/04-177r1   All,   First, let me state that I agree with the need to allow future generations of the standard to have flexibility in regards to the rate = at which OOB is performed. However, I believe there should be a way that the = standard can preserve this flexibility without compromising interoperability and over-burdening a design primarily used to bring a device out of a = powered-down state. As a result, I would like to post a few comments regarding the = 177r1 proposal to stimulate a discussion on some of the issues I = see.   1.)The wording presented in the 177r1 proposal = allows for interoperability holes in the standard. As an example, suppose = there are two 3.0Gbps PHY;s physically connected to one another. The first = PHY decided to implement OOB at its lowest supported rate while the second = PHY decided to implement a receiver that supports 1.5Gbps OOB only. Both = are compliant and share a common link rate,    yet two = 3.0Gig PHY;s cannot interoperate.  The question I would pose to the PHY working group = is, do we want to intentionally create the possibility of interoperability issues = on a COMWAKE/COMINIT/COMSAS circuit? Allowing interoperability issues on = fundamental signaling schemes such as OOB seems dangerous and should not be left to = market forces to decide. 2.)From a technology only perspective, = I;m having trouble coming up with valid reasons to OOB at anything higher = than 1.5Gbps. At the last face-to-face meeting on May 3rd, the = PMC proposal was voted on with 6 in favor and 2 against. Design trade-offs = were discussed. The only additional design burden cited against the proposal = was always transmitting OOB at 1.5Gbps. All in the room agreed the burden on the = receiver to support the highest data rate far outweighed the burden to transmit = at 1.5Gbps. Why then would the PHY working group recommend adding = complexity to OOB by supporting this proposal?  From my understanding, OOB is = primarily used to wake sleeping PHY;s as a power management feature. From a = technology perspective, I could see a large benefit to reusing this circuit as = opposed to redesigning for each generation. Please keep in mind the receiver as = stated in proposal 177r1 is required to OOB at 1.5Gbps. In other words, the = receiver is already locked in to supporting 1.5Gbps for all future generations. = This may preclude any future opportunity to change subsequent generations of the standard. The only issue at hand is whether the transmitter can perform = OOB at 1.5Gbps either by actually clocking at that rate or = doubling/tripling/etc. each bit at its lowest supported rate. I;m hoping someone on this = reflector can highlight the technological advantages of supporting this proposal = as I am not able to think of any. 3.)Looking forward to data rates beyond = 10-12Gig, there are several possibilities which can dramatically change the = electrical landscape. Signaling schemes may be quite different than they are at = 1.5Gbps and could require a serious change to the electrical definitions that = are currently in place. The flexibility highlighted in the proposal needs = to remain and should also apply to all of the electrical definitions. The = challenge is to maintain the flexibility while doing the right thing technologically as = well as close any obvious interoperability holes.   Thanks for your time in entertaining the thoughts above and I = look forward to any comments you may have.     Andrew Cable Intel Corporation SCD Analog Engineering 480-554-9446   


------_=_NextPart_001_01C44E74.0F446AD2--




More information about the T10 mailing list