Hi Steve,

 

What I am trying to point out is that bad implementation could lead to interoperability issues. And this can happen as standard does not provide high level guidance on how PHYCAP should be implemented and so there is a possibility that vendors will choose one of the bad implementation.

 

I am not sure why you call the bad implementation as non-complaint implementation.

 

Also when I said that receiver can start BCT when ComWake Detect is detected, I meant receiver will start BCT in the next cock of CW Detect. So it means that in one BCT time, bad implementation will wait for only one CW event (either Detect or Complete). Maybe it was mis-leading as I didn’t draw that one clock difference in the diagram.

 

Also when I was talking about clock crossing issues, I did not mean a drift. I meant a simple back to back sync flop that will synchronize burst / idle detect signals from SERDES in the HW logic that detects Comwake sequence. Also in the SERDES itself, if the detection signal for idle / burst gets asserted few psec / nsec late and if that results in missing of CW sequence detection in HW, it could be a problem.

 

Steve replied:

>>When the first (START) bit is detected – i.e., ComWake Detect in the diagram below, we are in the middle of the first BCT time.  This is not the start of the first BCT.  If one were to load the BCT timer with a start value that is appropriate (maybe the middle of the full BCT count) when the first ComWake Detect occurs, then all of the remaining ComWake Detects will be positioned roughly in the middle of each remaining BCT.  Drift in clock frequencies will not move it outside of the window.  Now in each of the BCT’s you will see zero or one ComWake Detects.  Never two.

Amit: I am not sure if I understand your response in this paragraph. But the diagram shows two BCT timers. One for TX and one for RX. What I show is that as a TX, we should start BCT when we start transmission of CW sequence. But as a receiver, we can only rely on CW Detect of Complete events. So as a receiver we can only start our BCT on Detect or Complete (the standard does not mention this explicitly). Also I agree that in one BCT we will never see two ComWake Detect. As mentioned above, even detection one ComWake Detect could be a problem if we try to detect it on the last clock edge of BCT.

 

So to re-capture the problem – Bad implementation rely on the fact that they will detect a CW sequence (either a Detect or Complete) during the end of BCT time (most probably the last clock of BCT expiration). Now if due to internal clock crossing (back to back sync flops) or SERDES timing issue, we miss the CW sequence by a clock, we will mis-interpret the PHY CAP.

 

So what I am asking for is why cant the standard provide higher level guidance so that vendors don’t choose the wrong implementation. I have been bitten by these kind of implementation issues in the past and I am just trying to be pro-active about it.

 

Let me know if we can talk for couple of minutes so that I can clarify the issue at hand…

 

Thanks,

Amit Shah

Intel Corporation

 

 

From: Stephen FINCH [mailto:steve.finch@st.com]
Sent: Wednesday, September 12, 2007 8:51 AM
To: Shah, Amit M; t10@t10.org; 'Elliott, Robert (Server Storage)'
Subject: RE: BCT and PHY CAP exchange -- Possible interoperability issue

 

I had a lot of problems understanding what the issue is.  I don’t see interoperability problems, I see bad a implementation that won’t work reliably.

 

The transmitters of both ends are transmitting the same thing.  There is not difference.

 

The good receiver and the bad receiver see the same stream.  One works reliably, the other doesn’t.  One is a compliant implementation, the other isn’t.

 

 

That being said, I would suggest that the descriptions of the implementations is, in it self, wrong.

 

When the first (START) bit is detected – i.e., ComWake Detect in the diagram below, we are in the middle of the first BCT time.  This is not the start of the first BCT.  If one were to load the BCT timer with a start value that is appropriate (maybe the middle of the full BCT count) when the first ComWake Detect occurs, then all of the remaining ComWake Detects will be positioned roughly in the middle of each remaining BCT.  Drift in clock frequencies will not move it outside of the window.  Now in each of the BCT’s you will see zero or one ComWake Detects.  Never two.

 

I don’t see what needs to be changed.  Except some bad implementations.

 

Regards,

 

Steve Finch

STMicroelectronics

 

 

 

From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Shah, Amit M
Sent: Tuesday, September 11, 2007 11:26 PM
To: t10@t10.org; Elliott, Robert (Server Storage)
Cc: Shah, Amit M
Subject: BCT and PHY CAP exchange -- Possible interoperability issue

 

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