要看“发送数据”是哪一层。
结论先说：SATA 发送一个 Frame 前后需要等对方回应，但不是每发一个 Dword 都等一次。
可以分成三个阶段：
发送前：要等对方准备好 发送中：连续发送，不逐拍等待 发送后：要等对方确认 R_OK / R_ERR1. Link 层发送 Frame，需要等对方回应
SATA Link 层发送一个 FIS Frame 时，一般流程是：
本端发送 X_RDY ↓ 等待对方返回 R_RDY ↓ 本端发送 SOF ↓ 本端连续发送 FIS payload ↓ 本端发送 CRC ↓ 本端发送 EOF ↓ 本端发送 WTRM ↓ 等待对方返回 R_OK 或 R_ERR也就是：
X_RDY → R_RDY → SOF → DATA → CRC → EOF → WTRM → R_OK/R_ERR所以答案是：
发 Frame 前，要等 R_RDY 发 Frame 后，要等 R_OK / R_ERR 发 payload 过程中，不是每个 Dword 都等 ACK2. X_RDY / R_RDY 是发送前握手
如果本端要发一个 FIS，不能直接上来就发 SOF。
发送方先发：
X_RDYp含义是：
我要发送一个 Frame，你准备好接收了吗？接收方如果可以接收，就返回：
R_RDYp含义是：
我准备好了，你可以发。然后发送方才开始：
SOFp + FIS payload + CRC + EOFp所以发送前需要等对方回：
R_RDYp3. Payload 发送过程中，不需要每拍等对方
进入真正的数据发送阶段后，比如：
SOFp FIS payload dword0 FIS payload dword1 FIS payload dword2 ... CRC EOFp中间这些 payload Dword 是连续流式发送的。
不需要：
发 dword0 → 等 ACK 发 dword1 → 等 ACK 发 dword2 → 等 ACK而是：
连续发送整个 Frame只有发生流控时例外。
4. 发送过程中如果对方来不及收，会用 HOLD / HOLDA
如果接收方 FIFO 快满，接收方可以发：
HOLDp意思是：
我暂时收不过来了，你先暂停。发送方收到HOLDp后，需要返回：
HOLDAp意思是：
我已经暂停。然后发送方暂停 payload 指针，不继续发送新的数据。
等对方不再要求 HOLD 后，继续从暂停位置发送。
所以发送中不是每个 Dword 都等回应，但要随时监听：
HOLDp5. Frame 发完后，要等 R_OK / R_ERR
发送方发完：
EOFp之后，还要发送：
WTRMpWTRM可以理解成：
我发完了，等待你确认。接收方收到完整 Frame 后，会检查 CRC。
如果 CRC 正确：
接收方返回 R_OKp如果 CRC 错误：
接收方返回 R_ERRp所以发送方必须等待：
R_OKp 或 R_ERRp然后决定：
收到 R_OK → 本帧发送成功 收到 R_ERR → 重传当前 Frame 超时未收到 → 错误恢复 / 重发 / reset link6. 所以 Link 层发送状态机大概是这样
TX_IDLE ↓ TX_SEND_X_RDY ↓ 等 R_RDY TX_SEND_SOF ↓ TX_SEND_PAYLOAD ↓ TX_SEND_CRC ↓ TX_SEND_EOF ↓ TX_SEND_WTRM ↓ 等 R_OK / R_ERR TX_DONE / TX_RETRY / TX_ERROR重点是两个等待点：
1. 发送前等 R_RDY 2. 发送后等 R_OK / R_ERR7. 从“是不是等对方回消息”角度总结
| 阶段 | 是否等对方 | 等什么 |
|---|---|---|
| PHY OOB 阶段 | 要等 | COMINIT / COMWAKE |
| Link 初始化阶段 | 要等/检测 | ALIGN / SYNC |
| Frame 发送前 | 要等 | R_RDY |
| Payload 发送中 | 通常不等 | 只监听 HOLD |
| Payload 被暂停 | 要响应 | 收到 HOLD，返回 HOLDA |
| Frame 发送后 | 要等 | R_OK / R_ERR |
| Transport 命令层 | 要等 | Device 返回 D2H FIS / Data FIS / Set Device Bits |
link层和传输层等待的区别
核心是：Link 层等的是“这一帧有没有传输成功”；Transport/命令层等的是“设备有没有真正执行完这个命令”。
这是两种完全不同的“等待”。
1. Link 层等的是帧级确认
比如 FPGA Host 发一个命令 FIS：
Register H2D FIS：READ DMA EXTLink 层会把它封装成 SATA Frame：
X_RDY R_RDY SOF Register H2D FIS payload CRC EOF WTRM 等待 R_OK / R_ERR如果对方返回：
R_OK只说明一件事：
这个 FIS 帧在链路上传输正确，对方已经收到，没有 CRC 错误。但它不代表 SSD 已经完成读操作。
也就是说：
R_OK = 这一帧收到了 不是 = 命令执行完成2. Transport/命令层等的是设备的业务响应
你发给 SSD 一个READ DMA EXT命令以后，SSD 收到命令只是第一步。
接下来 SSD 还要：
解析命令 查 LBA 准备 NAND/缓存数据 组织 Data FIS 把数据发回 Host 最后返回状态这些后续响应，就是 Transport/Command 层要等的。
所以我前面说：
Transport 命令层要等 Device 返回 D2H FIS / Data FIS / Set Device Bits意思是：Host 发完命令后，还要等设备返回真正的协议响应。
3. 举例：READ DMA EXT 读盘流程
假设 FPGA Host 要读 SSD 的 LBA 1000，读 8 个 sector。
第一步：Host 发送命令
Transport/Command 层生成：
Register Host to Device FIS Command = READ DMA EXT LBA = 1000 Sector Count = 8Link 层负责把这个 FIS 发出去，并等：
R_OK这里的R_OK只表示：
SSD 收到了这个命令 FIS。还不表示数据已经读回来了。
第二步：Device 返回数据
SSD 开始返回：
Data FIS里面才是真正的数据。
比如：
Data FIS 1：sector 数据 Data FIS 2：sector 数据 ...Host 的 Transport 层看到Data FIS后，才知道：
设备正在把读出来的数据返回给我。然后 Transport 层把 Data FIS 里的 payload 交给 DMA：
Data FIS payload → RX FIFO → DMA → DDR / Host Memory第三步：Device 返回命令完成状态
数据发完以后，设备通常还会返回状态类 FIS，例如：
Register Device to Host FIS或者在某些场景下：
Set Device Bits FIS里面会有：
Status Error Interrupt bit Command completeCommand 层看到这个，才认为：
这次 READ DMA EXT 命令完成了。4. 所以 READ 的完整等待关系是这样
Host Command 层： 我要读 LBA 1000 Transport 层： 构造 Register H2D FIS Link 层： 发送这个 FIS 等 R_OK → 只说明命令帧传输成功 Command/Transport 层： 继续等 Device 返回 Data FIS → 收到真正读出的数据 Command/Transport 层： 再等 Device 返回 D2H FIS / 状态 FIS → 确认命令完成或失败你可以记成：
R_OK：链路层确认 Data FIS：设备返回数据 D2H FIS：设备返回状态5. 举例：WRITE DMA EXT 写盘流程
写盘更能看出区别。
第一步：Host 发写命令
Host → Device： Register H2D FIS Command = WRITE DMA EXT LBA = xxx Sector Count = xxxLink 层等：
R_OK这只说明：
SSD 收到写命令了。第二步：Device 通知可以发数据
设备可能返回：
DMA Activate FIS或者相关 DMA 准备信号。
意思是：
我准备好了，你可以把要写的数据发给我。这才是 Transport/Command 层关心的响应。
第三步：Host 发送 Data FIS
Host 发送真正要写入 SSD 的数据：
Host → Device： Data FIS每个 Data FIS 发出去后，Link 层仍然要等：
R_OK / R_ERR但这仍然只是链路确认。
第四步：Device 返回写完成状态
最后 Device 返回：
Register D2H FIS里面的状态如果正常，Command 层才认为：
这次写盘命令真正完成。6. 三种“等待”要区分
| 层级 | 等什么 | 代表什么 |
|---|---|---|
| Link 层 | R_OK / R_ERR | 当前这个 Frame 是否传输正确 |
| Transport 层 | Data FIS / DMA Setup FIS / DMA Activate FIS | 设备进入了数据传输阶段 |
| Command 层 | Register D2H FIS / Set Device Bits FIS | ATA 命令完成、失败或状态变化 |
最容易混的是：
R_OK 不等于命令完成。R_OK只是链路层说：
这一帧我收到了，CRC 没问题。真正命令完成要看设备后续返回的：
D2H FIS Set Device Bits FIS Status/Error 字段7. 用一句话类比
你可以类比成寄快递：
Link 层 R_OK： 快递员确认包裹送到了对方门口。 Transport/Command 层 D2H FIS： 对方拆开包裹，处理完事情，然后回信告诉你结果。所以：
包裹送到 ≠ 事情办完对应 SATA：
FIS 帧传输成功 ≠ ATA 命令执行完成8. 最简理解
如果 FPGA 是 SATA Host：
你发 Register H2D FIS： Link 层等 R_OK 说明命令帧发成功 你发 READ 命令： Command 层还要等 Data FIS 因为数据还没回来 你要判断命令结束： Command 层还要等 D2H FIS / Set Device Bits FIS 因为这才是设备状态反馈所以那一行表格的意思是：
Transport/Command 层等待的不是链路 ACK， 而是设备对 ATA 命令的真实响应： 数据、DMA 准备信息、完成状态、错误状态。
