UCIe协议概述与架构
各位好，我是老周。先聊个题外话——做UCIe调试这几年，我最怕什么？最怕协议层出了问题，物理层报个“链路正常”，但数据就是传不过去。你抓耳挠腮看波形，最后发现是协议层的FIT序号错了。所以说，理解协议层架构是调试的第一步。
这一章，咱们把UCIe协议层从里到外捋一遍。我不打算照本宣科念spec，而是从实战角度告诉你：协议层到底在干什么，哪些地方最容易踩坑。
1.1 UCIe协议栈长什么样？
UCIe（Universal Chiplet Interconnect Express）的协议栈分为三层，从下往上依次是：
- 物理层（PHY Layer）——负责信号的电气特性、时钟、训练和边带。
- D2D适配层（Die-to-Die Adapter）——做协议封装、数据包路由、通道映射。
- 协议层（Protocol Layer）——我们调试的主战场，负责成帧、CRC、重传、流控等。
说白了，物理层像一条高速公路，D2D适配层是收费站和匝道，协议层就是跑在路上的卡车——它决定了数据能不能安全到达、有没有丢包、要不要重发。
核心观点：协议层是UCIe调试的“心脏”。80%的棘手问题都出在协议层，而不是物理层。我遇到过很多团队花两周查物理层眼图，最后发现是FIT错位——白白浪费时间。
下面这张图把三层结构画了出来。我从实战角度标了协议层内部的关键模块，方便你对照调试。
1.2 协议层的两个核心协议
我自己分的时候，喜欢把协议层拆成两个维度：LT（Logical Transmit/Receive）和FIT（Flit Control）。你trace上看到的各种字段，基本都归属这两个协议。
| 协议 | 作用域 | 关键字段 | 我踩过的坑 |
|---|---|---|---|
| LT | 端到端逻辑链路 | Seq#、Ack#、CRC | Seq#溢出导致重传死循环 |
| FIT | 物理通道的flit调度 | Type、Credit、Vendor | Credit调度策略搞反，吞吐塌到50MB/s |
实战提示：抓trace时先看FIT的Type字段。如果是Data Flit，再往下解析LT的Seq#。这个顺序能帮你快速过滤掉无关的链路维护报文。
1.3 协议Trace到底长什么样？
做调试，你手里得有trace。UCIe协议层的trace通常长这样（我简化了一下）：
Timestamp LT_Seq# LT_Ack# CRC32 FIT_Type Credit_VC0
0.000123 0x1 0x1 0xA3B4C Data 1
0.000245 0x2 0x1 0xD5E6F Data 2
0.000367 0x3 0x2 0x7G8H9 Null 0
...嗯，注意看第三行——FIT_Type是Null，说明这是一个维持链路状态的空flit。很多新手看到Null就以为链路有问题，其实正常。我曾经在一家客户那，他们debug了三天，结果发现Null flit正常现象，只是链路在等Credit。
1.4 协议层调试的三大检查点
- CRC一致性——发送方算的CRC和接收方算的CRC必须一致。不一致意味着比特错误。
- Seq#连续性——LT Seq#必须是连续递增的（Modulo 16）。跳号说明丢包了。
- Credit反压——如果发送方一直拿不到Credit，Flit就塞不出去。出现“空洞”时先查Credit。
警告：不要一上来就查物理层眼图！我见过太多团队绕了远路。先花5分钟看协议层trace，80%的问题在Seq#或CRC上就能现原形。
1.5 一个真实案例
去年我做某个chiplet项目，双die通信，带宽死活上不去。我打开协议层trace，发现FIT Credit的VC0一直为0。厂商说是物理层问题，我坚持查die间适配层的Credit映射——结果发现是D2D适配层的Credit计数器被复位了。说白了，协议层的Credit没走到物理层，等于车在收费站排队，但收费员下班了。
这个案例给我的教训就是：协议层不是孤岛。你看到的CRC错，源头可能在物理层信号质量；你看到的Credit空，源头可能在D2D适配层的计数器。
1.6 本章小结
协议层是UCIe调试的枢纽。你得先看懂LT和FIT，然后学会按“CRC→Seq#→Credit”的顺序排查。不要机械地看着trace发呆，要带着问题去读：谁发的？发给谁？校验对吗？流控堵了吗？
好，这一章就这些。下个章节咱们开始抓第一手Trace，手把手教你用工具定位问题。