Subject: BCT and PHY CAP exchange -- Possible interoperability issue
Date: Tue, 11 Sep 2007 22:26:23 -0700
From: "Shah, Amit M" <amit.m.shah@intel.com>
To: <t10@t10.org>, "Elliott, Robert (Server Storage)" <Elliott@hp.com>
Cc: "Shah, Amit M" <amit.m.shah@intel.com>
X-Message-Number: 8053
Formatted message: HTML-formatted message
Attachment #1: oledata.mso
Attachment #2: image001.emz
Attachment #3: image002.gif

Hello,
The SAS standard does not talk about BCT timer and PHY CAP exchange high
level mplementation at all.
It mentions
"Each phy capabilities bit is one bit cell time (BCT) and contains
either COMWAKE (indicating one) or D.C. idle (indicating zero)"
Right now it is open to designer's interpretation of the standard and I
am afraid that different vendors will have different implementation of
BCT / PHYCAP which will cause interoperability issues in future.
Recently I came across of one interpretation of BCT and PHY Capability
which I thought was not correct. This implementation is accurate w.r.t.
SAS standard (as SAS standard does not mention any rules or SM to govern
BCT / PHY CAP exchange) but I believe it will not work in real silicon.
Here are the details of what I observed...
BCT is 2200 OOBI.
Transmitter of ComWake (CW) will have to transmit CW for 2200 OOBI which
is equivalent to BCT.
Receiver of this CW can detect the negation time a little sooner. TX
Negation time = 186.6nsec. RX Negation time > 175 nsec. So basically
receiver can completely detect a CW (with negation time) about 11nsec
earlier. 
Now lets look at this diagram....
You can see when TX is transmitting CW.
Also after some latency, RX receives the CW.
RX can detect the complete CW sequence along with negation time 11 nsec
earlier (as mentioned above). So that is the reason there is some IDLE
shown between two CW sequence as seen by receiver.
During an OOB sequence, there are only two distinct events that are
reliable for a receiver. Once is a "ComWake Detected" and other is
"ComWake Completed".
Logically, RX can only start its BCT timer on ComWake Detect (I don't
know why SAS Standard does not mention this critical detail) or a
ComWake Completed as starting BCT timer on any random burst sequence
could be fatal for PHY CAP detection sequence.
What I think is a good implementation....
1.	Receiver starts the BCT on the "first" CW Detect.
2.	When BCT is still active and if it recognized a CW Completed, it
marks it as a start bit.
3.	Once the BCT timer expires, it will start the next BCT timer
automatically (this time it will not start it based on CW Detect).
4.	Now during the new BCT time, if the receiver detects a CW
Completed, it should capture it as a "1", else a "0".
5.	go back to step "#3".
Advantage: The decoding of the PHY CAP bit during BCT time will happen
about 186nsec before BCT expires. So this approach is less susceptible
to design implementation / clock crossing issues. Better for
Interoperability.
BAD implementation # 1 (This is the wrong implementation that I came
across)....
1.	Receiver starts the BCT on the "first" CW Detect.
2.	The First CW Detect is also marked internally as START BIT.
3.	When BCT is still active and if it recognized another CW
Deteted, it marks it as a "1", else it will mark it as a "0" (as part of
PHY CAP)
4.	Once the BCT timer expires, it will start the next BCT timer
automatically (this time it will not start it based on CW Detect).
5.	go back to step #3.
BAD implementation # 2....
1.	Receiver starts the BCT on the "first" CW Completed.
2.	The First CW Completed is also marked internally as START BIT.
3.	When BCT is still active and if it recognized another CW
Completed, it marks it as a "1", else it will mark it as a "0" (as part
of PHY CAP)
4.	Once the BCT timer expires, it will start the next BCT timer
automatically (this time it will not start it based on CW Completed).
5.	go back to step #3.
The last two implementation are marked as "BAD Implementation" as the
internal decoding of a "1" or a "0" (after Start bit detection) is based
on a CW event which will happen only during the time when BCT is about
to expire. Theoretically, BCT is equal to a CW. So one clock before BCT
expires, a new CW event should be detected to decode the PHY CAP bit as
a "1". 
In real world, if BCT expires and one clock later the CW event occurs,
that event will be missed and a wrong PHY CAP will be captured. Due to
clock crossing of signals or due to SERDES implementation, if a CW
detect is detected (bad implementation #1) one clock later or if CW
completed (implementation #2) is detected 1 clock later, the whole PHY
CAP exchange will be bad.
So these bad implementations as stretching the detection of a "1" or a
"0" during a BCT to a 1 clock period and I am worried about that.
By not defining BCT and PHYCAP at a higher level, the standard is
relying on the vendors to implement this functionality as they feel is
right.
But I am worried that wrong implementation of BCT / PHY CAP will lead to
a lot of interoperability issues in future.
It will be good if the SAS standard will throw some light on this
issue....
Thanks,
Amit Shah