UFS3.1协议中文学习讲解(8~9)

事先声明本文不用于任何商业行为，仅用于本人学习与记录。

欢迎点赞、收藏、转发分享给朋友，禁止未经书面授权的复制、搬运、二次剪辑。

如有引用请注明出处。

标准规范仍然以《JESD220E-UFS3.1》为准

写在最前：往后个人见解部分均用实线框出来。

8 UFS UIC Layer: MIPI M-PHY UFS UIC 层：MIPI M-PHY

8.1 Termination端接

M-TX（发送器）应按照 M-PHY 规范 [MIPI-M-PHY] 中 "端接方案（Termination Scheme）" 一节的定义进行端接。

M-RX（接收器）应包含可切换的差分端接（switchable differential termination）。默认情况下：

• PWM-BURST 状态：M-RX 端接应关闭，可通过设置适当的 MIPI 属性将其打开
• HS-BURST 状态：端接应默认开启（因为不支持未端接的 HS-BURST）
• SLEEP 和 STALL 状态：不应有端接
• DISABLE 和 HIBERNATE 状态：M-TX 驱动 High-Z（高阻态），而 M-RX 通过 "Dif-Z keeper" 端接 lane。Dif-Z keeper 表示 M-RX 在 lane 上驱动一个弱差分零（weak differential zero）。

链路（LINK）中某条子链路（SUBLINK）的 M-RX 可以有不同的端接设置。

受支持的端接设置在能力属性（Capability Attributes）中定义（见表 8.1 和表 8.2）。端接通过配置属性（Configuration Attributes）控制。接收端端接电阻在 M-PHY 规范中定义。

端接启用和禁用的时序在 M-PHY 规范中定义。

8.2 Drive Levels驱动电平

M-PHY 规范定义了两种驱动幅度：大幅度（Large Amplitude, LA）和小幅度（Small Amplitude, SA）。UFS 接口使用大幅度（LA）。

每条链路中的每个 M-TX 在上电或复位后，都将以 LA 开始通信。

链路（LINK）中的子链路（SUBLINKS）应以相同的幅度进行通信。

8.3 PHY State machinePHY 状态机

UFS 接口应实现 Type I 状态机。

M-PHY 规范为低速模式（LS-MODE）定义了两种不同的信号方案：非归零（NRZ）和脉冲宽度调制（PWM）。UFS 接口在 LS-MODE 下应使用 PWM 信号方案，如 M-PHY 规范对 State Machine Type I [MIPI-M-PHY] 所定义的那样。

对 LCC 功能的支持是可选的。

8.4 HS Burst高速突发

UFS 设备应支持 HS-GEAR1、HS-GEAR2、HS-GEAR3 和 HS-GEAR4。受支持的档位在能力属性中指示（见表 8.1 和表 8.2）。

链路（LINK）中的子链路（SUBLINKS）可以以不同的 HS-GEAR 或 PWM-GEAR 通信。

8.4.1 HS Prepare Length Control HS 准备长度控制

TX_HS_PREPARE_LENGTH（M-PHY 配置属性）定义了从 STALL 状态移动到 HS-BURST 状态的时间。复位时，M-TX 将 TX_HS_PREPARE_LENGTH 设置为 15。

8.4.2 HS Sync Length Control HS 同步长度控制

TX_HS_SYNC_LENGTH（M-PHY 配置属性）定义了HS Burst 之前的同步符号（synchronization symbols）数量。在 UFS 接口中，同步序列应由 M-TX 生成。对协议控制同步的支持是可选的。M-TX 在复位时以 TX_HS_SYNC_LENGTH = 15，类型为 COARSE 开始。

8.5 PWM Burst PWM 突发

UFS 设备应支持 PWM-G1。其他 PWM 档位是可选的。受支持的 PWM 档位在能力属性中指示（见表 8.1 和表 8.2）。

注：即使物理层支持 PWM-G0，该档位也不能使用，因为它不被 [MIPI-UniPro] 支持。

PWM-G1 在上电或复位后应默认为活动档位。

链路（LINK）中的子链路（SUBLINKS）可以以不同的 PWM-GEAR 或 HS-GEAR 通信。

8.5.1 LS Prepare Length Control LS 准备长度控制

