diff --git a/非对称可靠串行传输技术规范.md b/非对称可靠串行传输技术规范.md index 77631b3..e1437cd 100644 --- a/非对称可靠串行传输技术规范.md +++ b/非对称可靠串行传输技术规范.md @@ -2,7 +2,7 @@ **Asymmetric Reliable Serial Transport Technical Specification** -**版本：V0.3**
+**版本：V0.4**
**日期：2026-09-30**
**作者：周爽** @@ -12,6 +12,7 @@ | 版本 | 日期 | 说明 | |---|---|---| +| V0.4 | 2026-09-30 | 重构通信机制概述与总体架构，补充SEQ术语定义；明确规范核心覆盖数据链路层和传输协议层，区分数据链路层的相位或延迟控制职责与物理承载的执行能力，并明确业务应用配置的可选属性。 | | V0.3 | 2026-09-30 | 新增基于Transaction帧结构的典型业务应用配置，明确请求与响应封装、设备与通道路由、字节序及分片规则，并增加读写分片示意图。 | | V0.2 | 2026-09-29 | 删除专用配置帧，将寄存器配置等业务统一纳入DATA载荷；统一术语和分层边界，完善拓扑、同步、重传、解析及帧布局图。 | | V0.1 | 2026-09-29 | 整合数据协议、链路同步、非对称可靠传输机制和三层接口，形成首个统一规范基线。 | @@ -22,7 +23,7 @@ - 第1章 范围、目标与适用边界 - 第2章 规范性用语与一致性 - 第3章 术语、角色与方向 - - 第4章 总体架构与工作阶段 + - 第4章 通信机制概述与总体架构 - 第5章 物理承载的通用要求 - 第二篇 物理承载与时钟配置 - 第6章 同源时钟与物理拓扑 @@ -83,17 +84,20 @@ 本规范定义一种用于点对点、全双工、同源时钟串行链路的非对称可靠传输技术。规范覆盖线路帧编码、链路训练与同步、运行期边界监测、主端到从端方向的可靠传输与重传、从端到主端方向的无确认传输，以及数据链路层、传输协议层和业务应用层之间的接口契约。 +本规范所定义通信机制的总体工作原理、分层架构和运行阶段见第4章。 + 本规范不限定必须使用LVDS，也不限定线路速率必须为750 Mbps。LVDS和750 Mbps配置是第7章规定的一种典型物理实现配置。采用其他差分或单端物理承载、其他线路速率或不同的串并转换结构时，只要满足本规范的公共编码、时钟关系、状态行为和层间接口语义，即可形成兼容实现。 本规范面向RTL、ASIC、FPGA及功能等价的其他实现。互操作设备必须选择相同的物理实现配置，并实现本规范中所有标记为“必须”的行为。 本规范明确以下边界： -- 物理承载负责可靠地提供连续串行比特流及所需的相位调节能力； -- 数据链路层负责训练、同步、边界、加扰、CRC和线路帧封装； -- 传输协议层负责SEQ、窗口、确认、重传、接收提交和回滚； -- 业务应用层负责解释和处理有效载荷； -- 本规范不定义具体业务数据格式，也不规定寄存器映射表。 +- 本规范的核心实现规则覆盖数据链路层和传输协议层； +- 物理承载的内部电路结构不属于本规范的规定范围，但物理承载必须提供符合约束的连续串行比特流、同源时钟条件以及受数据链路层控制的相位或延迟调节能力； +- 数据链路层负责训练、相位或延迟扫描与配置、同步、边界、加扰、CRC和线路帧封装； +- 传输协议层负责业务帧序号管理、接收窗口、确认与重传，并控制接收数据的提交和回滚； +- 业务应用层负责解释和处理有效载荷，其内部实现不属于基础传输规范的强制要求，但必须遵守与传输协议层之间的职责边界和接口语义； +- 基础传输规范不强制规定具体业务数据格式；可选业务应用配置另行明确其适用条件。 ## 2. 规范性用语与一致性 @@ -131,6 +135,7 @@ | 下行链路（Downlink，`DL`） | 主端到从端方向 | | 上行链路（Uplink，`UL`） | 从端到主端方向 | | 业务帧 | 带业务`SEQ`的`DATA`帧 | +| 业务帧序号（`SEQ`） | `DATA`帧携带的16位模65536序号；每条物理链路的每个方向分别维护独立的序号空间。`DL`使用`SEQ`进行累计确认和重传控制，`UL`仅使用`SEQ`循环编号，不依据其执行确认或重传 | | 控制帧 | `CTRL`帧，不占用业务`SEQ` | | 固定帧 | `TRAIN`、`TRAIN_ACK`、`SYNC`、`SYNC_ACK`或`SYNC_RESET` | | 逻辑帧 | 传输协议层交给数据链路层的完整帧内容，包括明文`SOF`、协议字段和载荷，不包含`CRC32`且未加扰 | @@ -150,6 +155,7 @@ | 缩写 | 中文名称 | 英文全称或说明 | |---|---|---| | `SOF` | 帧起始标记 | Start of Frame | +| `SEQ` | 业务帧序号 | Sequence Number | | `CRC32` | 32位循环冗余校验 | 32-bit Cyclic Redundancy Check | | `PRBS7` | 7阶伪随机二进制序列 | Pseudo-Random Binary Sequence 7 | | `ACK` | 确认 | Acknowledgement | @@ -178,18 +184,87 @@ `DL`和`UL`名称按系统拓扑固定，不随当前观察端点改变。多个从端场景中，每个从端均通过独立的一条`DL`和一条`UL`连接到主端，帧内不设置设备地址。 -## 4. 总体架构与工作阶段 +## 4. 通信机制概述与总体架构 + +### 4.1 通信机制概述 + +本规范定义一种采用同源时钟的点对点全双工串行通信机制。系统由一个主端和一个或多个从端组成，每个从端分别通过独立的下行链路`DL`和上行链路`UL`与主端连接。链路采用连续传输方式：有协议帧时发送协议帧，没有其他内容时持续发送`IDLE`，线路上不出现未定义空洞。 + +主端承担可调延迟扫描、窗口判定、可靠发送和重传等复杂功能；从端使用固定收发时序和较简单的确定性状态机。链路启动时，主端先校准`UL`接收采样位置，再校准`DL`发送位置，随后完成双向同步确认。物理同步建立后，双方对齐传输状态并进入正常业务通信。 + +正常通信采用非对称传输策略：主端到从端的`DL`业务数据使用确认、接收窗口和错误重传保证可靠交付；从端到主端的`UL`业务数据采用无确认传输，主端丢弃校验失败的数据而不要求从端重传。运行期间，数据链路层持续维护帧边界并监测同步状态；发现同步丢失时，系统退出正常通信并重新训练受影响的链路。 + +本章用于建立对完整通信机制的总体认识，不替代后续章节中的精确字段定义、状态转移条件、计数参数和接口时序。发生解释差异时，应按第2章规定的优先级采用后续详细规范。 + +### 4.2 分层架构 ```mermaid flowchart TB - APP[业务应用层] <--> TP[传输协议层] - TP <--> DL[数据链路层] - DL <--> PHY[物理承载] + APP["业务应用层
产生和解释有效载荷"] <--> TP["传输协议层
序号、窗口、确认与重传"] + TP <--> DLAYER["数据链路层
训练、同步、相位或延迟控制、边界、CRC与扰码"] + DLAYER <--> PHY["物理承载
连续串行比特流与受控相位或延迟调节能力"] ``` -系统依次经历资源就绪、`UL`训练、`DL`训练、双向同步确认和运行期通信。运行期中，数据链路层持续维护帧边界并监测同步；传输协议层在`DL`执行累计确认、字节窗口和Go-Back-N重传，在`UL`执行无确认发送和无确认接收。 +各层按照以下边界协同工作： -同步丢失时，数据链路层进入对应训练流程。按照本规范的简化策略，`UL`失效触发`UL`与`DL`完整重训。物理重新训练不自动清除传输协议状态；只有完成明确的会话复位流程后，业务`SEQ`和重传状态才重新初始化。 +- 业务应用层产生和消费`DATA`有效载荷，不处理线路帧、业务序号或重传； +- 传输协议层将业务载荷组织为逻辑帧，维护业务`SEQ`、累计确认、接收窗口和重传状态； +- 数据链路层完成线路帧封装与解析、`CRC32`、扰码、训练、同步、边界恢复，以及相位或延迟的扫描、判定和配置； +- 物理承载提供连续双向串行通道、共同频率基准及受数据链路层控制的相位或延迟调节单元。本规范约束这些能力及其对外行为，不规定其内部电路实现。 + +传输协议层交给数据链路层的内容称为逻辑帧。数据链路层追加适用的`CRC32`并执行规定的扰码后，形成实际通过物理通道发送的线路帧。三层功能和层间接口的完整要求见第37章至第46章。 + +### 4.3 链路建立流程 + +系统从上电或复位后的资源等待状态开始，按照下列顺序建立通信： + +```mermaid +flowchart LR + READY["物理与时钟资源就绪"] --> ULTRAIN["UL训练
主端扫描接收延迟"] + ULTRAIN --> DLTRAIN["DL训练
主端扫描发送延迟"] + DLTRAIN --> SYNC["双向同步确认
建立稳定帧边界"] + SYNC --> ALIGN["传输状态对齐
取得确认点和接收窗口"] + ALIGN --> RUN["正常业务通信"] +``` + +资源就绪表示双方已经具备稳定参考时钟、可用收发路径以及完成初始化的延迟调节资源。`UL`训练期间，从端连续发送训练序列，主端扫描接收采样位置并选择通过窗口中心。`DL`训练期间，主端在不同发送延迟下发送定量训练序列，并根据从端返回的训练应答确定通过窗口中心。 + +延迟校准完成后，双方通过长同步序列和同步应答确认两个方向均能稳定识别帧边界。随后主端使用控制帧取得从端的累计确认点和可用接收窗口，使传输协议状态与当前链路会话一致。各阶段的精确状态机、判定计数和等待间隔见第18章至第27章；传输状态初始化和对齐规则见第28章至第36章。 + +### 4.4 运行期非对称传输 + +```mermaid +flowchart LR + M["主端"] -->|"DL：可靠DATA
累计ACK、字节窗口、Go-Back-N重传"| S["从端"] + S -->|"UL：无确认DATA
不要求重传"| M + S -->|"UL：CTRL
报告ACK_NEXT与WIN_BYTES"| M + M -->|"DL：CTRL
状态询问与控制请求"| S +``` + +在`DL`方向，主端只在公告窗口允许时首次发送新的业务帧，并保存所有尚未累计确认的业务帧。从端按期望序号接收，通过累计`ACK`报告下一期望序号，并使用`WIN_BYTES`公布可继续占用的接收容量。出现帧错误、序号不符合预期或确认超时时，主端按照回退N帧机制从最早未确认帧开始重传。 + +在`UL`方向，从端按循环序号发送业务帧，但不保存待确认副本，也不等待主端确认。主端对通过格式和`CRC32`检查的帧正常提交，对损坏帧直接丢弃；序号跳变或重复不触发`UL`重传。`UL`承载的`CTRL`用于支持`DL`可靠传输，不改变`UL DATA`自身的无确认属性。 + +`DATA`、`CTRL`和固定同步类帧均以完整帧为单位仲裁。一帧开始发送后必须连续发送至帧尾；当没有其他帧可发送时，发送端持续发送`IDLE`。线路帧格式及编码规则见第8章至第17章，可靠传输和重传的精确算法见第28章至第36章。 + +### 4.5 同步监测与异常恢复 + +正常通信期间，数据链路层在已知帧边界上识别`IDLE`或合法`SOF`。识别到带长度字段的帧后，先依据`LEN`得到暂定帧尾并完成整帧解析；到达暂定边界后，只有下一个位置仍无法识别`IDLE`或合法`SOF`时，才进入边界恢复。单帧`CRC32`失败表示该帧内容不可信，但不单独等同于链路失步。 + +空闲期间如果不能持续检测到合法`IDLE`，或者帧结束后的预期边界不能恢复，数据链路层判定同步异常并进入相应训练流程。按照本规范采用的简化恢复策略，`UL`失效触发`UL`和`DL`完整重训；其他异常按照第26章规定恢复受影响的同步状态。 + +物理重新训练只恢复采样位置和帧边界，不自动清除业务`SEQ`、累计确认点、接收窗口或重传缓存。只有执行明确的会话复位流程后，传输协议状态才重新初始化。运行期监测、边界恢复和重新训练的详细条件见第24章至第27章。 + +### 4.6 后续内容索引 + +| 内容 | 详细章节 | +|---|---| +| 物理拓扑、同源时钟和典型实现配置 | 第5章至第7章 | +| 公共编码、帧格式、CRC、扰码和解析 | 第8章至第17章 | +| 延迟训练、同步确认、运行期监测和重新训练 | 第18章至第27章 | +| 累计确认、接收窗口、重传和传输状态机 | 第28章至第36章 | +| 三层职责、处理流程及层间接口 | 第37章至第46章 | +| RTL诊断、验证与实现基线 | 第47章至第49章 | ## 5. 物理承载的通用要求 @@ -198,7 +273,7 @@ flowchart TB 物理承载必须满足： 1. 两端串行线路速率相同且长期无频差； -2. 主端能够遍历`UL`采样相位，并能够调节`DL`发送相位或实现等效功能； +2. 向主端数据链路层提供可遍历的`UL`采样相位和可调节的`DL`发送相位，或提供功能等价的延迟调节能力； 3. 相位调节范围覆盖至少一个完整UI，或通过粗相位与细延迟组合达到等效覆盖； 4. 接收端能够连续观察串行流，帧间不得出现未定义空洞； 5. 电气实现满足所选介质的眼图、抖动、共模和耦合要求； @@ -535,7 +610,7 @@ W(2+LEN/4) = CRC32 ### 13.2 由用户业务定义的内容 -`PAYLOAD`的内部格式完全由业务应用定义，本规范不规定： +基础传输机制不解释`PAYLOAD`内部字段，也不强制规定统一的`PAYLOAD`格式。未采用本规范可选业务应用配置时，通信双方自行约定以下内容： - 操作码、命令类型或事务类型； - 寄存器地址、寄存器宽度、读写方向及连续访问格式； @@ -543,7 +618,7 @@ W(2+LEN/4) = CRC32 - 业务状态码、权限检查和执行结果； - 业务数据的版本、子协议或应用级校验。 -如果使用`DATA`实现从端寄存器配置，主端和从端必须在本规范之外约定相同的载荷格式。该业务定义不得改变`DATA`外层格式，不得引入新的线路`SOF`，也不得改变本规范规定的确认、窗口和重传语义。 +通信双方自行定义的业务格式不得改变`DATA`逻辑帧格式，不得引入新的线路`SOF`，也不得改变本规范规定的确认、窗口和重传语义。声明采用第39.3节Transaction应用配置时，必须遵守该节规定；未声明采用时，第39.3节不构成基础传输规范的强制要求。 ### 13.3 传输成功与业务执行的边界 @@ -2357,9 +2432,9 @@ stateDiagram-v2 数据链路层必须负责： -1. 物理串行收发、串并转换及相关时钟接口； -2. FPGA SERDES或ASIC串行接收发送适配； -3. `IDELAY`、`ODELAY`等链路校准； +1. 对接物理承载提供的串行收发、串并转换及相关时钟接口； +2. 控制并使用FPGA SERDES、ASIC串行收发适配电路或功能等价的物理接口； +3. 控制物理承载提供的`IDELAY`、`ODELAY`或功能等价的调节单元，完成`UL`采样位置和`DL`发送位置的扫描、判定与配置； 4. 训练、同步建立、同步确认及`SYNC_RESET`处理； 5. 32位字边界建立； 6. `IDLE`、固定同步帧及`DATA`、`CTRL` `SOF`检测； @@ -3220,7 +3295,7 @@ sync_reset_request 每个符合本规范的设备或IP至少应提供以下声明： -1. 本规范版本：V0.3； +1. 本规范版本：V0.4； 2. 主端或从端角色； 3. 采用的物理实现配置及第7章全部参数； 4. 最大`DATA`载荷；