- 博客(13)
- 收藏
- 关注
RSS订阅原创 CXL-IDE
模型密钥协商主体密钥分发路径适用场景模型A（主机主导）主机CPU主机 → 交换机 → 设备主机算力充足，需要全链路集中控制模型B（交换机代理）交换机主机 ↔ 交换机，交换机 ↔ 设备（并行）需要卸载主机压力，交换机有一定智能模型C（带外配置）带外管理代理带外通道分别配置大规模集群，集中化管理，不占用数据链路带宽。
2026-09-02 10:28:37
361
原创 CXL-RAS-ISOLATION
当 Root Port 处于 CXL.cache 隔离 状态时，对原本应发往设备的 H2D（Host to Device）请求，Root Port 会在本地合成响应，不再真正发往设备。当 Root Port 处于 CXL.mem 隔离 状态时，对原本应发往设备的 M2S（Memory to Slave/Device）请求，Root Port 会在本地合成响应。隔离的目的是快速完成经 Root Port 的待处理/后续事务（通过架构定义的响应）。软件必须显式清除隔离状态位，Root Port 才会退出隔离。
2026-05-12 14:15:00
376
原创 CXL-RAS-poison
如果数据可疑 → 设备的 MetaField 必须设置为 No‑Op非 Viral 状态：如果数据已知坏/可疑 → 必须标记 PoisonViral 状态（且 Viral 已启用）：推荐 不要再标记 Poison（避免“错误污染”，即一层套一层的错误标记反而干扰诊断）Host 向设备发送 Poison 数据的情况主机可能把 Poison 数据发给 CXL 设备设备对 Poison 的响应方式取决于具体设备设要求，但必须遵循 PCIe 规范。
2026-05-09 15:49:21
402
原创 CXL-RAS-viral
Viral是一种错误遏制机制。平台必须选择在启动时启用 Viral。Viral的主机实现允许平台通过写入寄存器来启用 Viral功能。类似地，设备上可访问的控制寄存器被写入以在设备上启用 Viral行为（接收和发送）。Viral支持能力和启用控制反映在DVSEC中。启用后，只要检测到，就会生成 Viral指示。Viral不能取代现有的错误报告机制。它的目的是一种额外的错误控制机制。错误的检测者负责通过AER报告错误并生成 Viral指示。
2026-05-08 13:54:49
406
原创 cxl 主机偏向和设备偏向，设备分别怎么访问设备内存
CXL（Compute Express Link）协议中的“主机偏向”和“设备偏向”，是针对（如带有内部内存的GPU或加速器）提出的。这两种模式的核心区别在于由谁来负责维护设备内存与CPU缓存之间的一致性，并直接影响主机和设备访问该内存的方式。
2026-03-02 15:38:03
551
原创 link layer-cxl.cache&cxl.mem 256B Flit 模式
在这两种比特模式中，比特报文打包规则是通用的，但槽位 8 除外，在 LOpt 256B比特模式中，槽位 8 是一个具有特殊打包规则的 12B 槽位。每个插槽图都包括 G 插槽、H 插槽和 HS 插槽，其中的子集是这样创建的：H 插槽是 G 插槽的子集，其中不包括超出14 字节边界的报文。最大报文规则适用于滚动 128B 分组，其中分组为 A="插槽 0 至 3"，B="插槽 4 至7"，C="插槽 8 至 11"，D="插槽 12 至 14"。H 插槽的打包规则是 G 插槽规则的严格子集。
2024-09-10 11:05:16
3257
原创 link layer-cxl.cache&cxl.mem 68B Flit模式
当本地的接收方检测到CRC错误时，启动LRSM中状态机，本地Tx接口发送Retry.Req序列准备重传。与此同时，Tx也开始超时计时。这个计时器的目的主要是用来分析Retry.Req和Retry.Ack 消息序列是否在传输过程中丢失，如果丢失了，那么在启动一次重传请求。接收到多个Retry.Ack被认为是一种非常严重的错误（因为后续的Ack会没有对应的Req）。为了降低这种致命错误出现带来的风险，我们检查返回的NUM_RETRY值以从先前的重传序列中过滤出Retry.Ack消息。
2024-09-10 11:03:43
3675
1
原创 link layer-cxl.io
使用X16链路宽度去发送和传输数据的时候，不需要链路带宽的协商。但是对于X1、X2、X4、X8的链路宽度，应该是需要协商的。对于降级传输，当链路有效通道数小于x16时，还是使用x16策略形成单个x16数据流，在x16或降级链路上传输。它的主要职责是为链路上的两个组件之间交换事务层数据包（TLP）提供可靠的机制。对于 68B Flit 模式，CXL.io 链路层实现了 CXL.io 数据包的成帧/解帧。CXL.io 仅使用适用于 8 GT/s、16 GT/s 和 32 GT/s 数据速率的编码。
2024-09-10 11:02:09
581
原创 cxl.mem
定义了CPU和内存之间的传输接口。当CPU和Mem位于不同的chip中，该通道走的是CXL的链路层和物理层，该协议可用于多个不同的内存连接选项，包括当内存控制器位于主机CPU中时，或当内存控制器位于加速器设备内时，或当内存控制器移动到单独的存储芯片时主机管理设备内存 (HDM) 地址区域提供 3种基本一致性模型：• HDM-H（仅主机相干）：仅用于第 3 类设备• HDM-D（设备一致性）：仅用于依赖 CXL.cache 管理与主机一致性的传统2 型设备。
2024-09-04 14:28:26
1769
原创 CXL-cxl.cache
将设备和主机之间的交互定义为多个请求，每个请求至少有一条相关的响应消息，有时还有数据传输。该接口在每个方向上由三个通道组成：请求（Request）、响应（Response）和数据（Data）。通道按其方向和传输内容命名，D2H表示设备到主机，H2D表示主机到设备。独立通道允许不同类型的信息使用专用线路，从而实现解耦和更高的单线有效吞吐量。D2H Req通道，将新请求从设备传送到主机。请求通常以内存为目标。每个请求将收到0、1或2个响应，和最多一个64字节的缓存行。
2024-09-03 11:49:22
926
原创 cxl.io
用于管理数据传输的流量控制机制。一个完整 DLLP，除去物理层添加的 1 个字节起始控制符号和 1 个字节结束控制符外，剩下的 6 个字节为通用 DLLP，其中 4 个字节为 DLLP 主要部分，包含了 1 个字节的 DLLP 类型字段和 3 个字节的附加属性字段，属性随 DLLP 类型的不同而不同；Ack/Nak DLLP，在 Ack/Nak 机制中由接收设备发向发送设备，保证 TLP 的可靠传送，Ack DLLP 表示TLP 被正确接收，Nak DLLP 表示 TLP 出现错误，请求发送设备重传。
2024-09-02 10:22:54
2446
原创 CXL协议
ARB/MUX 在来自 CXL 链路层的 CXL.io 和 CXL.cache/mem 的请求之间进行仲裁，跟据仲裁结果对数据进行多路复用，该结果使用加权轮询仲裁和主机设置的权重。CXL.mem是访问内存的，使用加载和存储命令为处理器提供了对设备附加存储器的访问，其中处理器作为主设备，CXL 设备作为从设备，能够支持易失性和持久性的存储器架构。CXL.cache是访问缓存的，定义了处理器与设备之间的交互，允许连接的 CXL 设备使用请求和响应方法，以极低的延迟高效地缓存处理器内存。
2024-08-30 10:16:09
3017
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人