TX_LS_PREPARE_LENGTH（M-PHY 配置属性）定义了从 SLEEP 状态移动到 PWM-BURST 状态的时间。复位时，M-TX 将 TX_LS_PREPARE_LENGTH 设置为 10。

8.6 Adapt适配

MIPI M-PHY 版本 4.1 支持一种新的适配序列（Adapt sequence），用于根据通道（channel）训练 M-RX 模块中均衡器（equalizer）的滤波器特性。

UFS 设备和 UFS 主机应实现均衡器，并且M-TX 应在需要时能够向其对应的 M-RX 提供适配序列。

UFS 设备应能够发起适配序列，但它应仅在主机请求时才开始。

8.7 UFS PHY Attributes UFS PHY 属性

MIPI M-PHY 包含多个可配置属性（configurable attributes）。这些属性定义了一个取值范围（range of values），但具体所需的实际值由应用程序在该范围内确定。以下是此类属性的列表。UFS 应用程序对这些值的具体要求可在表 8.1 和表 8.2 中找到。

8.8 Electrical characteristics电气特性

8.8.1 Transmitter Characteristics发送器特性

如 M-PHY 规范所定义。

8.8.2 Receiver Characteristics接收器特性

如 M-PHY 规范所定义。

9 UFS UIC Layer: MIPI UNIPRO UFS UIC 层：MIPI UniPro

9.1 Overview概述

UFS 构建在 MIPI 统一协议（Unified Protocol，UniPro） 之上，作为其互连层（服务交付子系统），为 UFS 传输协议（UTP）层提供基本的传输能力。

在数据平面（data plane）上，UTP 和 UniPro 通过 UniPro 传输层 CPorts（T_CO_SAPs） 的服务原语进行通信。

在控制平面（control plane）上，UFS 与 UniPro 之间更高级协议功能的交互（例如链路的发现、枚举和配置）使用 UniPro 规范所定义的设备管理实体（Device Management Entity）服务原语来完成。

9.2 Architectural Model架构模型

UniPro 内部由多个子层（sub-layers）组成，这些子层均由 MIPI UniPro 规范 [MIPI-UniPro] 明确定义。在 UFS 的语境下，整个 UniPro 协议栈在最大程度上应被视为一个黑盒模型（black box model）（见图 9.1）。因此，以下章节仅：

1. 规定 UFS 与 UniPro 之间所需接口的数量和类型
2. 规定 UFS 与 UniPro 寻址方案之间的映射关系
3. 选择 UniPro 规范中的可选特性（optional features）和可定义属性（definable attributes）

9.3 UniPro/UFS Transport Protocol Interface (Data Plane) UniPro/UFS 传输协议接口（数据平面）

UniPro 为 UniPro 之上的应用或协议层提供 CPorts 作为概念性接口。CPort 可以被视为 T_CO_SAP 的实例化，如 UniPro 规范 8.8 节所规定。

T_CO_SAP 的物理实现在 MIPI 中刻意未定义，因为实现者应该可以自由选择，例如：

• 更高层 UniPro 层的软件（SW）实现
• 基于缓冲（buffering）的硬件实现
• 基于 CPort 或 每个 CPort 的 DMA 通道的硬件实现

服务访问点（SAP） 提供服务原语（SP），可供 UniPro 之上的应用或协议（如 UFS）规范使用，以定义它们的交互。关于协议规范中 SAP/SP 概念的更多信息，请参见 UniPro 规范的附录 C。

T_CO_SAP 提供以下核心数据传输服务原语（见 UniPro 规范 8.8.1）：

1. T_CO_DATA.req( MessageFragment, EOM )

由 UniPro 的服务使用者发出，用于发送一条消息（分片）。

注：当 UFS 层请求 UIC 层传输数据时，UFS 层应确保该数据的最后一个分片会以 EOM 标志置位 来传输。确保这一行为的一种方式是：UFS 层对每个原子协议数据单元（例如每个 UFS 传输层的 UPIU）仅调用一次此 UIC 数据传输服务原语，并且始终将 EOM 标志置为 'true'。

2. T_CO_DATA.cnf_L( L4CPortResultCode )

