docs: 发布非对称可靠串行传输规范 v0.3
This commit is contained in:
zhoushuang
parent
60eb71414e
commit
fe6748270d
132
非对称可靠串行传输技术规范.md
132
非对称可靠串行传输技术规范.md
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
**Asymmetric Reliable Serial Transport Technical Specification**
|
||||
|
||||
**版本：V0.2**
|
||||
**日期：2026-09-29**
|
||||
**版本：V0.3**<br>
|
||||
**日期：2026-09-30**<br>
|
||||
**作者：周爽**
|
||||
|
||||
---
|
||||
|
|
@ -12,6 +12,7 @@
|
|||
|
||||
| 版本 | 日期 | 说明 |
|
||||
|---|---|---|
|
||||
| V0.3 | 2026-09-30 | 新增基于Transaction帧结构的典型业务应用配置，明确请求与响应封装、设备与通道路由、字节序及分片规则，并增加读写分片示意图。 |
|
||||
| V0.2 | 2026-09-29 | 删除专用配置帧，将寄存器配置等业务统一纳入DATA载荷；统一术语和分层边界，完善拓扑、同步、重传、解析及帧布局图。 |
|
||||
| V0.1 | 2026-09-29 | 整合数据协议、链路同步、非对称可靠传输机制和三层接口，形成首个统一规范基线。 |
|
||||
|
||||
|
|
@ -2673,6 +2674,131 @@ LINE_FRAME_BYTES = FRAME_COST + CRC32 4 B
|
|||
- 链路同步和重新训练。
|
||||
|
||||
业务应用层只接收传输协议层已经提交的`DATA`载荷。业务应用层对载荷内容的接受或拒绝不得反向改变已经完成的传输确认。
|
||||
|
||||
### 39.3 典型业务应用：基于Transaction帧结构的业务应用层处理
|
||||
|
||||
本节定义一种可选的典型业务应用配置，不属于基础传输规范的强制要求。只有声明支持本Transaction应用配置的设备才必须遵守本节。在本应用场景中，主端为FPGA，从端为用于SPI扇出的ASIC。
|
||||
|
||||
Transaction是业务应用层的数据单元。一个完整Transaction作为`PAYLOAD`，由传输协议层封装进第12章定义的`DATA`逻辑帧；数据链路层随后追加`CRC32`并执行扰码，形成在线路上传输的`DATA`线路帧。为避免与传输协议层的`DATA`逻辑帧混淆，本节将Transaction内部的数据区统一称为`T_DATA`。
|
||||
|
||||
#### 39.3.1 Transaction帧结构
|
||||
|
||||
一个Transaction帧由8字节命令字段`CMD`和可选的Transaction数据区`T_DATA`组成。`CMD`包含读写标志`W/R`、主动回读标志`ARD FLAG`、芯片标识`CID`、地址`ADDR`、扩展地址`EXADDR`和数据长度`LENGTH`。
|
||||
|
||||
| 组成 | 字段 | 长度 | 位位置 | 功能描述 | 备注 |
|
||||
|---|---|---:|:---:|---|---|
|
||||
| `CMD` | `W/R` | 1 bit | `[63]` | 读写标识，0表示写，1表示读 | — |
|
||||
| `CMD` | `ARD FLAG` | 1 bit | `[62]` | 主动回读数据标志 | 主动回读模块根据读出芯片的读请求读出实验数据 |
|
||||
| `CMD` | `CID` | 5 bits | `[61:57]` | 芯片组中每个芯片的ID标识 | 包括量子测控芯片组及其他需要配置的芯片组 |
|
||||
| `CMD` | `ADDR` | 25 bits | `[56:32]` | 目标设备中的字节地址 | 必须4字节对齐，即`ADDR[1:0] == 2'b00` |
|
||||
| `CMD` | `EXADDR` | 12 bits | `[31:20]` | 设备及通道路由字段 | `[11:8]`预留，`[7:3]`选择设备，`[2:0]`选择从端通道 |
|
||||
| `CMD` | `LENGTH` | 20 bits | `[19:0]` | `T_DATA`的长度，单位为字节 | 必须是4字节的整数倍，最大支持1 MByte |
|
||||
| 数据区 | `T_DATA` | `N*4` bytes | — | 写入数据或读响应数据 | 读请求不包含该字段 |
|
||||
|
||||
`LENGTH`始终表示`T_DATA`字段的字节数，不包括8字节`CMD`。`CMD`按64位小端序封装，先发送`CMD[7:0]`，最后发送`CMD[63:56]`。`T_DATA`中的每个32位字同样按小端序传输，即低字节先发送；多个32位字按照业务提供的先后顺序传输。
|
||||
|
||||
#### 39.3.2 请求和响应封装
|
||||
|
||||
承载Transaction的`DATA`逻辑帧，其`LEN`与Transaction字段之间必须满足以下关系：
|
||||
|
||||
| Transaction类型 | 传输方向 | `DATA`逻辑帧的`LEN` | Transaction `LENGTH` | Transaction数据区 |
|
||||
|---|---|---:|---:|---|
|
||||
| 写请求 | `DL` | `8 + LENGTH` | 写入数据的字节数 | 包含`LENGTH`字节`T_DATA` |
|
||||
| 读请求 | `DL` | `8` | 期望读取的字节数 | 不包含`T_DATA` |
|
||||
| 读响应 | `UL` | `8 + LENGTH` | 返回数据的字节数 | 包含`LENGTH`字节`T_DATA` |
|
||||
|
||||
读响应的`CMD`必须与对应读请求的`CMD`逐位完全一致，并返回该命令指定的全部`LENGTH`字节数据，不支持部分响应。`DL`中的`W/R=1`表示读请求，`UL`中的`W/R=1`表示读响应。
|
||||
|
||||
本应用配置不增加事务编号，也不要求多个读请求的响应按请求顺序返回。多个完全相同的读请求同时在途时不进行特殊区分，其读响应允许按任意顺序返回。读响应仍遵守本规范规定的`UL`无确认传输机制，本节不为其增加确认或重传能力。
|
||||
|
||||
#### 39.3.3 设备与通道路由
|
||||
|
||||
`EXADDR[7:3]`用于设备路由：`5'd0`代表主端，`5'd1`～`5'd31`代表从端。因此，本应用配置最多表示31个从端。
|
||||
|
||||
基础传输规范中的各从端分别使用独立的点对点物理链路。主端业务应用层根据`EXADDR[7:3]`选择对应的物理链路；Transaction进入选定链路后，不依靠`EXADDR`完成线路层寻址。读响应保持请求CMD不变，因此其`EXADDR`仍保留被访问从端的编号。
|
||||
|
||||
`EXADDR[2:0]`用于从端内部的通道路由，具体定义如下：
|
||||
|
||||
| `EXADDR[2:0]` | 目的通道 |
|
||||
|:---:|:---:|
|
||||
| `3'b000` | 从端内部 |
|
||||
| `3'b001` | A-SPI0 |
|
||||
| `3'b010` | A-SPI1 |
|
||||
| `3'b011` | A-SPI2 |
|
||||
| `3'b100` | A-SPI3 |
|
||||
| `3'b101` | A-SPI4 |
|
||||
| `3'b110` | A-SPI5 |
|
||||
| `3'b111` | B-SPI[1:0] |
|
||||
|
||||
一个确定的`EXADDR`值只映射到一个确定设备的一个确定通道。一次Transaction及其全部分片不得跨设备、跨SPI通道或跨地址空间边界。
|
||||
|
||||
#### 39.3.4 Transaction分片
|
||||
|
||||
Transaction的`LENGTH`最大支持1 MByte，可能超过`DATA`逻辑帧允许的最大载荷。`DATA`逻辑帧允许的最大`PAYLOAD`长度为1032字节，因此每个Transaction分片最多包含8字节`CMD`和1024字节`T_DATA`。
|
||||
|
||||
以下示意图以4200字节`T_DATA`为例，展示主端业务应用层的分片结果：
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
O["原始Transaction<br/>ADDR = A，LENGTH = 4200<br/>T_DATA = 4200 B"]
|
||||
S{"按T_DATA每片最多1024 B分片"}
|
||||
F0["分片0<br/>ADDR = A，LENGTH = 1024<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
F1["分片1<br/>ADDR = A + 1024，LENGTH = 1024<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
F2["分片2<br/>ADDR = A + 2048，LENGTH = 1024<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
F3["分片3<br/>ADDR = A + 3072，LENGTH = 1024<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
F4["分片4<br/>ADDR = A + 4096，LENGTH = 104<br/>T_DATA = 104 B<br/>DATA逻辑帧 LEN = 112"]
|
||||
|
||||
O --> S
|
||||
S --> F0
|
||||
S --> F1
|
||||
S --> F2
|
||||
S --> F3
|
||||
S --> F4
|
||||
```
|
||||
|
||||
图中的每个分片都包含独立的8字节`CMD`。`ADDR`只按此前已经分片的`T_DATA`累计字节数递增，`CMD`长度不参与地址计算。
|
||||
|
||||
对于写请求，当原始Transaction的`T_DATA`超过1024字节时，主端业务应用层必须将其拆分为多个写请求，每个分片的`LENGTH`不得大于1024。例如，一个包含8字节`CMD`和4200字节`T_DATA`的Transaction，应拆分为4个包含1024字节`T_DATA`的分片和1个包含104字节`T_DATA`的分片；承载这些分片的`DATA`逻辑帧，其`LEN`依次为1032、1032、1032、1032和112字节。
|
||||
|
||||
对于读请求，其自身只携带8字节`CMD`。当`LENGTH`大于1024时，主端业务应用层必须将其拆分为多条读请求，每条读请求的`LENGTH`不得大于1024，以保证承载对应读响应的`DATA`逻辑帧之`LEN`不超过1032字节。
|
||||
|
||||
以下示意图以从地址`A`开始读取4200字节为例。五条分片读请求均只携带8字节`CMD`，所以承载请求的`DATA`逻辑帧之`LEN`均为8；每条读响应回显对应请求的`CMD`，并携带该分片指定长度的`T_DATA`：
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
O["原始读请求<br/>ADDR = A，LENGTH = 4200<br/>不携带T_DATA"]
|
||||
S{"按每条响应最多1024 B T_DATA拆分读请求"}
|
||||
R0["读请求0<br/>ADDR = A，LENGTH = 1024<br/>DATA逻辑帧 LEN = 8"]
|
||||
P0["读响应0<br/>CMD与读请求0完全一致<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
R1["读请求1<br/>ADDR = A + 1024，LENGTH = 1024<br/>DATA逻辑帧 LEN = 8"]
|
||||
P1["读响应1<br/>CMD与读请求1完全一致<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
R2["读请求2<br/>ADDR = A + 2048，LENGTH = 1024<br/>DATA逻辑帧 LEN = 8"]
|
||||
P2["读响应2<br/>CMD与读请求2完全一致<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
R3["读请求3<br/>ADDR = A + 3072，LENGTH = 1024<br/>DATA逻辑帧 LEN = 8"]
|
||||
P3["读响应3<br/>CMD与读请求3完全一致<br/>T_DATA = 1024 B<br/>DATA逻辑帧 LEN = 1032"]
|
||||
R4["读请求4<br/>ADDR = A + 4096，LENGTH = 104<br/>DATA逻辑帧 LEN = 8"]
|
||||
P4["读响应4<br/>CMD与读请求4完全一致<br/>T_DATA = 104 B<br/>DATA逻辑帧 LEN = 112"]
|
||||
|
||||
O --> S
|
||||
S --> R0 --> P0
|
||||
S --> R1 --> P1
|
||||
S --> R2 --> P2
|
||||
S --> R3 --> P3
|
||||
S --> R4 --> P4
|
||||
```
|
||||
|
||||
图中的五组请求与响应相互独立。图示连线只表示对应关系，不表示各读响应必须按照请求编号顺序返回。
|
||||
|
||||
除`ADDR`和`LENGTH`外，每个分片的`W/R`、`ARD FLAG`、`CID`和`EXADDR`均复制原始Transaction。第`i`个分片的地址按此前各分片`T_DATA`的累计字节数计算：
|
||||
|
||||
```text
|
||||
fragment_ADDR[i] = original_ADDR + sum(fragment_LENGTH[0 .. i-1])
|
||||
```
|
||||
|
||||
8字节`CMD`不参与地址递增。发起方必须保证地址计算不会发生25位`ADDR`溢出；地址溢出不进入`EXADDR`，本应用配置不定义溢出后的处理。
|
||||
|
||||
接收端将每个分片作为独立Transaction分别执行，不重组原始长Transaction，也不保证全部分片构成一个原子操作。
|
||||
|
||||
## 40. 层间处理流程
|
||||
|
||||
### 40.1 `DL`正常接收
|
||||
|
|
@ -3094,7 +3220,7 @@ sync_reset_request
|
|||
|
||||
每个符合本规范的设备或IP至少应提供以下声明：
|
||||
|
||||
1. 本规范版本：V0.2；
|
||||
1. 本规范版本：V0.3；
|
||||
2. 主端或从端角色；
|
||||
3. 采用的物理实现配置及第7章全部参数；
|
||||
4. 最大`DATA`载荷；
|
||||
|
|
|
|||
Loading…
Reference in New Issue