企业官网建设流程全解析

做数字SoC集成，USB2.0 PHY上电后CLK不输出60MHz，Controller一直挂死——问题到底出在哪？

景芯训练营一位学员在流片前的仿真回归测试中，发现USB2.0模块上电后Controller状态机始终停在 IDLE，Trace了一下发现PHY根本没有输出60MHz的ULPI_CLK。这个问题看似是PHY的锅，但根因其实在SoC系统集成侧。今天把这个问题彻底讲透。

问

学员提问

"老师，我在做SoC集成时，USB3320这颗ULPI PHY上电后REFCLK输入是24MHz，但CLKOUT始终没有60MHz输出，Controller收不到时钟就一直挂死。POR时序也给了，RESETB也释放了，到底是PHY没起来，还是我的SoC侧配置有问题？"

这个问题在数字SoC的USB2.0集成中非常典型，而且坑点极深。很多工程师第一反应是怀疑PHY芯片坏了，或者电源没供好，但真相往往藏在ULPI接口的POR时序和寄存器配置顺序里。

先说一个根本性的认知：USB2.0 PHY（不管是ULPI还是UTMI+接口）内部都有一个PLL，负责把外部输入的参考时钟倍频到480MHz，再分频出60MHz的CLK供给Controller。这个PLL能不能Lock，直接决定了后续整个USB子系统的生死。而PLL Lock的前提，是PHY的数字逻辑正确走完上电复位流程。

图1：USB2.0 PHY内部架构（TI TUSB1210）

以USB3320为例，它的POR时序要求RESETB必须保持低电平至少1μs，而且释放RESETB之前，VDDIO、VDD18、VDD33必须全部稳定。很多SoC的电源管理单元（PMU）上电时序没有严格保证这一点，导致PHY内部的数字状态机在没有稳定电源的情况下就开始初始化，PLL自然Lock不上。

更深一层的问题是：即使电源时序对了，SoC侧的Controller在RESETB释放后多久开始驱动ULPI总线？USB3320的数据手册明确规定，RESETB释放后PHY需要一段初始化时间，期间DIR信号由PHY驱动为高，表示PHY正在占用总线。如果Controller在这个窗口期内就去写寄存器，总线冲突会让PHY直接进入异常状态，CLK输出也就永远起不来了。

图2：UTMI+与ULPI接口映射关系

还有一个极易被忽略的点——REFCLK的时钟质量。USB3320支持两种模式：Input Clock Mode（外部直接供60MHz到CLKIN）和Output Clock Mode（外部供24MHz到REFCLK，PHY内部倍频）。学员用的是24MHz Output Clock Mode，这个模式下REFCLK的抖动（Jitter）必须控制在±50ppm以内，占空比要在45%~55%。如果SoC的时钟树为了省面积，用了一个品质很差的RC振荡器去驱动REFCLK，PLL Lock的时间会大幅拉长，甚至直接Lock不上。

从SoC系统集成的角度，正确的上电流程应该是这样的：PMU按序释放各路电源 → 等待电源稳定（建议至少5ms）→ 释放RESETB → 等待PHY拉高DIR（表示初始化完成）→ 读取Function Control寄存器（地址0x04）确认PHY版本 → 配置XcvrSelect和TermSelect → 开始正常的枚举流程。这个顺序一步都不能错。

图3：USB2.0上游端口接收状态机

最后说一个调试技巧：如果仿真里PHY的CLK始终不出来，不要只盯着PHY看。用逻辑分析仪抓一下ULPI总线上的DIR、STP、NXT信号，如果DIR一直为高且NXT没有变化，说明PHY卡在初始化状态；如果DIR为低但STP被Controller异常拉高，说明是总线冲突导致的死锁。区分清楚是PHY的问题还是Controller的问题，才能对症下药。