由 UniPro 发出，用于报告一次消息（分片）传输请求的结果。

3. T_CO_DATA.ind( MessageFragment, EOM, SOM, MsgStatus )

由 UniPro 发出，用于将接收到的消息（分片）交付给服务使用者。

• EOM 告知服务使用者：这是最后一个消息分片（消息结束，EndOfMessage）
• SOM 告知服务使用者：这是第一个消息分片（消息开始，StartOfMessage）

4. T_CO_DATA.rsp_L()

由 UniPro 的服务使用者发出，用于表示准备好接收下一条消息（分片）。

9.3.1 Flow control流控

UFS 不会使用 UniPro 的端到端流控（End-to-End Flow Control）功能进行数据通信，因为 UFS 传输层已经通过严格的客户端 - 服务器通信模型、带标签的命令队列（tagged command queues）以及设备侧对数据传输的节流（throttling） 避免了任何溢出。

因此，UFS 将不使用 UniPro 的 T_CO_FLOWCONTROL 服务原语，因而不要求实现它。

9.3.2 Object sizes对象大小

一条 UniPro 消息（Message） 可以是任意大小，UniPro 不会以任何方式解释其内容。消息可以以多个消息分片（Message Fragments） 的形式从 UniPro 交付或接收。

一个消息分片（Message Fragment） 是一条消息中可被传递到、或由 CPort 接收的部分。接收到的分片通常与发送的分片不完全相同。 消息分片可以携带消息结束（EoM）标志，也可以不携带。

一个消息分片的最大大小应为 T_MTU 字节，以避免在更低层被进一步拆分。

---

9.3节主讲：UFS 的数据（UPIU）是怎么交给 UniPro 传出去的，以及 UniPro 那边传回来的数据怎么交回 UFS。

一、UTP 和 UniPro 之间有个 "交接窗口"，叫 CPort（连接端口），CPort 的正式名字叫 T_CO_SAP（传输层服务访问点），这个窗口在硬件上怎么实现（用软件、用缓冲、用 DMA），UniPro 不管，实现者自己定。UFS 只要知道 "有这么一个窗口能用" 就行。

二、交接动作

原语	谁发起	干什么	大白话
T_CO_DATA.req	UFS	请求把数据发出去	request"我要发这个包"
T_CO_DATA.cnf_L	UniPro	告诉 UFS 发的结果	confirm"收到了，发出去 / 失败了"
T_CO_DATA.ind	UniPro	把从下面收到的数据交给 UFS	indication"对方发来一个包，给你"
T_CO_DATA.rsp_L	UFS	告诉 UniPro 可以继续收	response"我收好了，继续"

1、UFS层发数据 ------request通过窗口(T_CO_SAP/CPort)----->UNIPRO，

      UNIPRO------confirm-------->UFS,然后UNIPRO继续把数据下发。

2、UNIPRO接到数据 -----indication通过窗口(T_CO_SAP/CPort)-----> 交给UFS,

     UFS层 ------response----->UNIPRO，UFS说我收好了，可以继续。

这就是典型的"请求 - 确认"（发送方向）+"指示 - 响应"（接收方向）两对动作。

三、数据太大怎么办？—— 消息 / 消息分片 / T_MTU

• 消息（Message）：UniPro 眼里的一整包数据，可以任意大小，UniPro 不关心里面装什么
• 消息分片（Fragment）：如果消息太大，会切成一段段传输，每段叫一个分片
• T_MTU：每个分片的大小上限，不能超过它（否则更低层还得再拆）

四、会不会 "塞爆"？—— 流控

UniPro 本来提供了一种防溢出机制（端到端流控 T_CO_FLOWCONTROL），但 UFS 明确不用它！

为什么不用？ 因为 UFS 自己已经有三重 "防堵车" 手段：

UFS 自己的手段	作用
严格的客户端 - 服务器模型	不会乱发
带标签的命令队列	每个命令有唯一编号，能追踪
设备侧节流	设备自己控制发送节奏

既然上层已经防好了，再加 UniPro 的流控就是重复建设，白费硬件成本。所以 UFS 说 "我不需要你那个流控，别实现了"。

---

9.4 UniPro/UFS Control Interface (Control Plane)UniPro/UFS 控制接口（控制平面）

