zhoushuang
/
Asymmetric_Reliable_Serial_Transport_Technical_Specification
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: 发布非对称可靠串行传输规范 v0.5

This commit is contained in:
zhoushuang 2026-09-30 17:55:42 +08:00
parent 77842dae00
commit 08c6cdd9b5
1 changed files with 159 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

246
非对称可靠串行传输技术规范.md
View File

@ -2,7 +2,7 @@
**Asymmetric Reliable Serial Transport Technical Specification**
**版本：V0.4**<br>
**版本：V0.5**<br>
**日期：2026-09-30**<br>
**作者：周爽**
@ -12,7 +12,8 @@
| 版本 | 日期 | 说明 |
|---|---|---|
| V0.4 | 2026-09-30 | 重构通信机制概述与总体架构，补充SEQ术语定义；明确规范核心覆盖数据链路层和传输协议层，区分数据链路层的相位或延迟控制职责与物理承载的执行能力，并明确业务应用配置的可选属性。 |
| V0.5 | 2026-09-30 | 明确链路重新训练期间的传输状态保持、恢复门控及主从状态机行为；统一`IDLE`和`CRC-32/MPEG-2`术语；修订数据协议边界、封装解析图、发送仲裁、`LEN`校验及帧内字计数规则。 |
| V0.4 | 2026-09-30 | 重构通信机制概述与总体架构，补充SEQ术语定义；明确规范核心覆盖数据链路层和传输协议层，将相位或延迟调节单元及其控制归入数据链路层的物理接口适配功能，并明确业务应用配置的可选属性。 |
| V0.3 | 2026-09-30 | 新增基于Transaction帧结构的典型业务应用配置，明确请求与响应封装、设备与通道路由、字节序及分片规则，并增加读写分片示意图。 |
| V0.2 | 2026-09-29 | 删除专用配置帧，将寄存器配置等业务统一纳入DATA载荷；统一术语和分层边界，完善拓扑、同步、重传、解析及帧布局图。 |
| V0.1 | 2026-09-29 | 整合数据协议、链路同步、非对称可靠传输机制和三层接口，形成首个统一规范基线。 |
@ -25,9 +26,9 @@
- 第3章 术语、角色与方向
- 第4章 通信机制概述与总体架构
- 第5章 物理承载的通用要求
- 第二篇 物理承载与时钟配置
- 第二篇 物理承载、时钟与链路实现配置
- 第6章 同源时钟与物理拓扑
- 第7章 物理承载与时钟配置
- 第7章 物理承载、时钟与链路实现配置
- 第三篇 统一数据协议
- 第8章 数据协议的接口边界
- 第9章 公共编码规则
@ -93,8 +94,8 @@
本规范明确以下边界：
- 本规范的核心实现规则覆盖数据链路层和传输协议层；
- 物理承载的内部电路结构不属于本规范的规定范围，但物理承载必须提供符合约束的连续串行比特流、同源时钟条件以及受数据链路层控制的相位或延迟调节能力；
- 数据链路层负责训练、相位或延迟扫描与配置、同步、边界、加扰、CRC和线路帧封装；
- 物理承载的内部实现不属于本规范的规定范围；本规范只约束其点对点串行通道、同源时钟条件、线路速率、电气特性和连续比特流；
- 数据链路层负责串行收发适配、相位或延迟调节单元及其扫描与配置、训练、同步、边界、加扰、CRC和线路帧封装；
- 传输协议层负责业务帧序号管理、接收窗口、确认与重传，并控制接收数据的提交和回滚；
- 业务应用层负责解释和处理有效载荷，其内部实现不属于基础传输规范的强制要求，但必须遵守与传输协议层之间的职责边界和接口语义；
- 基础传输规范不强制规定具体业务数据格式；可选业务应用配置另行明确其适用条件。
@ -200,17 +201,17 @@
```mermaid
flowchart TB
APP["业务应用层<br/>产生和解释有效载荷"] <--> TP["传输协议层<br/>序号、窗口、确认与重传"]
TP <--> DLAYER["数据链路层<br/>训练、同步、相位或延迟控制、边界、CRC与扰码"]
DLAYER <--> PHY["物理承载<br/>连续串行比特流与受控相位或延迟调节能力"]
APP["<b>业务应用层</b><br/>产生和解释有效载荷"] <--> TP["<b>传输协议层</b><br/>序号、窗口、确认与重传"]
TP <--> DLAYER["<b>数据链路层</b><br/>串并转换、相位或延迟调节、训练、同步、边界、CRC与扰码"]
DLAYER <--> PHY["<b>物理承载</b><br/>点对点连续串行通道与同源时钟条件"]
```
各层按照以下边界协同工作：
- 业务应用层产生和消费`DATA`有效载荷，不处理线路帧、业务序号或重传；
- 传输协议层将业务载荷组织为逻辑帧，维护业务`SEQ`、累计确认、接收窗口和重传状态；
- 数据链路层完成线路帧封装与解析、`CRC32`、扰码、训练、同步、边界恢复，以及相位或延迟的扫描、判定和配置；
- 物理承载提供连续双向串行通道、共同频率基准及受数据链路层控制的相位或延迟调节单元。本规范约束这些能力及其对外行为，不规定其内部电路实现。
- 数据链路层完成串行收发与串并转换适配、相位或延迟调节单元的实现和控制、线路帧封装与解析、`CRC32`、扰码、训练、同步及边界恢复；
- 物理承载提供独立的双向点对点串行通道、共同频率基准和满足信号完整性要求的连续比特流。本规范只约束这些外部条件，不规定其内部实现。
传输协议层交给数据链路层的内容称为逻辑帧。数据链路层追加适用的`CRC32`并执行规定的扰码后，形成实际通过物理通道发送的线路帧。三层功能和层间接口的完整要求见第37章至第46章。
@ -253,7 +254,7 @@ flowchart LR
空闲期间如果不能持续检测到合法`IDLE`，或者帧结束后的预期边界不能恢复，数据链路层判定同步异常并进入相应训练流程。按照本规范采用的简化恢复策略，`UL`失效触发`UL`和`DL`完整重训；其他异常按照第26章规定恢复受影响的同步状态。
物理重新训练只恢复采样位置和帧边界，不自动清除业务`SEQ`、累计确认点、接收窗口或重传缓存。只有执行明确的会话复位流程后，传输协议状态才重新初始化。运行期监测、边界恢复和重新训练的详细条件见第24章至第27章。
链路重新训练只恢复采样位置和帧边界。重训练期间，传输协议层停止提交线路帧、回滚未完成候选帧并停止协议计时，但保留已经完成记账的业务序号、接收状态、未确认帧及缓存资源；主端缓存的旧对端窗口公告失效。链路重新同步后，主端必须通过`POLL_REQ`重新取得从端的`ACK_NEXT`和当前`WIN_BYTES`，完成传输状态恢复后才能重新置位`transport_ready`。只有双方执行明确的会话复位流程时，才清除并重新初始化传输协议状态。详细规则见第26.2节、第35章和第46章。
### 4.6 后续内容索引
@ -268,18 +269,16 @@ flowchart LR
## 5. 物理承载的通用要求
物理实现必须提供相互独立的`DL`和`UL`连续串行通道。双方必须预先采用一致的线路速率、位序、时钟关系和训练参数。本版不定义在线物理参数协商。
物理承载必须提供相互独立的`DL`和`UL`连续串行通道。双方必须预先采用一致的线路速率、位序和时钟关系。本版不定义在线物理参数协商。
物理承载必须满足：
1. 两端串行线路速率相同且长期无频差；
2. 向主端数据链路层提供可遍历的`UL`采样相位和可调节的`DL`发送相位，或提供功能等价的延迟调节能力；
3. 相位调节范围覆盖至少一个完整UI，或通过粗相位与细延迟组合达到等效覆盖；
4. 接收端能够连续观察串行流，帧间不得出现未定义空洞；
5. 电气实现满足所选介质的眼图、抖动、共模和耦合要求；
6. 数据链路层看到的比特流满足第9章规定的位序和字节序。
2. 接收端能够连续观察串行流，帧间不得出现未定义空洞；
3. 电气实现满足所选介质的眼图、抖动、共模和耦合要求；
4. 数据链路层看到的比特流满足第9章规定的位序和字节序。
# 第二篇物理承载与时钟配置
# 第二篇物理承载、时钟与链路实现配置
## 6. 同源时钟与物理拓扑
@ -326,7 +325,7 @@ R_{line}=N_M f_{M,parallel}=N_S f_{S,parallel}
其中，\(N_M\)和\(N_S\)分别为两端每个并行时钟周期对应的线路位数。
## 7. 物理承载与时钟配置
## 7. 物理承载、时钟与链路实现配置
### 7.1 配置声明
@ -348,9 +347,9 @@ R_{line}=N_M f_{M,parallel}=N_S f_{S,parallel}
配置由硬件设计、寄存器或系统集成约束预先确定。本版不设置在线协商帧。
### 7.2 相位与延迟能力
### 7.2 数据链路层的相位与延迟能力
主端`UL`接收路径必须能够改变采样相位或等效输入延迟；主端`DL`发送路径必须能够改变发送相位或等效输出延迟。`IDELAY`和`ODELAY`是典型FPGA实现名称，并非强制要求。使用PLL相移、相位插值器、可调时钟树或其他等效方法均可。
主端数据链路层的物理接口适配子模块必须能够改变`UL`采样相位或等效输入延迟，并能够改变`DL`发送相位或等效输出延迟。调节范围必须覆盖至少一个完整UI，或通过粗相位与细延迟组合达到等效覆盖。`IDELAY`和`ODELAY`是典型FPGA实现名称，并非强制要求；使用PLL相移、相位插值器、可调时钟树或其他等效方法均可。
从端可以采用固定采样相位和固定发送相位。训练扫描、窗口判定和中心点选择集中在主端，以降低从端实现复杂度。
@ -398,7 +397,7 @@ R_{line}=N_M f_{M,parallel}=N_S f_{S,parallel}
`TRAIN`、`TRAIN_ACK`、`SYNC`、`SYNC_ACK`、`SYNC_RESET`虽由链路状态机处理，其线路表示仍由本规范统一定义。
本规范不定义延迟扫描、同步握手顺序、重复发送次数、`SEQ`初始化时机、窗口调度、重传触发、超时参数或链路重新训练策略。这些由工作机制/架构规范定义。本规范只规定解析错误发生后，帧解析器必须满足的安全行为和重新取得可信帧边界的条件。接收解析器报告格式有效事件，并不自行决定该帧在当前状态下是否可以执行。
本篇规定帧编码、封装、解析以及错误报告规则，不在本篇重复规定链路训练和可靠传输状态机。延迟扫描、同步握手顺序、固定帧重复发送次数及链路重新训练策略见第四篇；`SEQ`初始化、窗口调度、重传触发及超时参数见第五篇。接收解析器只报告格式和完整性检查结果，不自行决定该帧在当前链路状态或传输状态下是否可以执行。
适用链路为点对点全双工同源时钟串行链路；具体物理承载和线路速率由第7章的实现配置声明确定。每个方向独立形成一个连续串行流。多个从端分别使用独立链路，线路帧不含设备地址。逻辑序号不表示物理帧位置。
@ -415,7 +414,7 @@ R_{line}=N_M f_{M,parallel}=N_S f_{S,parallel}
### 9.2 连续传输与对齐
- 所有帧均以 32位字为单位，长度为 4 字节整数倍。
- 在没有其他帧可发送时，连续发送`IDLE32`。帧之间可以直接相接，不要求额外`IDLE`。
- 在没有其他帧可发送时，连续发送`IDLE`。帧之间可以直接相接，不要求额外`IDLE`。
- 一帧开始后必须连续发送至结束。不得在帧内插入`IDLE`、控制帧、等待字或其他填充。
- 不使用字节转义、位填充、EOF、8b/10b 或 64b/66b 编码。
- `PAYLOAD`不自动补齐；提交给编码器的数据长度必须满足本规范。`DATA`和`CTRL`的逻辑帧不包含CRC；数据链路层追加4字节CRC后再执行等长扰码，因此其线路帧比对应逻辑帧增加4字节。
@ -717,11 +716,11 @@ AVAILABLE_BYTES = max(WIN_BYTES - OUTSTANDING_BYTES, 0)
`CTRL`不含自己的业务`SEQ`、`LEN`或载荷。解析器不得因收到`CTRL`就自动生成回复；触发动作由外部控制逻辑决定。`CTRL`不得被解释为`TRAIN_ACK`或`SYNC_ACK`。
## 15. `CRC32`
## 15. `CRC-32/MPEG-2`
### 15.1 参数与覆盖范围
采用 CRC-32/MPEG-2 参数集。多项式和初始值保持为 32'h04C11DB7 和 32'hFFFFFFFF；输入不反转、输出不反转，最终结果不异或。
本规范的`CRC32`算法明确采用标准`CRC-32/MPEG-2`参数集。多项式和初始值分别为`32'h04C11DB7`和`32'hFFFFFFFF`；输入不反转、输出不反转，最终结果不异或。CRC覆盖范围和结果字段封装仍按本章规定执行。
| 参数 | 数值 |
|---|---|
@ -757,21 +756,21 @@ CRC 使用正常形式多项式 32'h04C11DB7，以寄存器最高位一侧进行
## 16. 扰码与解扰
### 16.1 作用范围及与 10GBASE-R 的关系
### 16.1 作用范围与初始化规则
采用 10GBASE-R 的自同步递推多项式：
本规范采用以下自同步递推多项式：
```text
G(x) = 1 + x^39 + x^58
```
本协议的作用范围和初始化规则是自定义的：
扰码作用范围和初始化规则如下：
- `DATA`、`CTRL`：`SOF`原样发送，`SOF`后所有位，包括`CRC32`，参与扰码。
- 每个上述帧在`SOF`结束后、主体第一个位之前，将 58位状态重新加载为全 1。
- 一帧主体内连续推进状态，不得在头部、载荷或 CRC 边界复位。
- 每个上述帧在`SOF`结束后、主体第一个位之前，将58位状态重新加载为全1。
- 一帧主体内连续推进状态，不得在头部、载荷或CRC边界复位。
- `SOF`、`IDLE`、五种固定同步类帧期间绕过扰码器，不推进状态。
- 本协议不引入 64b/66b，也不采用标准以太网的跨块连续状态管理。不能直接使用保持跨帧历史的 IP 默认配置而不检查兼容性。
- 扰码状态不得跨帧延续；实现不得使用跨帧连续保持历史状态的扰码器配置。
### 16.2 逐位参考算法
@ -808,15 +807,18 @@ flowchart LR
SCR --> MUX_TX
end
MUX_TX --> LINE["连续串行线路"]
LINE["连续串行线路"]
subgraph RX["接收端"]
LINE --> CLASSIFY["在可信边界识别SOF或IDLE"]
CLASSIFY["在可信边界识别SOF或IDLE"]
CLASSIFY -->|"DATA或CTRL"| DESCR["解扰并按长度接收"]
DESCR --> CRC_RX["校验CRC32"]
CRC_RX --> PARSER["输出候选帧及校验结果"]
CLASSIFY -->|"固定同步类帧或IDLE"| FIX_RX["完整码型比较"]
end
MUX_TX --> LINE
LINE --> CLASSIFY
```
如上图所示，发送端首先根据帧类型形成逻辑帧。对于`DATA`和`CTRL`，发送端按第 15 章规定的非反射字节输入规则，对明文`SOF`、字段及载荷计算`CRC32`，原样发送`SOF`，并对`SOF`后面的字段、载荷和`CRC32`进行逐帧加扰；固定同步类帧和`IDLE`则绕过 CRC 与扰码路径，按固定码型直接发送。各路径最终汇合为连续、32位对齐的串行数据流。
@ -845,7 +847,7 @@ flowchart LR
固定同步帧直接输出对应`SOF`和四个固定 PRBS 字；`IDLE`直接输出一个码字。两者都不经过 CRC 和业务扰码路径。
如何仲裁这些发送请求、某种帧发送几次，以及何时允许发送，属于外部工作机制。
本节只规定固定同步类帧和`IDLE`的线路生成方式。固定同步类帧的发送种类、次数和时机由第四篇的链路训练与同步状态机决定；`DATA`和`CTRL`的发送调度及优先级由第35章规定。数据链路层只在完整帧边界选择下一帧；没有固定同步类帧或传输协议层逻辑帧需要发送时，持续发送`IDLE`。
### 17.2 接收解析
@ -869,9 +871,9 @@ flowchart LR
5. `DATA`通过CRC和外层格式检查后报告完整候选帧。
6. 接收控制逻辑再决定序号接受和应用交付；解析器不擅自推进外部协议状态。
`LEN`不合法时不得将未经限制的数值用于缓存地址、DMA 长度或接收计数。解析器必须报告`length_error`、终止当前候选帧并进入第 17.4 节定义的边界恢复状态。
如果`LEN`不满足第12.1节规定的范围或4字节对齐要求，解析器必须立即报告`length_error`并终止当前候选帧。不得使用该非法`LEN`确定剩余接收长度、CRC位置或下一帧边界，随后必须进入第17.4节规定的边界恢复状态。
合法范围内的`LEN`也可能已经损坏；无独立头部 CRC 时，错误可能直到帧尾 CRC 或下一边界才暴露。实现不得把“长度范围合法”当成“长度已校验正确”。
通过范围和对齐检查的`LEN`只表示其结构合法，不表示该字段未发生传输错误。例如，原始`LEN`可能因误码变成另一个仍在合法范围内的数值。由于帧头没有独立CRC，接收端必须暂时按照收到的合法`LEN`确定候选帧长度，但在整帧CRC通过前不得提交载荷或产生协议动作。CRC失败后的边界处理按照第17.5节执行。
#### 17.2.3 `CTRL`
@ -883,10 +885,10 @@ flowchart LR
#### 17.2.5 帧内标记与缓存提交
- 接收帧体期间不得把与`SOF`/`IDLE`相同的内容识别为新标记，无论相同模式出现在加扰前还是加扰后。
- 解析器进入`DATA`或`CTRL`帧体后，必须按照已经确定的帧长持续接收至预期CRC位置。在到达预期帧尾前，任何与`SOF`或`IDLE`相同的32位数值都属于当前帧内容，不得被识别为新的帧边界或帧类型标记。
- 所有有效动作必须发生在完整校验之后。允许内部暂存载荷，但不得提前进行不可撤销的业务输出或其他业务动作。
- 可使用整帧缓存，或具有提交/回滚能力的暂存 FIFO；具体结构由实现决定。
- 在连续流模型下，合法长度由确定的位/32位字数计数接收。本规范不引入额外的帧接收超时字段或计时规则。
- `LEN`合法后，接收端必须使用32位字计数器确定当前帧的CRC位置和结束位置。`DATA`线路帧总长度为`3 + LEN/4`个32位字；识别`SOF`后还需接收`2 + LEN/4`个32位字。`CTRL`线路帧固定为4个32位字，识别`SOF`后还需接收3个32位字。本规范不使用EOF标记或接收超时来确定正常帧尾。
### 17.3 解析结果契约
@ -894,7 +896,7 @@ flowchart LR
| 解析结果 | 产生条件 | 可交付内容 | 必须禁止的动作 | 边界状态 |
|---|---|---|---|---|
| idle_seen | 完整匹配`IDLE32` | `IDLE`事件 | 不得更新业务、窗口或控制状态 | 保持可信 |
| idle_seen | 完整匹配`IDLE` | `IDLE`事件 | 不得更新业务、窗口或控制状态 | 保持可信 |
| `fixed_valid(type)` | 固定帧`SOF`和全部 128位 PRBS 完整匹配 | 固定帧类型 | 不得仅凭`SOF`提前产生事件 | 保持可信 |
| `data_candidate_valid` | `DATA`的长度、CRC 和格式全部合法 | `SEQ`、`LEN`、完整`PAYLOAD` | 解析器不得自行判断窗口、重复或交付顺序 | 保持可信 |
| `ctrl_valid` | `CTRL`的 CRC、`WIN_BYTES`和`FLAGS`全部合法；`RESERVED`被忽略 | `ACK_NEXT`、`WIN_BYTES`、`FLAGS` | 校验完成前不得更新确认、窗口或重传状态 | 保持可信 |
@ -923,7 +925,7 @@ flowchart LR
1. 保持已建立的32位字相位，每次移动一个完整32位字检查原始线路数据；
2. 搜索期间不运行普通帧体解扰，不把未知字交付上层；
3. 完整匹配一个固定帧，或者连续匹配至少两个`IDLE32`，可重新建立可信边界；
3. 完整匹配一个固定帧，或者连续匹配至少两个`IDLE`，可重新建立可信边界；
4. 命中`DATA`或`CTRL` `SOF`时，只建立重新锁定候选；必须完成对应长度、解扰和CRC检查后才恢复可信边界并提交候选；
5. 候选失败时继续搜索，不得输出候选内容；
6. 持续无法恢复、32位字相位本身失效或错误达到门限时，由链路同步状态机触发重新训练。
@ -1376,19 +1378,52 @@ stateDiagram-v2
训练失败时状态机持续执行相应训练，不因重试次数达到某个值而停止。重试计数只用于诊断。单个 CRC错误、合法帧的内容错误或上层丢包不触发物理重训。
### 26.2 物理重训练与会话复位
### 26.2 链路重新训练与会话复位
- **物理重训练**只重新建立采样相位和帧边界，保留发送序号、接收期望序号、窗口状态和未确认缓存；
- **会话复位**清除传输协议状态和缓存，从初始序号开始。会话复位必须由独立系统条件触发，不能由普通失步隐式触发。
链路重新训练和会话复位是两个相互独立的过程：
物理重训练步骤：
- **链路重新训练**只重新建立采样位置、发送位置和帧边界，保留仍然有效的传输协议状态；
- **会话复位**清除传输协议状态和缓存，从初始序号开始。会话复位必须由双方可见的独立系统条件触发，不能由普通失步隐式触发。
1. 链路层撤销 `link_sync_up` 并置位 `link_retraining`；
2. 传输协议层停止提交新帧，并冻结计时器或进入链路不可用状态；
3. 接收端丢弃尚未得到最终 CRC 结论的半帧；
4. 完成双向校准、`DL` `SYNC`/`SYNC_ACK`以及`UL` `SYNC`确认后，链路层恢复`IDLE`；
5. 主端通过`POLL_REQ`获取从端当前累计 ACK 和接收窗口；
6. 主端依据返回状态继续发送或重传未确认帧。
#### 26.2.1 重训练入口与状态保持
任意传输状态下，只要`link_sync_up`撤销、`sync_lost`有效或数据链路层进入`retrain_busy`，传输协议层必须立即进入链路不可用保持状态，并执行以下动作：
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`。
#### 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`不保留原快照，恢复后根据当前确认点和窗口重新生成。
#### 26.2.3 重训练期间的行为
数据链路层执行相位或延迟扫描、双向训练和同步确认。传输协议层在此期间不得发送或接受普通`DATA`和`CTRL`，不得推进任何业务序号，不得释放未确认缓存，也不得根据协议超时触发新的重传轮次。只有训练和同步固定帧可以在线路上传输。
#### 26.2.4 重训练后的传输状态恢复
链路重新同步后按照以下顺序恢复：
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.3 `SYNC_RESET`
@ -2113,7 +2148,8 @@ T_PROGRESS_LIMIT： ACK仍未推进，启动或判定一轮Go-Back-N
| 事件 | 条件 | 必须动作 |
|---|---|---|
| 同步完成 | 新协议会话 | 初始化状态并发送`POLL_REQ` |
| 会话复位完成 | 新协议会话 | 按第31.2节初始化状态并发送`POLL_REQ` |
| 链路重训练完成 | 原协议状态和缓存有效 | 保留传输状态，将旧对端窗口公告置为无效，进入`M_WAIT_STATUS`并发送`POLL_REQ` |
| 新业务请求 | 窗口和描述符均足够 | 分配`SND_NXT`、缓存、首次发送、增加`OUTSTANDING_BYTES` |
| 新业务请求 | 窗口不足 | 保持请求，停止首次发送，等待ACK或`POLL_REQ` |
| 合法前进ACK | `ACK_NEXT`在已发送区间 | 释放前缀、更新`SND_UNA`和`WIN_BYTES`、重算窗口 |
@ -2178,9 +2214,9 @@ 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` | 已达到连续失败门限 | 保留未确认缓存，停止业务帧请求并请求链路重新训练 |
| `M_RETRAIN` | 链路失步、数据链路层正在重训练，或已达到连续失败门限 | 保留协议状态，停止协议帧请求；由连续失败门限进入时置位`retrain_request`；等待链路重新同步 |
`M_RUN`同时覆盖有未确认帧、等待窗口和暂时没有上层发送请求的情况。这些情况由 `OUTSTANDING_BYTES`、窗口比较和请求有效信号区分，不需要建立互斥的等待状态。
`M_RUN`同时覆盖有未确认帧、等待窗口和暂时没有上层发送请求的情况。这些情况由`OUTSTANDING_BYTES`、窗口比较和请求有效信号区分，不需要建立互斥的等待状态。主端可对业务层宣告的就绪条件为`master_transport_ready = link_sync_up && (MASTER_STATE == M_RUN)`。
`M_RETX_PREP`按以下规则确定重传批次：
@ -2222,13 +2258,19 @@ stateDiagram-v2
M_RETX_WAIT --> M_RETX_PREP: T_PROGRESS_LIMIT无进展且失败次数小于3
M_RETX_WAIT --> M_RETRAIN: T_PROGRESS_LIMIT无进展且形成第3次连续失败
M_RETRAIN --> M_WAIT_STATUS: retrain完成 / 请求POLL
M_WAIT_STATUS --> M_RETRAIN: link_sync_up撤销或sync_lost
M_RUN --> M_RETRAIN: link_sync_up撤销或sync_lost
M_RETX_PREP --> M_RETRAIN: link_sync_up撤销或sync_lost
M_RETX_SEND --> M_RETRAIN: link_sync_up撤销或sync_lost
M_RETX_WAIT --> M_RETRAIN: link_sync_up撤销或sync_lost
M_RETRAIN --> M_WAIT_STATUS: retrain_done / 请求POLL
```
#### 35.2.3 规范性转移与动作
| 当前状态 | 事件和条件 | 寄存器及控制动作 | 下一状态 |
|---|---|---|---|
| 任意非`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`状态 | 收到合法`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` |
@ -2248,11 +2290,11 @@ stateDiagram-v2
| `M_RETX_WAIT` | T_ACK_WAIT及随后一个T_POLL_INTERVAL到期且无进展 | 置位`POLL_PENDING`；不增加失败计数 | `M_RETX_WAIT` |
| `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` 开始下一轮 | `M_RETX_PREP`或`M_RETRAIN` |
| `M_RETRAIN` | 物理重新训练完成且协议状态保留 | 保留`SEQ`、缓存和描述符，置位`POLL_PENDING` | `M_WAIT_STATUS` |
| `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` |
如果状态转移发生时主端→从端发送器正在发送一个完整帧，当前帧必须先发送结束。状态机可以立即禁止新的首次发送请求，但重传帧或`POLL_REQ`只能在下一帧边界被调度。
由协议事件触发普通状态转移时，当前完整帧必须发送结束后再切换调度请求。链路失步或重训练入口不适用该等待规则：未产生`tx_frame_done`的帧必须立即中止，并按第26.2.2节恢复其描述符和记账状态。
因此，`RETRY_REQ`或T_PROGRESS_LIMIT超时到达时不得立即用旧`SND_NXT`冻结RETX_END。若当时正在首次发送新业务帧，必须先等待 `frame_tx_done`，完成该帧的`SND_NXT`和`OUTSTANDING_BYTES`更新，再以更新后的`SND_NXT`冻结重传范围。这样能够保证已经上线的最后一帧不会遗漏在Go-Back-N范围之外。
@ -2260,15 +2302,16 @@ stateDiagram-v2
同一时钟周期出现多个事件时，必须按以下顺序处理：
1. 双方完整协议复位或重新训练进入事件；
2. 合法接收`CTRL`：先做累计ACK和窗口更新，再解释`FLAGS`；
3. 当前发送帧完成事件；
4. T_ACK_WAIT、后续T_POLL_INTERVAL及T_PROGRESS_LIMIT定时事件；
5. 新上层业务请求。
1. 双方完整协议复位；
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. 新上层业务请求。
前进ACK与T_PROGRESS_LIMIT超时同周期发生时，以前进ACK为准，重置进度计时并抑制本周期的失败判定。合法`RETRY_REQ`中的`ACK_NEXT`必须先释放确认前缀；仅当处理后仍有未确认帧时才进入重传。
ACK进度计时独立于 `M_RUN` 的发送活动。只要存在未确认帧，即使主端仍在窗口内连续发送新帧，也必须继续统计最早未确认帧的无进展时间。初始化等待或没有未确认帧但窗口不足时，可以复用同一个计数器作为T_POLL_INTERVAL `POLL_REQ`间隔计时；两种模式不得同时解释同一个超时事件。
ACK进度计时独立于`M_RUN`的发送活动。只要存在未确认帧，即使主端仍在窗口内连续发送新帧，也必须继续统计最早未确认帧的无进展时间。初始化等待或没有未确认帧但窗口不足时，可以复用同一个计数器作为`T_POLL_INTERVAL`轮询间隔计时；两种模式不得同时解释同一个超时事件。进入`M_RETRAIN`时所有协议计时停止并清零，重训练期间不产生超时事件；恢复后的计时按照第26.2.4节重新启动。
### 35.3 主端发送调度器
@ -2300,6 +2343,7 @@ stateDiagram-v2
|---|---|
| `S_EXPECT` | 等待`SEQ`等于`RCV_NEXT`的合法业务帧 |
| `S_RETRY_WAIT` | 已发现错误，仍等待同一个`RCV_NEXT`对应的正确业务帧 |
| `S_LINK_HOLD` | 链路不可用或正在重训练；保留`RCV_NEXT`和接收资源，不处理普通协议帧 |
```mermaid
stateDiagram-v2
@ -2308,21 +2352,26 @@ stateDiagram-v2
S_EXPECT --> S_RETRY_WAIT: 业务帧错误 / 丢弃、RETRY_PENDING=1、ACK_PENDING=1
S_RETRY_WAIT --> S_RETRY_WAIT: 非期望或错误帧 / 丢弃、ACK_PENDING=1
S_RETRY_WAIT --> S_EXPECT: 正确期望帧 / 提交、RCV_NEXT++、RETRY_PENDING=0、ACK_PENDING=1
S_EXPECT --> S_LINK_HOLD: link_sync_up撤销或sync_lost
S_RETRY_WAIT --> S_LINK_HOLD: link_sync_up撤销或sync_lost
S_LINK_HOLD --> S_EXPECT: retrain_done / 等待POLL_REQ
```
收到合法`POLL_REQ`只置位`ACK_PENDING`，不改变上述接收状态。`WIN_BYTES`从0恢复为非0时同样只置位`ACK_PENDING`。无效`CTRL`直接丢弃，不改变`RCV_NEXT`、`ACK_PENDING`或`RETRY_PENDING`。
`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`。
#### 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_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` |
| `S_RETRY_WAIT` | 再次收到错误帧或非期望`SEQ` | 丢弃；`RCV_NEXT`不变；保持`RETRY_PENDING`；`ACK_PENDING=1` | `S_RETRY_WAIT` |
| 任意接收状态 | 收到合法`POLL_REQ` | `ACK_PENDING=1` | 状态不变 |
| 任意接收状态 | `WIN_BYTES`从0恢复为非0 | `ACK_PENDING=1` | 状态不变 |
| 任意接收状态 | `CTRL`校验或格式失败 | 丢弃`CTRL`，不产生状态更新 | 状态不变 |
| 任意非`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 待发送状态的并发更新
@ -2349,10 +2398,12 @@ ACK_PENDING_next = NEW_STATUS_EVENT
同一时钟周期出现多个事件时，必须按以下顺序形成下一状态：
1. 双方完整协议复位；
2. `DATA`候选帧完成事件，按成功接受或失败丢弃更新`RCV_NEXT`和`RETRY_PENDING`；
3. 合法`POLL_REQ`及`WIN_BYTES`从0恢复事件；
4. 状态`CTRL`开始发送产生的旧快照清除事件；
5. 从端上层无确认业务发送请求。
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. 从端上层无确认业务发送请求。
同一个候选业务帧不得同时报告成功和失败。如果业务帧事件、`POLL_REQ`或窗口恢复与 `STATUS_LAUNCH` 同周期发生，新状态事件必须使`ACK_PENDING`在周期结束后保持为1。从端发送调度事件不得改变接收状态，也不得阻止接收控制器在同周期处理业务帧。
@ -2373,6 +2424,8 @@ 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`，从端必须保留其载荷，并在链路重新同步且传输状态恢复后重新提交。
### 35.6 RTL接口事件契约
状态机可以使用不同端口名称，但至少需要等价的内部事件：
@ -2386,7 +2439,7 @@ stateDiagram-v2
| `frame_tx_done` | 发送器 | 完整帧最后一位已经发送，并同时报告帧类别及业务`SEQ` |
| `ack_progress` | 主端`CTRL`处理器 | 合法`ACK_NEXT`使`SND_UNA`向前推进 |
| `status_launch` | 从端发送调度器 | 最新状态快照已经锁存并开始发送 |
| `retrain_done` | 链路同步层 | 物理同步恢复；是否保留协议状态由链路恢复结果同时给出 |
| `retrain_done` | 数据链路层 | 采样位置和帧边界已经恢复；传输协议层仍须执行状态查询后才能恢复业务 |
解析器不得在CRC和格式检查完成前产生 `business_candidate_valid` 或 `ctrl_valid`。状态机不得把仅识别到`SOF`当作有效帧事件。
@ -2432,9 +2485,9 @@ stateDiagram-v2
数据链路层必须负责：
1. 对接物理承载提供的串行收发、串并转换及相关时钟接口；
2. 控制并使用FPGA SERDES、ASIC串行收发适配电路或功能等价的物理接口；
3. 控制物理承载提供的`IDELAY`、`ODELAY`或功能等价的调节单元，完成`UL`采样位置和`DL`发送位置的扫描、判定与配置；
1. 实现与物理承载对接的串行收发、串并转换及相关时钟接口；
2. 实现并控制FPGA SERDES、ASIC串行收发适配电路或功能等价的物理接口；
3. 实现并控制`IDELAY`、`ODELAY`或功能等价的相位或延迟调节单元，使调节范围覆盖至少一个完整`UI`，并完成`UL`采样位置和`DL`发送位置的扫描、判定与配置；
4. 训练、同步建立、同步确认及`SYNC_RESET`处理；
5. 32位字边界建立；
6. `IDLE`、固定同步帧及`DATA`、`CTRL` `SOF`检测；
@ -3171,21 +3224,25 @@ app_rx_data_last
### 46.1 数据链路层向传输协议层
```text
link_up
link_sync_up
sync_lost
retrain_busy
retrain_done
tx_frame_abort
session_reset
```
| 信号 | 含义 |
|---|---|
| `link_up` | 普通协议帧可以发送和接收 |
| `sync_lost` | 当前字或帧边界不再可信 |
| `retrain_busy` | 数据链路层正在执行训练和同步恢复 |
| `retrain_done` | 物理同步已经重新建立 |
| `link_sync_up` | 采样位置和帧边界可信，数据链路层可以承载普通协议帧 |
| `sync_lost` | 当前采样位置、字边界或帧边界不再可信；触发传输协议层进入保持状态 |
| `retrain_busy` | 数据链路层正在执行相位或延迟训练和同步恢复 |
| `retrain_done` | 采样位置和帧边界已经重新建立；不表示传输状态已经恢复 |
| `tx_frame_abort` | 此前接受的逻辑帧未完成线路发送；不得将其视为`tx_frame_done` |
| `session_reset` | 双方已经完成完整协议会话复位，传输`SEQ`必须重新初始化 |
`link_sync_up`和`transport_ready`含义不同：前者只表示数据链路可以承载普通协议帧，后者表示传输协议状态已经对齐并可以接受新的可靠业务请求。
### 46.2 传输协议层向数据链路层
```text
@ -3195,10 +3252,24 @@ sync_reset_request
| 请求 | 数据链路层动作 | 传输协议层状态 |
|---|---|---|
| `retrain_request` | 重新执行物理训练和同步 | 保留`SEQ`、窗口状态和未确认重传缓存 |
| `sync_reset_request` | 执行双方完整会话复位流程 | 完成session_reset后清空并重新初始化 |
| `retrain_request` | 重新执行相位或延迟训练和同步确认 | 保留有效序号、缓存和窗口占用记账；停止协议计时；旧对端窗口公告失效 |
| `sync_reset_request` | 发送`SYNC_RESET`并使对端返回同步训练状态 | 按链路重训练处理，保留有效序号、缓存和窗口占用记账 |
物理重新训练完成后，主端传输协议层应发送`POLL_REQ`重新取得从端的`ACK_NEXT`和`WIN_BYTES`，再恢复`DL`发送或重传。
### 46.3 传输恢复门控
进入重训练时，传输协议层必须撤销`transport_ready`和业务发送就绪，不得向数据链路层提交新的普通协议帧。数据链路层可以中止尚未完成的线路帧，并通过`tx_frame_abort`或`retrain_busy`使传输协议层执行第26.2.2节规定的回滚。
`retrain_done`之后，主端进入`M_WAIT_STATUS`并发送`POLL_REQ`。从端使用当前`RCV_NEXT`和当前真实接收容量返回`ACK_NEXT`及`WIN_BYTES`。主端必须完成累计确认处理，并在需要时完成保留未确认帧的Go-Back-N恢复；只有进入`M_RUN`后才能重新置位`transport_ready`。
主端的确定性就绪条件为：
```text
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`时同步撤销。
如果恢复结果表明任一端的协议状态或缓存已经失效，数据链路层或系统控制逻辑必须触发`session_reset`，双方不得使用保留状态继续通信。
# 第七篇实现、诊断与验证
@ -3208,7 +3279,8 @@ sync_reset_request
| 输出 | 含义 |
|---|---|
| `link_sync_up` | 当前链路允许传输协议层工作 |
| `link_sync_up` | 采样位置和帧边界可信；不表示传输状态已恢复 |
| `transport_ready` | 传输状态已对齐，可以接受新的可靠`DL`业务请求 |
| `link_retraining` | 当前处于训练/重训 |
| `master_state / slave_state` | 顶层状态 |
| `monitor_state` | 运行期监测状态 |
@ -3295,9 +3367,9 @@ sync_reset_request
每个符合本规范的设备或IP至少应提供以下声明：
1. 本规范版本：V0.4；
1. 本规范版本：V0.5；
2. 主端或从端角色；
3. 采用的物理实现配置及第7章全部参数；
3. 采用的物理承载、时钟与链路实现配置及第7章全部参数；
4. 最大`DATA`载荷；
5. 接收窗口容量及重传缓存容量；
6. 延迟范围、步进和最小通过窗口；