UFS3.1 这套协议我第一次啃的时候差点被 JESD220E 那几百页的英文文档劝退。后来是因为手上一个项目要调一块 UFS 3.1 的存储芯片读写性能死活上不去抓波形、翻寄存器、对着协议逐条比对才硬着头皮把 UniPro、MIPI M-PHY、SCSI 命令集这几层给串了起来。这篇就按我当时的理解路径把 UFS3.1 协议从物理层到命令层拆开讲一遍重点放在每一层到底在干什么、为什么这么设计、调试时该盯哪里。如果你正在做嵌入式存储、手机主控、或者半导体封测设备里涉及 UFS 的对接测试这篇应该能帮你少走点弯路。1. 先把 UFS 的协议栈分层搞清楚很多人一上来就翻 JESD220E 的命令表结果看到 SCSI 那一堆 opcode 直接懵。我的建议是先建立一张分层地图知道每一层负责什么再往里钻。1.1 UFS 不是单一协议而是四层叠起来的UFSUniversal Flash Storage本质上是把一套完整的存储通信体系打包成了一个标准。从下往上数它大致分四层物理层MIPI M-PHY负责电气信号定义电压、速率、lane 数量、时钟恢复方式。UFS 3.1 用的是 M-PHY 的 HS-G4 模式单 lane 速率 11.6Gbps。链路层MIPI UniPro负责把物理层的原始信号组织成可靠的帧传输做流控、错误检测、重传。传输层/命令层UFS Transport Protocol SCSIUFS 自己定义了一套 UPIUUFS Protocol Information Unit结构里面封装的是 SCSI 命令集。应用层主机侧的文件系统、驱动最终把读写请求翻译成 SCSI 命令。这么分的好处是调不通的时候你能快速定位是哪一层的问题。比如链路起不来多半是 M-PHY 的速率协商或者 UniPro 的 lane 初始化能起来但读写报错那就要看 UPIU 和 SCSI 层了。1.2 为什么 UFS 要套这么多层有人会问eMMC 那么简单直接UFS 为什么要搞这么复杂核心原因是速度和并发。eMMC 是半双工命令和数据不能同时走UFS 是全双工而且支持多队列Command Queue。要支撑 11.6Gbps 这种速率还要保证多命令并发下的顺序和可靠性就必须有一套完整的链路管理和流控机制这就是 UniPro 存在的意义。打个比方eMMC 像一条单车道乡道车少的时候够用UFS 像高速公路有多个车道lane、有匝道控制流控、有事故处理重传复杂但吞吐高。1.3 学习路径建议我个人的顺序是先看 M-PHY 的电气参数和状态机再看 UniPro 的帧结构和流控然后重点啃 UPIU 的几种类型最后落到 SCSI 命令集。JESD220E 文档里这几块是分开章节的别跳着看跳了后面会反复回来补。提示JESD220E 是 UFS 3.1 对应的规范版本号网上流传的很多中文资料其实是 UFS 2.1 或 3.0 的命令集差异不大但物理层速率和部分特性有区别对照时注意版本。2. M-PHY 物理层速率、lane 和状态机物理层是很多人觉得最枯燥的部分但恰恰是调试时最常出问题的地方。信号完整性、速率协商、lane 配置任何一个不对后面全都白搭。2.1 HS-G4 的速率是怎么算出来的UFS 3.1 支持的最高速率是 HS-G4单 lane 11.6Gbps。这个数字不是随便定的它来自 M-PHY 的速率档位定义速率档位单 lane 速率典型应用HS-G11.25GbpsUFS 2.0HS-G22.5GbpsUFS 2.1HS-G35.8GbpsUFS 3.0HS-G411.6GbpsUFS 3.1注意 HS-G3 是 5.8Gbps 而不是 5GbpsHS-G4 是 11.6Gbps 而不是 10Gbps这是因为 M-PHY 的速率是基于一个基准时钟倍频出来的具体倍频关系在规范里有明确公式。实际项目里你不需要自己算但要知道这个数字的来源避免在配置寄存器时填错档位。UFS 3.1 通常用 2 个 lanelane 0 和 lane 1理论总带宽就是 11.6 × 2 23.2Gbps换算成字节大约是 2.9GB/s。实际有效带宽会打折扣因为协议开销、流控、命令处理都要占时间。2.2 lane 的配置和常见坑lane 数量是可以配置的1 lane 或 2 lane。配置在 UniPro 的初始化阶段完成。这里有个容易踩的坑主机和设备侧的 lane 配置必须一致。我遇到过主机配了 2 lane设备只支持 1 lane结果链路一直起不来抓波形看只有 lane 0 有信号lane 1 是死的。后来查设备手册才发现那颗芯片只支持单 lane。另一个坑是 lane 的极性polarity和顺序lane order。有些 PCB 布线时为了走线方便会把 lane 0 和 lane 1 对调或者差分对的 P/N 反接。M-PHY 支持极性反转和 lane 交换但需要正确配置否则链路训练会失败。2.3 M-PHY 的状态机M-PHY 有一套状态机从 LINE RESET 到 STALL、SLEEP、HIBERNATE8 等状态。理解这套状态机对调试很重要因为链路起不来往往是卡在某个状态没跳出去。大致流程是上电后进入 LINE RESET然后经过一系列训练进入 STALL再根据配置进入高速模式HS或低速模式LS。HS 模式下才能跑 11.6GbpsLS 模式一般用于初始化协商。调试时如果发现链路一直停在某个状态可以用示波器看差分信号的活动情况。如果完全没有信号翻转可能是供电或时钟问题如果有信号但状态不跳转多半是训练序列不匹配。注意M-PHY 的 HS 模式对信号完整性要求很高PCB 走线阻抗要控制在 100 欧姆差分走线长度要匹配。我见过因为两根 lane 走线长度差了 5mm 导致高速下误码率飙升的案例。3. UniPro 链路层帧、流控和错误处理UniPro 是 UFS 里最隐形的一层平时你感觉不到它但一旦出问题就是链路级别的故障。它的核心职责是把物理层的比特流变成可靠的、有序的帧传输。3.1 UniPro 的帧结构UniPro 传输的基本单位是帧Frame。一个帧包含帧头、有效载荷和 CRC 校验。帧头里有目标地址、源地址、帧类型等信息。UFS 里通常只有两个端点主机Host和设备Device所以地址比较简单。帧的类型主要有几种数据帧、控制帧、确认帧。数据帧承载实际的 UPIU控制帧用于链路管理确认帧用于流控和重传。这里的关键点是UniPro 保证了帧的可靠传输。如果接收方 CRC 校验失败会请求重传。这意味着上层UPIU/SCSI不需要关心比特错误只需要关心逻辑错误。这个分层设计大大简化了上层协议的复杂度。3.2 流控机制为什么需要 creditUniPro 用 credit-based 流控。简单说接收方会告诉发送方我还有多少缓冲区可以接收数据发送方根据这个 credit 决定能发多少帧。这个机制避免了接收方缓冲区溢出。credit 的数量在链路初始化时协商。如果 credit 太少带宽利用率上不去如果太多接收方缓冲区压力大。实际项目中这个值通常是固定的不需要手动调但理解它能帮你分析为什么某些场景下带宽上不去。我遇到过一个案例主机侧驱动配置的 credit 值偏小导致高速读写时频繁等待 credit 更新实际带宽只有理论值的一半。后来调整了驱动里的缓冲区配置才解决。3.3 错误处理和重传UniPro 的错误处理分几个层次物理层错误信号丢失、同步失败由 M-PHY 处理。帧错误CRC 校验失败由 UniPro 请求重传。链路错误连续多次重传失败触发链路复位。调试时如果看到链路频繁复位通常是物理层信号质量有问题或者 credit 配置严重不匹配。这时候要先排除硬件问题再查配置。3.4 UniPro 的初始化流程UniPro 初始化分几个阶段链路启动、能力协商、credit 交换、进入数据传输状态。每个阶段都有对应的控制帧交互。这个过程如果卡住可以用协议分析仪抓链路层的帧看卡在哪个阶段。没有分析仪的话可以看主机侧驱动的日志通常会有状态机的打印。提示UniPro 的初始化对时序有要求某些阶段有超时限制。如果设备响应慢可能会超时失败。这种情况在低质量存储芯片上偶有出现选型时要注意。4. UPIU 与 SCSI 命令层真正干活的地方前面三层都是修路UPIU 和 SCSI 才是跑车。你所有的读写请求最终都要翻译成 SCSI 命令封装进 UPIU发给设备。4.1 UPIU 的几种类型UPIUUFS Protocol Information Unit是 UFS 自己定义的信息单元。常见的类型有UPIU 类型用途Command UPIU主机下发命令Response UPIU设备返回命令执行结果Data IN UPIU设备向主机传数据Data OUT UPIU主机向设备传数据Task Management UPIU任务管理如中止命令Query UPIU查询/配置设备参数一次典型的读操作流程是主机发 Command UPIU里面是 SCSI READ 命令→ 设备回 Data IN UPIU带数据→ 设备回 Response UPIU表示完成。写操作类似只是数据方向相反。理解这个流程对调试很关键。如果读操作卡住你可以判断是卡在 Command 阶段设备没响应、Data 阶段数据传输中断还是 Response 阶段设备报错。4.2 SCSI 命令集在 UFS 里的裁剪UFS 用的是 SCSI 命令集但不是完整的 SCSI而是做了裁剪。常用的命令有READ (10) / READ (16)读数据WRITE (10) / WRITE (16)写数据INQUIRY查询设备信息READ CAPACITY查询容量MODE SENSE / MODE SELECT查询/配置模式页UNMAPTRIM 操作SYNCHRONIZE CACHE刷缓存READ (10) 和 READ (16) 的区别在于地址位宽。10 字节的命令用 32 位 LBA16 字节的用 64 位 LBA。大容量存储必须用 16 字节版本。这里有个实际经验很多性能问题出在命令大小上。如果主机驱动一直用 READ (10) 发小命令命令开销占比高带宽上不去。改成 READ (16) 并增大单次传输长度性能会有明显提升。4.3 Command QueueUFS 的并发利器UFS 支持 Command Queue这是它比 eMMC 强的重要一点。主机可以同时下发多个命令设备可以乱序执行提高并发度。Command Queue 的深度在设备描述符里定义通常是 32。主机驱动会根据这个深度决定同时下发多少命令。但这里有个坑不是队列越深越好。如果设备内部处理能力有限队列太深反而会增加延迟。我实测过某颗芯片队列深度 32 时随机读的延迟比深度 8 时还高因为设备内部排队严重。后来把驱动里的队列深度调小延迟就降下来了。4.4 Query 功能配置设备的入口Query UPIU 是 UFS 特有的用来读写设备的描述符和属性。描述符包括设备描述符、配置描述符、单元描述符等属性包括当前电源模式、最大速率等。调试时经常用 Query 来读设备信息确认设备是否正常枚举。如果 Query 都失败说明链路层或更底层有问题。注意Query 操作有读和写两种写操作要谨慎改错属性可能导致设备行为异常。建议先读出来备份再改。5. 实际调试中怎么定位问题理论讲完了说说实战。UFS 调试最怕的是没反应因为链路复杂任何一层出问题都表现为读写失败。我的排查顺序是从下往上。5.1 第一步确认物理层有没有起来先看供电和时钟。UFS 设备需要多路供电VCC、VCCQ、VCCQ2任何一路不对都起不来。用万用表量一下各路电压是否正常。然后看参考时钟。UFS 通常需要 26MHz 或 19.2MHz 的参考时钟时钟不对链路训练会失败。最后看差分信号。如果有示波器看 lane 上有没有信号翻转。完全没有翻转说明设备没进入训练状态有翻转但幅度不对可能是阻抗匹配问题。5.2 第二步看链路层状态如果物理层正常接下来看 UniPro 是否进入数据传输状态。主机侧驱动通常有状态打印看是否卡在某个初始化阶段。没有日志的话可以用协议分析仪抓链路层帧。分析仪能看到 UniPro 的控制帧交互直接定位卡在哪一步。5.3 第三步验证 UPIU 和 SCSI 层链路通了之后先发一个简单的 INQUIRY 命令看设备是否正常响应。INQUIRY 是最基础的命令如果这个都失败说明 UPIU 封装或 SCSI 解析有问题。INQUIRY 成功后再试 READ CAPACITY确认容量读取正常。然后试小数据量的读写最后上大数据量和多队列。这个渐进式验证方法能帮你快速缩小问题范围。我见过有人一上来就跑性能测试结果失败后完全不知道是哪层的问题。5.4 常见问题速查表现象可能原因排查方向链路完全起不来供电/时钟异常量电压、看时钟链路训练失败lane 配置不匹配查 lane 数量和极性链路频繁复位信号完整性差查 PCB 走线和阻抗命令超时设备未响应抓 UPIU 看卡在哪阶段读写错误SCSI 命令参数错查 LBA 和传输长度性能不达标队列深度/命令大小调驱动配置6. 几个容易被忽略的细节最后分享几个我在实际项目中踩过的坑都是文档里不会明说但很影响调试效率的。6.1 电源模式的切换UFS 有多种电源模式Active、Idle、Sleep、Power Down。模式切换需要时间如果驱动频繁切换模式会引入额外延迟。性能测试时要把电源模式固定在 Active否则测出来的数据波动很大。6.2 温度对速率的影响UFS 设备在高温下可能会降速。我遇到过夏天实验室没开空调芯片温度上到 70 度以上读写速率直接掉了一半。后来加了散热片才恢复。做性能测试时要注意环境温度。6.3 描述符的版本兼容不同版本的 UFS 设备描述符字段有差异。UFS 3.1 的设备描述符里有一些 3.0 没有的字段。如果驱动按 3.0 的格式解析 3.1 的描述符可能会读错。建议先读设备描述符里的版本号再决定用哪套解析逻辑。6.4 中断和轮询的选择UFS 支持中断和轮询两种方式获取命令完成状态。中断方式 CPU 占用低但有延迟轮询方式延迟低但占 CPU。高吞吐场景用中断低延迟场景可以考虑轮询。这个在驱动里可以配置根据实际需求选。我在实际使用中的体会是UFS3.1 这套协议看着复杂但分层设计其实很清晰。只要按物理层、链路层、命令层的顺序去理解再配合实际的调试工具大部分问题都能定位。最怕的是一上来就钻命令细节忽略了底层链路的状态。另外手边常备一份 JESD220E 的英文原版中文资料只能当参考关键参数一定要回原文档核对。