Die to Die Adapter （1）

UCIe的Die to Die Adapter主要维护链路层的状态，数据完整性，支持多协议层的仲裁和Mux调度，链路协议和参数的协商等功能。

Adapter层向上承接各种协议层，接口为FDI，向下面向物理层，RDI接口。

UCIe协议定义的FDI接口支持单一协议层（protocol layer）或者多协议共存，CXL.io/Cachemem, 或Streaming protocol或者PCIe 协议共存，多协议在Adapter内经过Arb/Mux进行仲裁和多路选择。

Die2Die 链路初始化：

链路初始化分别由UCIe的Physical layer (Electrical, Logical), 和adapter layer完成。UCIe定义了分4个阶段的额链路初始化过程： 

Stage0: 第一阶段为每个die各自的复位和解复位操作。

Stage1: 第二阶段使用sideband信号的detection（信号侦测）和训练。

Stage2: 第三阶段是mainband的训练和链路repair。

Stage3: 第四阶段是两个die之间Adapter的参数协商和决策。

UCIe 链路初始化各阶段定义

其中Adapter在链路初始化阶段主要负责Stage3，也就是最后一阶段的初始化。

Die2Die Adapter主要功能有以下几方面：

1. 通过Sideband对协议参数的协商和交互。（链路初始化的最后一步）
2. 对各个不同的上层FDI协议的不同FLIT 封装。
3. 电源管理和状态协商
4. 链路可靠性：CRC/Retry和重传
5. 链路可靠性：runtime自测试

链路参数协商和交互

Adapter的下层接口RDI 报告active之后，UCIe link初始化进入最后一步，Stage3。这一步，UCIe协议通过一系列的协商来决定链路的capabilities和parameters。这一步的最后，将FDI state machine转到Active，表示FDI active。

这个阶段链路通过sideband交互和决定的参数有：

基本模式和capability：
        Raw_mode:

        UCIe 支持的模式之一，UCIe设备不支持PCIe/CXL 模式，此时仅可以协商为streaming protocol，则必须支持Raw_mode。 

        68bit Flit Mode：

如果协议层需要支持CXL 68B Flit mode或者PCIe non-Flit mode，则此cap必须置1. 根据CXL2.0 Spec, 如果链路最后协商的可支持协议是PCIe non-flit 模式，那么使用CXL.io 68B 格式Flit。

        CXL 256bit Flit Mode：

此Cap置1如果链路协商支持CXL 256bit Flit mode.

        PCIe Flit Mode

此Cap置1如果链路协商支持CXL 256bit Flit mode.

        Streaming: 

此Cap置1如果链路协商支持Streaming Protoco in Raw Mode.

Retry:

是否支持重传。

Multi_protocol_enable:

FDI是否支持多种协议，例如PCIe + CXL或其他组合，支持多协议则表示下面的两个cap都需要支持，Stack0_enable和Stack1_Enable都是1.

Stack0_Enable：

FDI协议上层有多种接口instance，此bit表示上层协议层Stack0使能。

Stack1_Enable

FDI协议上层有多种接口instance，此bit表示上层协议层Stack1使能。

CXL_LatOpt_Fmt5

支持CXL Latency Optimized Flit Format5

CXL_LatOpt_Fmt6

支持CXL Latency Optimized Flit Format5

Retimer:

Retimer 协商时此bit置1

Retimer Credits:

9bit，表示链路上Retimer Receiver端Buffer 大小， 1credit代表256Bytes。

DP:

链路的Downstream Port。主要用于PCIe/CXL设备announce downstream/Upstream, 并且Retimer设备不允许设置这个bit。

UP:

链路的Upstream Port。主要用于PCIe/CXL设备announce downstream/Upstream, 并且Retimer设备不允许设置这个bit。

下图示例了两个Die之间UCIe link的adapter capability协商过程，总体来说分两个步骤：

1. AdvCap：Die0 （DP）和Die1 （UP）分别 Advertise 自己的Capability。

2. FinCap： Die0最终选择一个可行的Cap，并通知对方Final的Cap。

下面示例了稍微复杂的协商：相关性cap协商，如

关于Cap的协商，有几个special case：

1. 如果链路两端，或者有一端不支持CXL/PCIe 模式，那么链路默认协商到streaming protocol模式。在此情况下，如果在Stage0  link bringup之时或者电路设计中，链路并未支持vendor specific模式，那么。那么FinCap默认是Raw_Mode。在此情况下，链路DP并不需要发送FinCap消息。

2. Adapter必须提供一个8ms超时的计时器，此计时器从RDI active开始计时，直至每次收到AdvCap.stall或者FinCap.stall message清0重新计时。此计时器用来跟踪链路stage3协商是否超时。如果链路协商过程中，接收端并不能计时响应（例如，接收端正busy）， 则adapter需要最长4ms内发送stall message给对端以重置对端的timeout计时器。

当stage3链路参数协商和交互结束，则通过FDI接口通知上层进行FDI bringup流程（其他章节再叙）