跳到主要内容

04. SG2262 C2C 通信协议与数据通路

本文档覆盖 PAXI 协议桥、Send/Receive 通信流程、报文格式、流控与背压机制。行为级描述：硬件做什么、怎么做、什么时候做。

信息来源标注：[DOC] = 原始方案文档, [PPT] = feature PPT, [推导] = 从文档推导。

PAXI 协议桥​

定位与基本参数​

[DOC] PAXI 是 AXI 协议的跨芯片透明桥接 (AXI Bridge)。从上层软件视角，远端芯片内存与本地 AXI 地址空间无差异。

[DOC] 物理参数：

参数值说明
link_count88 组 x4 SerDes link
lanes_per_link4每组 4 lane
serdes_rate_gbps112.0单 lane 速率
total_bw_gbps448.08 * 4 * 112 / 8 (GB/s)
max_payload_bytes1344单报文最大有效载荷
header_overhead_bytes50报头开销
max_ost512TYPE1 outstanding 请求上限

TX Buffer 积攒与发出策略​

[DOC] PAXI TX Buffer 根据 AXI 事务类型采用不同的积攒策略，核心权衡是小包延迟 vs. 大包吞吐：

AXI 事务类型积攒规则行为描述
AW+W (写请求)必须收齐整个 burst 才发送AW 等待 W 通道最后一拍 (wlast)，收齐后打包为一笔 PAXI 报文发出
AR (读请求)按水位/超时/DA 切换触发打包最多积攒 16 笔 AR 事务后打包发出；水位线到达或超时同样触发发送
B (写响应)与 AR 相同的打包策略最多积攒 16 笔 B 响应后打包发出

[推导] 延迟影响：小包场景下 TX Buffer 需要等待积攒，引入额外延迟；大包场景下 burst 本身较长，积攒开销占比低，有效提高吞吐。

8 VC 通道仲裁​

[DOC] PAXI 内部使用 8 条 Virtual Channel (VC)，通过加权轮询仲裁决定哪条 VC 获得发送权。

[DOC] VC 映射规则 (Mode 0 默认配置)：

AXI 通道类型映射 VC说明
REQ (请求)VC0 / VC2写请求 / 读请求
RSP (响应)VC1 / VC3写响应 / 读响应
MUL (组播)VC4组播报文专用

[DOC] 设计要点：

  • REQ 和 RSP 使用不同 VC，防止请求-响应死锁（响应永远有通道可走）
  • 加权轮询权重：REQ/RSP = 0x0008, MUL = 0x0100（组播优先级显著高于单播）

CBFC/PFC 流控​

[DOC] PAXI 支持两种流控机制，二者互斥，不能同时启用。

CBFC (Credit-Based Flow Control) 模式：

项目描述
工作原理发送方按 per-VC 追踪 credit；每发一笔消耗 credit，收到 ack 回收 credit
credit 粒度32 ~ 2048B 可配
阻塞条件某 VC credit 不足时，该 VC 阻塞，上游 CDMA 被背压
适用交换机先进交换机（支持 CBFC 协议）

PFC (Priority Flow Control) 模式：

项目描述
工作原理接收方按 RX buffer 水位线控制发送方
触发暂停RX buffer 超过 high_watermark -> 发送 PFC PAUSE (per-priority)
恢复发送RX buffer 降到 low_watermark -> 发送 PFC RESUME
适用交换机典型以太网交换机（标准 PFC 支持）

OST 限制​

[DOC] TYPE1 请求最多 512 outstanding。当 outstanding 请求数达到 512 时，PAXI 停止接受新的 TYPE1 请求，直至收到响应释放 slot。

报文封装效率​

[推导] 有效带宽按最大 payload 计算：

有效带宽 = raw_bw * payload / (payload + header)
         = 448 * 1344 / (1344 + 50)
         = 432.0 GB/s (约 96.4% 封装效率)

[推导] 封装效率随 payload 减小而下降。当 payload 远小于 max_payload_bytes 时（如 256B 小报文），header 占比上升，有效带宽显著降低。

