UFS简介与架构概述

各位工程师朋友，咱们今天开始聊UFS。说实话，我从eMMC时代一路做过来的，第一次拿到UFS spec的时候，第一反应是——这玩意儿怎么这么复杂？但真正上手之后才发现，它的设计思路其实非常清晰。

为什么需要UFS？

先说说背景。老一点的嵌入式工程师应该都用过eMMC，那时候大家觉得还行，够用。但到了高清视频、大型游戏、AI应用的年代，eMMC那点带宽真的顶不住了。你想想看，一个4K视频流需要的读写带宽，eMMC的HS400模式也只能勉强扛住，而且延迟还大。

JEDEC组织在2011年推出了UFS 1.0标准，后来进化到现在的UFS 4.0。我个人认为，UFS最大的革命性变化是两件事：全双工通信和命令队列。

特性	eMMC	UFS
通信方式	半双工（不能同时读写）	全双工（读写可同时进行）
命令队列	一次一条命令	最多32条命令排队
接口	并行接口（HS400）	差分串行（M-PHY）
链路层	MMC协议	UniPro协议栈

UFS的分层架构

UFS最核心的设计思想就是分层。为什么要分层？说白了，就是把复杂的问题拆开处理。每一层只关心自己的事，接口固定好了，上层不用管下层用的是什么物理介质。

我画了一张分层架构图，你看看就明白了：

各层功能解析

咱们从上往下捋一遍：

1. 应用层（UFS Application Layer）

这一层说白了就是命令的发起者和响应者。Host这边发SCSI命令（比如READ/WRITE），Device那边执行并返回数据。标准UFS命令都是SCSI命令集的子集，但也有一些UFS特有的命令，比如Query Request用来读写设备属性。

• UFS Command Set：标准的SCSI命令（READ10/WRITE10等）
• UFS UIC Commands：用于链路控制（比如启动、速率切换）
• Task Management：重置某个命令或整个任务队列

2. 传输层（Transport Layer）

这一层负责把应用层的命令打包成UTP帧。UTP帧有固定的格式：Header + Data + CRC。嗯，这里要注意，UTP帧的大小不能超过链路层允许的最大帧大小（默认512字节，可以协商到更大的）。我在项目中遇到过一个问题，数据量很大的时候如果没做好分帧，传输层会一直报错，最后发现是UTP帧长度字段配置不对。

3. 链路层（Link Layer）

链路层用的是UniPro协议栈。这一层做的事情包括：帧定界（找到帧的边界）、流量控制、重传管理、电源管理等等。UniPro协议栈有很多子层：PHY Adapter、Data Link、Network Layer、Transport Layer（注意这里的Transport和UFS的Transport不一样，容易搞混）。

我曾经在Power Mode切换上栽过跟头——UniPro有Active、Hibernate、Sleep三种电源状态，切换时需要严格遵循时序。有一次我把Hibernate恢复时间设错了，导致设备唤醒后链路一直卡在Link Startup阶段，查了两天才发现是UniPro的PA_Hibern8Time参数超出范围。

4. PHY层（Physical Layer）

物理层用的是MIPI M-PHY标准。UFS用的是差分串行总线，支持多个Gear（速率等级）。Gear 1是1248 Mbps/lane，Gear 2是2496 Mbps/lane，Gear 3是4992 Mbps/lane，最高到Gear 5（目前UFS 4.0用到Gear 5）。

Gear	速率（每lane）	典型用途
Gear 1	1248 Mbps	上电初始、低速调试
Gear 2	2496 Mbps	普通读写场景
Gear 3	4992 Mbps	高速读写场景
Gear 4	7488 Mbps	高性能场景
Gear 5	9984 Mbps	UFS 4.0旗舰

UFS与传统eMMC的核心区别

做个比较你就清楚了：

• 通信方式：eMMC是半双工，同一时间只能读或写。UFS是全双工，读写可以同时进行——这一点在实际项目中体验差异巨大。我记得做高速摄像机的存储时，eMMC那边视频写入还没完成，又要读配置文件，就卡住了。换成UFS后，写入视频的同时读配置文件完全不受影响。
• 命令处理：eMMC一次只能处理一条命令。UFS有命令队列，最多32条命令同时排队，而且每个命令都有自己的上下文。这就让UFS的随机读写性能比eMMC高了好几个量级。
• 电源管理：eMMC只有Sleep和Wakeup两种状态。UFS有Active、Idle、Hibernate、Sleep多种状态，而且每层都可以独立管理电源。嗯，灵活多了，但调试起来也更复杂。