UniPro 通过服务访问点（DME SAP）提供对其设备管理实体（Device Management Entity，DME）的访问，向 UFS 暴露以下服务，允许控制 UniPro 的属性（properties）和行为（behavior）：

DME 配置原语（DME Configuration Primitives）

1. DME_GET / DME_SET 提供对本地 UniPort（local UniPort）所有 UniPro 和 M-PHY 属性的读 / 写访问。

2. DME_PEER_GET（可选）/ DME_PEER_SET（可选） 提供对对端 UniPort（peer UniPort）所有 UniPro 和 M-PHY 属性的读 / 写访问。

注：在某些情况下，属性设置的顺序对 UniPro 的正确操作是相关的。因此，更高级的 UFS 层应保持 UFS 应用对 DME 配置原语调用的顺序。如果由 UFS 自身内部生成，DME 配置原语应按照 UniPro 规范所定义的正确顺序发出。

DME 控制原语（DME Control Primitives）

1. DME_POWERON（可选）/ DME_POWEROFF（可选） 允许上电或断电所有 UniPro 层（L1.5 至 L4）。

2. DME_ENABLE 允许使能整个本地 UniPro 协议栈（UniPro L1.5~L4）。

3. DME_RESET 允许复位整个本地 UniPro 协议栈（UniPro L1.5~L4）。

4. DME_ENDPOINTRESET 允许向链路端点（link end point）发送端点复位请求命令。

5. DME_LINKSTARTUP 允许在本地启动链路，并通知远端链路启动调用。

6. DME_HIBERNATE_ENTER / DME_HIBERNATE_EXIT 允许将整个链路置入 HIBERNATE（休眠）电源模式，以及唤醒链路。

• 影响本地和对端 UniPort（UniPro L1.5~L4 和 M-PHY）

注：从 Hibernate 退出后，所有 UniPro 传输层属性（包括 L4 T_PeerDeviceID、L4 T_PeerCPortID、L4 T_ConnectionState 等）将复位为其复位值。在通信恢复之前，必须在两端正确恢复所有必需的属性。

7. DME_POWERMODE 允许改变 M-PHY 链路的一个或两个方向的电源模式。

8. DME_TEST_MODE（可选） 允许将链路上的对端 UniPro 设备设置为特定的测试模式。

9. DME_LINKLOST 向更高层指示：链路已丢失（Link has been lost）。

10. DME_ERROR 向更高层指示：在某个 UniPro 层中遇到了错误条件（error condition）。

9.5 UniPro/UFS Transport Protocol Address MappingUniPro/UFS 传输协议地址映射

UniPro 从根本上具有两层寻址，用于控制远程 UniPro 实体之间的信息交换：

第 1 层：网络层（L3）— Device ID（设备 ID），最低层级的可寻址性

为未来的 UniPro 设备网络而提供。在连接建立期间，创建连接的一方使用该值来选择连接远端（remote end）的物理实体。该值在连接的生命周期内应视为静态（static）（不变）。

---

类似于eMMC是基本上是一机一片，就像一对一的串口线，所以用不到网络层。

一个手机、一片 UFS，一对一，根本不需要路由。所以 UFS 规范里网络层是被 "架空" 的：

• 9.6.3节中对网络层的要求只有一条：能收发最大 L3 数据包（N_MTU）
• 表 9.2 里网络层属性就是 N_DeviceID（主机 = 0，设备 = 1），一个取值就完事

所以 UFS 里网络层基本是个 "空壳"，不干路由的活。

那为什么还要保留它？—— 因为 UniPro 不是为 UFS 专造的。

关键点：UniPro 是 MIPI 联盟设计的 "通用协议"，UFS 只是它的一个使用者。

UniPro 的设计初衷，是要支持一个链路上挂多个设备的场景。UFS 是 "单设备" 应用，但还有别的应用会用 UniPro，UniPro 想做到 "一套协议通吃所有场景"，所以把网络层（路由 / 寻址）作为协议栈的标准组成部分保留下来了。UFS 用不上，但协议栈的分层结构是固定的，不能因为 UFS 不用就删掉这一层。