Send/Receive 完整流程​

核心机制​

[DOC] Send/Receive 的核心优势：地址可动态分配（无需预分配片间交互地址），通过配对完成发送方和接收方的同步。

替代方案：如不支持 Send/Receive，可通过 write + msg 方式替代，但地址需在运行模型前预分配好，且所有芯片的片间交互地址需相同。

配对规则​

[DOC] Send/Receive 配对约束（严格 thread 级一一对应）：

规则描述
Send 配对每个 CDMA Thread 的 Send 只能与一个对端 Chip 的一个 CDMA Thread 配对
Receive 配对每个 CDMA Thread 的 Receive 只能与一个对端 Chip 的一个 CDMA Thread 配对
跨芯片灵活性同一 CDMA Thread 的 Send 和 Receive 可与不同芯片配对
一对多限制不支持一对多发送（一个 Send Thread 不能同时发给多个 Receive Thread）
多对一接收支持：一个 Send Thread 可收集来自多个 Receive Chip 的 tcredit

[DOC] 多 tcredit 收集能力：

  • Send Chip 的 CDMA Thread N 可同时持有来自不同 Receive Chip 的 tcredit
  • 每个 tcredit 通过 chipid + cdmaid 唯一标识，存入 tcredit tracker
  • write_done 需分别发送到各 Receive Chip 对应的 write_done 地址
  • 这不意味着一对多通信 -- 每个 tcredit 仍代表一次独立的 thread 级一对一配对

tcredit 机制​

[DOC] tcredit 存储与 tracker 实现：

项目实现方式
tcredit 数据存储放入 SRAM（多个线程共享同一 SRAM）
tracker 匹配标识chipid + cdmaid 使用专用寄存器实现
队列深度32 per CDMA
一次通信最大指令数30 条（通信之间可全系统同步）
设计演变从 FIFO 改为 tracker 结构，以支持多 Receive Chip 场景下按 chipid 区分

[PPT] Descriptor 配对要求：

  • Send descriptor 需指定 receive chip 和 receive cdma thread
  • Receive descriptor 需指定 send chip 和 send cdma thread

CFS 模式流程​

[DOC] CFS (C2C Fence Sequence) 模式使用 non-post write 请求。Send 指令自带 fence 语义：必须收齐所有 write_send 的 bresp 后才能发送 write_done。

完整 9 步流程：

步骤执行方动作
1Receive ChipCDMA Thread 收到 Receive 指令
2Receive Chip将 receive 指令内容打包进 wdata，连同 cdmaid 一起，发送 tcredit 报文给对应 Send Chip CDMA Thread
3Send ChipCDMA Thread 收到所属 tcredit (chipid+cdmaid 匹配)，结合已有的 Send 指令，进入 Ready 状态
4Send Chip获得 Datapath 仲裁，执行搬运：连续发出多笔 write_send 报文 (awuser 携带 reduce_opcode)
5Send Chip搬运完成，Datapath 退出，将剩余 Bresp 个数信息交付 CDMA Thread（Datapath 只负责发送，不等 Bresp）
6Send ChipThread 独立收集 Bresp，逐一收集所有 write_send 对应的 bresp
7Send Chip所有 Bresp 收齐，发送 write_done 报文给 Receive Chip（写入 descriptor 指定的 write_done 地址），Retire Send 指令
8Receive Chip收到 write_done，发送 bresp 给 Send Chip（确认 write_done 接收），Retire Receive 指令
9Send Chip收到 write_done 的 bresp，完成整个 Send/Receive 周期

[DOC] CFS 关键约束：

约束项说明
写请求类型non-post write（必须等待远端 bresp）
fence 语义Send 指令默认自带 fence：收齐所有 write_send 的 bresp 后才 retire
Datapath 退出时机发完所有 write_send 后立即退出，bresp 收集交还 thread
Send/Receive 切换不需要做同步（但可以做）
一次通信最大指令数30 条

CHS 模式流程​

