diff --git a/非对称可靠串行传输技术规范.md b/非对称可靠串行传输技术规范.md index 2feb6d2..24c1bf3 100644 --- a/非对称可靠串行传输技术规范.md +++ b/非对称可靠串行传输技术规范.md @@ -2,7 +2,7 @@ **Asymmetric Reliable Serial Transport Technical Specification** -**版本：V0.8**
+**版本：V0.9**
**日期：2026-10-01**
**作者：周爽** @@ -12,6 +12,7 @@ | 版本 | 日期 | 说明 | |---|---|---| +| V0.9 | 2026-10-01 | 完善分层接口的确定性语义；补充诊断可观察性、接口时序、重新训练握手、验证验收与互操作声明要求。 | | V0.8 | 2026-10-01 | 完善重传协议的确定性实现规则；统一协议层`link_up`接口，明确最大接收能力、窗口计时切换、`POLL_REQ`、业务接口契约、状态图说明及重传验证要求。 | | V0.7 | 2026-10-01 | 完善链路训练和运行期监测的异常闭环；明确主端重启可见性、运行入口就绪时机、连续计数与超时优先级、可信方向帧边界切换、方向化重训、恢复候选帧丢弃、单个IDLE恢复、意外固定帧处理及运行期CRC错误门限。 | | V0.6 | 2026-10-01 | 完善主从同步与重新训练状态机；明确重复`SYNC_RESET`、训练应答保护、同步确认和运行入口超时；补充`IDELAY`与`ODELAY`扫描状态机；统一200帧边界搜索与测量周期；修订完整UI环形窗口、`ALL_PASS`及最小通过窗口派生规则。 | @@ -262,7 +263,7 @@ flowchart LR 空闲期间如果不能持续检测到合法`IDLE`，或者帧结束后的预期边界不能恢复，数据链路层判定同步异常并进入相应训练流程。按照本规范采用的简化恢复策略，`UL`失效触发`UL`和`DL`完整重训；其他异常按照第26章规定恢复受影响的同步状态。 -任一方向同步丢失都会终止当前双向传输协议会话，并使双方传输协议层复位。重新训练范围与会话复位相互独立：`UL`异常时重新训练`UL`和`DL`；`DL`异常且`UL`仍可信时只重新训练`DL`。同步恢复后，主端通过`POLL_REQ`取得从端当前的`WIN_BYTES`并确认控制帧通路可用；从端必须在初始响应中发送`ACK_NEXT=0`，主端把实际收到的`ACK_NEXT`作为新会话起始序号，不将其解释为旧会话累计确认。完成新会话初始化后才能重新置位`transport_ready`。详细规则见第26.2节、第35章和第46章。 +任一方向同步丢失都会终止当前双向传输协议会话，并使双方传输协议层复位。重新训练范围与会话复位相互独立：`UL`异常时重新训练`UL`和`DL`；`DL`异常且`UL`仍可信时只重新训练`DL`。同步恢复后，主端通过`POLL_REQ`取得从端当前的`WIN_BYTES`并确认控制帧通路可用；从端必须在初始响应中发送`ACK_NEXT=0`，主端把实际收到的`ACK_NEXT`作为新会话起始序号，不将其解释为旧会话累计确认。完成新会话初始化后，传输协议层才允许对业务发送接口置位`app_tx_ready`。详细规则见第26.2节、第35章和第46章。 ### 4.6 后续内容索引 @@ -1008,7 +1009,7 @@ sequenceDiagram 15. 主端连续正确检测10000个`UL` `SYNC`后停止发送`SYNC`并持续发送`IDLE`； 16. 从端检测到首个完整合法的`DL IDLE`后停止发送`SYNC`，使接收方向进入运行期边界监测，并在`UL`连续发送20个`IDLE`；20个`IDLE`完整发送结束前不提交普通协议帧； 17. 主端检测到首个完整合法的`UL IDLE`后进入`M_RUN`并置位`link_up`；剩余`IDLE`按正常空闲码字处理； -18. 主端随后通过`POLL_REQ`确认控制帧通路并取得`WIN_BYTES`；只有新会话初始化完成后才置位`transport_ready`； +18. 主端随后通过`POLL_REQ`确认控制帧通路并取得`WIN_BYTES`；只有新会话初始化完成后才允许业务发送接口接受新帧； 19. `SYNC`采用“持续发送、条件终止、超时失败”；不需要额外的“进入业务状态”控制帧。 步骤12至17的同步确认和运行入口均受对应超时保护：正常情况下由对端状态变化终止；超过规定时间仍未观察到终止条件，则按当前方向是否仍可信进入规定的重新训练路径。长序列由连续重复固定160位`SYNC`帧构成，不改变单帧长度。 @@ -1091,7 +1092,7 @@ stateDiagram-v2 - 进入`M_UL_CONFIRM`后，主端允许继续收到从端尚未发送完的`SYNC_ACK`；这些剩余ACK不计为错误； - `M_UL_CONFIRM`检测到第一个完整`SYNC`时将`UL SYNC`连续计数置1；此后任一非`SYNC`固定帧使计数清零，重新等待下一个完整`SYNC`作为新序列起点； - `M_RUN_ENTRY`期间`DL`持续发送`IDLE`，不允许发送协议帧；主端在已知边界完整匹配首个`UL IDLE`后立即进入`M_RUN`，不执行额外连续检测；若超时前仍持续收到完整`UL SYNC`，说明UL可信而从端未接受DL运行入口，返回`M_TX_TRAIN`；若UL也不再可靠，则返回`M_RX_TRAIN`； -- 主端进入`M_RUN`后发送`POLL_REQ`；`link_up`和`transport_ready`必须按第46章分别产生； +- 主端进入`M_RUN`后发送`POLL_REQ`；`link_up`与协议层内部`session_ready`的关系按第46章执行； - `UL`失步返回`M_RX_TRAIN`，随后依次重新训练`UL`和`DL`；能够明确判断为`DL`单向异常时，直接返回`M_TX_TRAIN`； - 点间隔发送满50个有效`IDLE`仍未收到完整`TRAIN`时，不得开始下一`ODELAY`点；UL仍可靠时重新执行完整DL训练，UL不可靠时重新训练UL和DL； - 主端主动请求从运行状态进入链路重新训练时，如果`DL`仍具备传送完整固定帧的条件，应先连续发送20个`SYNC_RESET`；从端完整检测到其中任意一个后，清除当前训练上下文并进入`S_TRAIN`；主端发送完成后根据需要进入`M_TX_TRAIN`，或者进入`M_RX_TRAIN`并在`UL`恢复后继续执行`M_TX_TRAIN`； @@ -1203,7 +1204,7 @@ stateDiagram-v2 | `RX_ANALYZE_WINDOW` | 找最长连续通过区间并选择中心 | 有合法窗口或失败 | | `RX_LOAD_CENTER` | 请求装载中心延迟档位，等待`rx_delay_ready`并重新建立字边界 | 完成后进入`DL`扫描 | -`rx_delay_ready`是抽象就绪条件，表示当前请求的`IDELAY`配置已经生效且接收路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。设置请求未被接受或就绪条件长期无效时，状态机可以保持在`RX_SET_DELAY`、`RX_WAIT_DELAY_READY`或`RX_LOAD_CENTER`，本规范不要求统一超时；挂起期间必须保持`link_up=0`和`transport_ready=0`，不得启动200帧单点计时、搜索候选边界、累计`TRAIN`、更新扫描位图或发送普通协议帧。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`，不得把该事件记录为普通失败点。 +`rx_delay_ready`是抽象就绪条件，表示当前请求的`IDELAY`配置已经生效且接收路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。设置请求未被接受或就绪条件长期无效时，状态机可以保持在`RX_SET_DELAY`、`RX_WAIT_DELAY_READY`或`RX_LOAD_CENTER`，本规范不要求统一超时；挂起期间必须保持`link_up=0`和`session_ready=0`，不得启动200帧单点计时、搜索候选边界、累计`TRAIN`、更新扫描位图或发送普通协议帧。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`，不得把该事件记录为普通失败点。 ### 21.3 测试点判定 @@ -1267,7 +1268,7 @@ stateDiagram-v2 | `TX_ANALYZE_WINDOW` | 找最长连续通过区间并选择中心 | 有合法窗口或失败 | | `TX_LOAD_CENTER` | 请求装载中心延迟档位并等待`tx_delay_ready` | 就绪后进入双向`SYNC`确认 | -`tx_delay_ready`是抽象就绪条件，表示当前请求的`ODELAY`配置已经生效且发送路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。设置请求未被接受或就绪条件长期无效时，状态机可以保持在`TX_SET_DELAY`、`TX_WAIT_DELAY_READY`或`TX_LOAD_CENTER`，本规范不要求统一超时；挂起期间必须保持`link_up=0`和`transport_ready=0`，不得记录扫描结果或发送普通协议帧。延迟切换期间的线路输出不参与任何测试点判定；只有`tx_delay_ready=1`后才能清除旧ACK历史并开始新的`TRAIN`序列和200帧计时。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`。 +`tx_delay_ready`是抽象就绪条件，表示当前请求的`ODELAY`配置已经生效且发送路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。设置请求未被接受或就绪条件长期无效时，状态机可以保持在`TX_SET_DELAY`、`TX_WAIT_DELAY_READY`或`TX_LOAD_CENTER`，本规范不要求统一超时；挂起期间必须保持`link_up=0`和`session_ready=0`，不得记录扫描结果或发送普通协议帧。延迟切换期间的线路输出不参与任何测试点判定；只有`tx_delay_ready=1`后才能清除旧ACK历史并开始新的`TRAIN`序列和200帧计时。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`。 ### 22.3 测试点判定与应答归属 @@ -1446,7 +1447,7 @@ stateDiagram-v2 2. `DATA`将剩余字数装载为 `2 + LEN/4`，对应`SOF`之后的`SEQ`/`LEN`字、载荷和CRC；`CTRL`将剩余字数装载为3； 3. 每接收一个32位字递减剩余字数； 4. 计数未归零前，任何`IDLE`、`SOF`或固定帧图样都只作为帧内容，不执行同步判断； -5. 逻辑帧最后一个字输出时置位 `rx_data_last`；随后接收CRC字并在校验结果有效时置位 `rx_crc_valid` 和 `rx_crc_pass`。若实现使用流水线对齐这些信号，仍必须保持“帧数据结束在前、CRC最终结论在后”的接口语义； +5. 数据链路层暂存逻辑帧最后一个字；收到并比较随后的CRC字后，在输出该逻辑末字时同时置位`rx_data_last`、`rx_crc_valid`和`rx_crc_pass`； 6. 计数归零后的下一个32位位置就是 `expected_next_boundary`； 7. CRC正确时该位置为可信边界；CRC错误时该位置为暂定边界； 8. 在该位置完整匹配`IDLE`或合法`SOF`后，边界转为可信；若匹配失败则进入 `MON_RECOVERY`。 @@ -1563,10 +1564,10 @@ link_up = ul_sync_up && dl_sync_up && run_entry_complete #### 26.2.3 协议复位动作 -任意传输状态下，只要`link_up`撤销，传输协议层必须立即撤销`transport_ready`，停止接受新的业务发送请求，并进入协议复位保持状态。必须执行以下动作： +任意传输状态下，只要`link_up`撤销，传输协议层必须立即撤销`session_ready`，不得开始接受新的业务发送帧，并进入协议复位保持状态。已经完成首字握手但尚未完成末字握手的当前业务发送帧，按第45.1节继续接收到`app_tx_last`并报告中止。必须执行以下动作： 1. 停止并清除`T_ACK_WAIT`、`T_POLL_INTERVAL`、`T_PROGRESS_LIMIT`以及连续失败计数； -2. 中止尚未完成线路发送的普通协议帧；不得把`tx_frame_abort`当作`tx_frame_done`； +2. 中止尚未完成线路发送的普通协议帧；未产生有效`tx_frame_done`的帧不得用于发送记账或形成完成结果； 3. 回滚所有尚未得到最终CRC结论的接收候选帧，不产生业务应用层可见提交； 4. 主端清零`SND_UNA`、`SND_NXT`、`OUTSTANDING_BYTES`和`PEER_WIN_BYTES`，清空重传缓存、未发送描述符及控制请求快照； 5. 从端清零`RCV_NEXT`、`ACK_PENDING`和`RETRY_PENDING`，丢弃尚未提交的接收候选帧及控制响应快照； @@ -1585,12 +1586,12 @@ link_up = ul_sync_up && dl_sync_up && run_entry_complete 规定范围内的重新训练和运行入口过程完成后，按照以下顺序建立新会话： -1. 双方数据链路层重新置位各自的`link_up`；双方传输协议状态仍保持第26.2.3节规定的初始值，`transport_ready`保持为0； +1. 双方数据链路层重新置位各自的`link_up`；双方传输协议状态仍保持第26.2.3节规定的初始值，`session_ready`保持为0； 2. 主端进入`M_WAIT_STATUS`并置位`POLL_PENDING`； 3. 从端进入`S_EXPECT`。收到合法`POLL_REQ`后，以`ACK_NEXT=0`和当前实际`WIN_BYTES`形成状态`CTRL`； 4. 从端必须在该初始状态响应中发送`ACK_NEXT=0`。主端只要求响应帧的格式和CRC合法，不使用`ACK_NEXT`作为新会话准入条件；主端把收到的`ACK_NEXT`解释为新会话起始序号，原子设置`SND_UNA=ACK_NEXT`和`SND_NXT=ACK_NEXT`，保持`OUTSTANDING_BYTES=0`及重传缓存为空，并装载响应中的`WIN_BYTES`； -5. 主端收到合法初始状态后进入`M_RUN`并置位`master_transport_ready`；从端在初始状态`CTRL`完整发送后置位`slave_transport_ready`； -6. 只有`transport_ready=1`后，业务应用层才能提交新会话的业务发送请求。合规新会话从`SEQ=0`开始；若收到非零初始`ACK_NEXT`，按第46.3节执行兼容对齐。 +5. 主端收到合法初始状态后进入`M_RUN`并置位内部`master_session_ready`；从端在初始状态`CTRL`完整发送后置位内部`slave_session_ready`； +6. 只有内部`session_ready=1`后，协议层才允许在新业务帧边界置位`app_tx_ready`。业务应用层不读取`session_ready`。合规新会话从`SEQ=0`开始；若收到非零初始`ACK_NEXT`，按第46.3节执行兼容对齐。 初始响应中的`ACK_NEXT`只定义新会话从哪个序号开始，不表示对旧会话帧的累计确认。该响应必须绕过正常运行期的ACK合理性检查，不得释放任何缓存；此时旧会话缓存已经清空。`POLL_REQ/ACK`同时用于确认控制帧通路可用并取得真实接收窗口。单端重启也按本节处理，不需要从该值推断重启前的会话状态。 @@ -2147,7 +2148,7 @@ WIN_BYTES = 以当前ACK_NEXT为锚点、当前能够承诺的协议层逻辑 - 若`ACK_NEXT`相对原`SND_UNA`发生推进，按正常前进ACK清零连续失败计数；若未推进，则不得把它计作ACK进展； - 根据新窗口返回正常发送状态：有待发送帧且窗口足够时允许首次发送，否则等待窗口更新或上层业务。 -3. 如果 `ACK_NEXT != SND_NXT`，主端必须先验证区间`[ACK_NEXT, SND_NXT)`中的每个`SEQ`均恰好存在一个重传描述符及其对应缓存内容。若任一项缺失、重复或无法读取，主端必须将其判定为本地传输协议状态损坏；不得继续重传，也不得将任何未确认帧报告为成功。主端必须报告当前会话中止，撤销`transport_ready`，清空当前协议状态，置位`retrain_request`并进入`M_RETRAIN`，按第26.2节重新训练和建立新会话。 +3. 如果 `ACK_NEXT != SND_NXT`，主端必须先验证区间`[ACK_NEXT, SND_NXT)`中的每个`SEQ`均恰好存在一个重传描述符及其对应缓存内容。若任一项缺失、重复或无法读取，主端必须将其判定为本地传输协议状态损坏；不得继续重传，也不得将任何未确认帧报告为成功。主端必须报告当前会话中止，撤销`session_ready`，清空当前协议状态，置位`retrain_request`并进入`M_RETRAIN`，按第26.2节重新训练和建立新会话。 4. 上述一致性检查通过后，停止首次发送新业务帧。 5. 设置 `RETX_PTR=ACK_NEXT`。 6. 按原`SEQ`顺序重传未确认帧。 @@ -2202,7 +2203,7 @@ WIN_BYTES = 以当前ACK_NEXT为锚点、当前能够承诺的协议层逻辑帧 OUTSTANDING_BYTES == 0 FRAME_COST > AVAILABLE_BYTES link_up == 1 -transport_ready == 1 +session_ready == 1 ``` 该状态只表示当前窗口不能容纳队首待发送业务帧，不表示ACK丢失、业务帧传输失败或链路同步异常。主端必须执行以下流程： @@ -2279,7 +2280,7 @@ FRAME_COST <= AVAILABLE_BYTES 1. 停止首次发送和重传业务帧； 2. 报告窗口承诺或本地协议状态一致性故障； 3. 将全部未完成业务请求报告为会话中止，不得报告为成功； -4. 撤销`transport_ready`并清空当前传输协议状态； +4. 撤销`session_ready`并清空当前传输协议状态； 5. 触发重新训练，并按第26.2节建立新会话。 主端估算值与从端内部瞬时空闲资源可以在数值上不同，但只要双方仍满足已经公告的窗口承诺，这种差异不构成错误，也不需要专门的“窗口重新同步状态”。 @@ -2381,8 +2382,8 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N | 同确认点ACK | `ACK_NEXT`等于`SND_UNA` | 不释放缓存；可以更新同锚点`WIN_BYTES` | | 旧或越界ACK | 不满足合理性检查 | 丢弃整个`CTRL`并记录错误 | | `RETRY_REQ` | `ACK_NEXT`合法且存在未确认帧 | 暂停新帧，从`ACK_NEXT`开始Go-Back-N | -| 重传缓存一致性检查失败 | 合法未确认区间内存在描述符或缓存缺失、重复或不可读 | 报告本地传输协议状态损坏和会话中止；撤销`transport_ready`；清空当前协议状态；置位`retrain_request`并进入`M_RETRAIN` | -| 窗口承诺一致性检查失败 | `OUTSTANDING_BYTES > PEER_WIN_BYTES`，或对端无法兑现已公告窗口 | 报告窗口承诺一致性故障和会话中止；撤销`transport_ready`；清空当前协议状态；置位`retrain_request`并进入`M_RETRAIN` | +| 重传缓存一致性检查失败 | 合法未确认区间内存在描述符或缓存缺失、重复或不可读 | 报告本地传输协议状态损坏和会话中止；撤销`session_ready`；清空当前协议状态；置位`retrain_request`并进入`M_RETRAIN` | +| 窗口承诺一致性检查失败 | `OUTSTANDING_BYTES > PEER_WIN_BYTES`，或对端无法兑现已公告窗口 | 报告窗口承诺一致性故障和会话中止；撤销`session_ready`；清空当前协议状态；置位`retrain_request`并进入`M_RETRAIN` | | T_ACK_WAIT无进展 | 存在未确认帧 | 发送第一次`POLL_REQ` | | T_ACK_WAIT+T_POLL_INTERVAL无进展 | 仍无进展 | 再次发送`POLL_REQ` | | T_PROGRESS_LIMIT无进展 | 存在未确认帧 | 开始重传或判定当前轮失败 | @@ -2443,7 +2444,7 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N | `M_RETX_WAIT` | 本轮冻结范围重传结束后等待ACK进展 | 在T_ACK_WAIT及随后一个T_POLL_INTERVAL到期时请求状态；在T_PROGRESS_LIMIT判定本轮成功或失败 | | `M_RETRAIN` | 链路失步、数据链路层正在重训练、达到连续失败门限，或检测到缓存/窗口承诺一致性故障 | 清除当前协议会话状态和缓存，停止协议帧请求；由协议层故障进入时置位`retrain_request`；等待链路重新同步 | -`M_RUN`同时覆盖有未确认帧、等待窗口和暂时没有上层发送请求的情况。这些情况由`OUTSTANDING_BYTES`、窗口比较和请求有效信号区分，不需要建立互斥的等待状态。主端可对业务层宣告的就绪条件为`master_transport_ready = link_up && (MASTER_STATE == M_RUN)`。 +`M_RUN`同时覆盖有未确认帧、等待窗口和暂时没有上层发送请求的情况。这些情况由`OUTSTANDING_BYTES`、窗口比较和请求有效信号区分，不需要建立互斥的等待状态。主端内部会话状态必须满足：`M_WAIT_STATUS`和`M_RETRAIN`时`master_session_ready=0`；`M_RUN`、`M_RETX_PREP`、`M_RETX_SEND`和`M_RETX_WAIT`属于同一个有效会话，保持`master_session_ready=1`。重传期间是否接受新的业务发送帧由`app_tx_ready`单独控制，不得通过撤销`master_session_ready`表示普通反压。 `M_RETX_PREP`按以下规则冻结本轮重传范围： @@ -2489,7 +2490,7 @@ stateDiagram-v2 M_RETX_PREP --> M_RETRAIN: link_up撤销或窗口承诺故障 M_RETX_SEND --> M_RETRAIN: link_up撤销或窗口承诺故障 M_RETX_WAIT --> M_RETRAIN: link_up撤销或窗口承诺故障 - M_RETRAIN --> M_WAIT_STATUS: link_up重新置位 / 请求POLL + M_RETRAIN --> M_WAIT_STATUS: 已观察link_up=0后再次置位 / 请求POLL ``` 本状态图用于表示主要控制路径；窗口与ACK计时模式切换、同周期事件优先级及全部寄存器动作以第35.2.3节和第35.2.4节为准。 @@ -2498,7 +2499,7 @@ stateDiagram-v2 | 当前状态 | 事件和条件 | 寄存器及控制动作 | 下一状态 | |---|---|---|---| -| 任意非`M_RETRAIN`状态 | `link_up=0` | 按第26.2节中止当前会话；清零序号、窗口和协议计时，清空描述符及重传缓存，撤销`transport_ready`，并对每个已接受但未完成的业务请求报告一次中止 | `M_RETRAIN` | +| 任意非`M_RETRAIN`状态 | `link_up=0` | 按第26.2节中止当前会话；清零序号、窗口和协议计时，清空描述符及重传缓存，撤销`session_ready`，并对每个已接受但未完成的业务请求报告一次中止 | `M_RETRAIN` | | 任意非`M_RETRAIN`状态 | 收到合法`CTRL` | 先按第31.6节处理`ACK_NEXT`和`WIN_BYTES`；无效`CTRL`不改变任何可靠传输状态 | 按下列事件继续判断 | | `M_WAIT_STATUS` | 收到格式和CRC合法的初始状态 | 绕过运行期ACK合理性检查；原子设置`SND_UNA=ACK_NEXT`和`SND_NXT=ACK_NEXT`，保持`OUTSTANDING_BYTES=0`及重传缓存为空；装载`PEER_WIN_BYTES`并清除本次`POLL_REQ`等待 | `M_RUN`，即使`WIN_BYTES`为0 | | `M_WAIT_STATUS` | T_POLL_INTERVAL无合法状态 | 置位`POLL_PENDING`；保持当前新会话初始状态不变 | `M_WAIT_STATUS` | @@ -2513,19 +2514,19 @@ stateDiagram-v2 | `M_RUN` | T_PROGRESS_LIMIT无ACK进展且存在未确认帧 | 置位重传启动请求，停止接受新的首次发送请求；若有新业务帧正在发送，等待其完成 | `M_RETX_PREP` | | `M_RETX_PREP` | `ACK_NEXT==SND_NXT` | 不建立重传请求，停止进度计时 | `M_RUN` | | `M_RETX_PREP` | 主端→从端帧仍在发送 | 等待该帧完整结束；若它是首次发送的新业务帧，先完成`SND_NXT`和`OUTSTANDING_BYTES`记账 | `M_RETX_PREP` | -| 任意非`M_RETRAIN`状态 | 合法`CTRL`处理后得到`OUTSTANDING_BYTES > PEER_WIN_BYTES`，或检测到窗口承诺无法兑现 | 报告窗口承诺一致性故障和会话中止；撤销`transport_ready`；清空当前协议状态；置位`retrain_request` | `M_RETRAIN` | -| `M_RETX_PREP`或`M_RETX_SEND` | 合法未确认区间内存在描述符或缓存缺失、重复或不可读 | 报告本地传输协议状态损坏和会话中止；撤销`transport_ready`；清空当前协议状态；置位`retrain_request` | `M_RETRAIN` | +| 任意非`M_RETRAIN`状态 | 合法`CTRL`处理后得到`OUTSTANDING_BYTES > PEER_WIN_BYTES`，或检测到窗口承诺无法兑现 | 报告窗口承诺一致性故障和会话中止；撤销`session_ready`；清空当前协议状态；置位`retrain_request` | `M_RETRAIN` | +| `M_RETX_PREP`或`M_RETX_SEND` | 合法未确认区间内存在描述符或缓存缺失、重复或不可读 | 报告本地传输协议状态损坏和会话中止；撤销`session_ready`；清空当前协议状态；置位`retrain_request` | `M_RETRAIN` | | `M_RETX_PREP` | 发送器已到帧边界且仍有未确认帧 | 使用此时的`SND_UNA`和`SND_NXT`锁存`RETX_PTR`和`RETX_END`；重传不再次检查或扣减窗口额度 | `M_RETX_SEND` | | `M_RETX_SEND` | 一个重传帧发送完成 | `RETX_PTR++`；不得增加`OUTSTANDING_BYTES`或分配`SEQ` | 未到`RETX_END`则保持，否则转`M_RETX_WAIT` | | `M_RETX_SEND` | 收到合法前进ACK | 立即释放确认前缀；若`RETX_PTR`落后于新`SND_UNA`则令`RETX_PTR=SND_UNA`；清零失败计数 | 全部确认则`M_RUN`，否则继续当前冻结范围 | | `M_RETX_WAIT` | T_ACK_WAIT及随后一个T_POLL_INTERVAL到期且无进展 | 置位`POLL_PENDING`；不增加失败计数 | `M_RETX_WAIT` | | `M_RETX_WAIT` | ACK推进且本轮冻结范围已经全部发送 | 清零失败计数；剩余未确认帧重新按正常计时处理 | `M_RUN` | | `M_RETX_WAIT` | T_PROGRESS_LIMIT无进展 | 当前轮失败计数加一；小于3时令`RETX_PTR=SND_UNA`开始下一轮；形成第3次连续失败时置位`retrain_request` | 小于3时进入`M_RETX_PREP`，否则进入`M_RETRAIN` | -| `M_RETRAIN` | `link_up=1` | 保持第31.2节规定的初始协议状态；保持`transport_ready=0`；置位`POLL_PENDING` | `M_WAIT_STATUS` | +| `M_RETRAIN` | 本轮已观察到`link_up=0`，随后`link_up`重新置位 | 保持第31.2节规定的初始协议状态；保持`session_ready=0`；置位`POLL_PENDING` | `M_WAIT_STATUS` | 由协议事件触发普通状态转移时，当前完整帧必须发送结束后再切换调度请求。同步丢失或重新训练入口不适用该等待规则：未产生`tx_frame_done`的帧必须立即中止，相关描述符和记账状态随旧会话一起清除，并向业务应用层报告会话中止。 -因此，`RETRY_REQ`或T_PROGRESS_LIMIT超时到达时不得立即用旧`SND_NXT`冻结RETX_END。若当时正在首次发送新业务帧，必须先等待 `frame_tx_done`，完成该帧的`SND_NXT`和`OUTSTANDING_BYTES`更新，再以更新后的`SND_NXT`冻结重传范围。这样能够保证已经上线的最后一帧不会遗漏在Go-Back-N范围之外。 +因此，`RETRY_REQ`或T_PROGRESS_LIMIT超时到达时不得立即用旧`SND_NXT`冻结RETX_END。若当时正在首次发送新业务帧，必须先等待 `tx_frame_done`，完成该帧的`SND_NXT`和`OUTSTANDING_BYTES`更新，再以更新后的`SND_NXT`冻结重传范围。这样能够保证已经上线的最后一帧不会遗漏在Go-Back-N范围之外。 #### 35.2.4 主端事件优先级 @@ -2593,8 +2594,8 @@ stateDiagram-v2 | 当前状态 | 事件和条件 | 必须动作 | 下一状态 | |---|---|---|---| -| 任意非`S_LINK_HOLD`接收状态 | `link_up=0` | 回滚未完成候选帧；清零`RCV_NEXT`、`ACK_PENDING`和`RETRY_PENDING`，释放未提交接收资源并重新计算`WIN_BYTES`；撤销`transport_ready` | `S_LINK_HOLD` | -| 任意非`S_LINK_HOLD`接收状态 | 无法为依据已公告窗口合法发送的期望`SEQ`帧或其重传提供已承诺资源 | 报告窗口承诺一致性故障和会话中止；回滚当前候选帧；撤销`transport_ready`；复位当前协议状态并置位`retrain_request` | `S_LINK_HOLD` | +| 任意非`S_LINK_HOLD`接收状态 | `link_up=0` | 回滚未完成候选帧；清零`RCV_NEXT`、`ACK_PENDING`和`RETRY_PENDING`，释放未提交接收资源并重新计算`WIN_BYTES`；撤销`session_ready` | `S_LINK_HOLD` | +| 任意非`S_LINK_HOLD`接收状态 | 无法为依据已公告窗口合法发送的期望`SEQ`帧或其重传提供已承诺资源 | 报告窗口承诺一致性故障和会话中止；回滚当前候选帧；撤销`session_ready`；复位当前协议状态并置位`retrain_request` | `S_LINK_HOLD` | | `S_LINK_HOLD` | `link_up=1` | 保持`RCV_NEXT=0`，根据真实资源重新计算`WIN_BYTES`，等待`POLL_REQ` | `S_EXPECT` | | `S_EXPECT` | `DATA`的CRC和格式正确、`SEQ==RCV_NEXT`且资源足够 | 提交一次；`RCV_NEXT++`；`ACK_PENDING=1` | `S_EXPECT` | | `S_EXPECT` | `DATA`发生第32.2节任一错误 | 丢弃；`RCV_NEXT`不变；`RETRY_PENDING=1`；`ACK_PENDING=1` | `S_RETRY_WAIT` | @@ -2653,7 +2654,7 @@ stateDiagram-v2 选择状态`CTRL`时按第35.4.3节锁存字段。当前正在发送的从端业务帧不得被新到达的ACK、`RETRY_REQ`状态或`POLL_REQ`响应中断；这些事件只置位`ACK_PENDING`，并在下一个完整帧边界参与仲裁。发送调度状态不得阻塞第35.4节接收控制器。 -同步丢失是上述不可抢占规则的例外。未产生`frame_tx_done`的`CTRL`立即中止且不保留原快照；未产生`frame_tx_done`的无确认`UL DATA`不得产生`app_tx_completed`。如果该业务请求已经产生`app_tx_accepted`，从端必须向业务应用层报告会话中止，不得自动带入新会话重新提交。 +同步丢失是上述不可抢占规则的例外。未产生`tx_frame_done`的`CTRL`立即中止且不保留原快照；未产生`tx_frame_done`的无确认`UL DATA`不得产生`COMPLETED`结果。如果该完整业务请求已经通过业务发送流接口被接受，从端必须向业务应用层返回`ABORTED`结果，不得自动带入新会话重新提交。 ### 35.6 RTL接口事件契约 @@ -2665,7 +2666,7 @@ stateDiagram-v2 | `business_candidate_error` | `DATA`解析器或接收控制器 | 第32.2节定义的错误，候选帧不得提交 | | `ctrl_valid` | `CTRL`解析器 | CRC、`FLAGS`和`WIN_BYTES`均合法 | | `frame_tx_start` | 发送调度器 | 完整帧字段已经锁存，本帧不可被抢占 | -| `frame_tx_done` | 发送器 | 完整帧最后一位已经发送，并同时报告帧类别及业务`SEQ` | +| `tx_frame_done` | 发送器 | 单周期脉冲；完整线路帧最后一位已经发送，并关联发送开始时锁存的帧类别及业务`SEQ` | | `ack_progress` | 主端`CTRL`处理器 | 合法`ACK_NEXT`使`SND_UNA`向前推进 | | `status_launch` | 从端发送调度器 | 最新状态快照已经锁存并开始发送 | | `link_up_rise` | 数据链路层接口 | `link_up`从0变为1；传输协议层进入新会话状态查询，但尚不得恢复业务 | @@ -2706,7 +2707,7 @@ stateDiagram-v2 3. 合法`CTRL`处理后若`OUTSTANDING_BYTES > PEER_WIN_BYTES`，或者任一端无法兑现已经公告的窗口承诺，必须报告一致性故障和会话中止并进入重新训练；不得通过分批重传或等待窗口增大继续旧会话。 4. 从端→主端业务不得进入链路重传或窗口控制状态机。 5. 主端业务缓存满时可以丢弃从端业务帧，但必须继续解析线路并保证`CTRL`接收。 -6. 任一方向同步丢失都必须使双方复位传输协议状态；重新训练完成后从`SEQ=0`建立新会话。 +6. 任一方向同步丢失都必须使双方复位传输协议状态；合规从端在新会话初始响应中发送`ACK_NEXT=0`，主端按第46.3节以实际收到的初始值执行防御性对齐。 # 第六篇 分层架构与层间接口 @@ -2808,11 +2809,11 @@ WAIT_BOUNDARY 外层`LEN`合法后，数据链路层按确定字数持续解扰并输出字段和载荷。帧体中的任何`SOF`或`IDLE`相同码字都不得被识别为新边界。 -逻辑帧最后一个字输出时，必须同时置位 `rx_data_last`。 +数据链路层必须暂存逻辑帧最后一个字，直到随后线路CRC字已经接收并完成比较；输出该逻辑末字时，必须同时置位`rx_data_last`、`rx_crc_valid`和`rx_crc_pass`。 #### 37.4.4 RX_CRC -CRC字段必须解扰，但不得通过 `rx_data` 输出。数据链路层比较收到的CRC与本帧计算结果，并产生一次CRC结果事件。 +CRC字段必须解扰，但不得通过`rx_data`输出。数据链路层比较收到的CRC与本帧计算结果，并把比较结果与此前暂存的逻辑末字对齐输出。该末字暂存不等同于完整帧缓存。 CRC处理完成后，下一个32位线路字重新作为预期帧边界进行检查。 @@ -2912,6 +2913,19 @@ CRC失败时必须回滚全部候选数据： | 主端接收`UL` `DATA` | 直接丢弃，不请求重传 | | 任意端接收`CTRL` | 丢弃`CTRL`，不更新ACK、窗口或重传状态 | + +#### 38.4.3 外层长度非法导致候选帧中止 + +数据链路层以`rx_frame_abort`报告已经识别`SOF`、但因外层`LEN`非法而无法继续定位帧尾的候选帧。传输协议层必须根据已经锁存的候选帧类型和接收方向执行： + +| 接收端及候选类型 | 处理 | +|---|---| +| 从端接收`DL DATA` | 回滚候选帧，不推进`RCV_NEXT`，置位`RETRY_PENDING`和`ACK_PENDING` | +| 主端接收`UL DATA` | 回滚并丢弃，不发送确认且不请求重传 | +| 任意端接收`CTRL` | 回滚并丢弃，不更新ACK、窗口或重传状态 | + +`rx_frame_abort`只描述当前候选帧不能完成，不单独终止协议会话。数据链路层随后按第25章执行边界恢复；只有恢复失败并撤销`link_up`时，传输协议层才复位整个会话。 + ### 38.5 `DATA`载荷处理边界 传输协议层不得解析`PAYLOAD`内部的业务字段。`DATA`通过`CRC32`、外层`LEN`、方向相关的`SEQ`和接收资源检查后，即可按第38.7节决定提交或回滚。 @@ -2920,42 +2934,39 @@ CRC失败时必须回滚全部候选数据： ### 38.6 `CTRL`检查 -传输协议层在CRC通过后检查： +传输协议层必须先检查CRC、`FLAGS`编码、接收方向和当前状态。`RESERVED`必须忽略，不参与合法性判断。其余字段按`FLAGS`分别处理： -- `FLAGS`是否为`ACK/UPDATE`、`RETRY_REQ`或`POLL_REQ`； -- `WIN_BYTES`是否为4字节整数倍； -- `ACK_NEXT`是否位于当前合理序号区间； -- `CTRL`方向和当前端点状态是否允许执行对应动作。 +| `CTRL`类别 | 合法方向 | `ACK_NEXT`和`WIN_BYTES`处理 | +|---|---|---| +| `POLL_REQ` | 主端发送、从端接收 | 两个字段只为保持统一帧布局而占位；从端不解析、不检查合理性，也不得据此更新任何序号或窗口状态 | +| 运行期`ACK/UPDATE` | 从端发送、主端接收 | `WIN_BYTES`必须为4字节整数倍；`ACK_NEXT`必须通过当前运行期累计ACK合理性检查 | +| 运行期`RETRY_REQ` | 从端发送、主端接收 | `WIN_BYTES`必须为4字节整数倍；先检查并处理`ACK_NEXT`，再按第32.3节决定是否进入Go-Back-N | +| 新会话初始`ACK/UPDATE` | 从端发送、处于`M_WAIT_STATUS`的主端接收 | `WIN_BYTES`必须为4字节整数倍；绕过运行期ACK区间检查，按第26.2.5节以收到的`ACK_NEXT`初始化`SND_UNA`和`SND_NXT` | -任一项不满足时必须丢弃整个`CTRL`，不得部分更新窗口、确认点或重传状态。 +主端发送的`POLL_REQ`仍按第31.2节把`ACK_NEXT`和`WIN_BYTES`置0，CRC覆盖这两个字段的实际值；该发送约束不要求从端解析或校验其数值。任一适用检查不满足时必须丢弃整个`CTRL`，不得部分更新窗口、确认点或重传状态。 ### 38.7 协议接受条件 -`DL` `DATA`的接受条件为： +`DL DATA`的接受条件为： ```text DL_ACCEPT = CRC通过 AND 外层格式合法 AND SEQ == RCV_NEXT - AND 接收资源足够 + AND 从端接收资源足够 ``` -`UL` `DATA`的接受条件为： +`UL DATA`向业务应用层提交的条件为： ```text -UL_ACCEPT = CRC通过 - AND 外层格式合法 +UL_DELIVER = CRC通过 + AND 外层格式合法 + AND 主端业务接收资源足够 ``` -`UL`采用无确认接收，主端不得因`SEQ`跳变或重复拒绝CRC和格式正确的帧。 +`UL`采用无确认接收。主端不得因`SEQ`跳变或重复拒绝CRC和格式正确的帧；主端业务接收资源不足时，可以丢弃该完整候选帧，但必须继续消费线路数据、维持帧边界，不发送确认且不请求重传。 -`CTRL`的执行条件为： - -```text -CTRL_ACCEPT = CRC通过 - AND CTRL字段合法 - AND ACK_NEXT合理 -``` +`CTRL`必须按第38.6节根据`FLAGS`、方向和当前状态分别判定，不得使用一个统一的`ACK_NEXT`合理性条件处理全部`CTRL`。 ### 38.8 接收暂存和提交 @@ -2967,10 +2978,10 @@ CTRL_ACCEPT = CRC通过 候选帧处理顺序为： ```text -rx_data_valid → 写候选暂存区 -rx_data_last → 候选数据接收完成，但仍不提交 -rx_crc_valid → 获取最终CRC结果 -协议检查 → 检查SEQ和资源 +rx_data_valid → 写候选暂存区 +rx_data_last && rx_crc_valid && rx_crc_pass → 候选数据接收完成并取得CRC通过结论 +rx_data_last && rx_crc_valid && !rx_crc_pass → 回滚CRC失败候选帧 +协议检查 → CRC通过后检查SEQ和资源 commit → 向业务应用层提交 rollback → 丢弃候选暂存内容 ``` @@ -3198,14 +3209,14 @@ Master传输协议层：rollback并直接丢弃 ### 40.4 外层`LEN`错误 ```text -数据链路层： -检测OUTER_LENGTH_ERROR +数据链路层：检测OUTER_LENGTH_ERROR并产生rx_frame_abort ↓ -rx_frame_abort=1 +传输协议层：回滚当前候选帧 + ├─ 从端接收DL DATA：RETRY_PENDING=1，ACK_PENDING=1 + ├─ 主端接收UL DATA：丢弃，不请求重传 + └─ CTRL：丢弃，不更新协议状态 ↓ -传输协议层rollback - ↓ -数据链路层进入边界恢复 +数据链路层进入边界恢复；恢复失败时撤销link_up ``` ### 40.5 `DATA`载荷的业务处理 @@ -3224,9 +3235,9 @@ rx_frame_abort=1 1. 数据链路层必须独立解析外层`LEN`，以确定帧结束和CRC位置。 2. 数据链路层不得要求传输协议层返回帧结束位置。 -3. rx_data_valid期间的数据必须被视为候选数据，CRC通过前不得提交。 -4. 每个正常结束的候选帧必须产生一次且仅一次rx_crc_valid。 -5. 外层`LEN`非法而无法定位CRC时，必须产生rx_frame_abort，不得让协议层无限等待CRC结果。 +3. `rx_data_valid`期间的数据必须被视为候选数据，CRC通过前不得提交。 +4. 每个正常结束的候选帧必须在逻辑末字周期产生一次且仅一次`rx_crc_valid`，并使`rx_data_last`与`rx_crc_valid`同周期有效。 +5. 外层`LEN`非法而无法定位CRC时，必须产生`rx_frame_abort`；该候选帧不再产生`rx_data_last`或`rx_crc_valid`。 6. 接收接口不得使用能够暂停物理数据流的反压。 7. 发送接口必须具有帧开始前及帧间反压能力。 8. 一帧开始后不得在帧内暂停tx_data流。 @@ -3235,7 +3246,7 @@ rx_frame_abort=1 11. 主端重传缓存必须保存CRC生成前、加扰前的协议帧内容。 12. `FRAME_COST`必须按不含CRC的逻辑帧长度计算，不得按重传RAM实际存储字节数计算。 13. `DL`和`UL`名称必须按第3章固定方向使用，不得相对当前端点反转含义。 -14. 任一方向同步丢失都必须终止当前会话并清除传输协议状态；重新训练完成后，双方从`SEQ=0`建立新会话。 +14. 任一方向同步丢失都必须终止当前会话并清除传输协议状态；合规从端在新会话初始响应中发送`ACK_NEXT=0`。主端仍按第46.3节以实际收到的初始`ACK_NEXT`执行防御性对齐。 ## 42. 时序预算与实现风险 @@ -3287,47 +3298,50 @@ rx_crc_valid rx_crc_pass rx_frame_abort -rx_error_code ``` | 信号 | 方向 | 定义 | |---|---|---| | `rx_data[31:0]` | 链路层→协议层 | 解扰后的候选帧字，包含`SOF`和协议字段，不包含CRC | -| `rx_data_valid` | 链路层→协议层 | 当前rx_data属于候选帧 | -| `rx_data_last` | 链路层→协议层 | 当前字是逻辑帧的最后一个字 | -| `rx_crc_valid` | 链路层→协议层 | 当前候选帧的CRC结果有效 | -| `rx_crc_pass` | 链路层→协议层 | 在rx_crc_valid有效时表示CRC比较结果 | -| `rx_frame_abort` | 链路层→协议层 | 当前候选帧无法正常完成，协议层必须立即回滚 | -| `rx_error_code` | 链路层→协议层 | 帧中止或边界错误原因 | +| `rx_data_valid` | 链路层→协议层 | 当前`rx_data`属于候选帧 | +| `rx_data_last` | 链路层→协议层 | 当前字是逻辑帧的最后一个字；正常结束时必须与`rx_crc_valid`同周期有效 | +| `rx_crc_valid` | 链路层→协议层 | 当前候选帧的CRC结果有效；必须与该候选帧的`rx_data_last`同周期有效 | +| `rx_crc_pass` | 链路层→协议层 | 在`rx_crc_valid`有效时表示CRC比较结果 | +| `rx_frame_abort` | 链路层→协议层 | 已经开始输出的候选帧因外层`LEN`非法而无法正常完成；协议层必须立即回滚该候选帧 | -### 43.3 错误码 +链路可用状态使用第46.1节定义的`link_up`电平表示。`link_up=0`时，协议层必须回滚所有未完成候选帧并复位当前会话，因此链路层不需要再用`rx_frame_abort`重复报告同步丢失。 -建议至少支持： +### 43.3 错误表示规则 -```text -OUTER_LENGTH_ERROR -BOUNDARY_ERROR -SYNC_LOST -``` +接收错误必须按以下方式唯一表示： -CRC失败使用 `rx_crc_valid=1` 且 `rx_crc_pass=0` 表示，不要求再使用rx_error_code重复报告。 +| 情况 | 接口表示 | 协议层动作 | +|---|---|---| +| 外层`LEN`非法 | `rx_frame_abort=1` | 立即回滚且不再等待`rx_data_last`或`rx_crc_valid`；从端的`DL DATA`按业务帧错误置位`RETRY_PENDING`和`ACK_PENDING`，主端的`UL DATA`及任意`CTRL`直接丢弃 | +| CRC校验失败 | `rx_crc_valid=1`且`rx_crc_pass=0` | 丢弃已完整输出的候选帧；是否产生`RETRY_REQ`由传输协议状态决定 | +| 边界异常但链路层恢复成功 | `link_up`保持为1，不向协议层报告单独错误 | 链路层内部完成边界恢复；协议层不执行会话复位 | +| 边界恢复失败、同步丢失或链路资源不可用 | `link_up=0` | 回滚所有未完成候选帧并按第26.2节复位当前会话 | + +`rx_frame_abort`只终止当前候选帧，不表示链路失步。边界错误类型、同步丢失原因及资源故障原因可以保存在链路层诊断寄存器或计数器中，但不得作为传输协议状态机的额外控制输入。 ### 43.4 接口时序 -正常`DATA`： +正常`DATA`或`CTRL`候选帧使用以下接口时序： ```text -周期： 0 1 2 ... N N+1 -rx_data： SOF SEQ/LEN PAYLOAD - -rx_data_valid： 1 1 1 0 -rx_data_last： 0 0 最后字=1 0 -rx_crc_valid： 0 0 0 1 -rx_crc_pass： X X X PASS/FAIL +接口周期： 0 1 2 ... N +rx_data： SOF 协议字段 PAYLOAD/字段末字 +rx_data_valid： 1 1 1 +rx_data_last： 0 0 1 +rx_crc_valid： 0 0 1 +rx_crc_pass： X X PASS/FAIL ``` -CRC结果对应此前最近一个已经产生 `rx_data_last` 的候选帧。 +线路上的CRC字位于逻辑末字之后。为了形成上述接口时序，数据链路层必须暂存逻辑末字，在收到并比较CRC字后，同时输出该末字、`rx_data_last`、`rx_crc_valid`和`rx_crc_pass`。`rx_crc_pass`仅在`rx_crc_valid=1`时有效。 -外层`LEN`非法时，数据链路层可能已经输出`SOF`及`SEQ`/`LEN`字。随后必须产生 `rx_frame_abort`，传输协议层不得继续等待rx_data_last或rx_crc_valid。 +这一对齐只需要末字及相关CRC状态的流水暂存，不要求数据链路层缓存完整帧。CRC字所在的线路周期不向协议层输出`rx_data`，因此可以用于输出暂存末字；实现必须同时支持CRC后立即到来的下一帧`SOF`或`IDLE`，不得降低连续线路帧的吞吐率。 + +协议层必须在末字周期原子处理结果：`rx_crc_pass=1`时才允许继续进行`SEQ`、资源和控制字段检查；`rx_crc_pass=0`时回滚整个候选帧。外层`LEN`非法时，数据链路层可能已经输出`SOF`及`SEQ`/`LEN`字，随后必须产生`rx_frame_abort`；该候选帧不再产生`rx_data_last`或`rx_crc_valid`。 ### 43.5 无接收反压 @@ -3364,7 +3378,7 @@ tx_frame_done | `tx_data_valid` | 协议层→链路层 | 当前tx_data有效 | | `tx_data_ready` | 链路层→协议层 | 数据链路层当前能够接收逻辑帧字 | | `tx_data_last` | 协议层→链路层 | 当前字是逻辑帧的最后一个字 | -| `tx_frame_done` | 链路层→协议层 | 自动追加的CRC最后一位已经发送到线路 | +| `tx_frame_done` | 链路层→协议层 | 单周期完成脉冲；自动追加的CRC最后一位已经发送到线路 | ### 44.3 反压规则 @@ -3389,70 +3403,108 @@ tx_frame_done ### 44.4 发送完成语义 -`tx_data_last`握手只表示数据链路层已经接受逻辑帧的最后一个字。只有 `tx_frame_done` 才表示： +`tx_data_valid && tx_data_ready && tx_data_last`只表示数据链路层已经接受逻辑帧的最后一个字。数据链路层仍须生成、追加、扰码并发送CRC；只有CRC最后一位完成线路发送后，才能产生`tx_frame_done`。 -- CRC已经生成； -- CRC已经完成加扰； -- 完整线路帧已经发送结束。 +`tx_frame_done`必须是发送接口时钟域中的单周期脉冲，并满足： -重传计时、发送描述符推进及无确认方向的线路发送完成通知应以tx_frame_done为边界。 +1. 在`link_up=1`的正常发送过程中，每个完整发送的`DATA`或`CTRL`产生一次且仅一次`tx_frame_done`； +2. `tx_frame_done`必须晚于对应帧的`tx_data_last`握手，不得与尚未接受完整逻辑帧的请求关联； +3. 每个方向只允许存在一个已经由数据链路层接受、但尚未产生`tx_frame_done`的普通逻辑帧；传输协议层必须从该帧`SOF`握手起保存帧类别、业务`SEQ`及请求上下文，直至收到按序返回的`tx_frame_done`或会话中止；数据链路层无需接收或返回帧标识； +4. 未完成CRC发送的帧、被中止的帧以及仅完成`tx_data_last`握手的帧不得产生有效完成事件； +5. 新帧可以在`tx_frame_done`同周期或后续周期开始，但新帧的锁存信息不得覆盖本周期完成事件对应的信息； +6. `link_up`撤销与`tx_frame_done`同周期发生时，会话终止具有最高优先级，该完成脉冲不得用于推进序号、释放状态或产生`COMPLETED`结果。 + +确定性时序示例如下： + +```text +周期： N N+1或更晚 +tx_data_valid： 1 0 +tx_data_ready： 1 X +tx_data_last： 1 0 +tx_frame_done： 0 1 +事件： 逻辑末字握手 CRC最后一位完成发送 +``` + +重传计时、首次发送记账、重传指针推进、状态`CTRL`上线确认、`POLL_REQ`间隔重启，以及无确认方向的线路发送完成通知，均必须以有效的`tx_frame_done`脉冲为边界。`tx_data_ready`只表示逻辑字接受能力，不得代替`tx_frame_done`。 ## 45. 传输协议层与业务应用层接口 -### 45.1 业务发送接口 +业务应用层与传输协议层之间使用两组独立的32位流式数据接口：一组用于业务发送，一组用于业务接收。接口只传输`DATA PAYLOAD`，不传输`SOF`、`SEQ`、`LEN`、CRC或扰码后的内容。 -建议接口包含： +### 45.1 业务发送流接口 ```text +app_tx_data[31:0] app_tx_valid app_tx_ready -app_tx_len -app_tx_data -app_tx_data_valid -app_tx_data_ready -app_tx_data_last -app_tx_tag +app_tx_last ``` -业务应用层只提供`DATA`及其有效载荷，不提供`SOF`、`SEQ`、CRC或扰码数据。传输协议层负责分配`SEQ`、缓存可靠方向帧并生成发送逻辑帧。 +| 信号 | 方向 | 定义 | +|---|---|---| +| `app_tx_data[31:0]` | 业务应用层→传输协议层 | 当前32位有效载荷字 | +| `app_tx_valid` | 业务应用层→传输协议层 | 当前`app_tx_data`有效 | +| `app_tx_ready` | 传输协议层→业务应用层 | 传输协议层能够接受当前有效载荷字 | +| `app_tx_last` | 业务应用层→传输协议层 | 当前字是本业务帧有效载荷的最后一个字 | -`transport_ready`只表示新会话已经建立，不等同于单个业务请求的`app_tx_ready`。可靠`DL`方向只有在协议层能够接收并保存完整载荷及其请求信息时才允许完成请求握手；完整载荷保存完成后产生一次`app_tx_accepted`。实现可以在窗口不足时先缓存已接受请求，也可以将`app_tx_ready`保持为0并要求业务应用层保持请求，但必须保证：已经产生`app_tx_accepted`的请求由协议层持续保存，直至产生且只产生一次`app_tx_completed`或`app_tx_aborted`。尚未产生`app_tx_accepted`的请求不得分配`SEQ`、不得写入重传描述符，也不得在会话终止时报告`app_tx_aborted`。 +一次数据传输在`app_tx_valid && app_tx_ready`时发生。业务应用层必须提供1～258个完整32位字，并在最后一个字上置位`app_tx_last`，因此协议层计数得到的`LEN`自然满足`4 <= LEN <= 1032`且为4字节整数倍。接口不支持不足32位的末字。 -### 45.2 业务发送结果 +传输协议层根据成功握手的字数生成`LEN`。在业务帧起始位置，只有同时满足以下条件时才允许置位`app_tx_ready`： -建议区分： +1. `session_ready=1`； +2. 当前没有正在接收的业务发送帧； +3. 本地请求缓存至少能够保存一个最大1032 B有效载荷及其内部描述信息。 + +一旦业务帧第一个字完成握手，传输协议层必须为该帧保留最大载荷缓存，并保持`app_tx_ready=1`直至最后一个字完成握手；即使内部`session_ready`在帧中途撤销，也必须继续接收该帧。允许业务应用层在帧内暂时撤销`app_tx_valid`；传输协议层不得把数据间隙解释为帧结束。 + +最后一个字完成握手表示完整业务请求已经被传输协议层接受并保存。此前不得为该请求分配业务`SEQ`、建立重传描述符或产生发送完成结果。如果内部`session_ready`在首字握手后、末字握手前曾经撤销，协议层必须锁存本帧的中止标志；末字握手后不得为该帧分配`SEQ`或发送到新会话，而应按接受顺序产生一次`app_tx_aborted`。`session_ready`撤销与末字握手同周期发生时同样按中止处理。 + +窗口不足只阻止协议层把已经接受的业务请求首次发送到链路，不得破坏已经完成接口握手并保存的请求。协议层可以在本地请求缓存允许的范围内继续接受后续业务帧；缓存不足时在下一帧开始前拉低`app_tx_ready`。 + +### 45.2 发送结果接口 + +业务发送流接口的最后一个字握手只表示请求已经被协议层完整接受，不表示该请求已经达到传输完成条件。发送结果使用两个独立事件信号： ```text -app_tx_accepted app_tx_completed app_tx_aborted ``` -| 事件 | 含义 | -|---|---| -| `app_tx_accepted` | 传输协议层已经接收并保存业务请求 | -| `app_tx_completed` | 该方向规定的完成条件已经满足 | -| `app_tx_aborted` | 请求已经被接受，但同步丢失使当前会话终止，请求未取得确定的完成结果 | +| 信号 | 方向 | 定义 | +|---|---|---| +| `app_tx_completed` | 传输协议层→业务应用层 | 单周期脉冲；最早一个尚未报告结果的已接受业务请求达到完成条件 | +| `app_tx_aborted` | 传输协议层→业务应用层 | 单周期脉冲；最早一个尚未报告结果的已接受业务请求因会话终止而中止 | -`DL`的`app_tx_completed`表示对应`SEQ`已经被累计ACK确认。`UL`的`app_tx_completed`只表示完整线路帧已经发送，不保证主端接收成功。每个已经产生`app_tx_accepted`但尚未产生`app_tx_completed`的请求，在会话终止时必须产生一次`app_tx_aborted`；同一请求不得同时报告完成和中止。若接口实现`app_tx_tag`，完成和中止事件必须返回对应标签；否则必须按请求接受顺序报告。业务应用层依据自身语义决定是否在新会话中重新提交中止请求。 +结果接口必须满足： -### 45.3 业务接收接口 +1. `app_tx_completed`和`app_tx_aborted`均为业务接口时钟域中的单周期脉冲，同一周期不得同时置位； +2. 每个已经完整接受的业务请求必须产生一次且仅产生一次结果，同一请求不得同时报告完成和中止； +3. 结果严格按照完整业务帧在发送流接口上的接受顺序输出，因此不需要请求标签； +4. `DL`业务帧在对应`SEQ`被累计ACK确认后形成完成结果；`UL`业务帧在产生有效`tx_frame_done`后形成完成结果，该结果不保证主端接收成功； +5. 已接受请求在取得完成结果前遇到会话终止时形成中止结果；业务应用层依据自身语义决定是否在新会话中重新提交； +6. 业务应用层必须在每个周期接收结果，本接口不提供反压； +7. 如果一次累计ACK或会话终止同时形成多个结果，传输协议层必须暂存尚未输出的结果，并按接受顺序每周期最多输出一个，不得覆盖或丢失； +8. 接口跨时钟域时，实现必须增加可靠的事件同步或异步队列，不得直接跨时钟传递单周期脉冲。 -建议接口包含： +### 45.3 业务接收流接口 ```text +app_rx_data[31:0] app_rx_valid app_rx_ready -app_rx_len -app_rx_data -app_rx_data_valid -app_rx_data_ready -app_rx_data_last +app_rx_last ``` -业务应用层接口可以使用反压，因为传输协议层负责接收缓存和窗口管理。只有协议接受帧才能出现在该接口。 +| 信号 | 方向 | 定义 | +|---|---|---| +| `app_rx_data[31:0]` | 传输协议层→业务应用层 | 当前32位有效载荷字 | +| `app_rx_valid` | 传输协议层→业务应用层 | 当前`app_rx_data`有效 | +| `app_rx_ready` | 业务应用层→传输协议层 | 业务应用层能够接受当前有效载荷字 | +| `app_rx_last` | 传输协议层→业务应用层 | 当前字是本业务帧有效载荷的最后一个字 | -对于`DL`，从端只有在完整帧已经可靠写入接收缓存后才能推进`RCV_NEXT`并触发累计ACK。 +一次数据传输在`app_rx_valid && app_rx_ready`时发生。该接口只输出已经通过CRC、格式、序号及资源检查并完成协议提交的`PAYLOAD`，不得输出候选帧、协议头或CRC字段。 + +业务应用层可以通过`app_rx_ready`实施反压。反压期间传输协议层必须保持`app_rx_valid`和`app_rx_data`稳定，并保留尚未输出的完整业务帧；从端据此维护并公告`WIN_BYTES`。一帧开始输出后允许在任意字处暂停，帧边界仅由`app_rx_last`确定。 ## 46. 链路状态与恢复接口 @@ -3462,13 +3514,11 @@ app_rx_data_last ```text link_up -tx_frame_abort ``` | 信号 | 含义 | |---|---| | `link_up` | 电平为1表示`UL`、`DL`及运行入口过程均已完成，数据链路层能够正常收发普通协议帧；电平为0表示数据链路层未就绪，传输协议层必须保持会话复位状态 | -| `tx_frame_abort` | 此前接受的逻辑帧未完成线路发送；不得将其视为`tx_frame_done` | `link_up`必须是协议层可见的聚合电平： @@ -3476,164 +3526,216 @@ tx_frame_abort link_up = ul_sync_up && dl_sync_up && run_entry_complete ``` +普通逻辑帧已经被数据链路层接受、但未能完整发送CRC最后一位时，数据链路层不得产生`tx_frame_done`，并必须撤销`link_up`。发送中止统一由`link_up`撤销表示。 + `link_up`从1变为0时，传输协议层必须立即按第26.2.3节终止并复位当前会话；`link_up=0`期间不得发送或接受普通`DATA`和`CTRL`，不得运行协议定时器。`link_up`重新变为1后，主端进入`M_WAIT_STATUS`并发起初始`POLL_REQ`，从端进入`S_EXPECT`并等待该请求。`ul_sync_up`、`dl_sync_up`、`sync_lost`、`retrain_busy`和`retrain_done`可以作为数据链路层内部状态或诊断输出，但不得作为传输协议状态机的独立控制输入。 ### 46.2 传输协议层向数据链路层 ```text retrain_request -sync_reset_request ``` -| 请求 | 数据链路层动作 | 传输协议层动作 | -|---|---|---| -| `retrain_request` | 根据第26.2.2节判断重新训练方向并完成同步恢复 | 撤销`transport_ready`并复位当前协议会话 | -| `sync_reset_request` | 按第26.3节发送`SYNC_RESET`，使对端进入相应训练状态 | 撤销`transport_ready`并复位当前协议会话 | +`retrain_request`是保持型请求，采用以下确定性握手： + +1. 传输协议层因连续重传失败、缓存一致性故障或窗口承诺故障要求重新训练时，置位`retrain_request`并进入`M_RETRAIN`或`S_LINK_HOLD`； +2. 数据链路层接受请求后必须先撤销`link_up`，锁存本次重新训练请求，并按第26.2.2节判断重新训练方向；保持为1的请求不得重复启动新的训练轮次； +3. 传输协议层观察到`link_up=0`后才允许撤销`retrain_request`，并记录本次重新训练已经经过链路不可用阶段； +4. 数据链路层完成规定的重新训练和运行入口过程后重新置位`link_up`； +5. 协议层只有在已经观察到本次`link_up=0`、随后又观察到`link_up=1`时，才能退出重训练保持状态并开始新会话初始化。 + +主端数据链路层处理`retrain_request`时，如果`DL`仍具备发送完整固定帧的条件，则按第26.3节先连续发送20个`SYNC_RESET`，再进入相应训练状态；如果`DL`已经无法可靠传送固定帧，则直接依靠对端运行期监测进入训练。是否发送`SYNC_RESET`由数据链路层根据链路状态自行决定，不需要第二个协议层请求接口。 ### 46.3 新会话恢复门控 -进入重新训练时，传输协议层必须停止业务收发并执行第26.2.3节的协议复位。只重新训练`DL`时，仍可信的`UL`只能承载链路层训练和状态信息，不能承载原会话普通协议帧。 +传输协议层内部维护`session_ready`，用于表示业务序号、窗口及控制帧通路已经完成新会话初始化。该状态不是层间端口，也不要求输出给业务应用层；业务发送能力必须统一反映到`app_tx_ready`。 -`link_up`重新置位后，主端进入`M_WAIT_STATUS`并发送`POLL_REQ`；从端必须以`ACK_NEXT=0`和当前真实接收容量返回初始状态。主端只检查响应帧的格式和CRC，不以`ACK_NEXT`的具体取值决定是否进入`M_RUN`；主端把收到的值作为新会话起始序号，同时设置`SND_UNA`和`SND_NXT`，不得把它按运行期累计ACK处理。 +进入重新训练时，传输协议层必须停止普通协议帧收发并执行第26.2.3节的协议复位，同时清零内部`session_ready`。只重新训练`DL`时，仍可信的`UL`只能承载链路层训练和状态信息，不能承载原会话普通协议帧。 -主端的确定性就绪条件为： +`link_up`重新置位后，主端进入`M_WAIT_STATUS`并发送`POLL_REQ`；从端必须以`ACK_NEXT=0`和当前真实接收容量返回初始状态。主端必须确认响应为CRC和格式合法的初始`ACK/UPDATE`，但不以`ACK_NEXT`的具体取值决定是否进入`M_RUN`；主端把收到的值作为新会话起始序号，同时设置`SND_UNA`和`SND_NXT`，不得把它按运行期累计ACK处理。 + +主端内部状态按以下规则维护： ```text -master_transport_ready = link_up && (MASTER_STATE == M_RUN) +M_WAIT_STATUS、M_RETRAIN： + master_session_ready = 0 + +M_RUN、M_RETX_PREP、M_RETX_SEND、M_RETX_WAIT： + master_session_ready = link_up ``` -从端在初始状态`CTRL`产生`tx_frame_done`后置位`slave_transport_ready`。任一端的`link_up`撤销时，必须立即撤销相应的`transport_ready`。 +进入普通重传状态不终止当前会话，因此不得清零`master_session_ready`。重传期间如果暂时禁止接受新的业务发送帧，只拉低`app_tx_ready`。 + +从端在`link_up`重新置位后保持`slave_session_ready=0`并等待初始`POLL_REQ`。针对该请求的初始状态`CTRL`产生有效`tx_frame_done`后，置位`slave_session_ready`；进入`S_RETRY_WAIT`不终止会话，因此保持该状态。进入`S_LINK_HOLD`、检测到协议一致性故障或`link_up=0`时清零。 + +在新业务帧边界，协议层只能在内部`session_ready=1`且本地请求缓存满足第45.1节要求时置位`app_tx_ready`。业务应用层不需要也不得依赖`session_ready`；它只根据`app_tx_valid/app_tx_ready`握手提交数据，并通过`app_tx_completed`或`app_tx_aborted`获得最终结果。 从端发送非零初始`ACK_NEXT`属于不符合本规范的行为，主端可以记录诊断信息；但为避免序号冲突，只要响应帧本身合法，主端仍必须把该值作为新会话起始序号，并使用其中的`WIN_BYTES`完成初始化。这一赋值不恢复任何旧会话状态。 +### 46.4 层间接口通用时序规则 + +1. 每组层间接口必须在具体实现中声明所属时钟域和复位极性；跨时钟域时必须使用可靠的同步器、握手或异步队列，不得直接跨域传递单周期事件。 +2. `link_up`和`retrain_request`为保持型电平；`rx_frame_abort`、`rx_crc_valid`、`tx_frame_done`、`app_tx_completed`和`app_tx_aborted`为各自接口时钟域中的单周期事件。 +3. 对带`valid/ready`握手的发送接口，发送方在`valid=1 && ready=0`期间必须保持`data`和`last`稳定；一次传输只在`valid && ready`同周期有效时发生。 +4. 复位期间`valid`、所有完成或中止事件以及`link_up`必须为0；传输协议层的`session_ready`必须为0。解除复位后，只有完成规定的链路训练和新会话初始化才能恢复普通业务。 +5. `link_up`撤销与`tx_frame_done`、接收帧完成、合法ACK或协议定时器到期同周期发生时，会话终止优先，所有较低优先级事件不得推进旧会话状态或产生完成结果。 + # 第七篇 实现、诊断与验证 -## 47. RTL 实现输出与诊断契约 +## 47. RTL实现输出与诊断契约 -每条链路至少提供： +### 47.1 强制功能状态 -| 输出 | 含义 | -|---|---| -| `link_up` | `UL`、`DL`及本端运行入口条件均已完成；不表示初始`POLL_REQ/ACK`已经完成 | -| `transport_ready` | 传输状态已对齐，可以接受新的可靠`DL`业务请求 | -| `link_retraining` | 当前处于训练/重训 | -| `master_state / slave_state` | 顶层状态 | -| `monitor_state` | 运行期监测状态 | -| `rx_delay_selected` | `UL`最终`IDELAY` | -| `tx_delay_selected` | `DL`最终`ODELAY` | -| `rx_pass_first/last` | `UL`选中窗口边界 | -| `tx_pass_first/last` | `DL`选中窗口边界 | -| `rx_pass_bitmap / tx_pass_bitmap` | 扫描结果 | -| `fixed_frame_error_count` | 固定帧比较错误数 | -| `crc_error_count` | 普通帧 CRC 错误数 | -| `length_error_count` | 外层长度非法数 | -| `boundary_recovery_count` | 边界恢复次数 | -| `retrain_count` | 重训次数 | -| `last_retrain_reason` | 最近重训原因 | -| `resource_fault` | 时钟、延迟或串并转换故障 | +每个端点必须向其传输协议层提供第46章定义的`link_up`。如果业务应用层或系统管理逻辑需要判断整个传输通路是否可提交新业务，应使用`app_tx_ready`或实现提供的等价业务就绪状态，不得把`link_up`单独解释为新会话已经初始化完成。 -计数器可饱和，不应无提示回卷。跨时钟域读取状态和延迟值时必须使用可靠 CDC。 +### 47.2 诊断可观察性 + +除`link_up`功能接口外，表中项目不要求全部实现为RTL顶层端口。实现可以通过状态寄存器、调试总线、片上逻辑分析、仿真层次信号或功能等价的方式提供，但必须在实现声明中说明读取方式、位宽、时钟域及编码。 + +| 诊断项目 | 适用角色 | 含义 | +|---|---|---| +| `retrain_busy` | 主端、从端 | 当前正在执行训练、重新训练或运行入口过程 | +| `master_state` | 主端 | 主端链路训练或传输顶层状态 | +| `slave_state` | 从端 | 从端链路训练或传输顶层状态 | +| `monitor_state` | 主端、从端 | 本端接收方向的运行期监测状态 | +| `rx_delay_selected` | 具有UL可调接收延迟的主端 | 最终选择的UL接收延迟点 | +| `tx_delay_selected` | 具有DL可调发送延迟的主端 | 最终选择的DL发送延迟点 | +| `rx_pass_first/last` | 具有UL扫描能力的主端 | UL所选通过窗口边界；`ALL_PASS`时同时报告对应状态 | +| `tx_pass_first/last` | 具有DL扫描能力的主端 | DL所选通过窗口边界；`ALL_PASS`时同时报告对应状态 | +| `rx_pass_bitmap / tx_pass_bitmap` | 具有对应扫描能力的主端 | 最近一次完整扫描结果 | +| `fixed_frame_error_count` | 主端、从端 | 在要求完整匹配固定帧的状态中发生的固定帧比较失败数 | +| `crc_error_count` | 主端、从端 | 本端接收方向到达预期CRC位置但CRC比较失败的普通帧数 | +| `length_error_count` | 主端、从端 | 本端接收方向的外层`LEN`非法数 | +| `boundary_recovery_count` | 主端、从端 | 进入`MON_RECOVERY`的次数 | +| `retrain_count` | 主端、从端 | 实际开始的新训练或重新训练轮次 | +| `last_retrain_reason` | 主端、从端 | 最近一次训练入口原因 | +| `resource_fault` | 按实现适用 | 时钟、延迟调节或串并转换资源不可用的诊断状态 | + +固定采样结构且没有对应可调资源的从端不需要伪造延迟点、窗口边界或扫描位图。状态编码和`last_retrain_reason`数值编码可以由实现定义，但必须提供符号映射；最近训练原因至少应能够区分上电初始化、外部请求、协议层`retrain_request`、UL同步异常、DL同步异常、CRC错误门限、边界恢复失败和物理资源异常。 + +诊断计数器必须饱和或提供溢出指示，不得无提示回卷。除非实现声明提供显式诊断清零操作，以上累计计数从全局复位开始统计，普通会话复位和重新训练不得清零。跨时钟域读取多位状态、计数器和延迟值时必须使用可靠CDC或一致性快照。 ## 48. 验证与验收要求 -### 48.1 RTL 仿真 +### 48.1 RTL仿真 + +#### 48.1.1 训练、扫描与同步 至少覆盖： -1. 所有固定帧的 160位正确匹配及单位错误拒绝； -2. `PRBS7`初值、位序、终止位置和 64/64 平衡； -3. 扫描位图、最长窗口、并列窗口和偶数中心选择； -4. 窗口触及扫描边界时不误判完成； -5. `IDELAY`点连续49个`TRAIN`后出现错误时计数清零，连续50个时立即通过，200帧到期时失败； -6. 从端在连续50个`DL` `TRAIN`后锁存`TRAIN_ACK`发送状态，并只由合法`IDLE`点间隔解除； -7. `ODELAY`点连续9个`TRAIN_ACK`后出现非ACK固定帧时计数清零，连续10个时立即通过，200帧到期时失败； -8. 每个`ODELAY`点结束后发送最多50个`IDLE`、忽略残余`TRAIN_ACK`，并只以首个完整`TRAIN`确认点间隔成功；50个`IDLE`超时不得进入下一测试点； -9. 从端的`DL` `SYNC`连续计数在9999后出现错误时清零，连续10000个时通过； -10. 从端精确发送20个`SYNC_ACK`，主端连续10个时通过； -11. 主端进入`UL`确认后忽略剩余`SYNC_ACK`，并从第一个完整`SYNC`开始累计10000个连续`SYNC`； -12. 主端和从端的`SYNC`均由状态条件终止，并能由超时退出； -13. 主端以`DL IDLE`结束同步；从端收到首个完整`DL IDLE`后连续发送20个`UL IDLE`，主端收到首个完整`UL IDLE`后进入`M_RUN`； -14. 载荷中出现全部`SOF`/`IDLE`图样时不误分帧； -15. CRC错误且长度合法时保持边界； -16. 长度非法或当前边界被判定为不可信时进入恢复； -17. 恢复成功和搜索超时重训； -18. `DL`单向重训和`UL`、`DL`完整重训都会复位双方传输协议状态，并在恢复后从`SEQ=0`建立新会话； +1. 所有固定帧均完成160位比较后才产生匹配事件，任一位错误均不得被接受； +2. `PRBS7`多项式、初值、位序、终止位置和128位序列的64/64平衡； +3. 扫描位图、最长窗口、并列窗口、偶数点中心及标称延迟点的确定性选择； +4. 环形扫描正确合并跨越最小和最大档位的窗口；线性扫描发现窗口被边界截断时不得直接完成；`ALL_PASS`按第23.2节选择标称点并继续同步确认； +5. 通过窗口分别满足和不满足`RX_MIN_PASS_TAPS`、`TX_MIN_PASS_TAPS`及`MIN_PASS_WINDOW_TIME`时的判定； +6. `IDELAY`点连续49个`TRAIN`后出现错误时计数清零，连续50个时立即通过，200帧到期时失败； +7. 从端连续正确检测50个`DL TRAIN`后置位`train_ack_active`并持续发送`TRAIN_ACK`；合法`IDLE`正确解除该状态；300个固定帧时间内未收到合法`IDLE`时按规定进入重新训练； +8. `ODELAY`点连续9个`TRAIN_ACK`后出现非ACK固定帧时计数清零，连续10个时立即通过，200帧到期时失败； +9. 每个`ODELAY`点结束后发送最多50个`IDLE`并忽略残余`TRAIN_ACK`；只有满足第22.3节条件的首个完整`TRAIN`确认点间隔成功，超时不得进入下一测试点； +10. 从端的`DL SYNC`计数在9999后出现错误时清零，连续10000个时通过； +11. 从端精确发送20个`SYNC_ACK`，主端连续正确检测10个时通过； +12. 主端进入UL确认后忽略剩余`SYNC_ACK`，并从第一个完整`SYNC`开始累计10000个连续`SYNC`； +13. 主端和从端的`SYNC`均由规定状态条件终止，并能由各自超时路径退出； +14. 主端以`DL IDLE`结束同步；从端收到首个完整`DL IDLE`后连续发送20个`UL IDLE`，只在全部发送完成后置位本端`link_up`；主端收到首个完整`UL IDLE`后进入`M_RUN`并置位本端`link_up`； +15. 所有训练通过条件与超时条件同周期成立时，通过条件优先； +16. 延迟配置未就绪时状态机保持等待且不开始测量；就绪丢失时进入资源恢复，不把该点记录为普通失败点； +17. `M_DL_CONFIRM`、`M_UL_CONFIRM`和`M_RUN_ENTRY`收到完整`TRAIN`时按UL仍可信处理并返回`M_TX_TRAIN`； +18. `M_RUN_ENTRY`超时时分别验证UL仍持续收到`SYNC`和UL不再可靠两个分支； 19. 主端单独复位时，DL退出合法运行流并使从端确定进入`S_TRAIN`； -20. 从端仅在完整发送20个运行入口`UL IDLE`后置位`link_up`，期间的普通协议帧不提交； -21. 所有训练通过条件与超时同周期发生时通过优先； -22. 可信方向从普通帧切换到训练固定帧时保持完整帧边界； -23. `M_DL_CONFIRM`、`M_UL_CONFIRM`和`M_RUN_ENTRY`收到完整`TRAIN`时按UL仍可信处理并返回`M_TX_TRAIN`； -24. `M_RUN_ENTRY`超时时分别验证UL仍持续收到`SYNC`和UL不再可靠两个分支； -25. `MON_RECOVERY`期间保持当前会话但丢弃全部候选普通帧；一个合法`IDLE`即可恢复，搜索失败才撤销`link_up`； -26. 运行期出现意外完整固定帧时立即进入规定训练路径； -27. 连续4个CRC错误或最近256个CRC承载帧中8个错误时触发方向化重训； -28. 多从端处于不同状态且互不影响； -29. power_on初始化、PLL失锁和延迟就绪丢失发生在各主要状态时的行为。 -30. `DATA`和`CTRL`无`IDLE`背靠背发送时，下一`SOF`只在计算得到的边界被识别； -31. 帧长可确定但CRC错误、下一边界为合法`IDLE`或`SOF`时，丢弃当前帧但保持同步； -32. 帧长可确定但CRC错误、下一边界也非法时，进入边界恢复； -33. `LEN`越界或未按4字节对齐时，不使用该`LEN`继续计数并立即进入恢复； -34. `LEN`误码后仍为合法值时，接收等待不超过对应最大帧长度，随后由CRC或下一边界发现异常； -35. 依次测试实现支持的全部接收对齐候选位置，验证边界搜索和重新锁定； -36. 恢复期间出现仅`SOF`匹配但完整固定帧、长度或CRC失败时，不得错误恢复边界。 +20. 可信方向从普通帧切换到训练固定帧时保持完整帧边界； +21. 多从端处于不同训练和运行状态时，各自的状态、延迟配置、计数和结果互不影响。 -37. 连续发送多个`DATA`并由一个累计ACK释放多个重传项，验证`OUTSTANDING_BYTES`始终等于未确认描述符`FRAME_COST`之和； -38. 同确认点ACK只更新同锚点窗口，旧ACK和越界ACK不改变任何可靠传输状态； -39. `SEQ`跨越`16'hFFFF`回绕时，累计ACK合理性判断、缓存释放和Go-Back-N范围均正确； -40. 分别丢弃或破坏ACK、`RETRY_REQ`、`POLL_REQ`及其响应，验证后续累计ACK、周期查询和超时重传能够恢复； -41. 验证零窗口、非零但不足以容纳队首帧、窗口恢复以及单纯窗口长期不足；单纯窗口等待不得启动Go-Back-N或重训练； -42. 验证ACK进度计时与单纯窗口问询计时在最后一个未确认帧被确认和首个新帧完成发送时原子切换，任一时刻只有一种计时解释有效； -43. 重传期间收到部分前进ACK时立即释放确认前缀并跳过已经确认的重传项； -44. 连续三轮完整重传无进展时只产生一次会话中止，所有已接受但未完成请求各产生一次`app_tx_aborted`； -45. 注入重传描述符缺失、重复、缓存不可读及`OUTSTANDING_BYTES > PEER_WIN_BYTES`，验证当前会话中止且不得跳过错误继续传输； -46. 模拟从端无法兑现已公告窗口，验证双方终止旧会话并进入重新训练； -47. `link_up`撤销与`tx_frame_done`、合法ACK或定时器到期同周期发生时，以会话终止为最高优先级，且不得同时报告完成与中止； -48. `link_up`重新置位后，协议层只通过初始`POLL_REQ/ACK`建立新会话，旧会话的序号、窗口、控制快照和重传缓存均不得恢复； -49. 最大载荷`LEN=1032`的`DATA`能够在从端最小合规资源配置下获得1040 B窗口和一个帧描述符并完成传输。 +#### 48.1.2 普通帧、边界及层间接口 + +至少覆盖： + +1. 载荷中出现全部`SOF`、`IDLE`及固定帧相同图样时不误分帧； +2. `DATA`和`CTRL`无`IDLE`背靠背发送时，只在计算得到的下一边界识别新`SOF`； +3. CRC错误且长度合法时，按声明长度得到暂定边界；下一位置为合法`IDLE`或`SOF`时丢弃当前帧并恢复可信边界，下一位置非法时进入`MON_RECOVERY`； +4. `LEN`越界、低两位非零或无法完整取得时，不使用该值继续计数，产生`rx_frame_abort`并立即进入边界恢复； +5. `LEN`误码后仍处于合法范围时，接收等待不超过该值对应且受最大帧限制的长度，随后由CRC或下一边界发现异常； +6. `MON_RECOVERY`依次测试实现支持的接收对齐候选位置；一个合法`IDLE`、一个完整合法固定帧或一个满足完整确认条件的普通帧能够恢复，搜索超时才撤销`link_up`； +7. 恢复期间仅匹配`SOF`，但完整固定帧、长度、CRC或下一边界失败时，不得错误确认恢复；用于恢复确认的候选普通帧必须丢弃； +8. 连续4个CRC承载帧错误或最近256个CRC承载帧中达到8个错误时，按异常方向触发规定的重新训练；单个CRC错误不得直接撤销`link_up`； +9. 正常候选帧的逻辑末字与`rx_data_last`、`rx_crc_valid`和`rx_crc_pass`同周期输出，CRC字不得出现在`rx_data`中； +10. 从端收到`DL DATA`的`rx_frame_abort`时回滚并置位`RETRY_PENDING`和`ACK_PENDING`；主端收到`UL DATA`时只丢弃；任意`CTRL`中止时不更新协议状态； +11. `tx_data_valid && !tx_data_ready`期间数据和末字标志保持稳定；一帧`SOF`被接受后链路层持续接受到`tx_data_last`，帧内不得反压； +12. `tx_data_last`握手后只有CRC最后一位完成线路发送才产生一个`tx_frame_done`；每个方向最多存在一个尚未完成的普通逻辑帧； +13. 已接受的普通逻辑帧未能完整发送时不产生`tx_frame_done`并撤销`link_up`，协议层不得对该帧记账或报告完成； +14. `link_up`撤销与`tx_frame_done`、接收完成、合法ACK或定时器到期同周期发生时，会话终止优先； +15. 对每个跨时钟域接口分别验证单周期事件不丢失、不重复，多位状态读取一致，且不会产生非法握手。 + +#### 48.1.3 传输协议与业务接口 + +至少覆盖： + +1. 连续发送多个`DATA`并由一个累计ACK释放多个重传项，`OUTSTANDING_BYTES`始终等于未确认描述符`FRAME_COST`之和； +2. 同确认点ACK只更新同锚点窗口，旧ACK和越界ACK不改变任何可靠传输状态； +3. `SEQ`跨越`16'hFFFF`回绕时，累计ACK合理性判断、缓存释放和Go-Back-N范围均正确； +4. 分别丢弃或破坏`ACK/UPDATE`、`RETRY_REQ`、`POLL_REQ`及其响应，验证累计确认、周期查询和超时重传能够恢复； +5. 从端收到`POLL_REQ`时只依据CRC、`FLAGS`、方向和当前状态处理，不解析或检查其中的`ACK_NEXT`和`WIN_BYTES`，也不以其更新任何状态； +6. 新会话初始`ACK/UPDATE`绕过运行期ACK区间检查；合规从端以`ACK_NEXT=0`初始化，另注入非零初始值并验证主端以该值同时初始化`SND_UNA`和`SND_NXT`且不恢复旧状态； +7. 验证零窗口、非零但不足以容纳队首帧、窗口恢复及单纯窗口长期不足；单纯窗口等待不得启动Go-Back-N或重新训练； +8. ACK进度计时与单纯窗口问询计时在最后一个未确认帧被确认和首个新帧完成发送时原子切换，任一时刻只有一种计时解释有效； +9. 重传期间收到部分前进ACK时立即释放确认前缀并跳过已确认的重传项； +10. 连续三轮完整重传无进展时只产生一次会话中止，所有已接受但未完成请求各产生一次`app_tx_aborted`； +11. 注入重传描述符缺失、重复、缓存不可读及`OUTSTANDING_BYTES > PEER_WIN_BYTES`，验证旧会话中止且不得跳过错误继续传输； +12. 模拟从端无法兑现已公告窗口，验证双方终止旧会话并进入重新训练； +13. 协议层置位`retrain_request`后保持请求，数据链路层只接受一次并撤销`link_up`；协议层观察到低电平后撤销请求，且只有随后观察到`link_up`重新置位才能退出重训练保持状态； +14. `link_up`重新置位后只通过初始`POLL_REQ/ACK`建立新会话，旧会话的序号、窗口、控制快照和重传缓存均不得恢复； +15. 最大载荷`LEN=1032`的`DL DATA`能够在从端最小合规资源配置下获得1040 B窗口和一个帧描述符并完成传输； +16. 主端UL业务接收资源不足时完整消费并丢弃CRC和格式正确的`UL DATA`，保持边界且不产生ACK、`RETRY_REQ`或重新训练； +17. 业务发送接口分别验证1字和258字有效载荷、帧间反压及帧内`app_tx_valid`间隙；`app_tx_valid && !app_tx_ready`期间数据与末字标志保持稳定； +18. 首字握手后、末字握手前发生会话终止时，协议层继续接收到`app_tx_last`，不向新会话发送该帧，并按接受顺序产生一次`app_tx_aborted`； +19. 一个累计ACK或一次会话终止同时形成多个业务结果时，结果按业务帧接受顺序每周期最多输出一个，不丢失、不重复，`app_tx_completed`和`app_tx_aborted`不得同周期有效； +20. 业务接收接口被反压时保持`app_rx_valid`、`app_rx_data`和`app_rx_last`稳定，并保留尚未输出的完整业务帧。 ### 48.2 门级、时序与板级验证 -- 对所选物理配置的SERDES时钟、串行采样时钟、并行时钟和所有CDC路径完成静态时序检查；第7.3节典型配置对应375 MHz DDR与750 MHz SDR； -- 验证每次设置`IDELAY`或`ODELAY`后，只有对应延迟配置就绪条件有效才开始测量；验证就绪丢失时进入资源恢复而不记录普通失败点； -- 在工艺、电压、温度角落记录窗口宽度和中心漂移； -- 在最长线、最差连接器和最大同时翻转条件下测量； -- 验证 AC 耦合基线漂移和终端匹配； +- 对所选物理配置的串行收发时钟、采样时钟、并行时钟和全部CDC路径完成静态时序检查；第7.3节典型配置还必须验证主端375 MHz DDR、187.5 MHz四位并行接口和从端750 MHz SDR之间的关系； +- 验证每次设置接收或发送延迟后，只有对应延迟配置就绪条件有效才开始测量；验证就绪丢失时进入资源恢复而不记录普通失败点； +- 在工艺、电压、温度角落记录窗口宽度、所选延迟点及中心漂移； +- 在最长线路、最差连接器和最大同时翻转条件下验证； +- 验证AC耦合基线漂移、终端匹配和目标误码环境； - 注入位错误、CRC错误、长度错误、边界丢失、接收资源不可用和固定帧丢失； -- 验证任一同步丢失都会使双方协议状态复位；验证`DL`单向重训和`UL`、`DL`完整重训后均通过初始`POLL_REQ/ACK`从`SEQ=0`建立新会话。 +- 验证任一同步丢失都会使双方协议状态复位；`DL`单向重训和`UL`、`DL`完整重训后均须完成初始`POLL_REQ/ACK`。合规从端以`ACK_NEXT=0`建立新会话，主端还必须通过非零初始值的防御性对齐测试。 ### 48.3 链路验收条件 一条链路只有同时满足以下条件才可进入系统可用状态： -- `UL`和`DL`均找到不小于规定宽度的有效窗口； -- `UL`和`DL`窗口中心均已装载； -- 从端连续正确检测10000个`DL` `SYNC`，主端连续正确检测10个`SYNC_ACK`； -- 从端精确发送20个`SYNC_ACK`后持续发送`SYNC`，主端连续正确检测10000个`UL` `SYNC`； +- `UL`和`DL`均按第23章得到合格结果；正常窗口装载所选中心点，`ALL_PASS`装载实现声明的确定标称点； +- 从端连续正确检测10000个`DL SYNC`，主端连续正确检测10个`SYNC_ACK`； +- 从端精确发送20个`SYNC_ACK`后持续发送`SYNC`，主端连续正确检测10000个`UL SYNC`； - 从端识别首个完整`DL IDLE`后精确发送20个`UL IDLE`，主端识别首个完整`UL IDLE`后进入`M_RUN`； -- `link_up` 稳定； -- 初始协议`POLL_REQ`/ACK 完成后，传输协议层声明 `transport_ready`。 +- 双方`link_up=1`； +- 主端发送初始`POLL_REQ`并收到CRC、格式和类型合法的初始`ACK/UPDATE`，双方内部`session_ready`均已建立； +- 业务发送能力已按第45章正确反映到`app_tx_ready`。 -`link_up`表示`UL`、`DL`及运行入口过程均已就绪；`transport_ready`表示新会话的初始`POLL_REQ/ACK`已经完成。业务应用层只能在`transport_ready`后启动需要可靠`DL`的业务。 +`link_up`只表示UL、DL及运行入口过程均已就绪；系统业务可用还要求初始`POLL_REQ/ACK`完成。实现不得用未定义的固定保持时间代替这些确定条件。 ## 49. 实现基线结论 -本方案将复杂性集中在主端：主端负责两个方向的延迟扫描、窗口分析、中心选择、同步确认和运行期恢复；从端只需使用所选物理配置规定的固定收发结构，并完成固定帧比较、`TRAIN_ACK`/`SYNC_ACK`生成、普通帧解析和同步监测；第7.3节典型配置使用750 MHz SDR。 +本规范将主要校准和可靠传输复杂性集中在主端。主端负责两个方向的延迟扫描、窗口分析、最终延迟点选择、同步确认、累计确认、窗口控制和Go-Back-N；从端负责固定帧比较、`TRAIN_ACK`/`SYNC_ACK`生成、DL错误检测、状态`CTRL`生成、普通帧解析和同步异常上报。双方共同执行运行期边界监测和规定的重新训练状态转换。第7.3节给出的750 Mbps LVDS配置只是一种典型物理实现。 -正常上电顺序固定为“从端连续`TRAIN` → 主端校准`UL` → 主端以最多50个`IDLE`隔离相邻`ODELAY`点并校准`DL` → 主端持续`SYNC` → 从端定量发送`SYNC_ACK`并持续发送`SYNC` → 主端持续发送`DL IDLE` → 从端发送20个`UL IDLE` → 主端收到首个`UL IDLE`后进入`M_RUN`”。运行期通过确定边界上的`IDLE`或`SOF`、帧内长度计数和帧尾CRC完成持续监测；内容错误与边界失步分开处理。发生同步丢失时按异常方向执行重新训练，同时复位双方传输协议状态；同步恢复后从`SEQ=0`建立新会话。 +正常上电顺序固定为“从端连续`TRAIN` → 主端校准UL → 主端以最多50个`IDLE`隔离相邻发送延迟点并校准DL → 主端持续`SYNC` → 从端定量发送`SYNC_ACK`并持续发送`SYNC` → 主端持续发送`DL IDLE` → 从端发送20个`UL IDLE` → 主端收到首个`UL IDLE`后进入`M_RUN`”。运行期通过确定边界上的`IDLE`或`SOF`、帧内长度计数和帧尾CRC完成持续监测；内容错误与边界失步分别处理。 + +任一方向同步丢失都终止当前双向传输协议会话。重新训练范围由异常方向决定，但双方协议状态均复位；恢复后通过初始`POLL_REQ/ACK`建立新会话。合规从端发送`ACK_NEXT=0`，主端仍按实际收到的初始值执行防御性序号对齐。 ## 附录A：互操作实现声明清单 每个符合本规范的设备或IP至少应提供以下声明： -1. 本规范版本：V0.8； +1. 本规范版本：V0.9； 2. 主端或从端角色； -3. 采用的物理承载、时钟与链路实现配置及第7章全部参数； -4. 最大`DATA`载荷； -5. 接收窗口容量、帧描述符数量、重传缓存容量及`MAX_INFLIGHT_FRAMES`； -6. 延迟范围、步进和最小通过窗口； -7. 第27章规定的训练计数、超时和间隔参数，以及第33章的`T_ACK_WAIT`、`T_POLL_INTERVAL`、`T_PROGRESS_LIMIT`和`MAX_GBN_FAILURE_ROUNDS`； -8. `SYNC_RESET`、方向化重新训练及同步丢失后协议复位的实现方式； -9. 对外层间接口的位宽和时钟域映射； -10. 第48章验证项目的完成情况。 +3. 物理承载类型、电气接口、线路速率、同源时钟关系、线路位序和连续比特流接口约束； +4. 确认支持本规范固定的1032 B最大`DATA PAYLOAD`、帧格式、固定码字、CRC和扰码规则； +5. 按角色适用的接收窗口容量、帧描述符数量、主端重传缓存容量及主端`MAX_INFLIGHT_FRAMES`； +6. 按角色适用的延迟调节范围、实际延迟映射、扫描步进、环形或线性窗口算法、标称延迟点及最小通过窗口； +7. 确认采用第27章和第33章规定的固定计数与门限，并声明结合线路速率、流水线和CDC换算后的各超时周期数； +8. `SYNC_RESET`、方向化重新训练、`retrain_request`握手及同步丢失后协议复位的实现方式； +9. 第43章至第46章层间接口的位宽、时钟域、复位极性和CDC映射； +10. 第47章诊断信息的访问方式、位宽、编码和清零规则； +11. 第48章验证项目及链路验收条件的完成情况。 -两端只有在线路编码、物理实现配置和方向行为一致时才能互操作。实现可以在内部采用不同流水线、RAM组织、状态编码和时钟域结构，但不得改变线路比特序列、接收接受条件、确认语义或错误恢复行为。 +互操作要求两端的外部物理接口、电气特性、线路速率、位序、同源时钟关系、线路编码和方向行为相互兼容，不要求两端使用相同的内部串并转换结构、并行宽度、工作时钟、延迟资源或状态编码。实现可以采用不同的流水线、RAM组织和时钟域结构，但不得改变线路比特序列、接收接受条件、确认语义、状态转换或错误恢复行为。