通俗想就是我UFS想复用UniPro，那就得按UniPro的规矩来，大家约定的行规就不要改了，我可以不用，但格式要保留，就像如果TCP/IP少一层，那肯定别扭，也不对。

---

第 2 层：传输层（L4）— CPort ID（连接端口 ID），最高层级的端到端可寻址性

在连接建立期间，创建连接的一方使用该值来选择远端目标 UniPro 设备内部的逻辑实体。该值在连接的生命周期内应视为静态。

UFS 采用 SCSI 架构模型 [SAM] 基于 Nexus 定义的寻址记法。

Nexus（I_T_L_Q）由以下组成：

• 发起设备端口标识符（Initiator Port Identifier，I）
• 目标设备端口标识符（Target Port Identifier，T）
• 逻辑单元号（Logical Unit Number，L）
• 命令标识符（Command Identifier，Q）

一个 I_T_L_Q Nexus 唯一地定义了：

• 通过特定的主机发起端口（I）
• 访问特定的设备目标端口（T）
• 连接到的特定逻辑单元（L）
• 内部的特定命令槽（command slot，Q）

UFS 互连层地址（Device ID 和 CPort ID）仅与 Nexus 的 I_T 部分相关。

本标准仅要求并在设备端和主机端各使用一个 UniPro CPort。

映射规则（Mapping Rules）

UFS 发起设备端口标识符（I）和 UFS 目标设备端口标识符（T）都应各为 16 位宽，并且：

1. UFS 发起 / 目标端口标识符应包含包含该 UFS 端口的实体（主机或设备）的 UniPro 网络层 Device ID
   • 主机的 UniPro 网络层 Device ID 复位值应为 0
   • 设备的 UniPro 网络层 Device ID 复位值应为 1
2. UFS 发起 / 目标端口标识符包含该 UFS 端口用于与远程实体通信的 UniPro 传输层 CPort ID
   • 主机的 UniPro 传输层 CPort ID 复位值应为 0
   • 设备的 UniPro 传输层 CPort ID 复位值应为 0
3. UFS 发起设备端口标识符应包含发起设备 ID（Initiator ID，ID）。

表 9.1 定义了 UFS 的发起设备端口标识符（I）和目标设备端口标识符（T）。

UFS 主机的 UTP 层与 UFS 设备的 UTP 层之间的单个 UniPro 连接，可以由上述 UFS_I_T Nexus 唯一标识。

注：UFS_I_T Nexus 的元素（Device IDs 和 CPort IDs）可以在复位后由主机使用 DME 服务原语修改：

• "T" 元素可以由主机使用 DME_SET 原语修改（注：原文此处可能应为本地属性）
• "T" 元素可以由主机使用 DME_PEER_SET 原语修改（对端属性）
• 主机侧的 CPort 所有属性（包括如 "T_ConnectionState"）可以在复位后由主机使用 DME_GET 和 DME_SET 原语检查和修改
• 设备侧的 CPort 所有属性（包括如 "T_ConnectionState"）可以在复位后由主机使用 DME_PEER_GET 和 DME_PEER_SET 原语检查和修改

---

传输层负责端到端，从哪个端口号发到哪个端口号。

举例，网络层是A公司->B公司，那么传输层就是A.张三->B.李四。

对于UFS设备来说，如果一台设备只有一个UFS，那通常其实也就是一对一的关系。

---

9.6 Options and Tunable Parameters of UniPro UniPro UniPro UniPro的可选和可调参数

MIPI UniPro 被设计为一种通用（versatile）协议规范，因此具有多个选项（options）和参数（parameters），像 UFS 这样的应用应该为它的专用 UniPro 使用场景指定这些选项和参数。UniPro 规范的附录 E 详细说明了所有可能的选择。

本章剩余部分定义了针对本版本 UFS 标准的这些选项和参数的具体要求。除非另有明确说明，它们同时适用于 UFS 主机侧和 UFS 设备侧的 UniPro 实现。

9.6.1 UniPro PHY AdapterUniPro PHY 适配器

对于 MIPI M-PHY 相关的属性值和实现选项，UFS 的定义请参见 8.7 节，UFS PHY 属性。

在 UFS 系统中，主机和设备使用相同的参考时钟（reference clock），因此不使用 skip symbol 插入功能，其实现是可选的。

