4. 协议层交互：事务层与数据链路层
UCIe的多Die集成中，协议层交互是保证数据正确传输的核心。我个人习惯把这一层看作“合同”——事务层负责谈生意，数据链路层负责送货确认。两个层级配合不好，整个系统就会出乱子。
4.1 事务层 vs 数据链路层：各自管什么
事务层处理的是“语义”，比如读请求、写请求、完成响应。数据链路层处理的是“可靠性”，比如包的分片、CRC校验、重传。我在项目中遇到过不少团队把这两层混为一谈，结果调试时根本分不清问题是出在事务理解还是链路传输。
| 层级 | 职责 | 典型包类型 |
|---|---|---|
| 事务层 | 定义请求/响应语义、地址、数据 | Req、Resp、Completion |
| 数据链路层 | 包分片、错误检测、流控、重传 | DLP、FLIT |
4.2 流控机制
流控说白了就是“你发慢点，我快吃不消了”。UCIe使用基于信用的流控（Credit-Based Flow Control）。数据链路层维护接收端的缓冲区信用，发送端只有在有信用时才发送包。
我记得有一次在调试多Die集成时，某个Die的流控信用计数器出现错误，导致发送端被永久阻塞。排查了两天才发现是初始化时信用值没有正确同步。
- 信用初始化： 链路初始化阶段，接收端广播其可用缓冲区深度，发送端据此建立信用池。
- 信用返还： 接收端消耗完包后会返还信用。返还信息通过专用的流控包或随路信号传递。
- 死锁风险： 如果信用返还路径和正常数据路径形成循环依赖，就会死锁。我建议在设计中保留独立的流控通道。
4.3 包格式解析
UCIe的包格式可以分成三层封装。你看这个结构：
+------------------+-------------------+------------------+
| 事务层头（TLH） | 数据链路层头（DLH） | 载荷（Payload） |
| 类型、地址、长度 | 序列号、CRC | 数据或完成状态 |
+------------------+-------------------+------------------+
事务层头定义了这个包是读还是写，目标地址在哪。数据链路层头加上序列号和CRC，用于重传和检测。我在项目中碰到过一个坑：事务层头和数据链路层头中的长度字段必须一致，否则接收端会解析出错误或者直接丢弃包。
常见的包类型
- Req（请求）：非投递式（如读）或投递式（如写）。
- Resp（响应）：对非投递请求的完成响应。
- Completion（完成）：带数据的读响应。
- Flow Control Packet：用于信用返还或状态更新。
包格式解析最容易出错的地方是边界对齐。UCIe要求包按64字节FLIT（流量控制单元）对齐。如果你的包长度不是64的倍数，需要填充。曾经有个合作方没填充，导致接收端CRC校验失败，整整调了一周。
4.4 重传与确认
数据链路层通过自动重传请求（ARQ）保证可靠性。发送端给每个包分配序列号，接收端收到后回复确认（ACK）或否定确认（NAK）。
为什么需要重传？物理层即使有均衡和纠错，也不能保证100%无误。数据链路层做了最后的把关。我推荐使用ACK/NAK结合超时重传的机制。光靠超时重传效率低，光靠NAK容易丢包。
重传流程
- 发送端发出序列号为N的包，开启重传定时器。
- 接收端校验CRC。正确则发ACK，错误则发NAK。
- 发送端收到NAK或超时未收到ACK，立即重传序列号N的包。
- 接收端收到重传包后，去重并继续处理。
确认机制还有个细节：ACK/NAK本身也可能会丢失。数据链路层通常采用快速重传——接收到多个相同序列号的ACK片段时，触发重传。嗯，这和TCP的快速重传思路有点像。
4.5 核心知识结构
下面这张图汇总了协议层交互的核心流程，画了事务层与数据链路层之间的主要交互：请求下发、信用控制、包封装、重传确认。你可以把它当成调试时的检查清单。
4.6 常见调试陷阱
- 流控信用不同步： 多Die系统启动顺序不一致，信用初始化消息丢失。我建议在固件中加入信用同步状态机，每次握手确认后再开放数据流。
- ACK/NAK丢失： 确认包也可能损坏。需要把确认包也纳入CRC保护，并使用定时器兜底。
- 包长度不匹配： 事务层头里的Payload长度和数据链路层维护的FLIT数量不一致。调试时可以用协议分析仪抓取原始包，逐字段对比。
- 死锁： 信用返还和正常数据路径形成环路。例如写请求占用了所有缓冲区，但信用返还也走同一缓冲区，导致双向阻塞。解决办法是分离流控通道或者预留信用。
协议层交互调试的核心是分层隔离。先确保数据链路层跑通，再看事务层语义。信用流控和重传机制是最容易出问题的环节，建议在仿真阶段就加入错误注入测试。