Hi everyone
-
I would like to
point out a couple of items that the committee might wish to clarify in the link
layer portion of the SATA spec.
First, while the
spec makes no claim that the state names are unique, and in fact they are not,
but are used in the spec as if they are. In the link layer, all names are unique
except L_SendHold, which can refer to either LT6 or LR5. This is particularly
strange, as L_SendHold is a misnomer for LR5 which sends HOLDA not
HOLD.
I propose that the
state name of LR5 be changed to L_RcvHold which is in keeping with the other
names in that it denotes the state type (RCV) and the reason that got
you there (HOLD). I ran this passed Knut who concurred that L_RcvHold is a
better choice than say L_SendHoldA, which someone else might think of. This
effects the table entries for transition LR4.2 and LR5.2.
I have similiar
comments for the transport layer, but will reserve them for a future note. Note
that in the transport layer diagrams some use the notation SD : SN in the
transition, thus avoiding the confusion over duplicates. In the Link layer, only
SN is used in the transition.
Second, I think that
some clarification around ALIGNs and CONTs should be made. The spec notes
(referring to the 1.0a spec) in 7.4.5 para 2, that ALIGNS are excluded in
sentence 2, but doesn't in sentence 3. This leaves open the interpretations of
whether the following sequences are legal:
1) PRIM, PRIM, ALIGN, ALIGN, CONT
2) PRIM, ALIGN, ALIGN, PRIM, CONT
3) and as seen by the receiver missing one PRIM: PRIM, ALIGN, ALIGN,
CONT
I think both are
legal as noted elsewhere the PHY may be discarding ALIGNs, thus the resulting
sequence is PRIM, PRIM, CONT which is what we want. However someone else might
argue that the whole purpose of requiring 2 PRIMs before sending a CONT was to
be sure that the PRIM was seen, and that might not hold true if they are
separated by the ALIGNs. I was never quite clear on why a privitive would not
bee seen in the first place, maybe someone can enlighten me about the thought
behind that statement.
Thanks,
Craig
Stoops
Expert
I/O
"Your I/O protocol
experts for design and verification."