[DOC] CHS (C2C post-write Hardware Sequence) 模式使用 post write 请求。与 CFS 流程几乎相同，关键差异在于 write_done 与前置 write_send 的保序机制不同。

[DOC] CHS 与 CFS 的差异步骤：

  • 步骤 1~3：与 CFS 完全相同
  • 步骤 4 (Bresp 收集)：由于使用 post write，MAC 回复 early resp 后即视为完成，无需等待数据真正写入远端内存
  • 步骤 5 (write_done 发送)：write_done 地址必须配置在保序窗口内；write_done 报文发出后，不由 Send Thread 直接控制释放，而是由 c2c_sys 在保序窗口中等待，确认所有前置 write_send 已在远端执行完成后，才释放 write_done 报文给下游
  • 步骤 6~9：与 CFS 相同

[DOC] CFS vs CHS 核心差异对比：

差异点CFS 模式CHS 模式
写请求类型non-post writepost write
write_done 保序方式fence 指令保序：Send 指令自带 fence，收齐所有 bresp 后才发 write_done保序窗口保序：write_done 地址在保序窗口内，硬件保证前置写完成后才释放
write_done 地址约束无特殊约束必须落在保序窗口配置范围内
write_done 释放主体Send Thread 收齐 bresp 后主动发送c2c_sys 在确认前置 write_send 完成后自动释放
量化反量化传输支持重封包/重解包不支持重封包/重解包（只能根据量化前 ITLV 粒度封包）

报文格式​

AXI User 信号​

[DOC] C2C 使用 AXI user 信号传递芯片间路由信息：

信号用途
dst_chipid目标芯片 ID（MAC 层映射为 dst macid 进行寻址）
src_chipid源芯片 ID（在源芯片 MAC 层挂载）
src_chipen标识请求是否由本芯片发起（1 = 本芯片发起，0 = 转发）

转发场景​

[DOC] 多跳转发场景下的报文流程（以 Chip A -> Chip B -> Chip C 为例）：

步骤位置动作
1Chip A (源)发出请求：awuser 携带 dst_chipid=C，MAC 挂载 src_chipid=A，src_chipen=1
2Chip B (中继)识别 dst_chipid != 本芯片，执行转发，保持 src_chipid=A，设置 src_chipen=0
3Chip C (目标)识别 dst_chipid = 本芯片，使用 src_chipid=A 作为响应目标
4Chip C -> B -> ABresp/Rresp 经 Chip B 转发回 Chip A

Send/Receive 报文类型​

[DOC] Send/Receive 涉及的四种报文类型：

报文类型方向关键字段功能
tcreditReceive -> Sendreceive 指令内容打包进 wdata + cdmaid通知 Send 端接收方已就绪，携带目标地址信息
write_sendSend -> Receiveawuser 携带 reduce_opcode实际数据搬运报文
write_doneSend -> Receive写入 descriptor 指定的 receive chip cdma write_done 地址通知接收方所有数据已发送完成
bresp_sendReceive -> Send-确认 write_done 接收

All Reduce 操作码映射​

[DOC] All Reduce 操作码通过 awuser 传递，在 k2k 和 C2C 之间存在位域映射关系。

awuser 格式 (k2k 侧)：

位域字段含义
[11:8]psum_opReduce 操作类型 (sum/max/min 等)
[7:4]opcode具体操作码
[3:0]dtype数据类型 (fp16/bf16/fp32 等)

C2C 侧映射 (PCIe Link)：

Reduce_op 位域映射目标说明
Reduce_op[4]des_lst是否最后一个包
Reduce_op[3:2]psum_op与 k2k 侧 psum_op 对应
Reduce_op[1:0]opcode/dtype操作码和数据类型的压缩编码

Bresp 合并机制​

[DOC] Bresp merge 通过 CAM (Content-Addressable Memory) 结构实现确定性合并。合并规则：相同 dst macid 的 bresp 合并成一笔报文，不同 dst macid 占据不同 CAM entry。

存入条件（满足任一即可）：

条件描述
CAM 未满有空闲 entry，新 bresp 分配到空闲 entry；或命中已有 entry 时追加
CAM 满但命中未满 entrydst macid 匹配到一个未满的现有 entry，将 bresp 合并到该 entry

