|
Dan, If the host has an EOF ready to transmit
when a HOLD is received, it should send the EOF. The Link Transmit state diagram
does not allow the sending of HOLDA between CRC and data Dwords. The
reasoning is that the host does not have to respond to the hold immediately,
there is a 20 Dword latency requirement that gives the host the latitude to
send the EOF and immediately WTRM. It is faster to complete the frame than to
respond with the HOLDA. If the EOF has been transmitted, the HOLD is ignored following
the specification (since there is no HOLD except between SOF & EOF, it is
ignored). Also, it should be remembered that just because a Dword is on the
bus, it is not necessarily “received” by the link, there is a
delay. If you look in the Link receive state machine state LR4, arc 3, you will
see R_IP is transmitted before the CRC, and then the transition and
transmission of CRC word and EOF are mandatory transitions, as long as SYNC is
not received. For the case of your host that sends HOLDA
between CRC and EOF, it isn’t good bus behavior, and it might be argued
that it is illegal, but you should not fail for it. Many SATA implementations
automatically respond with HOLDA in HW as fast as possible. If you consider the
latency, it is not unusual in my experience to have spurious HOLDs and unsent
HOLDAs, depending on the situation. I do not think a recipient should fail for
the HOLDA before EOF, and I would argue that the recipient is required to
ignore the HOLD in that case, so there is no failure. John
Masiewicz Western
Digital From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan
Meyer Pardon
me if this is the incorrect forum for this question and please direct me to the
correct forum if this is the case. When
a host has EOF to send and a device sends HOLD, should the host send EOF or
HOLDA? In Serial ATA rev 1.0a section 7.6.1.3 state LT8 (page 167), I see
no mention of HOLD, only “When
in this state, the Link layer shall transmit the EOF primitive.” I
am seeing a host who sends HOLDA instead of EOF. Dan Meyer |
- [t13] SATA question about HOLD & EOF Dan Meyer
- RE: [t13] SATA question about HOLD & EOF John Masiewicz
- RE: [t13] SATA question about HOLD & EOF Joseph Chen - SISA
- RE: [t13] SATA question about HOLD & EOF Craig Stoops
