diff --git a/非对称可靠串行传输技术规范.md b/非对称可靠串行传输技术规范.md index 8290bc6..43e5664 100644 --- a/非对称可靠串行传输技术规范.md +++ b/非对称可靠串行传输技术规范.md @@ -2,7 +2,7 @@ **Asymmetric Reliable Serial Transport Technical Specification** -**版本：V0.6**
+**版本：V0.7**
**日期：2026-10-01**
**作者：周爽** @@ -12,6 +12,7 @@ | 版本 | 日期 | 说明 | |---|---|---| +| V0.7 | 2026-10-01 | 完善链路训练和运行期监测的异常闭环；明确主端重启可见性、运行入口就绪时机、连续计数与超时优先级、可信方向帧边界切换、方向化重训、恢复候选帧丢弃、单个IDLE恢复、意外固定帧处理及运行期CRC错误门限。 | | V0.6 | 2026-10-01 | 完善主从同步与重新训练状态机；明确重复`SYNC_RESET`、训练应答保护、同步确认和运行入口超时；补充`IDELAY`与`ODELAY`扫描状态机；统一200帧边界搜索与测量周期；修订完整UI环形窗口、`ALL_PASS`及最小通过窗口派生规则。 | | V0.5 | 2026-09-30 | 明确链路重新训练期间的传输状态保持、恢复门控及主从状态机行为；统一`IDLE`和`CRC-32/MPEG-2`术语；修订数据协议边界、封装解析图、发送仲裁、`LEN`校验及帧内字计数规则；更新延迟配置就绪语义、`ODELAY`点间隔确认及运行入口`IDLE`握手。 | | V0.4 | 2026-09-30 | 重构通信机制概述与总体架构，补充SEQ术语定义；明确规范核心覆盖数据链路层和传输协议层，将相位或延迟调节单元及其控制归入数据链路层的物理接口适配功能，并明确业务应用配置的可选属性。 | @@ -146,7 +147,7 @@ | 采样通过窗口 | 延迟扫描中连续判定为通过的延迟档位范围 | | 接收窗口 | `WIN_BYTES`表示的传输协议层可用接收容量 | | 链路同步 | 完成训练、双向同步确认和帧边界建立，使链路可以传输普通协议帧 | -| 传输状态对齐 | 通过`POLL_REQ`和状态控制帧取得`ACK_NEXT`及`WIN_BYTES`的过程 | +| 新会话初始化 | 同步恢复后，主端通过`POLL_REQ`确认控制帧通路可用、取得从端`WIN_BYTES`，并以响应中的`ACK_NEXT`初始化新会话发送序号的过程 | | 回退N帧（Go-Back-N） | 发生错误后从最早未确认序号开始连续重传的机制 | | 单位间隔（UI） | 一个线路位的持续时间 | | 提交（commit） | `CRC32`、格式、序号及资源检查完成后，将候选帧正式提交给上层 | @@ -225,13 +226,13 @@ flowchart LR READY["物理与时钟资源就绪"] --> ULTRAIN["UL训练
主端扫描接收延迟"] ULTRAIN --> DLTRAIN["DL训练
主端扫描发送延迟"] DLTRAIN --> SYNC["双向同步确认
建立稳定帧边界"] - SYNC --> ALIGN["传输状态对齐
取得确认点和接收窗口"] + SYNC --> ALIGN["新会话初始化
确认控制通路并取得接收窗口"] ALIGN --> RUN["正常业务通信"] ``` 资源就绪表示双方已经具备稳定参考时钟、可用收发路径以及完成初始化的延迟调节资源。`UL`训练期间，从端连续发送训练序列，主端扫描接收采样位置并选择通过窗口中心。`DL`训练期间，主端在不同发送延迟下发送定量训练序列，并根据从端返回的训练应答确定通过窗口中心。 -延迟校准完成后，双方通过长同步序列和同步应答确认两个方向均能稳定识别帧边界。随后主端使用控制帧取得从端的累计确认点和可用接收窗口，使传输协议状态与当前链路会话一致。各阶段的精确状态机、判定计数和等待间隔见第18章至第27章；传输状态初始化和对齐规则见第28章至第36章。 +延迟校准完成后，双方通过长同步序列和同步应答确认两个方向均能稳定识别帧边界。随后主端使用`POLL_REQ`确认控制帧通路可用、取得从端可用接收窗口，并以初始响应中的`ACK_NEXT`设置新会话发送起点；合规从端发送的起始值为0。各阶段的精确状态机、判定计数和等待间隔见第18章至第27章；新会话初始化规则见第28章至第36章。 ### 4.4 运行期非对称传输 @@ -255,7 +256,7 @@ flowchart LR 空闲期间如果不能持续检测到合法`IDLE`，或者帧结束后的预期边界不能恢复，数据链路层判定同步异常并进入相应训练流程。按照本规范采用的简化恢复策略，`UL`失效触发`UL`和`DL`完整重训；其他异常按照第26章规定恢复受影响的同步状态。 -链路重新训练只恢复采样位置和帧边界。重训练期间，传输协议层停止提交线路帧、回滚未完成候选帧并停止协议计时，但保留已经完成记账的业务序号、接收状态、未确认帧及缓存资源；主端缓存的旧对端窗口公告失效。链路重新同步后，主端必须通过`POLL_REQ`重新取得从端的`ACK_NEXT`和当前`WIN_BYTES`，完成传输状态恢复后才能重新置位`transport_ready`。只有双方执行明确的会话复位流程时，才清除并重新初始化传输协议状态。详细规则见第26.2节、第35章和第46章。 +任一方向同步丢失都会终止当前双向传输协议会话，并使双方传输协议层复位。重新训练范围与会话复位相互独立：`UL`异常时重新训练`UL`和`DL`；`DL`异常且`UL`仍可信时只重新训练`DL`。同步恢复后，主端通过`POLL_REQ`取得从端当前的`WIN_BYTES`并确认控制帧通路可用；从端必须在初始响应中发送`ACK_NEXT=0`，主端把实际收到的`ACK_NEXT`作为新会话起始序号，不将其解释为旧会话累计确认。完成新会话初始化后才能重新置位`transport_ready`。详细规则见第26.2节、第35章和第46章。 ### 4.6 后续内容索引 @@ -999,15 +1000,30 @@ sequenceDiagram 13. 从端连续正确检测10000个`SYNC`后，连续发送20个`SYNC_ACK`，随后持续发送固定160位`SYNC`； 14. 主端连续正确检测10个`SYNC_ACK`后，忽略可能剩余的`SYNC_ACK`，检测到第一个`UL` `SYNC`后开始连续计数； 15. 主端连续正确检测10000个`UL` `SYNC`后停止发送`SYNC`并持续发送`IDLE`； -16. 从端检测到首个完整合法的`DL IDLE`后停止发送`SYNC`，使接收方向进入运行期解析，并在`UL`连续发送20个`IDLE`； +16. 从端检测到首个完整合法的`DL IDLE`后停止发送`SYNC`，使接收方向进入运行期边界监测，并在`UL`连续发送20个`IDLE`；20个`IDLE`完整发送结束前不提交普通协议帧； 17. 主端检测到首个完整合法的`UL IDLE`后进入`M_RUN`并置位`link_sync_up`；剩余`IDLE`按正常空闲码字处理； -18. 主端随后通过`POLL_REQ`恢复传输状态；只有传输状态对齐完成后才置位`transport_ready`； +18. 主端随后通过`POLL_REQ`确认控制帧通路并取得`WIN_BYTES`；只有新会话初始化完成后才置位`transport_ready`； 19. `SYNC`采用“持续发送、条件终止、超时失败”；不需要额外的“进入业务状态”控制帧。 -步骤11和步骤12中的`SYNC`持续发送均受超时保护：正常情况下由对端状态变化终止；超过规定时间仍未观察到终止条件，则本次同步失败并进入重新训练。长序列由连续重复固定160位`SYNC`帧构成，不改变单帧长度。 +步骤12至17的同步确认和运行入口均受对应超时保护：正常情况下由对端状态变化终止；超过规定时间仍未观察到终止条件，则按当前方向是否仍可信进入规定的重新训练路径。长序列由连续重复固定160位`SYNC`帧构成，不改变单帧长度。 固定帧时间为`160/LINE_RATE`。连续帧数量判据与线路速率无关，具体时间必须按所选物理配置换算。采用第7.3节的750 Mbps典型配置时，一个固定帧为213.333 ns；50帧约10.667 μs，200帧约42.667 μs，10000帧`SYNC`约2.133 ms/方向，20帧`SYNC_ACK`约4.267 μs。50个32位`IDLE`为1600 bit，约2.133 μs；20个32位`IDLE`为640 bit，约0.853 μs。 +### 18.1 连续计数、超时与帧切换公共规则 + +“连续N个目标固定帧”表示在同一已确认接收边界上，相邻N个160位帧位置全部完整匹配目标固定帧。任一位置出现目标帧不匹配、其他固定帧、`IDLE`、普通协议帧、未知内容、接收数据无效或边界改变时，连续计数立即清零。 + +所有训练和确认计数器统一遵循以下规则： + +1. 计数包含第一个有效观察单位； +2. 计数达到终值的同周期立即产生完成事件； +3. 通过条件和超时条件在同一观察单位成立时，通过条件优先； +4. 资源失效或当前方向被实现判定为不可信时，资源或方向异常优先于通过和超时； +5. 状态离开后清零该状态专用计数器； +6. 计数器达到终值后饱和或立即转换，不允许回卷。 + +当重新训练仍需使用某个可信方向传递`TRAIN`、`SYNC_RESET`或其他固定帧时，该方向必须保持完整线路帧原子性。已经开始发送的普通帧必须完整结束，随后从下一个帧边界开始发送训练固定帧。若物理资源已经失效而无法完整结束当前帧，可以立即中止，但该方向必须被判为不可信，不能继续按单向重训处理。 + ## 19. 主端顶层状态机 ### 19.1 状态图 @@ -1027,17 +1043,22 @@ stateDiagram-v2 M_TX_TRAIN --> M_RX_TRAIN: RX lost during TX training M_DL_CONFIRM --> M_UL_CONFIRM: SYNC_ACK confirmed - M_DL_CONFIRM --> M_TX_TRAIN: ACK timeout and RX healthy + M_DL_CONFIRM --> M_TX_TRAIN: complete TRAIN, or ACK timeout and RX healthy M_DL_CONFIRM --> M_RX_TRAIN: RX no longer reliable M_UL_CONFIRM --> M_RUN_ENTRY: UL SYNC confirmed - M_UL_CONFIRM --> M_RX_TRAIN: UL SYNC timeout + M_UL_CONFIRM --> M_TX_TRAIN: complete TRAIN received + M_UL_CONFIRM --> M_RX_TRAIN: UL SYNC timeout or UL unreliable M_RUN_ENTRY --> M_RUN: first complete UL IDLE - M_RUN_ENTRY --> M_DL_CONFIRM: run_entry_timeout + M_RUN_ENTRY --> M_TX_TRAIN: complete TRAIN, or timeout with continued valid UL SYNC + M_RUN_ENTRY --> M_RX_TRAIN: timeout and UL unreliable M_RUN --> M_RX_TRAIN: UL synchronization lost M_RUN --> M_TX_TRAIN: Slave reports DL loss + M_RUN --> M_SYNC_RESET_TX: active retrain request and DL usable + M_SYNC_RESET_TX --> M_TX_TRAIN: 20 SYNC_RESET sent and UL reliable + M_SYNC_RESET_TX --> M_RX_TRAIN: 20 SYNC_RESET sent and UL requires retraining M_RUN --> M_WAIT_RESOURCE: common resource lost ``` @@ -1048,21 +1069,22 @@ stateDiagram-v2 | `M_WAIT_RESOURCE` | 等待时钟、MMCM/PLL和延迟控制资源可用；撤销`link_sync_up` | 资源就绪 | | `M_RX_TRAIN` | 执行第21章`IDELAY`扫描、`UL`窗口分析和中心点装载 | 找到合法窗口；失败时持续重试 | | `M_TX_TRAIN` | 执行第22章`ODELAY`扫描、点间隔确认、`DL`窗口分析和中心点装载 | 找到合法窗口；失败时按UL健康状态选择重试范围 | -| `M_DL_CONFIRM` | `DL`持续发送`SYNC`；等待从端完成10000个`DL SYNC`检测并返回`SYNC_ACK` | 连续收到10个`SYNC_ACK`或超时 | -| `M_UL_CONFIRM` | `DL`继续持续发送`SYNC`；先忽略剩余`SYNC_ACK`，检测到首个`UL SYNC`后连续计数 | 连续收到10000个`SYNC`或超时 | -| `M_RUN_ENTRY` | 停止发送`SYNC`并持续发送`DL IDLE`；允许残余`UL SYNC`，等待首个完整`UL IDLE` | 收到首个完整`UL IDLE`或超时 | -| `M_RUN` | 发送`IDLE`或协议帧；执行第25章同步监测 | 失步、资源失效或从端返回`TRAIN` | +| `M_DL_CONFIRM` | `DL`持续发送`SYNC`；等待从端完成10000个`DL SYNC`检测并返回`SYNC_ACK` | 连续收到10个`SYNC_ACK`；收到完整`TRAIN`；或超时 | +| `M_UL_CONFIRM` | `DL`继续持续发送`SYNC`；先忽略剩余`SYNC_ACK`，检测到首个`UL SYNC`后连续计数 | 连续收到10000个`SYNC`；收到完整`TRAIN`；或超时 | +| `M_RUN_ENTRY` | 停止发送`SYNC`并持续发送`DL IDLE`；允许残余`UL SYNC`，等待首个完整`UL IDLE` | 收到首个完整`UL IDLE`；收到完整`TRAIN`；或超时后按UL是否仍可靠选择训练范围 | +| `M_SYNC_RESET_TX` | 在完整帧边界开始连续发送20个`SYNC_RESET`；期间不发送普通协议帧 | 20个完整发送结束后按UL可靠性进入`M_TX_TRAIN`或`M_RX_TRAIN` | +| `M_RUN` | 发送`IDLE`或协议帧；执行第25章同步监测 | 失步、资源失效、从端返回`TRAIN`或主动重训请求 | ### 19.3 主端的确定性要求 - `UL`和`DL`扫描得到合法窗口后装载所选中心点；只有当前延迟配置就绪后才能进入下一同步阶段； - 上电后先执行`M_RX_TRAIN`，RX窗口建立后无条件进入`M_TX_TRAIN`； - 任何`UL`失效都返回`M_RX_TRAIN`；RX重新训练成功后仍无条件执行完整TX训练； -- `M_DL_CONFIRM`和`M_UL_CONFIRM`期间，主端均持续发送`SYNC`； +- `M_DL_CONFIRM`和`M_UL_CONFIRM`期间，主端均持续发送`SYNC`；任一状态收到完整`TRAIN`均表示从端已返回训练且UL仍可传递状态，主端进入`M_TX_TRAIN`； - `SYNC_ACK`只在`M_DL_CONFIRM`统计，必须连续正确收到10个；任一非`SYNC_ACK`固定帧使计数清零； - 进入`M_UL_CONFIRM`后，主端允许继续收到从端尚未发送完的`SYNC_ACK`；这些剩余ACK不计为错误； - `M_UL_CONFIRM`检测到第一个完整`SYNC`时将`UL SYNC`连续计数置1；此后任一非`SYNC`固定帧使计数清零，重新等待下一个完整`SYNC`作为新序列起点； -- `M_RUN_ENTRY`期间`DL`持续发送`IDLE`，不允许发送协议帧；主端在已知边界完整匹配首个`UL IDLE`后立即进入`M_RUN`，不执行额外连续检测； +- `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_sync_up`和`transport_ready`必须按第46章分别产生； - `UL`失步返回`M_RX_TRAIN`，随后依次重新训练`UL`和`DL`；能够明确判断为`DL`单向异常时，直接返回`M_TX_TRAIN`； - 点间隔发送满50个有效`IDLE`仍未收到完整`TRAIN`时，不得开始下一`ODELAY`点；UL仍可靠时重新执行完整DL训练，UL不可靠时重新训练UL和DL； @@ -1070,7 +1092,7 @@ stateDiagram-v2 - 从端因本地检测到`DL`失步而主动进入`S_TRAIN`时不依赖`SYNC_RESET`，而是直接清除当前训练上下文并持续发送`TRAIN`； - 公共时钟、MMCM/PLL或公共延迟资源异常时返回`M_WAIT_RESOURCE`，资源恢复后依次重新训练`UL`和`DL`； - 训练失败时停留在对应训练状态持续重试，重试计数仅用于诊断，不使状态机停止； -- 链路重新训练和双向确认期间保留传输协议层序号、累计ACK状态和未确认帧缓存； +- 任一方向同步丢失时立即复位传输协议层序号、累计ACK状态和未确认帧缓存；重新训练期间禁止普通协议帧； - 主端在`M_RUN`收到完整`TRAIN`，表示从端已因`DL`异常返回训练状态；若`UL`接收仍可靠，则直接进入`M_TX_TRAIN`。 ## 20. 从端顶层状态机 @@ -1087,12 +1109,13 @@ stateDiagram-v2 S_SYNC_ACK_TX --> S_UL_SYNC_TX: 20 SYNC_ACK sent S_UL_SYNC_TX --> S_RUN_ENTRY_IDLE_TX: first complete DL IDLE S_RUN_ENTRY_IDLE_TX --> S_RUN: 20 UL IDLE sent - S_SYNC_ACK_TX --> S_TRAIN: sync timeout - S_UL_SYNC_TX --> S_TRAIN: 10500 frame timeout or DL sync lost - S_RUN_ENTRY_IDLE_TX --> S_TRAIN: sync_lost or sync_reset + S_SYNC_ACK_TX --> S_TRAIN: DL sync lost, TRAIN, or SYNC_RESET + S_UL_SYNC_TX --> S_TRAIN: 10500 frame timeout, DL sync lost, TRAIN, or SYNC_RESET + S_RUN_ENTRY_IDLE_TX --> S_TRAIN: sync_lost, TRAIN, or SYNC_RESET S_RUN_ENTRY_IDLE_TX --> S_WAIT_RESOURCE: common resource lost - S_RUN --> S_TRAIN: sync_lost or sync_reset + S_RUN --> S_TRAIN: sync_lost, unexpected fixed frame, or SYNC_RESET S_RUN --> S_WAIT_RESOURCE: common resource lost + S_TRAIN --> S_TRAIN: SYNC_RESET / clear training history ``` ### 20.2 状态行为 @@ -1101,10 +1124,10 @@ stateDiagram-v2 |---|---|---|---| | `S_WAIT_RESOURCE` | 清空固定帧检测历史，禁止普通帧提交 | 等待资源稳定 | 资源就绪 | | `S_TRAIN` | 分别累计连续`TRAIN`和连续`SYNC`；`TRAIN`达到50后等待`IDLE`结束当前测试点 | 默认连续`TRAIN`；`train_ack_active`有效时持续发送`TRAIN_ACK` | 连续收到10000个有效`SYNC` | -| `S_SYNC_ACK_TX` | 继续检查`DL`是否保持`SYNC` | 连续发送20个`SYNC_ACK` | 20个发送完成或超时 | -| `S_UL_SYNC_TX` | 继续接收主端`SYNC`，检测首个完整合法`IDLE`；从进入本状态起累计固定帧时间 | 持续发送`SYNC` | 收到首个完整运行入口`IDLE`；达到10500个固定帧时间；或`DL`同步丢失 | -| `S_RUN_ENTRY_IDLE_TX` | 启用运行期接收解析；允许接收`POLL_REQ`并锁存待响应状态 | 连续发送20个`IDLE`，不得插入其他帧 | 完整发送20个`IDLE`；同步丢失；收到`SYNC_RESET`；或公共资源失效 | -| `S_RUN` | 解析普通帧并监测同步；处理`SYNC_RESET` | 优先发送待响应`CTRL`；无帧时发送`IDLE` | 失步、资源失效或`SYNC_RESET` | +| `S_SYNC_ACK_TX` | 继续检查`DL`是否保持`SYNC` | 连续发送20个`SYNC_ACK` | 20个完整发送结束；收到完整`TRAIN`或`SYNC_RESET`；或DL边界/资源失效 | +| `S_UL_SYNC_TX` | 继续接收主端`SYNC`，检测首个完整合法`IDLE`；从进入本状态起累计固定帧时间 | 持续发送`SYNC` | 收到首个完整运行入口`IDLE`；收到完整`TRAIN`或`SYNC_RESET`；达到10500个固定帧时间；或DL边界/资源失效 | +| `S_RUN_ENTRY_IDLE_TX` | 启用运行期边界监测但不向传输协议层提交普通帧；保持`link_sync_up=0` | 连续发送20个`IDLE`，不得插入其他帧 | 完整发送20个`IDLE`后进入`S_RUN`并置位`link_sync_up`；同步丢失；收到训练固定帧；或公共资源失效 | +| `S_RUN` | 解析普通帧并监测同步；处理固定帧状态事件 | 优先发送待响应`CTRL`；无帧时发送`IDLE` | 失步、资源失效、`SYNC_RESET`或意外固定帧 | ### 20.3 `TRAIN_ACK`调度 @@ -1129,13 +1152,13 @@ stateDiagram-v2 从端连续正确检测10000个`DL SYNC`后进入`S_SYNC_ACK_TX`，连续发送20个`SYNC_ACK`；随后进入`S_UL_SYNC_TX`并持续发送`SYNC`。主端确认10000个`UL SYNC`后停止发送`SYNC`并持续发送`DL IDLE`。 -从端进入`S_UL_SYNC_TX`时启动`S_UL_SYNC_TIMEOUT_FRAMES`计时。该计时按160位固定帧时间累计，固定为10500；在计满前收到首个完整合法`DL IDLE`即正常结束。计满仍未收到`DL IDLE`，或者等待期间`DL SYNC`连续异常达到失步门限，均放弃本次确认并返回`S_TRAIN`。 +从端进入`S_UL_SYNC_TX`时启动`S_UL_SYNC_TIMEOUT_FRAMES`计时。该计时按160位固定帧时间累计，固定为10500；在计满前收到首个完整合法`DL IDLE`即正常结束。计满仍未收到`DL IDLE`，或者等待期间收到完整`TRAIN`或`SYNC_RESET`、DL边界失效或公共资源失效，均放弃本次确认并返回`S_TRAIN`。通过条件和超时在同一观察单位成立时，按第18.1节由通过条件优先。 -从端在已知边界检测到首个完整合法`DL IDLE`后，使DL接收方向立即采用运行期解析规则、置位本端`link_sync_up`，并进入`S_RUN_ENTRY_IDLE_TX`。已经开始发送的`UL SYNC`必须完整结束；随后从端连续发送20个32位`IDLE`。这20个`IDLE`是运行入口响应，不用于重新验证链路质量。 +从端在已知边界检测到首个完整合法`DL IDLE`后，使DL接收方向采用运行期边界监测规则并进入`S_RUN_ENTRY_IDLE_TX`，但保持本端`link_sync_up=0`。已经开始发送的`UL SYNC`必须完整结束；随后从端连续发送20个32位`IDLE`。第20个`IDLE`完整发送结束后，从端进入`S_RUN`并置位本端`link_sync_up`。这20个`IDLE`是运行入口响应，不用于重新验证链路质量。 -从端发送20个`IDLE`期间可以接收并解析主端的`POLL_REQ`，但不得中断固定的20个`IDLE`发送序列；由该请求产生的状态响应先置为待发送，进入`S_RUN`后优先发送对应`CTRL`。业务应用层的UL发送请求在运行入口序列完成前不得上线。该状态不设置普通流程超时，状态转换以完整发送20个`IDLE`为准；同步丢失或收到`SYNC_RESET`时返回`S_TRAIN`，公共资源失效时进入`S_WAIT_RESOURCE`。 +从端发送20个`IDLE`期间不得向传输协议层提交普通`DATA`或`CTRL`；期间收到的`POLL_REQ`不锁存、不响应。主端如果尚未收到初始状态响应，必须按`T_POLL_INTERVAL`重新发送`POLL_REQ`。业务应用层的UL发送请求在运行入口序列完成前不得上线。该状态不设置普通流程超时，状态转换以完整发送20个`IDLE`为准；同步丢失、收到训练固定帧或`SYNC_RESET`时返回`S_TRAIN`，公共资源失效时进入`S_WAIT_RESOURCE`。 -从端在`S_SYNC_ACK_TX`和`S_UL_SYNC_TX`中都要求`DL`继续出现合法`SYNC`；若在`IDLE`到来前连续异常达到规定门限，或`S_UL_SYNC_TX`达到10500个固定帧时间仍未收到完整合法`DL IDLE`，则放弃本次确认并返回训练流程。 +从端在`S_SYNC_ACK_TX`中必须完整发送20个`SYNC_ACK`，该状态不设置普通流程超时；若收到完整`TRAIN`或`SYNC_RESET`，或者DL边界或公共资源失效，则立即放弃本次确认并返回训练入口。进入`S_UL_SYNC_TX`后，若收到完整`TRAIN`或`SYNC_RESET`、DL边界或公共资源失效，或者达到10500个固定帧时间仍未收到完整合法`DL IDLE`，则放弃本次确认并返回训练入口。 ## 21. 主端`UL` `IDELAY`扫描子状态机 @@ -1158,7 +1181,7 @@ stateDiagram-v2 RX_NEXT_POINT --> RX_ANALYZE_WINDOW: scan complete RX_ANALYZE_WINDOW --> RX_LOAD_CENTER: valid window found RX_ANALYZE_WINDOW --> RX_SET_DELAY: no valid window, restart scan - RX_LOAD_CENTER --> [*]: center ready and alignment rebuilt + RX_LOAD_CENTER --> [*]: center ready and boundary rebuilt ``` 图中的结束节点表示`UL`扫描成功，控制权返回主端顶层状态机并进入`M_TX_TRAIN`。任一子状态下公共资源失效时，立即中止扫描并进入`M_WAIT_RESOURCE`；该全局异常转移未逐条画出。尚未记录的当前点不得写入扫描位图，已有扫描结果在重新训练时失效。 @@ -1168,28 +1191,28 @@ stateDiagram-v2 | `RX_SET_DELAY` | 请求设置当前`IDELAY`延迟档位 | 设置请求已被物理接口适配逻辑接受 | | `RX_WAIT_DELAY_READY` | 等待当前延迟配置生效且接收路径可用于测量 | `rx_delay_ready=1` | | `RX_CLEAR_HISTORY` | 清零比较历史、字对齐历史和当前点统计 | 下一拍启动200帧单点总计时 | -| `RX_SEARCH_AND_QUALIFY` | 在全部可能的位滑移和32位字边界中持续搜索完整`TRAIN`，并在当前候选边界维护连续正确计数和200帧单点总计时 | 任一候选边界连续正确50个`TRAIN`，或达到200个固定帧时间 | +| `RX_SEARCH_AND_QUALIFY` | 在实现支持的全部接收对齐候选位置和32位字边界中持续搜索完整`TRAIN`，并在当前候选边界维护连续正确计数和200帧单点总计时 | 任一候选边界连续正确50个`TRAIN`，或达到200个固定帧时间 | | `RX_RECORD` | 按第21.3节记录通过、失败和错误数 | 下一拍 | | `RX_NEXT_POINT` | 选择下一个延迟档位 | 仍有测试点则继续，否则分析 | | `RX_ANALYZE_WINDOW` | 找最长连续通过区间并选择中心 | 有合法窗口或失败 | | `RX_LOAD_CENTER` | 请求装载中心延迟档位，等待`rx_delay_ready`并重新建立字边界 | 完成后进入`DL`扫描 | -`rx_delay_ready`是抽象就绪条件，表示当前请求的`IDELAY`配置已经生效且接收路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。就绪前不得启动200帧单点总计时、搜索候选边界、累计`TRAIN`、更新扫描位图或沿用旧字边界历史。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`，不得把该事件记录为普通失败点。 +`rx_delay_ready`是抽象就绪条件，表示当前请求的`IDELAY`配置已经生效且接收路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。设置请求未被接受或就绪条件长期无效时，状态机可以保持在`RX_SET_DELAY`、`RX_WAIT_DELAY_READY`或`RX_LOAD_CENTER`，本规范不要求统一超时；挂起期间必须保持`link_sync_up=0`和`transport_ready=0`，不得启动200帧单点计时、搜索候选边界、累计`TRAIN`、更新扫描位图或发送普通协议帧。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`，不得把该事件记录为普通失败点。 ### 21.3 测试点判定 -`IDELAY`用于调整串行数据的采样相位，位滑移或齿轮箱用于调整并行字的分组边界，两者属于相互独立的搜索维度。每个`IDELAY`测试点都必须清除旧边界历史，并在该点的200帧总计时内重新完成边界搜索和连续`TRAIN`判定。 +`IDELAY`用于调整串行数据的采样相位，接收对齐搜索用于建立并行字及32位协议字的分组边界，两者属于相互独立的搜索维度。每个`IDELAY`测试点都必须清除旧边界历史，并在该点的200帧总计时内重新完成边界搜索和连续`TRAIN`判定。接收对齐候选位置的形成和切换方法属于物理接口适配实现，本规范不作限定。 每个`IDELAY`点的确定判据为： -- 请求改变`IDELAY`并确认`rx_delay_ready`后，清零该点的`TRAIN`连续计数、单点总计时、位滑移搜索历史和旧边界历史； +- 请求改变`IDELAY`并确认`rx_delay_ready`后，清零该点的`TRAIN`连续计数、单点总计时、接收对齐搜索历史和旧边界历史； - 历史清除完成后立即启动200个固定帧时间的单点总计时；边界搜索和连续`TRAIN`判定共用该计时，不另设边界搜索超时； -- 计时期间持续遍历实现支持的全部位滑移位置和32位字边界候选位置；实现必须保证在200个固定帧时间内能够覆盖全部可能位置； +- 计时期间持续遍历实现支持的全部接收对齐候选位置和32位字边界候选位置；实现必须保证在200个固定帧时间内能够覆盖全部可能位置； - 在某一候选位置完整匹配一个160位`TRAIN`时，将该位置作为当前候选边界并把连续计数置1；后续在同一候选边界每完整匹配一个`TRAIN`，连续计数加一； - 当前候选边界上的预期`TRAIN`不匹配时，连续计数清零并继续执行边界搜索；旧候选不得阻止其他候选位置被检查； - 任一候选边界的连续计数达到50时，该点立即判定通过，并将该边界作为当前点的有效接收边界； - 单点总计时达到200个固定帧时间仍未出现连续50个正确`TRAIN`时，该点判定失败； -- 搜索和判定期间发生接收溢出时，该点失败。 +- 搜索和判定期间，如果实现报告当前接收边界或连续数据已经不可信，则清除当前候选历史并继续搜索；接收资源不可用时按下一段规定处理中止扫描。 公共资源失效不作为普通失败点记录，而是立即中止本轮扫描并使主端进入`M_WAIT_RESOURCE`。资源恢复后重新执行完整`UL`扫描。 @@ -1238,7 +1261,7 @@ stateDiagram-v2 | `TX_ANALYZE_WINDOW` | 找最长连续通过区间并选择中心 | 有合法窗口或失败 | | `TX_LOAD_CENTER` | 请求装载中心延迟档位并等待`tx_delay_ready` | 就绪后进入双向`SYNC`确认 | -`tx_delay_ready`是抽象就绪条件，表示当前请求的`ODELAY`配置已经生效且发送路径可以开始有效测量。本规范不规定它由器件状态信号、固定等待周期、配置回读还是其他机制产生。延迟切换期间的线路输出不参与任何测试点判定；只有`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_sync_up=0`和`transport_ready=0`，不得记录扫描结果或发送普通协议帧。延迟切换期间的线路输出不参与任何测试点判定；只有`tx_delay_ready=1`后才能清除旧ACK历史并开始新的`TRAIN`序列和200帧计时。资源全局就绪状态撤销时进入`M_WAIT_RESOURCE`。 ### 22.3 测试点判定与应答归属 @@ -1251,7 +1274,7 @@ stateDiagram-v2 - 任一非`TRAIN_ACK`固定帧使ACK连续计数清零； - 主端连续正确收到10个`TRAIN_ACK`时，该点立即通过并停止发送`TRAIN`； - 达到200个固定帧时间仍未得到连续10个`TRAIN_ACK`时，该点失败； -- `UL`固定帧接收仍可靠但发生单点接收溢出时，该点失败；`UL`失锁时退出本子状态机并进入`M_RX_TRAIN`。 +- 当前`UL`边界不再可信或固定帧接收失锁时，退出本子状态机并进入`M_RX_TRAIN`。 公共资源失效不作为普通失败点记录，而是立即中止本轮扫描并使主端进入`M_WAIT_RESOURCE`。资源恢复后重新训练`UL`和`DL`。 @@ -1332,7 +1355,7 @@ TX\_MIN\_PASS\_TAPS=\left\lceil\frac{MIN\_PASS\_WINDOW\_TIME}{TX\_DELAY\_STEP\_T ### 24.1 固定帧搜索 -训练期可以在允许的位滑移候选位置搜索固定帧，但产生固定帧事件前必须完成 160位全帧比较。 +训练期可以在实现支持的接收对齐候选位置搜索固定帧，但产生固定帧事件前必须完成160位全帧比较。候选位置的形成和切换方法属于物理接口适配实现，本规范不作限定。 - 初始字边界至少需要 `ALIGN_CONFIRM_FRAMES` 个连续完整固定帧； - 任一候选帧不匹配使连续计数清零； @@ -1345,7 +1368,7 @@ TX\_MIN\_PASS\_TAPS=\left\lceil\frac{MIN\_PASS\_WINDOW\_TIME}{TX\_DELAY\_STEP\_T 2. 外层长度字段编码完整； 3. 长度满足协议规定的最小值、最大值和 4-字节对齐； 4. 按长度计数恰好到达 CRC 和帧结束位置； -5. 接收期间没有资源失效、位滑移或本地 FIFO 溢出。 +5. 接收期间资源保持可用，且当前接收边界未被实现判定为不可信。 CRC失败但长度合法时，当前帧内容不可交付；根据声明长度计算得到的下一位置作为暂定边界。若该位置出现合法`IDLE`或`SOF`，边界恢复为可信并继续解析；否则进入恢复。长度非法、提前结束、超出实现上限或计数无法到达合法边界时，边界直接判定为不可信。 @@ -1360,11 +1383,11 @@ stateDiagram-v2 MON_LOCKED_BOUNDARY --> MON_IN_FRAME: valid SOF and legal length MON_IN_FRAME --> MON_LOCKED_BOUNDARY: frame end and legal length MON_LOCKED_BOUNDARY --> MON_RECOVERY: unknown word or illegal length - MON_IN_FRAME --> MON_RECOVERY: boundary or overflow error - MON_RECOVERY --> MON_LOCKED_BOUNDARY: recovery_confirmed - MON_RECOVERY --> MON_SYNC_LOST: search_limit_reached - MON_LOCKED_BOUNDARY --> MON_SYNC_LOST: physical resource lost - MON_IN_FRAME --> MON_SYNC_LOST: physical resource lost + MON_IN_FRAME --> MON_RECOVERY: boundary_invalid + MON_RECOVERY --> MON_LOCKED_BOUNDARY: recovery_confirmed / resume at next boundary + MON_RECOVERY --> MON_SYNC_LOST: search_limit_reached / deassert link_sync_up + MON_LOCKED_BOUNDARY --> MON_SYNC_LOST: receive resource unavailable + MON_IN_FRAME --> MON_SYNC_LOST: receive resource unavailable ``` ### 25.2 边界状态定义 @@ -1375,17 +1398,18 @@ stateDiagram-v2 |---|---|---| | 可信边界 | 当前32位位置已由`IDLE`、完整固定帧或上一完整帧长度确定 | 可以识别`IDLE`、`SOF`并开始新帧 | | 暂定边界 | 位置由一个长度合法但CRC失败的帧推算得到，尚未由下一标志确认 | 只能检查下一`IDLE`或`SOF`，不得提交前一帧 | -| 边界丢失 | 无法确定下一个32位帧起点，或位/字相位已经变化 | 禁止业务提交，进入边界恢复 | +| 边界丢失 | 无法确定下一个32位帧起点，或当前接收对齐位置不再可信 | 禁止业务提交，进入边界恢复 | `MON_LOCKED_BOUNDARY` 内部应使用 `boundary_provisional` 标志区分可信边界和暂定边界。CRC失败且长度合法时置位该标志；下一位置匹配合法`IDLE`或`SOF`后清零；匹配失败则进入 `MON_RECOVERY`。暂定状态最多维持到下一预期边界，不允许跨越多个未确认帧。 边界确定必须遵循以下优先级： -1. 物理资源失效、明确位滑移或接收溢出优先级最高，直接判定边界丢失； -2. 已经进入普通帧时，只能根据该帧已验证的长度计算结束位置； -3. 仅在预期帧边界上识别`IDLE`和`SOF`； -4. `SOF`单独匹配只能建立候选起点，不能证明完整帧有效； -5. 固定训练类帧必须完整匹配160位后才能确认其边界和类型。 +1. 接收资源不可用时，当前数据和边界均不可信，必须撤销`link_sync_up`并进入资源恢复或重新训练； +2. 实现明确报告当前接收边界不再可信时，必须丢弃当前未完成帧、清除解析历史并进入`MON_RECOVERY`； +3. 已经进入普通帧且未发生上述事件时，只能根据该帧已验证的长度计算结束位置； +4. 仅在预期帧边界上识别`IDLE`和`SOF`； +5. `SOF`单独匹配只能建立候选起点，不能证明完整帧有效； +6. 固定训练类帧必须完整匹配160位后才能确认其边界和类型。 ### 25.3 不同情况下的边界确定方法 @@ -1395,15 +1419,15 @@ stateDiagram-v2 | 正常`IDLE` | 在可信32位边界完整匹配 `32'hC4F0B966` | 当前边界加1个32位字 | 不匹配任何合法`SOF`时进入恢复 | | 固定160位帧 | 在候选起点完整匹配`SOF`和128位`PRBS7` | 当前边界加5个32位字 | 只匹配`SOF`或PRBS错误不得产生固定帧事件 | | `DATA` | 在可信边界匹配`DATA` `SOF`，并取得合法`LEN` | 当前边界加 `3 + LEN/4` 个32位字 | `LEN`非法立即进入恢复 | -| `CTRL` | 在可信边界匹配`CTRL` `SOF` | `CTRL`固定4个32位字，下一边界为当前边界加4 | 固定长度未完整接收、溢出或物理错误时进入恢复 | +| `CTRL` | 在可信边界匹配`CTRL` `SOF` | `CTRL`固定4个32位字，下一边界为当前边界加4 | 固定长度未完整接收或当前边界被判定为不可信时进入恢复 | | `DATA`/`CTRL` CRC正确 | 起点和帧长均已确认，CRC证明帧内容完整 | 按对应帧长得到的下一边界转为可信边界 | 下一位置仍必须出现`IDLE`或合法`SOF` | | CRC错误但帧长可确定 | 起点和已确定的帧长仍可用于推算位置，但内容不可交付 | 按帧长得到暂定边界，并检查该位置的`IDLE`或合法`SOF` | 下一标志合法则恢复为可信；否则进入恢复 | | `CTRL`格式错误 | `CTRL`固定长度已知，CRC位置仍可确定 | 当前边界加4个32位字 | 丢弃该`CTRL`，不更新确认或窗口状态 | | `LEN`越界、低2位非零或无法完整取得`LEN` | 无法安全确定帧总长度 | 不使用收到的`LEN`继续计数 | 立即进入恢复 | | `LEN`被误码改变但仍落在合法范围 | 接收端暂时无法识别该错误，按收到的`LEN`计数 | 在计算位置校验CRC和下一标志 | CRC或下一标志通常失败，随后进入恢复；等待时间受最大帧长限制 | | 预期边界出现未知32位字 | 原边界与线路内容不一致 | 无法计算下一边界 | 立即进入恢复 | -| 已确认位滑移、齿轮箱位滑移或FIFO溢出 | 原有32位相位不再可信 | 不沿用任何旧长度或边界历史 | 清除解析历史并进入恢复 | -| MMCM/PLL失锁、延迟控制器失效或时钟异常 | 物理采样本身不可信 | 不执行边界搜索 | 立即撤销 `link_sync_up` 并返回训练流程 | +| 实现明确报告当前接收边界或连续数据不再可信 | 原有32位边界不再可信 | 不沿用任何旧长度或边界历史 | 丢弃当前未完成帧，清除解析历史并进入恢复 | +| 接收资源不可用 | 当前接收数据不可信 | 不执行边界搜索 | 立即撤销`link_sync_up`并进入资源恢复或重新训练 | | 普通帧无缝背靠背发送 | 前一帧长度确定后一帧起点 | 前一帧下一边界直接匹配后一帧`SOF` | 不要求两帧之间插入`IDLE` | `DATA`的线路帧总长度为 `LINE_FRAME_BYTES = 12 + LEN` 字节；`CTRL`固定为16字节；固定训练类帧固定为20字节；`IDLE`固定为4字节。因此，在已知帧起点和合法`LEN`时，RTL应使用字计数直接生成 `expected_next_boundary`，不得通过搜索载荷中的`SOF`推测帧尾。 @@ -1421,41 +1445,75 @@ stateDiagram-v2 7. CRC正确时该位置为可信边界；CRC错误时该位置为暂定边界； 8. 在该位置完整匹配`IDLE`或合法`SOF`后，边界转为可信；若匹配失败则进入 `MON_RECOVERY`。 -最大`DATA`帧为1044字节，即261个32位字，线路时间约11.136 μs；`CTRL`为16字节，即4个32位字，约170.667 ns。因此，帧内不搜索`SOF`造成的逻辑失步发现延迟有确定上界。参考时钟、PLL、延迟资源和FIFO溢出监测在帧内仍持续工作，不受帧长影响。 +最大`DATA`帧为1044字节，即261个32位字，线路时间约11.136 μs；`CTRL`为16字节，即4个32位字，约170.667 ns。因此，帧内不搜索`SOF`造成的逻辑失步发现延迟有确定上界。接收资源可用状态和实现内部的边界有效性状态在帧内仍持续监测，不受帧长影响。 ### 25.5 边界恢复搜索 -进入 `MON_RECOVERY` 时，必须清除当前帧类型、剩余长度、解扰状态、CRC状态和此前的`SOF`匹配历史，并禁止向协议层提交数据。 +进入`MON_RECOVERY`时，必须清除当前帧类型、剩余长度、解扰状态、CRC状态、暂定边界标志和此前的`SOF`匹配历史，并禁止向传输协议层提交数据。进入`MON_RECOVERY`本身不撤销`link_sync_up`，也不复位当前传输协议会话；只有恢复搜索失败并产生`sync_lost`时才执行会话复位。 -当4位并行节拍仍可信、只有32位字起点未知时： +当物理接口适配逻辑输出的当前接收分组仍可信、只有32位协议字起点未知时： -1. 每接收4位更新一次32位滑动窗口； -2. 依次检查一个32位字包含的8种4位偏移； +1. 随每个有效接收数据块更新至少覆盖32位的滑动窗口； +2. 检查实现所支持的全部32位协议字边界候选位置； 3. 在候选位置只匹配未加扰的`IDLE`或各类`SOF`； 4. 匹配`SOF`后必须继续验证对应完整结构，不能仅凭`SOF`恢复。 +有效接收数据块的宽度、滑动窗口的内部组织以及候选位置的并行或串行检查方式不属于本规范的规定范围。 + 候选边界通过以下任一方式确认： -- 在同一32位相位连续匹配 `RECOVERY_IDLE_WORDS` 个`IDLE`； -- 完整匹配一个与当前角色允许状态一致的160位固定帧；若该帧为`TRAIN`、`SYNC`或`SYNC_RESET`，还必须执行相应顶层状态转换； -- 从候选`DATA` `SOF`开始取得合法`LEN`，按长度完成解扰和CRC，并连续得到 `RECOVERY_CONFIRM_FRAMES` 个CRC及边界均正确的普通帧； -- 从候选`CTRL` `SOF`开始完整接收固定16字节，CRC正确，并满足`CTRL`格式约束。 +- 在候选边界完整匹配1个合法`IDLE`； +- 完整匹配一个与当前角色允许状态一致的160位固定帧；若该帧具有顶层状态含义，必须执行对应状态转换； +- 从候选`DATA` `SOF`开始取得合法`LEN`，按长度完成解扰和CRC，并确认计算得到的下一边界合法； +- 从候选`CTRL` `SOF`开始完整接收固定16字节，CRC和格式正确，并确认计算得到的下一边界合法。 -若4位节拍内部的位相位也不可信，接收端必须遍历SERDES/齿轮箱支持的全部位滑移位置；每次改变位滑移后清除滑动窗口和候选历史，再执行上述搜索。只在旧32位相位上寻找`SOF`不能恢复位滑移。 +从进入`MON_RECOVERY`到产生`recovery_confirmed`之前，所有用于搜索和确认的候选`DATA`和`CTRL`均必须丢弃，包括最终满足恢复条件的候选帧；不得产生普通`rx_frame_valid`，不得更新`RCV_NEXT`、ACK、窗口或重传状态。恢复成功后，从确认候选结束后的下一个完整边界开始恢复普通帧提交。`DL`候选帧由ACK不推进和后续重传恢复；`UL`候选帧可能丢失，符合无确认接收语义。 -恢复成功后，将确认候选的起始位置设为新的可信边界，重新初始化对应帧的解扰和CRC状态。达到 `RECOVERY_SEARCH_LIMIT` 仍不能确认，则置位 `sync_lost`，撤销 `link_sync_up` 并返回训练流程。 +若物理接口适配逻辑输出的接收对齐位置不可信，接收端必须遍历实现支持的全部接收对齐候选位置；每次改变候选位置后清除滑动窗口和候选历史，再执行上述搜索。候选位置的数量、形成方法和切换机制不属于本规范的规定范围。 + +`RECOVERY_SEARCH_LIMIT_WORDS`从进入`MON_RECOVERY`并完成历史清除后的第一个32位接收字开始计数。恢复条件和搜索上限在同一字成立时，恢复成功优先。搜索上限不得小于`2 × MAX_LINE_FRAME_WORDS`加实现所需的接收对齐候选搜索余量；当前最大线路帧为261个32位字，因此不含额外候选余量的基础下限为522个32位字时间。 + +恢复成功后，将确认候选结束后的下一位置设为新的可信边界，并为下一帧重新初始化解扰和CRC状态。达到搜索上限仍不能确认时，置位`sync_lost`、撤销`link_sync_up`并按第26.2节复位当前协议会话和进入方向化重新训练。 ### 25.6 角色相关固定帧处理 | 接收端状态 | 完整固定帧 | 动作 | |---|---|---| | 主端 `M_RUN` | `TRAIN` | 从端已因`DL`异常退回训练；若`UL`仍可靠则进入 `M_TX_TRAIN` | -| 主端 `M_RUN` | 其他意外固定帧 | 记录异常；连续达到门限后重训 | +| 主端 `M_RUN` | `SYNC`、`TRAIN_ACK`、`SYNC_ACK`、`SYNC_RESET`或其他意外固定帧 | 认为双方状态不一致，立即撤销同步并重新训练`UL`和`DL` | | 从端 `S_RUN` | `SYNC_RESET` | 立即撤销同步并进入 `S_TRAIN`，不触发全局复位 | -| 从端 `S_RUN` | 连续`TRAIN`或`SYNC` | 认为主端正在重建链路，进入 `S_TRAIN` 并按训练流程响应 | +| 从端 `S_RUN` | `TRAIN`、`SYNC`、`TRAIN_ACK`、`SYNC_ACK`或其他意外固定帧 | 认为主端正在重建链路或双方状态不一致，立即撤销同步并进入`S_TRAIN` | | 任一端训练期 | 与当前状态不一致的固定帧 | 不向上传递；清零对应连续计数，继续或超时恢复 | -## 26. 重新训练与传输状态恢复 +### 25.7 运行期CRC错误门限 + +单个CRC错误只丢弃当前帧，不单独触发重新训练。每个接收方向同时维护连续错误计数和最近帧滑动窗口统计，只统计已经取得合法帧长并到达CRC位置的`DATA`和`CTRL`： + +```text +CRC_CONSECUTIVE_RETRAIN_THRESHOLD = 4 +CRC_WINDOW_FRAMES = 256 +CRC_ERROR_RETRAIN_THRESHOLD = 8 +``` + +连续4个CRC承载帧失败，或者最近256个CRC承载帧中累计8个CRC错误，任一条件满足即判定该方向链路质量失效。CRC正确使连续错误计数清零；长度非法和边界丢失按边界异常处理，不计入CRC错误统计。重新训练开始时清零两类统计。 + +主端检测到`UL`达到门限时重新训练`UL`和`DL`。从端检测到`DL`达到门限时撤销同步、进入`S_TRAIN`并通过可信`UL`持续发送`TRAIN`；主端确认`UL`仍可靠时只重新训练`DL`。 + +### 25.8 运行期事件优先级 + +同一接收周期出现多个事件时，链路同步层按以下顺序处理： + +1. 公共资源失效； +2. 当前方向被实现明确判定为不可信； +3. 完整`SYNC_RESET`； +4. 当前状态具有控制含义的完整固定帧； +5. 当前状态的通过条件； +6. 当前状态的超时条件； +7. 普通帧解析和计数更新。 + +完整固定帧引起的状态转换优先于普通协议帧。通过和超时同周期成立时通过优先。尚未完整接收的固定帧不得产生状态事件。 + +## 26. 重新训练与新会话建立 ### 26.1 触发条件 @@ -1470,56 +1528,77 @@ stateDiagram-v2 训练失败时状态机持续执行相应训练，不因重试次数达到某个值而停止。重试计数只用于诊断。单个 CRC错误、合法帧的内容错误或上层丢包不触发物理重训。 -### 26.2 链路重新训练与会话复位 +### 26.2 同步丢失、重新训练与协议复位 -链路重新训练和会话复位是两个相互独立的过程： +同步重新训练的方向范围和传输协议会话的有效性是两个不同问题。链路同步层根据异常方向决定需要重新训练的方向；只要任一方向同步丢失，当前双向传输协议会话就立即失效，双方传输协议层都必须复位。 -- **链路重新训练**只重新建立采样位置、发送位置和帧边界，保留仍然有效的传输协议状态； -- **会话复位**清除传输协议状态和缓存，从初始序号开始。会话复位必须由双方可见的独立系统条件触发，不能由普通失步隐式触发。 +#### 26.2.1 协议层可见的链路状态 -#### 26.2.1 重训练入口与状态保持 +`link_sync_up`是提供给传输协议层的聚合链路状态，只有同时满足以下条件时才允许为1： -任意传输状态下，只要`link_sync_up`撤销、`sync_lost`有效或数据链路层进入`retrain_busy`，传输协议层必须立即进入链路不可用保持状态，并执行以下动作： +```text +link_sync_up = ul_sync_up && dl_sync_up && run_entry_complete +``` -1. 撤销`transport_ready`，停止接受新的业务发送请求，并停止向数据链路层提交新的`DATA`或`CTRL`逻辑帧； -2. 停止并清除`T_ACK_WAIT`、`T_POLL_INTERVAL`和`T_PROGRESS_LIMIT`计时；重训练持续时间不得计入协议超时，也不得增加连续失败计数； -3. 回滚所有尚未得到最终CRC结论的接收候选帧，不推进`RCV_NEXT`，不更新确认点，也不产生业务应用层可见动作； -4. 保留已经提交的接收数据、已经完成记账的发送序号、接收期望序号、未确认帧描述符、重传载荷、窗口占用记账以及已经由传输协议层接受但尚未完成发送的业务请求； -5. 清除尚未开始发送的`POLL_PENDING`、`ACK_PENDING`和`RETRY_PENDING`等控制帧调度标志；恢复后的状态查询将重新生成当前状态，不依赖重训练前的控制帧快照； -6. 主端将此前缓存的`PEER_WIN_BYTES`标记为无效。在收到新的合法状态报告前，不得使用旧窗口公告首次发送业务帧； -7. 从端保留本地接收缓存和实际资源占用。重训练期间业务应用层可以继续消费已经提交的数据，因此恢复时必须根据当时的真实可用容量重新计算`WIN_BYTES`。 +`ul_sync_up`和`dl_sync_up`可作为链路同步层内部状态或诊断输出；传输协议层不得因为其中一个方向仍可信而继续处理原会话业务。任一方向同步丢失时，检测端必须立即撤销`link_sync_up`。另一端通过仍可信方向上的链路层训练序列或同步状态变化获知异常后，也必须撤销`link_sync_up`。只有双方完成规定范围内的重新训练及运行入口过程后，才能重新置位`link_sync_up`。 -#### 26.2.2 重训练入口处的在途帧 +#### 26.2.2 重新训练方向 -`tx_frame_done`是判断一帧是否完成线路发送的唯一边界： +重新训练范围按以下规则确定： -- 重训练入口与`tx_frame_done`同周期发生时，发送端必须先完成该帧的协议记账，再进入保持状态； -- 尚未产生`tx_frame_done`的线路帧必须由数据链路层中止，不得报告发送完成； -- 首次发送的业务帧在中止时不得推进`SND_NXT`或增加`OUTSTANDING_BYTES`，其描述符和载荷返回待发送状态，恢复后继续使用原定的下一业务序号； -- 重传帧在中止时不得推进`RETX_PTR`，恢复后由新的`ACK_NEXT`重新确定重传起点； -- 从端尚未完成的无确认`UL DATA`不得产生`app_tx_completed`。如果该请求已经产生`app_tx_accepted`，从端必须保留它并在恢复后重新提交；由此产生的`UL`重复帧符合无确认接收语义； -- 尚未完整发送的`CTRL`不保留原快照，恢复后根据当前确认点和窗口重新生成。 +| 异常情况 | 必须执行的重新训练 | +|---|---| +| `UL`同步异常，或者`UL`已不再可信 | 重新训练`UL`和`DL` | +| `DL`同步异常且`UL`仍可信 | 只重新训练`DL`；可信的`UL`可以继续承载链路层训练和状态信息 | +| `DL`重新训练期间`UL`也失去同步 | 转为重新训练`UL`和`DL` | +| 公共时钟或公共资源失效 | 资源恢复后重新训练`UL`和`DL` | -#### 26.2.3 重训练期间的行为 +即使只重新训练`DL`，仍然必须终止并复位整个双向传输协议会话。保持可信的`UL`在重新训练期间不得承载原会话的普通`DATA`或`CTRL`。 -数据链路层执行相位或延迟扫描、双向训练和同步确认。传输协议层在此期间不得发送或接受普通`DATA`和`CTRL`，不得推进任何业务序号，不得释放未确认缓存，也不得根据协议超时触发新的重传轮次。只有训练和同步固定帧可以在线路上传输。 +#### 26.2.3 协议复位动作 -#### 26.2.4 重训练后的传输状态恢复 +任意传输状态下，只要`link_sync_up`撤销、`sync_lost`有效或数据链路层进入`retrain_busy`，传输协议层必须立即撤销`transport_ready`，停止接受新的业务发送请求，并进入协议复位保持状态。必须执行以下动作： -链路重新同步后按照以下顺序恢复： +1. 停止并清除`T_ACK_WAIT`、`T_POLL_INTERVAL`、`T_PROGRESS_LIMIT`以及连续失败计数； +2. 中止尚未完成线路发送的普通协议帧；不得把`tx_frame_abort`当作`tx_frame_done`； +3. 回滚所有尚未得到最终CRC结论的接收候选帧，不产生业务应用层可见提交； +4. 主端清零`SND_UNA`、`SND_NXT`、`OUTSTANDING_BYTES`和`PEER_WIN_BYTES`，清空重传缓存、未发送描述符及控制请求快照； +5. 从端清零`RCV_NEXT`、`ACK_PENDING`和`RETRY_PENDING`，丢弃尚未提交的接收候选帧及控制响应快照； +6. 从端释放由未提交候选帧占用的传输协议接收资源，并根据复位后的实际可用接收容量重新计算`WIN_BYTES`，不得无条件把窗口设置为实现最大值； +7. 已经提交给业务应用层的数据不回滚。已经被传输协议层接受、但在会话失效前尚未取得最终完成结果的业务发送请求必须报告会话中止，不得静默报告成功，也不得自动带入新会话。 -1. 数据链路层置位`link_sync_up`并产生`retrain_done`；传输协议层仍保持`transport_ready=0`； -2. 主端清零重训练前的连续失败计数，进入`M_WAIT_STATUS`并置位`POLL_PENDING`；第一次`POLL_REQ`实际开始发送后启动`T_POLL_INTERVAL`； -3. 从端进入`S_EXPECT`，保留原`RCV_NEXT`和接收资源状态；收到合法`POLL_REQ`后，用当前`RCV_NEXT`形成`ACK_NEXT`，并用当前真实可用容量形成`WIN_BYTES`； -4. 主端收到合法状态报告后，先按`ACK_NEXT`释放已经累计确认的发送前缀，再更新新的`PEER_WIN_BYTES`； -5. 如果仍有未确认帧，主端从新的`SND_UNA`开始执行Go-Back-N恢复；如果没有未确认帧，则直接进入`M_RUN`； -6. 只有保留的未确认帧已按新状态完成必要的重传调度，且主端进入`M_RUN`后，才允许重新置位`transport_ready`并接受新的可靠`DL`业务请求。此条件不要求所有保留帧都已被ACK；进入`M_RUN`后仍可按正常机制等待其累计确认。 +上述协议复位不是主端或从端的全局器件复位，也不要求复位业务应用层。若业务应用层需要重新提交结果不确定的操作，必须由业务语义决定是否允许重复执行。 -如果任一端在重训练期间丢失了传输协议状态，例如发生掉电、协议复位或缓存内容失效，则不得使用上述保留状态恢复流程。系统必须触发双方完整会话复位；任何一端不得单独改变`SEQ`基准后继续通信。 +#### 26.2.4 重新训练期间的行为 + +传输协议层在`link_sync_up=0`期间保持复位，不得发送或接受普通`DATA`和`CTRL`，不得推进业务序号，也不得启动协议超时。数据链路层只允许发送重新训练和同步流程规定的固定帧、训练应答及运行入口序列。 + +`DL`异常且`UL`仍可信时，从端通过`UL`发送的`TRAIN`或规范规定的链路层状态，使主端得知`DL`异常并进入`DL`重新训练；该信息属于链路同步层，不得解释为传输协议业务。 + +#### 26.2.5 新会话初始化 + +规定范围内的重新训练和运行入口过程完成后，按照以下顺序建立新会话： + +1. 双方链路同步层置位`link_sync_up`并产生`retrain_done`；双方传输协议状态仍保持第26.2.3节规定的初始值，`transport_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节执行兼容对齐。 + +初始响应中的`ACK_NEXT`只定义新会话从哪个序号开始，不表示对旧会话帧的累计确认。该响应必须绕过正常运行期的ACK合理性检查，不得释放任何缓存；此时旧会话缓存已经清空。`POLL_REQ/ACK`同时用于确认控制帧通路可用并取得真实接收窗口。单端重启也按本节处理，不需要从该值推断重启前的会话状态。 ### 26.3 `SYNC_RESET` -`SYNC_RESET`是主端主动请求从端返回训练状态的固定帧。它不触发从端全局复位，也不清除传输状态。主端主动发起链路重新训练且`DL`仍具备传送完整固定帧的条件时，必须连续发送20个`SYNC_RESET`；发送期间收到的`TRAIN`不作为提前终止条件。逐帧重复发送是幂等操作：从端在任意非资源等待状态完整匹配其中任意一个160位`SYNC_RESET`后，清除`train_ack_active`及固定帧检测历史并进入或保持`S_TRAIN`。主端发送完成后再进入相应训练状态。若`DL`已严重失步而无法识别全部`SYNC_RESET`，从端的运行期监测仍应检测到边界异常并自行进入`S_TRAIN`。从端因本地检测到`DL`失步而自行进入`S_TRAIN`时，不要求先收到`SYNC_RESET`。 +`SYNC_RESET`是主端主动请求从端返回训练状态的固定帧。它不触发从端全局器件复位；收到该帧会使链路同步状态撤销，并按第26.2节终止和复位当前传输协议会话。主端主动发起链路重新训练且`DL`仍具备传送完整固定帧的条件时，必须连续发送20个`SYNC_RESET`；发送期间收到的`TRAIN`不作为提前终止条件。逐帧重复发送是幂等操作：从端在任意非资源等待状态完整匹配其中任意一个160位`SYNC_RESET`后，清除`train_ack_active`及固定帧检测历史并进入或保持`S_TRAIN`。主端发送完成后再进入相应训练状态。若`DL`已严重失步而无法识别全部`SYNC_RESET`，从端的运行期监测仍应检测到边界异常并自行进入`S_TRAIN`。从端因本地检测到`DL`失步而自行进入`S_TRAIN`时，不要求先收到`SYNC_RESET`。 + +### 26.4 复位可见性与训练入口 + +主端复位或重新初始化链路同步模块时，必须使`DL`退出合法运行期连续流，直至重新训练开始。该行为必须足以使从端撤销`DL`同步状态并进入`S_TRAIN`；不允许主端在本地同步状态已经丢失后继续输出会被从端解释为合法运行期`IDLE`或普通协议帧的连续流。满足此约束后，主端单独重启会使从端自动进入`S_TRAIN`并在`UL`持续发送`TRAIN`，主端按正常`M_RX_TRAIN`入口恢复。 + +进入任一新训练轮次时，必须清除固定帧连续计数、固定帧匹配历史、候选边界、普通帧剩余长度、CRC和解扰状态、暂定边界标志、当前扫描点统计、已失效的窗口扫描结果以及运行期CRC错误统计。诊断计数和最近一次成功延迟值可以保留；只重新训练`DL`时可以保留仍被确认可信的`UL`延迟配置。 + +当可信方向承担训练状态通知时，训练固定帧必须从该方向的完整帧边界开始。物理资源仍可用时，已经开始的普通帧先完整发送结束；物理资源失效导致无法完成时，必须中止该帧并把该方向一并判定为不可信。 ## 27. 同步机制配置参数 @@ -1547,19 +1626,23 @@ stateDiagram-v2 | `SYNC_ACK_TX_COUNT` | 帧 | 固定为20；从端定量发送 | | `SYNC_ACK_PASS_COUNT` | 帧 | 固定为10个连续正确`SYNC_ACK` | | `UL_SYNC_PASS_COUNT` | 帧 | 固定为10000个连续正确`SYNC` | -| `SYNC_PHASE_TIMEOUT_FRAMES` | 帧时间 | 必须大于10000并覆盖检测、切换和流水线余量 | +| `M_DL_CONFIRM_TIMEOUT_FRAMES` | 固定帧时间 | 必须大于`DL_SYNC_PASS_COUNT + SYNC_ACK_PASS_COUNT`并覆盖往返及流水线余量 | +| `M_UL_CONFIRM_TIMEOUT_FRAMES` | 固定帧时间 | 必须大于`UL_SYNC_PASS_COUNT + (SYNC_ACK_TX_COUNT-SYNC_ACK_PASS_COUNT)`并覆盖流水线余量 | | `S_UL_SYNC_TIMEOUT_FRAMES` | 固定帧时间 | 固定为10500；从端进入`S_UL_SYNC_TX`后等待首个完整合法`DL IDLE`的上限 | | `SYNC_RESET_TX_COUNT` | 帧 | 固定为20；主端主动发起链路重新训练时连续发送 | | `RUN_ENTRY_IDLE_TX_WORDS` | 32位字 | 固定为20；从端运行入口响应长度 | | `RUN_ENTRY_IDLE_PASS_WORDS` | 32位字 | 固定为1；主端收到首个完整`UL IDLE`即通过 | -| `RUN_ENTRY_TIMEOUT` | 时钟周期 | 主端在`M_RUN_ENTRY`中等待首个完整`UL IDLE`的最长时间；从端发送20个`UL IDLE`不使用此超时 | -| `RECOVERY_IDLE_WORDS` | 32位字 | 边界恢复所需连续`IDLE`数 | -| `RECOVERY_CONFIRM_FRAMES` | 帧 | 普通帧恢复确认数 | -| `RECOVERY_SEARCH_LIMIT` | 位或时钟周期 | 超过后触发重训 | +| `M_RUN_ENTRY_TIMEOUT_WORDS` | 32位字时间 | 主端进入`M_RUN_ENTRY`后等待首个完整`UL IDLE`的上限；必须大于`RUN_ENTRY_IDLE_TX_WORDS`并覆盖实现流水线余量 | +| `RECOVERY_IDLE_WORDS` | 32位字 | 固定为1；在候选边界匹配一个完整合法`IDLE`即可确认恢复 | +| `RECOVERY_CONFIRM_FRAMES` | 帧 | 固定为1；一个长度、CRC及下一边界均正确的普通帧即可确认恢复 | +| `RECOVERY_SEARCH_LIMIT_WORDS` | 32位字时间 | 实现配置值；不得小于`2 × MAX_LINE_FRAME_WORDS`加接收对齐候选搜索余量；当前最大帧下基础下限为522 | +| `CRC_CONSECUTIVE_RETRAIN_THRESHOLD` | CRC承载帧 | 固定为4；连续4个`DATA`或`CTRL` CRC失败触发方向化重训 | +| `CRC_WINDOW_FRAMES` | CRC承载帧 | 固定为256；滑动错误统计窗口 | +| `CRC_ERROR_RETRAIN_THRESHOLD` | CRC错误帧 | 固定为8；最近256个CRC承载帧中达到8个错误触发方向化重训 | 每次设置`IDELAY`或`ODELAY`后，数据链路层必须分别等待抽象条件`rx_delay_ready`或`tx_delay_ready`有效。本规范只约束“当前延迟配置就绪后才能开始测量”，不规定通过固定等待周期、器件状态信号、配置回读还是其他方法确认就绪。因此，通用参数表不规定统一的延迟稳定周期；具体物理实现可以在第7章配置声明中说明其就绪生成方法。 -本表中的50、200、300、10、10000、10500、20和1为本规范固定基线。除已明确固定的`TRAIN_ACK_ACTIVE_TIMEOUT_FRAMES`和`S_UL_SYNC_TIMEOUT_FRAMES`外，各阶段总超时仍须依据目标器件、线路速率及实际流水线验证。 +本表中的50、200、300、10、10000、10500、20、1、4、256和8为本规范固定基线。确认阶段、运行入口和边界恢复总超时必须按本表下限结合目标器件、线路速率、接收对齐候选数量及实际流水线确定。 计数器按包含终值设计时，50计数至少6位，200计数至少8位，300计数至少9位，10计数至少4位，20计数至少5位，10000和10500计数至少14位。所有连续计数器达到终值后应饱和或立即触发状态转换，不允许回卷。 @@ -2169,13 +2252,11 @@ OUTSTANDING_BYTES <= PEER_WIN_BYTES 连续三轮完整重传和查询均无ACK推进时，主端必须： 1. 停止首次发送新业务帧； -2. 保留全部未确认帧和描述符； -3. 报告可靠链路故障； -4. 触发链路重新训练。 +2. 报告可靠链路故障，并把全部未确认业务请求报告为会话中止； +3. 触发链路重新训练； +4. 按第26.2节清空旧会话的未确认帧、描述符和重传缓存。 -达到门限时不得把未确认帧当作成功帧释放或静默丢弃。 - -纯物理重新训练不自动清除协议状态。若双方仍保留`SEQ`，主端在重新训练后`POLL_REQ`并继续重传。若从端协议状态已经复位，双方必须执行完整协议复位；不得由单端自行改变`SEQ`基准。 +达到门限时不得把未确认帧当作成功帧。会话中止必须向业务应用层报告；同步恢复后从`SEQ=0`建立新会话，不继续重传旧会话帧。 ## 33. 定时参数与失败门限 @@ -2244,8 +2325,7 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N | 事件 | 条件 | 必须动作 | |---|---|---| -| 会话复位完成 | 新协议会话 | 按第31.2节初始化状态并发送`POLL_REQ` | -| 链路重训练完成 | 原协议状态和缓存有效 | 保留传输状态，将旧对端窗口公告置为无效，进入`M_WAIT_STATUS`并发送`POLL_REQ` | +| 链路重训练完成 | 新协议会话 | 确认协议状态保持第31.2节初始值，进入`M_WAIT_STATUS`并发送`POLL_REQ` | | 新业务请求 | 窗口和描述符均足够 | 分配`SND_NXT`、缓存、首次发送、增加`OUTSTANDING_BYTES` | | 新业务请求 | 窗口不足 | 保持请求，停止首次发送，等待ACK或`POLL_REQ` | | 合法前进ACK | `ACK_NEXT`在已发送区间 | 释放前缀、更新`SND_UNA`和`WIN_BYTES`、重算窗口 | @@ -2255,7 +2335,7 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N | T_ACK_WAIT无进展 | 存在未确认帧 | 发送第一次`POLL_REQ` | | T_ACK_WAIT+T_POLL_INTERVAL无进展 | 仍无进展 | 再次发送`POLL_REQ` | | T_PROGRESS_LIMIT无进展 | 存在未确认帧 | 开始重传或判定当前轮失败 | -| 连续3轮失败 | `SND_UNA`未推进 | 保留缓存，报告故障并重新训练 | +| 连续3轮失败 | `SND_UNA`未推进 | 报告可靠链路故障及会话中止，清空旧会话缓存并重新训练 | ### 34.2 从端事件表 @@ -2310,7 +2390,7 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N | `M_RETX_PREP` | 准备一个Go-Back-N重传批次 | 等待当前在途帧结束，再锁存范围、设置RETX_PTR并确定本批终点 | | `M_RETX_SEND` | 顺序提交重传帧 | 禁止首次发送新业务帧；按描述符顺序推进RETX_PTR | | `M_RETX_WAIT` | 本批重传结束后等待ACK进展 | 在T_ACK_WAIT及随后一个T_POLL_INTERVAL到期时请求状态；在T_PROGRESS_LIMIT判定本轮成功或失败 | -| `M_RETRAIN` | 链路失步、数据链路层正在重训练，或已达到连续失败门限 | 保留协议状态，停止协议帧请求；由连续失败门限进入时置位`retrain_request`；等待链路重新同步 | +| `M_RETRAIN` | 链路失步、数据链路层正在重训练，或已达到连续失败门限 | 清除当前协议会话状态和缓存，停止协议帧请求；由连续失败门限进入时置位`retrain_request`；等待链路重新同步 | `M_RUN`同时覆盖有未确认帧、等待窗口和暂时没有上层发送请求的情况。这些情况由`OUTSTANDING_BYTES`、窗口比较和请求有效信号区分，不需要建立互斥的等待状态。主端可对业务层宣告的就绪条件为`master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN)`。 @@ -2333,8 +2413,7 @@ RETX_PTR = 当前SND_UNA ```mermaid stateDiagram-v2 [*] --> M_WAIT_STATUS - M_WAIT_STATUS --> M_RUN: 收到合法状态且无待恢复帧 - M_WAIT_STATUS --> M_RETX_PREP: 收到合法状态且保留未确认帧 + M_WAIT_STATUS --> M_RUN: 收到格式和CRC合法的初始状态 M_WAIT_STATUS --> M_WAIT_STATUS: T_POLL_INTERVAL无合法状态 / 请求POLL M_RUN --> M_RUN: 新帧完成、合法ACK或窗口更新 @@ -2366,11 +2445,10 @@ stateDiagram-v2 | 当前状态 | 事件和条件 | 寄存器及控制动作 | 下一状态 | |---|---|---|---| -| 任意非`M_RETRAIN`状态 | `link_sync_up=0`、`sync_lost=1`或`retrain_busy=1` | 按第26.2节结算同周期`tx_frame_done`，中止未完成帧；保留序号、描述符、载荷和窗口占用记账；旧`PEER_WIN_BYTES`失效；停止协议计时并撤销`transport_ready` | `M_RETRAIN` | +| 任意非`M_RETRAIN`状态 | `link_sync_up=0`、`sync_lost=1`或`retrain_busy=1` | 按第26.2节中止当前会话；清零序号、窗口和协议计时，清空描述符及重传缓存，撤销`transport_ready`，并报告未完成业务请求已中止 | `M_RETRAIN` | | 任意非`M_RETRAIN`状态 | 收到合法`CTRL` | 先按第31.6节处理`ACK_NEXT`和`WIN_BYTES`；无效`CTRL`不改变任何可靠传输状态 | 按下列事件继续判断 | -| `M_WAIT_STATUS` | 收到合法状态，且无保留的未确认帧 | 更新确认点和窗口；清除本次`POLL_REQ`等待 | `M_RUN`，即使`WIN_BYTES`为0 | -| `M_WAIT_STATUS` | 重新训练后收到合法状态，且仍有未确认帧 | 保留描述符；设置 `RETX_END=SND_NXT` | `M_RETX_PREP` | -| `M_WAIT_STATUS` | T_POLL_INTERVAL无合法状态 | 置位 `POLL_PENDING`；不得初始化或清除`SEQ` | `M_WAIT_STATUS` | +| `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` | | `M_RUN` | 新业务帧完成首次发送 | `OUTSTANDING_BYTES += FRAME_COST`；`SND_NXT++`；若未确认集合由空变为非空则启动进度计时 | `M_RUN` | | `M_RUN` | 合法前进ACK | 释放确认前缀，更新`SND_UNA`和窗口，清零失败计数并重新开始或停止进度计时 | `M_RUN` | | `M_RUN` | 同确认点`ACK/UPDATE` | 仅更新同一确认点的窗口；不得释放缓存或重置进度计时 | `M_RUN` | @@ -2387,10 +2465,10 @@ stateDiagram-v2 | `M_RETX_WAIT` | ACK推进且 `RETX_PTR < RETX_END` | 清零失败计数，从新`SND_UNA`重新计算窗口允许的剩余前缀 | `M_RETX_PREP` | | `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` | `retrain_done=1`且协议状态有效 | 保留`SEQ`、缓存、描述符和窗口占用记账；清零连续失败计数；保持`transport_ready=0`；置位`POLL_PENDING` | `M_WAIT_STATUS` | -| 任意状态 | 双方完整协议复位 | 清空可靠传输状态并按第31.2节初始化 | `M_WAIT_STATUS` | +| `M_RETRAIN` | `retrain_done=1`且`link_sync_up=1` | 保持第31.2节规定的初始协议状态；保持`transport_ready=0`；置位`POLL_PENDING` | `M_WAIT_STATUS` | +| 任意状态 | `link_sync_up=0`、`sync_lost=1`或`retrain_busy=1` | 清空可靠传输状态并按第31.2节初始化 | `M_RETRAIN` | -由协议事件触发普通状态转移时，当前完整帧必须发送结束后再切换调度请求。链路失步或重训练入口不适用该等待规则：未产生`tx_frame_done`的帧必须立即中止，并按第26.2.2节恢复其描述符和记账状态。 +由协议事件触发普通状态转移时，当前完整帧必须发送结束后再切换调度请求。同步丢失或重新训练入口不适用该等待规则：未产生`tx_frame_done`的帧必须立即中止，相关描述符和记账状态随旧会话一起清除，并向业务应用层报告会话中止。 因此，`RETRY_REQ`或T_PROGRESS_LIMIT超时到达时不得立即用旧`SND_NXT`冻结RETX_END。若当时正在首次发送新业务帧，必须先等待 `frame_tx_done`，完成该帧的`SND_NXT`和`OUTSTANDING_BYTES`更新，再以更新后的`SND_NXT`冻结重传范围。这样能够保证已经上线的最后一帧不会遗漏在Go-Back-N范围之外。 @@ -2398,12 +2476,11 @@ stateDiagram-v2 同一时钟周期出现多个事件时，必须按以下顺序处理： -1. 双方完整协议复位； +1. `link_sync_up`撤销、`sync_lost`或`retrain_busy`引起的会话终止和协议复位；该事件抑制本周期所有较低优先级协议动作； 2. 已经有效的`tx_frame_done`及其发送记账； -3. `link_sync_up`撤销、`sync_lost`或`retrain_busy`引起的重训练进入事件； -4. 合法接收`CTRL`：先做累计ACK和窗口更新，再解释`FLAGS`； -5. T_ACK_WAIT、后续T_POLL_INTERVAL及T_PROGRESS_LIMIT定时事件； -6. 新上层业务请求。 +3. 合法接收`CTRL`：先做累计ACK和窗口更新，再解释`FLAGS`； +4. T_ACK_WAIT、后续T_POLL_INTERVAL及T_PROGRESS_LIMIT定时事件； +5. 新上层业务请求。 前进ACK与T_PROGRESS_LIMIT超时同周期发生时，以前进ACK为准，重置进度计时并抑制本周期的失败判定。合法`RETRY_REQ`中的`ACK_NEXT`必须先释放确认前缀；仅当处理后仍有未确认帧时才进入重传。 @@ -2439,7 +2516,7 @@ stateDiagram-v2 |---|---| | `S_EXPECT` | 等待`SEQ`等于`RCV_NEXT`的合法业务帧 | | `S_RETRY_WAIT` | 已发现错误，仍等待同一个`RCV_NEXT`对应的正确业务帧 | -| `S_LINK_HOLD` | 链路不可用或正在重训练；保留`RCV_NEXT`和接收资源，不处理普通协议帧 | +| `S_LINK_HOLD` | 链路不可用或正在重训练；协议状态保持复位，不处理普通协议帧 | ```mermaid stateDiagram-v2 @@ -2453,14 +2530,14 @@ stateDiagram-v2 S_LINK_HOLD --> S_EXPECT: retrain_done / 等待POLL_REQ ``` -`S_LINK_HOLD`期间不得接受普通`DATA`或`CTRL`。重训练完成后进入`S_EXPECT`，但在收到合法`POLL_REQ`前不主动恢复普通业务传输。收到合法`POLL_REQ`只置位`ACK_PENDING`，不改变上述接收状态。`WIN_BYTES`从0恢复为非0时同样只置位`ACK_PENDING`。无效`CTRL`直接丢弃，不改变`RCV_NEXT`、`ACK_PENDING`或`RETRY_PENDING`。 +`S_LINK_HOLD`期间不得接受普通`DATA`或`CTRL`。重训练完成后，保持`RCV_NEXT=0`进入`S_EXPECT`，但在收到合法`POLL_REQ`前不恢复普通业务传输。收到合法`POLL_REQ`只置位`ACK_PENDING`，不改变上述接收状态。`WIN_BYTES`从0恢复为非0时同样只置位`ACK_PENDING`。无效`CTRL`直接丢弃，不改变`RCV_NEXT`、`ACK_PENDING`或`RETRY_PENDING`。 #### 35.4.2 从端事件—动作表 | 当前状态 | 事件和条件 | 必须动作 | 下一状态 | |---|---|---|---| -| 任意非`S_LINK_HOLD`接收状态 | `link_sync_up=0`、`sync_lost=1`或`retrain_busy=1` | 回滚未完成候选帧；保留`RCV_NEXT`和接收资源；清除未发送的控制快照；撤销`transport_ready` | `S_LINK_HOLD` | -| `S_LINK_HOLD` | `retrain_done=1`且协议状态有效 | 保留`RCV_NEXT`，根据真实资源重新计算`WIN_BYTES`，等待`POLL_REQ` | `S_EXPECT` | +| 任意非`S_LINK_HOLD`接收状态 | `link_sync_up=0`、`sync_lost=1`或`retrain_busy=1` | 回滚未完成候选帧；清零`RCV_NEXT`、`ACK_PENDING`和`RETRY_PENDING`，释放未提交接收资源并重新计算`WIN_BYTES`；撤销`transport_ready` | `S_LINK_HOLD` | +| `S_LINK_HOLD` | `retrain_done=1`且`link_sync_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` | | `S_RETRY_WAIT` | 正确收到当前`RCV_NEXT`对应业务帧且资源足够 | 提交一次；`RCV_NEXT++`；`RETRY_PENDING=0`；`ACK_PENDING=1` | `S_EXPECT` | @@ -2468,7 +2545,6 @@ stateDiagram-v2 | 任意非`S_LINK_HOLD`接收状态 | 收到合法`POLL_REQ` | `ACK_PENDING=1` | 状态不变 | | 任意非`S_LINK_HOLD`接收状态 | `WIN_BYTES`从0恢复为非0 | `ACK_PENDING=1` | 状态不变 | | 任意非`S_LINK_HOLD`接收状态 | `CTRL`校验或格式失败 | 丢弃`CTRL`，不产生状态更新 | 状态不变 | -| 任意接收状态 | 双方完整协议复位 | `RCV_NEXT=0`，清除待发送状态 | `S_EXPECT` | #### 35.4.3 待发送状态的并发更新 @@ -2487,19 +2563,18 @@ ACK_PENDING_next = NEW_STATUS_EVENT OR (ACK_PENDING AND NOT STATUS_LAUNCH) ``` -其中 `NEW_STATUS_EVENT` 包括接受业务帧、检测业务帧错误、收到合法`POLL_REQ`以及`WIN_BYTES`从0恢复。发送`RETRY_REQ`不得清除`RETRY_PENDING`；只有正确接受当前`RCV_NEXT`对应业务帧或完整协议复位才能清除它。 +其中`NEW_STATUS_EVENT`包括接受业务帧、检测业务帧错误、收到合法`POLL_REQ`以及`WIN_BYTES`从0恢复。发送`RETRY_REQ`不得清除`RETRY_PENDING`；正常运行时只有正确接受当前`RCV_NEXT`对应业务帧才能清除它；同步丢失时按第26.2节直接复位该状态。 #### 35.4.4 从端事件优先级 同一时钟周期出现多个事件时，必须按以下顺序形成下一状态： -1. 双方完整协议复位； -2. `link_sync_up`撤销、`sync_lost`或`retrain_busy`引起的重训练进入事件； -3. `retrain_done`引起的保持状态退出； -4. `DATA`候选帧完成事件，按成功接受或失败丢弃更新`RCV_NEXT`和`RETRY_PENDING`； -5. 合法`POLL_REQ`及`WIN_BYTES`从0恢复事件； -6. 状态`CTRL`开始发送产生的旧快照清除事件； -7. 从端上层无确认业务发送请求。 +1. `link_sync_up`撤销、`sync_lost`或`retrain_busy`引起的会话终止和协议复位；该事件抑制本周期所有较低优先级协议动作； +2. `retrain_done`引起的保持状态退出； +3. `DATA`候选帧完成事件，按成功接受或失败丢弃更新`RCV_NEXT`和`RETRY_PENDING`； +4. 合法`POLL_REQ`及`WIN_BYTES`从0恢复事件； +5. 状态`CTRL`开始发送产生的旧快照清除事件； +6. 从端上层无确认业务发送请求。 同一个候选业务帧不得同时报告成功和失败。如果业务帧事件、`POLL_REQ`或窗口恢复与 `STATUS_LAUNCH` 同周期发生，新状态事件必须使`ACK_PENDING`在周期结束后保持为1。从端发送调度事件不得改变接收状态，也不得阻止接收控制器在同周期处理业务帧。 @@ -2520,7 +2595,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`，从端必须保留其载荷，并在链路重新同步且传输状态恢复后重新提交。 +同步丢失是上述不可抢占规则的例外。未产生`frame_tx_done`的`CTRL`立即中止且不保留原快照；未产生`frame_tx_done`的无确认`UL DATA`不得产生`app_tx_completed`。如果该业务请求已经产生`app_tx_accepted`，从端必须向业务应用层报告会话中止，不得自动带入新会话重新提交。 ### 35.6 RTL接口事件契约 @@ -2568,10 +2643,10 @@ stateDiagram-v2 ### 36.4 失败与方向差异 -1. 连续3轮重传无进展时必须保留缓存并触发重新训练，不得静默丢帧。 +1. 连续3轮重传无进展时必须报告可靠链路故障及会话中止，并触发重新训练；旧会话缓存按第26.2节清除，不得把未确认帧报告为成功。 2. 从端→主端业务不得进入链路重传或窗口控制状态机。 3. 主端业务缓存满时可以丢弃从端业务帧，但必须继续解析线路并保证`CTRL`接收。 -4. 重新训练不得由单端擅自重置业务`SEQ`；完整复位必须由双方一致执行。 +4. 任一方向同步丢失都必须使双方复位传输协议状态；重新训练完成后从`SEQ=0`建立新会话。 # 第六篇分层架构与层间接口 @@ -3100,7 +3175,7 @@ rx_frame_abort=1 11. 主端重传缓存必须保存CRC生成前、加扰前的协议帧内容。 12. `FRAME_COST`必须按不含CRC的逻辑帧长度计算，不得按重传RAM实际存储字节数计算。 13. `DL`和`UL`名称必须按第3章固定方向使用，不得相对当前端点反转含义。 -14. 重新训练不得自动清除传输协议状态；只有双方完成session reset后才能重新初始化业务`SEQ`。 +14. 任一方向同步丢失都必须终止当前会话并清除传输协议状态；重新训练完成后，双方从`SEQ=0`建立新会话。 ## 42. 时序预算与实现风险 @@ -3127,7 +3202,7 @@ T_{margin,side}\approx\frac{T_{有效}}{2} | 在载荷内搜索`SOF` | 假失步和错误分帧 | 帧内按已验证长度计数 | | CRC 错误立即重训 | 数据误码放大为链路中断 | CRC 错误与边界错误分开 | | 流式输出立即产生副作用 | CRC 失败无法撤销 | 上层暂存，CRC 通过后提交 | -| 重训清空传输状态 | 两端状态不一致 | 物理重训保留传输状态，恢复后`POLL_REQ` | +| 仅单端清空传输状态 | 两端会话不一致 | 任一同步丢失都使双方复位协议状态；从端初始响应固定发送`ACK_NEXT=0`，主端以实际收到的`ACK_NEXT`同时初始化`SND_UNA`和`SND_NXT`并取得`WIN_BYTES` | | 多从端共用扫描状态 | 链路相互污染 | 每条链路独立状态、延迟和结果 | ## 43. 数据链路层与传输协议层接收接口 @@ -3288,14 +3363,16 @@ app_tx_tag ```text app_tx_accepted app_tx_completed +app_tx_aborted ``` | 事件 | 含义 | |---|---| | `app_tx_accepted` | 传输协议层已经接收并保存业务请求 | | `app_tx_completed` | 该方向规定的完成条件已经满足 | +| `app_tx_aborted` | 请求已经被接受，但同步丢失使当前会话终止，请求未取得确定的完成结果 | -`DL`的 `app_tx_completed` 表示对应`SEQ`已经被累计ACK确认。`UL`的 `app_tx_completed` 只表示完整线路帧已经发送，不保证主端接收成功。 +`DL`的`app_tx_completed`表示对应`SEQ`已经被累计ACK确认。`UL`的`app_tx_completed`只表示完整线路帧已经发送，不保证主端接收成功。每个已经产生`app_tx_accepted`但尚未产生`app_tx_completed`的请求，在会话终止时必须产生一次`app_tx_aborted`；同一请求不得同时报告完成和中止。若接口实现`app_tx_tag`，完成和中止事件必须返回对应标签；否则必须按请求接受顺序报告。业务应用层依据自身语义决定是否在新会话中重新提交中止请求。 ### 45.3 业务接收接口 @@ -3325,19 +3402,23 @@ sync_lost retrain_busy retrain_done tx_frame_abort -session_reset ``` | 信号 | 含义 | |---|---| -| `link_sync_up` | 采样位置和帧边界可信，数据链路层可以承载普通协议帧 | -| `sync_lost` | 当前采样位置、字边界或帧边界不再可信；触发传输协议层进入保持状态 | -| `retrain_busy` | 数据链路层正在执行相位或延迟训练和同步恢复 | -| `retrain_done` | 采样位置和帧边界已经重新建立；不表示传输状态已经恢复 | +| `link_sync_up` | `UL`、`DL`及运行入口过程均已完成，数据链路层可以承载新会话的普通协议帧 | +| `sync_lost` | 任一方向同步不再可信；当前传输协议会话立即失效 | +| `retrain_busy` | 数据链路层正在执行规定范围内的重新训练和同步恢复 | +| `retrain_done` | 规定范围内的重新训练及运行入口过程已经完成；不表示初始`POLL_REQ/ACK`已经完成 | | `tx_frame_abort` | 此前接受的逻辑帧未完成线路发送；不得将其视为`tx_frame_done` | -| `session_reset` | 双方已经完成完整协议会话复位，传输`SEQ`必须重新初始化 | -`link_sync_up`和`transport_ready`含义不同：前者只表示数据链路可以承载普通协议帧，后者表示传输协议状态已经对齐并可以接受新的可靠业务请求。 +`link_sync_up`必须是协议层可见的聚合状态： + +```text +link_sync_up = ul_sync_up && dl_sync_up && run_entry_complete +``` + +`ul_sync_up`和`dl_sync_up`可以作为诊断信号输出，但不能替代`link_sync_up`控制传输协议层。`link_sync_up`撤销后，传输协议层必须执行第26.2.3节的复位动作；数据链路层只报告状态，不直接修改传输协议寄存器。 ### 46.2 传输协议层向数据链路层 @@ -3346,16 +3427,16 @@ retrain_request sync_reset_request ``` -| 请求 | 数据链路层动作 | 传输协议层状态 | +| 请求 | 数据链路层动作 | 传输协议层动作 | |---|---|---| -| `retrain_request` | 重新执行相位或延迟训练和同步确认 | 保留有效序号、缓存和窗口占用记账；停止协议计时；旧对端窗口公告失效 | -| `sync_reset_request` | 发送`SYNC_RESET`并使对端返回同步训练状态 | 按链路重训练处理，保留有效序号、缓存和窗口占用记账 | +| `retrain_request` | 根据第26.2.2节判断重新训练方向并完成同步恢复 | 撤销`transport_ready`并复位当前协议会话 | +| `sync_reset_request` | 按第26.3节发送`SYNC_RESET`，使对端进入相应训练状态 | 撤销`transport_ready`并复位当前协议会话 | -### 46.3 传输恢复门控 +### 46.3 新会话恢复门控 -进入重训练时，传输协议层必须撤销`transport_ready`和业务发送就绪，不得向数据链路层提交新的普通协议帧。数据链路层可以中止尚未完成的线路帧，并通过`tx_frame_abort`或`retrain_busy`使传输协议层执行第26.2.2节规定的回滚。 +进入重新训练时，传输协议层必须停止业务收发并执行第26.2.3节的协议复位。只重新训练`DL`时，仍可信的`UL`只能承载链路层训练和状态信息，不能承载原会话普通协议帧。 -`retrain_done`之后，主端进入`M_WAIT_STATUS`并发送`POLL_REQ`。从端使用当前`RCV_NEXT`和当前真实接收容量返回`ACK_NEXT`及`WIN_BYTES`。主端必须完成累计确认处理，并在需要时完成保留未确认帧的Go-Back-N恢复；只有进入`M_RUN`后才能重新置位`transport_ready`。 +`retrain_done`之后，主端进入`M_WAIT_STATUS`并发送`POLL_REQ`；从端必须以`ACK_NEXT=0`和当前真实接收容量返回初始状态。主端只检查响应帧的格式和CRC，不以`ACK_NEXT`的具体取值决定是否进入`M_RUN`；主端把收到的值作为新会话起始序号，同时设置`SND_UNA`和`SND_NXT`，不得把它按运行期累计ACK处理。 主端的确定性就绪条件为： @@ -3363,9 +3444,9 @@ sync_reset_request master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) ``` -从端在重训练期间撤销`slave_transport_ready`。重训练完成后，从端首先等待合法`POLL_REQ`；针对该请求的第一个状态`CTRL`产生`tx_frame_done`后，才置位`slave_transport_ready`。任一端的就绪信号均必须在下一次`link_sync_up`撤销、`sync_lost`或`session_reset`时同步撤销。 +从端在初始状态`CTRL`产生`tx_frame_done`后置位`slave_transport_ready`。任一端的`link_sync_up`撤销、`sync_lost`有效或`retrain_busy`有效时，必须立即撤销相应的`transport_ready`。 -如果恢复结果表明任一端的协议状态或缓存已经失效，数据链路层或系统控制逻辑必须触发`session_reset`，双方不得使用保留状态继续通信。 +从端发送非零初始`ACK_NEXT`属于不符合本规范的行为，主端可以记录诊断信息；但为避免序号冲突，只要响应帧本身合法，主端仍必须把该值作为新会话起始序号，并使用其中的`WIN_BYTES`完成初始化。这一赋值不恢复任何旧会话状态。 # 第七篇实现、诊断与验证 @@ -3375,7 +3456,7 @@ master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) | 输出 | 含义 | |---|---| -| `link_sync_up` | 采样位置和帧边界可信；不表示传输状态已恢复 | +| `link_sync_up` | `UL`、`DL`及本端运行入口条件均已完成；不表示初始`POLL_REQ/ACK`已经完成 | | `transport_ready` | 传输状态已对齐，可以接受新的可靠`DL`业务请求 | | `link_retraining` | 当前处于训练/重训 | | `master_state / slave_state` | 顶层状态 | @@ -3416,9 +3497,18 @@ master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) 13. 主端以`DL IDLE`结束同步；从端收到首个完整`DL IDLE`后连续发送20个`UL IDLE`，主端收到首个完整`UL IDLE`后进入`M_RUN`； 14. 载荷中出现全部`SOF`/`IDLE`图样时不误分帧； 15. CRC错误且长度合法时保持边界； -16. 长度非法、位滑移、FIFO溢出时进入恢复； +16. 长度非法或当前边界被判定为不可信时进入恢复； 17. 恢复成功和搜索超时重训； -18. 物理重训前后传输状态保持； +18. `DL`单向重训和`UL`、`DL`完整重训都会复位双方传输协议状态，并在恢复后从`SEQ=0`建立新会话； +19. 主端单独复位时，DL退出合法运行流并使从端确定进入`S_TRAIN`； +20. 从端仅在完整发送20个运行入口`UL IDLE`后置位`link_sync_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_sync_up`； +26. 运行期出现意外完整固定帧时立即进入规定训练路径； +27. 连续4个CRC错误或最近256个CRC承载帧中8个错误时触发方向化重训； 19. 多从端处于不同状态且互不影响； 20. power_on初始化、PLL失锁和延迟就绪丢失发生在各主要状态时的行为。 21. `DATA`和`CTRL`无`IDLE`背靠背发送时，下一`SOF`只在计算得到的边界被识别； @@ -3426,7 +3516,7 @@ master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) 23. 帧长可确定但CRC错误、下一边界也非法时，进入边界恢复； 24. `LEN`越界或未按4字节对齐时，不使用该`LEN`继续计数并立即进入恢复； 25. `LEN`误码后仍为合法值时，接收等待不超过对应最大帧长度，随后由CRC或下一边界发现异常； -26. 依次注入8种4位字偏移以及实现支持的全部位滑移位置，验证滑动搜索和重新锁定； +26. 依次测试实现支持的全部接收对齐候选位置，验证边界搜索和重新锁定； 27. 恢复期间出现仅`SOF`匹配但完整固定帧、长度或CRC失败时，不得错误恢复边界。 ### 48.2 门级、时序与板级验证 @@ -3436,8 +3526,8 @@ master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) - 在工艺、电压、温度角落记录窗口宽度和中心漂移； - 在最长线、最差连接器和最大同时翻转条件下测量； - 验证 AC 耦合基线漂移和终端匹配； -- 注入位错误、CRC错误、长度错误、位滑移、时钟失锁和固定帧丢失； -- 验证重训后传输层通过`POLL_REQ`恢复且不丢失已确认状态。 +- 注入位错误、CRC错误、长度错误、边界丢失、接收资源不可用和固定帧丢失； +- 验证任一同步丢失都会使双方协议状态复位；验证`DL`单向重训和`UL`、`DL`完整重训后均通过初始`POLL_REQ/ACK`从`SEQ=0`建立新会话。 ### 48.3 链路验收条件 @@ -3451,26 +3541,26 @@ master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN) - `link_sync_up` 稳定； - 初始协议`POLL_REQ`/ACK 完成后，传输协议层声明 `transport_ready`。 -`link_sync_up` 表示物理和帧边界可靠；`transport_ready` 表示可靠传输状态已经对齐。业务应用层只能在 `transport_ready` 后启动需要可靠`DL`的业务。 +`link_sync_up`表示`UL`、`DL`及运行入口过程均已就绪；`transport_ready`表示新会话的初始`POLL_REQ/ACK`已经完成。业务应用层只能在`transport_ready`后启动需要可靠`DL`的业务。 ## 49. 实现基线结论 本方案将复杂性集中在主端：主端负责两个方向的延迟扫描、窗口分析、中心选择、同步确认和运行期恢复；从端只需使用所选物理配置规定的固定收发结构，并完成固定帧比较、`TRAIN_ACK`/`SYNC_ACK`生成、普通帧解析和同步监测；第7.3节典型配置使用750 MHz SDR。 -正常上电顺序固定为“从端连续`TRAIN` → 主端校准`UL` → 主端以最多50个`IDLE`隔离相邻`ODELAY`点并校准`DL` → 主端持续`SYNC` → 从端定量发送`SYNC_ACK`并持续发送`SYNC` → 主端持续发送`DL IDLE` → 从端发送20个`UL IDLE` → 主端收到首个`UL IDLE`后进入`M_RUN`”。运行期通过确定边界上的`IDLE`或`SOF`、帧内长度计数和帧尾CRC完成持续监测；内容错误与边界失步分开处理。发生物理失步时执行重训并保留传输协议状态。 +正常上电顺序固定为“从端连续`TRAIN` → 主端校准`UL` → 主端以最多50个`IDLE`隔离相邻`ODELAY`点并校准`DL` → 主端持续`SYNC` → 从端定量发送`SYNC_ACK`并持续发送`SYNC` → 主端持续发送`DL IDLE` → 从端发送20个`UL IDLE` → 主端收到首个`UL IDLE`后进入`M_RUN`”。运行期通过确定边界上的`IDLE`或`SOF`、帧内长度计数和帧尾CRC完成持续监测；内容错误与边界失步分开处理。发生同步丢失时按异常方向执行重新训练，同时复位双方传输协议状态；同步恢复后从`SEQ=0`建立新会话。 ## 附录A：互操作实现声明清单 每个符合本规范的设备或IP至少应提供以下声明： -1. 本规范版本：V0.6； +1. 本规范版本：V0.7； 2. 主端或从端角色； 3. 采用的物理承载、时钟与链路实现配置及第7章全部参数； 4. 最大`DATA`载荷； 5. 接收窗口容量及重传缓存容量； 6. 延迟范围、步进和最小通过窗口； 7. 第27章规定的训练计数、超时和间隔参数； -8. 是否支持`SYNC_RESET`及会话复位； +8. `SYNC_RESET`、方向化重新训练及同步丢失后协议复位的实现方式； 9. 对外层间接口的位宽和时钟域映射； 10. 第48章验证项目的完成情况。