UFS 设备应支持以下物理 lane 连接：

9.6.2 UniPro Data Link Layer niPro 数据链路层

数据链路层的实现要求：

• 应实现数据链路层流量类 "Best Effort（尽力而为）"（TC 0）
• 不要求实现数据链路层流量类 1（TC1：'Low Latency（低延迟）'）
• 不要求具备 TX 抢占（preemption）能力
• 应提供至少 DL_MTU 字节的数据链路层 RX 和 TX 缓冲
• 应支持最大尺寸 L2 帧（DL_MTU）的发送和接收

---

TC0/TC1 是 Traffic Class（流量类） 的缩写，是 UniPro 提供的 QoS（服务质量）分级机制。

流量类	缩写	名称	优先级	大白话
Traffic Class 0	TC0	Best Effort（尽力而为）	低	普通快递，堵车就排队
Traffic Class 1	TC1	Low Latency（低延迟）	高	急救专线，优先放行

UFS 为什么只要求实现 TC0？

因为 UFS 的命令 / 数据都是主机按顺序、自己可控地发出去的，没有那种 "必须插队抢道" 的紧急数据（不像某些实时通信）。所以用最简单、最省资源的 TC0 就足够了。

也就是说主机和命令都做好任务队列，高优先级任务的管控，那么我数据链路只需要安安心心负责好传数据就可以了。

---

9.6.3 UniPro Network Layer UniPro 网络层

网络层的实现要求：

• 应支持最大尺寸 L3 数据包（N_MTU）的发送和接收

9.6.4 UniPro Transport Layer UniPro 传输层

UFS 主机和 UFS 设备应实现至少 1 个 CPort。

注：本标准仅要求并在链路任一侧使用单个 CPort

如果实现了多个 CPort，UFS 不强制任何超出 UniPro 默认值的 CPort 仲裁（arbitration）方案。

• 应支持 UniPro 测试特性（Test Feature）
• UFS 不要求 UniPro 端到端流控（End-to-End Flow Control）机制
• UFS 将不使用"受控段丢弃（Controlled Segment Dropping，CSD）"，因此 CSD 应被禁用
• UFS 将不使用"CPort 安全阀（CPort Safety Valve，CSV）"，因此 CSV 应被禁用
• 应支持最大尺寸 L4 段（T_MTU）的发送和接收

9.6.5 UniPro Device Management Entity Transport Layer UniPro 设备管理实体传输层

DME 服务原语提供以下手段：

• 检索或设置属性（retrieve or set attributes）
• 控制整个 UniPro 协议栈的复位和运行模式

UFS 主机和 UFS 设备应实现以下 DME 服务原语：

• DME_GET、DME_SET
• DME_ENABLE
• DME_RESET、DME_ENDPOINTRESET
• DME_LINKSTARTUP、DME_LINKLOST
• DME_HIBERNATE_ENTER、DME_HIBERNATE_EXIT
• DME_POWERMODE
• DME_ERROR

UFS 主机（UFS Hosts）

应实现 DME_PEER_GET 原语和 DME_PEER_SET 原语（这两个在 [MIPI-UniPro] 中是可选的）。

UFS 设备（UFS Devices）

• 不得使用 DME_SET 原语来修改本地 PA_PWRMode 属性
• 只能在以下情况使用 DME_RESET：
  • 上电或硬件复位时，或
  • 在收到 DME_LINKLOST.ind 之后
• 不得使用以下原语：
  • DME_PEER_GET.req、DME_PEER_SET.req
  • DME_POWERON.req、DME_POWEROFF.req
  • DME_ENDPOINTRESET.req
  • DME_HIBERNATE_ENTER.req、DME_HIBERNATE_EXIT.req
  • DME_POWERMODE.req、DME_TEST_MODE.req

9.6.6 UniPro Attributes UniPro 属性

为了优化 UFS 启动（Boot）流程，UFS UIC 实现应对所有 UniPro 属性使用 MIPI UniPro 规范定义的默认复位值。

作为例外，网络层属性（Network Layer Attributes）和 CPort 0 的特定属性的复位值，应反映前面各节已定义的设置，因此应包含表 9.2 所示的值。