12 KiB
| html | ||||||
|---|---|---|---|---|---|---|
|
修订记录
| 版本号 | 日期 | 修订内容 | 修订人 |
|---|---|---|---|
| 1.0 | 2025.12.08 | 初始版本 | 周爽 |
1. 引言
本文档用于描述ez-Q 2.5测控系统各子系统（驱动子系统、通信子系统、反馈子系统、调控子系统、读出子系统）间的通信协议。
各子系统间的通信互连关系如图1所示。驱动通过TCP和UDP协议与通信子系统和反馈子系统通信；通信子系统通过Aurora 64b/66b协议与调控子系统和读出板通信，通过UART协议与泵浦板和混频板通信；反馈子系统通过全局反馈板间数据协议（GFP）与读出板通信。
{:height="70%" width="70%"}
具体地，下表列举了各子系统间的通信协议以及对应的物理接口。
| 序号 | 通信端A | 通信端B | 通信协议 | 物理接口 |
|---|---|---|---|---|
| 1 | 驱动 | 通信子系统 | TCP, UDP | SFP光口 |
| 2 | 驱动 | 反馈子系统 | TCP, UDP | SFP光口 |
| 3 | 通信子系统 | 调控子系统 | Aurora 64b/66b | PXIe背板 |
| 4 | 通信子系统 | 读出子系统（读出板） | Aurora 64b/66b | PXIe背板 |
| ^ | ^ | 读出子系统（泵浦板、混频板） | UART | PXIe背板 |
| 5 | 反馈子系统 | 读出子系统（读出板） | GFP | PXIe背板 |
2. Transaction数据格式
在ez-Q 2.5测控系统中，定义了Transaction这一数据格式，该数据格式被应用于TCP、UDP、Aurora 64b/66b等通信协议中，基于Transaction可以实现寄存器读写、存储器读写、结果上传等所有实验中需要的业务数据传输。
Transaction的具体数据格式定义如下表所示。一个Transaction包括命令（CMD）和数据（DATA）两部分；其中，命令部分又可分为读写标志（W/R）、主动回读标志（ARD FLAG）、芯片ID（CID）、地址（ADDR）、扩展地址（EXADDR）和长度（LENGTH）；数据部分要求长度必须是32-bit的整数倍。
| 序号 | 数据结构 | 长度 | 比特序 | 功能描述 | 备注 | |
|---|---|---|---|---|---|---|
| 1 | CMD | W/R | 1 bit | [63] | 读写标识，0：W；1：R | / |
| ^ | ^ | ARD FLAG | 1 bit | [62] | 主动回读数据标志 | 主动回读模块根据读出芯片读请求读出实验数据 |
| ^ | ^ | CID | 5 bits | [61:57] | 芯片组中每个芯片的ID标识 | 包括量子测控芯片组及其他需要配置的芯片组 |
| ^ | ^ | ADDR | 25 bits | [56:32] | 低25位地址 | 可与EXADDR拼接使用，或直接映射到量子测控芯片的偏移地址 |
| ^ | ^ | EXADDR | 12 bits | [31:20] | 扩展地址，可根据需求划分为多个功能区 （4比特预留+5比特槽位+3比特板卡内部预留） |
可与ADDR拼接使用此时寻址空间为128GByte； 该4096K的地址空间可按照需求映射给集控中心和外部SIP芯片组 |
| ^ | ^ | LENGTH | 20 bits | [19:0] | 指示读写数据长度，以Byte为单位 | 最大支持1MByte |
| 2 | DATA | N*4 bytes | [31:0] | 数据 | 读操作时，无需包含该项 |
在ez-Q 2.5测控系统中，使用Transaction扩展地址（EXADDR）中的EXADDR[7:3]这5个比特来标识槽位号，一个机箱中槽位号的使用如下表所示。
| 机箱位置 | 槽位号 | EXADDR[7:3] | 板卡 |
|---|---|---|---|
| 正面 | 0 | 5‘b00000 | 调控板 #1 |
| ^ | 1 | 5‘b00001 | 调控板 #2 |
| ^ | 2 | 5‘b00010 | 调控板 #3 |
| ^ | 3 | 5‘b00011 | 泵浦板 #1 |
| ^ | 4 | 5‘b00100 | 读出板 #1 |
| ^ | 5 | 5‘b00101 | 混频板 #1 |
| ^ | 6 | 5‘b00110 | 调控板 #4 |
| ^ | 7 | 5‘b00111 | 调控板 #5 |
| ^ | 8 | 5‘b01000 | 调控板 #6 |
| ^ | 9 | 5‘b01001 | 调控板 #7 |
| ^ | 11 | 5‘b01011 | 调控板 #8 |
| ^ | 12 | 5‘b01100 | 调控板 #9 |
| ^ | 13 | 5‘b01101 | 调控板 #10 |
| ^ | 14 | 5‘b01110 | 泵浦板 #2 |
| ^ | 15 | 5‘b01111 | 读出板 #2 |
| ^ | 16 | 5‘b10000 | 混频板 #2 |
| ^ | 17 | 5‘b10001 | 调控板 #11 |
| ^ | 18 | 5‘b10010 | 调控板 #12 |
| ^ | 19 | 5‘b10011 | 调控板 #13 |
| ^ | 20 | 5‘b10100 | 调控板 #14 |
| 背面 | 21 | 5‘b10101 | 时钟同步板 |
| ^ | 23 | 5‘b10111 | 通信板 |
| ^ | 25 | 5‘b11001 | 反馈板 |
3. TCP与UDP协议
驱动子系统与通信子系统和反馈子系统间通过千兆/万兆光网络进行数据交互，数据传输采用标准的TCP协议和UDP协议。其中，UDP应用于状态监控和TOE配置；TCP应用于子系统配置数据、子系统回传数据和读出主动上传的数据。基于标准的TCP协议和UDP协议，对其报文格式中的数据字段部分进行了进一步的协议划分，以满足使用需求。
3.1 TCP数据协议
TCP协议提供了一种可靠的、面向连接的数据传输服务，确保了数据在传输过程中不丢失、不重复，并且按顺序到达。因此，实验中的配置数据、采集结果等对可靠性要求高的数据均采用TCP协议传输。
TCP报文的数据格式如图2所示，在数据字段中包括一个或多个Transaction，数据的封装与解析均按照Transaction数据格式执行。驱动软件通过TCP协议将所有的芯片与板卡配置信息发送给通信子系统和反馈子系统，实验中所有的采集结果也通过TCP协议上传给驱动。
{:height="70%" width="70%"}
3.2 UDP数据协议
UDP协议提供了一种简单的、无连接的数据传输服务，不提供可靠性、顺序性和流量控制。UDP协议不需要建立连接，因此适用于TOE的寄存器配置业务，包括IP地址配置、网关配置、启动TCP连接等。状态监控业务对传输可靠性要求不高，同时要求支持广播功能，因此也使用UDP协议。
UDP报文的数据格式如图3所示，在数据字段中包括了数据头部（HEADER）、数据长度（LENGTH）、负载数据（PAYLOAD）和校验值（CHECK）4个部分，其中PAYLOAD包含有一个或多个Transaction。
{:height="70%" width="70%"}
UDP数据的具体格式定义如下表所示，通过HEADER字段来区分TOE配置业务和状态监控业务。
| 序号 | 数据结构 | 长度 | 比特序 | 功能描述 | 备注 |
|---|---|---|---|---|---|
| 1 | HEADER | 16 bits | [31:16] | 0x4547，TOE寄存器； 0x494e，状态监控 |
/ |
| ^ | LENGTH | 16 bits | [15:0] | PAYLOAD字段的长度，单位为byte | / |
| 2 | PAYLOAD | N*4 bytes | [31:0] | 负载数据，长度为32-bits的整数倍 | 一个或多个Transaction |
| 3 | CHECK | 32 bits | [31:0] | CRC32校验，计算PAYLOAD字段的CRC32 | CRC32生成多项式：G(x) = x^32^ + x^26^ + x^23^ + x^22^ + x^16^ + x^12^ + x^11^ + x^10^ + x^8^ + x^7^ + x^5^ + x^4^ + x^2^ + x + 1，初始值为0xffffffff |
4. Aurora 64b/66b协议
Aurora 64b/66b协议是一种用于点对点串行链路间传输数据的可扩展轻量级链路层协议，可为物理层提供透明接口并支持高速收发器应用。该协议具有低延迟、高带宽及高度可配置特性，采用64b/66b编码。基于Aurora 64b/66b协议可以实现10 Gbps速率的数据传输，适用于通信子系统、调控子系统和读出子系统间的高速数据传输。
Aurora 64b/66b协议的数据格式如图4所示，分为数据块（Data Blocks）和分隔块（Separator Block），数据块为实际传输的业务数据，分隔块标志了数据块的结束，理论上数据块没有长度限制，可以实现很高的传输效率。实际使用中，数据块中包括了一个或多个Transaction。
{:height="70%" width="70%"}
在数据传输过程中，接收端的处理速率跟不上发送端的发送速率时会发生数据的丢失。引入流量控制机制来避免这一问题，当接收方接近处理极限时，发送流控数据给发送方，让发送放停止数据发送，待接收端有足够的接收处理能力时再恢复发送。使用Aurora 64b/66b协议中的immediate NFC流控方式，即发送端在接收到NFC信号后立即开始流控。
5. UART协议
通信子系统与读出子系统的泵浦板和混频板之间的通信数据量少、速率要求低，采用UART协议进行数据交互。UART协议采用标准的1-8-1模式，即1比特起始位、8比特数据位、1比特停止位。UART通信传输的具体数据内容为寄存器指令，每条指令64比特，指令采用小字节序传输。例如对于64比特指令：0x0807060504030201，先传输“08”字节，最后传输“01”字节；对于字节：0b00001111，先传输“1”比特，最后传输“0”比特。
主控端（通信子系统）发送和接收的指令数据格式如下表所示。
| 序号 | 字节 | 比特序 | 标识 | 说明 |
|---|---|---|---|---|
| 1 | 0~3 | [31:0] | DATA | 32比特寄存器数据；读寄存器时，该域置0xffffffff |
| 2 | 4~6 | [47:32] | ADDR | 寄存器地址，地址单位是字节 |
| 3 | 7 | [61:56] | SLOT | 槽位信息 |
| ^ | ^ | 62 | R/W | 读写选择；0：读，1：写 |
| ^ | ^ | 63 | MEM_REG | 寄存器/存储器操作指令区分，寄存器操作为0 |
主控端（通信子系统）数据发送后，从端（泵浦板、混频板）会发送响应帧，响应帧的高32位保持与控制帧高32位相同，低32位为读回的数据或者与控制帧低32位保持相同，具体数据格式如下表所示。
| 序号 | 字节 | 比特序 | 标识 | 说明 |
|---|---|---|---|---|
| 1 | 0~3 | [31:0] | DATA | 32比特寄存器数据；读寄存器时，该域为读回的寄存器值，写寄存器时该域返回实际写入后读回的数据 |
| 2 | 4~6 | [47:32] | ADDR | 寄存器地址，地址单位是字节 |
| 3 | 7 | [61:56] | SLOT | 槽位信息 |
| ^ | ^ | 62 | R/W | 读写选择；0：读，1：写 |
| ^ | ^ | 63 | MEM_REG | 寄存器/存储器操作指令区分，寄存器操作为0 |
6. 全局反馈板间数据协议（GFP）
反馈子系统中的反馈主板需要与读出子系统间进行全局反馈信息交互，该交互链路要求低通信延迟。基于GT物理链路制定了全局反馈板间数据协议，以实现低延迟的反馈信息交互。
全局反馈板间数据协议以帧为单位进行数据传输，每帧32字节，具体的数据格式如下表所示。
| 序号 | 字节 | 比特序 | 标识 | 说明 |
|---|---|---|---|---|
| 1 | 0~3 | [31:0] | 帧头 | 固定值0xFCA5B659（可自定义） |
| 2 | 4~7 | [31:0] | 帧序号 | 每128个量子比特对应1个序号，从0开始依次累加，4B字节溢出循环；序号发送前与0xA5A5A5A5进行异或处理，接收序号后进行异或处理后，再做序号连续性检测 |
| 3 | 8~15 | [63:0] | 消息体1 | 量子态信息，每2比特标识1个态信息；2’b00：0态，2’b01：1态，2’b10：2态，2’b11：无效态；每个读取有效传输只有64bit，每读取板4路读取线，每个读取线8qubit，共32个量子态 |
| 4 | 16~23 | [63:0] | 消息体2 | 默认0xA5A5A5A5_A5A5A5A5，预留设计，需要态扩充比特位时可以启用 |
| 5 | 24~25 | [15:0] | 校验码 | 生成多项式：G(x)=x^16^+x^15^+x^2^+1，初相为1；只包含序号和消息体，校验通过时无需采用后续汉明纠错 |
| 6 | 26~27 | [15:0] | 汉明码 | 校验不通过时，可以使用汉明纠错，暂不启用 |
| 7 | 28~31 | [31:0] | 帧尾 | 固定值0x3BA7A579（可自定义） |