若 CAM 满且无命中 entry（所有 entry 的 dst macid 均不匹配，或匹配的 entry 已满），需先释放再存入。

释放条件（必须同时满足）：

条件描述
条件 1CAM 有某个 entry 已满，或 CAM 满且上游有新 bresp 待发送
条件 2PAXI ready（下游链路可接受新报文）

释放行为：将满足条件的 entry 打包为一笔合并后的 bresp 报文发出。

Datagram 模式​

[DOC] Datagram 支持软件通过配置 buffer 触发发送和接收原始以太网帧。C2C 不提供可靠性支持，全部由软件负责。

发送 Buffer​

[DOC] 发送 buffer 结构：32 个元素，每元素 128B（共 4KB 地址空间），配套 size 寄存器 FIFO（深度 32）。

[DOC] 发送流程：

步骤动作
1复位后所有 32 个 buffer 元素为空，长度字段为 0
2软件写入数据到 buffer（接收地址固定，硬件自动分配到第一个空元素）
3有效载荷 1~128B；帧超过 128B 时自动跨元素紧凑存储
4软件配置 size 寄存器指定帧长度 -> 硬件开始发送（允许 MAC 背压）
5发送完成后清除长度字段，元素标记为空

[DOC] 溢出保护：写入导致 buffer 溢出时，对应完整帧被丢弃并报告中断。软件必须结合 reg_space_send_datagram 寄存器保证不触发帧丢弃。

接收 Buffer​

[DOC] 接收 buffer 结构：32 个元素，每元素 128B（共 4KB，只读），按 MACID + Priority 匹配过滤。

[DOC] 接收流程：

步骤动作
1PCS 收到帧后，DMAC 与 MACID 比对 + Priority 比对
2匹配后依次写入 buffer 元素，完成后更新长度字段
3C2C 上报中断通知 CPU 介入
4CPU 读取长度 -> 读取帧数据（每次完整元素 128B） -> 自动指向下一帧
5无空闲元素时，新帧完整丢弃并发出中断

寄存器​

[DOC]

寄存器描述
send_datagram[31:0]发送帧位置，4KB，128B 写入，只能写首元素地址，可读全地址
reg_rptr_send_datagram当前待发送首帧的首位元素指针
reg_space_send_datagram当前剩余元素空间
reg_size_send_datagram[15:0]帧长度配置，只能写首寄存器，可全部读出
rcv_datagram[31:0]接收帧位置，只读，只能读首元素地址，128B 为单位读出
reg_size_rcv_datagram[15:0]接收帧长度，只读，32bit 为单位读出

中断​

[DOC]

中断类型触发条件
发送帧中断帧发送完成
接收帧中断帧接收完成
发送帧溢出中断写入导致 buffer 溢出（帧被丢弃）
接收帧溢出中断无空闲元素（帧被丢弃）
读接收帧溢出中断读取空元素

流控与背压传播路径​

[DOC] 背压从 PAXI 向上游 CDMA 传播，有两条独立路径，取决于流控模式：

路径 1 -- CBFC 背压：

CDMA 发起写请求
  -> PAXI TX Buffer 接收
    -> 检查目标 VC credit 是否充足
      -> credit 不足: 该 VC 阻塞
        -> PAXI 无法接收新报文
          -> CDMA 被背压，暂停发送

路径 2 -- PFC 背压：

CDMA 发起写请求
  -> PAXI TX Buffer 接收
    -> 检查下游 Switch 是否发出 PFC PAUSE
      -> 收到 PFC PAUSE: PAXI 暂停对应 priority 的发送
        -> TX Buffer 积压
          -> CDMA 被背压，暂停发送

[DOC] 两条路径的共同特征：背压最终都传导到 CDMA 层，使 CDMA 暂停发起新的 AXI 事务。区别在于触发源不同 -- CBFC 由 per-VC credit 耗尽触发，PFC 由下游交换机/接收方的 buffer 水位线触发。