做数字SoC集成USB2.0 PHY上电后CLK不输出60MHzController一直挂死——问题到底出在哪景芯训练营一位学员在流片前的仿真回归测试中发现USB2.0模块上电后Controller状态机始终停在 IDLETrace了一下发现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的数字逻辑正确走完上电复位流程。图1USB2.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输出也就永远起不来了。图2UTMI与ULPI接口映射关系还有一个极易被忽略的点——REFCLK的时钟质量。USB3320支持两种模式Input Clock Mode外部直接供60MHz到CLKIN和Output Clock Mode外部供24MHz到REFCLKPHY内部倍频。学员用的是24MHz Output Clock Mode这个模式下REFCLK的抖动Jitter必须控制在±50ppm以内占空比要在45%~55%。如果SoC的时钟树为了省面积用了一个品质很差的RC振荡器去驱动REFCLKPLL Lock的时间会大幅拉长甚至直接Lock不上。从SoC系统集成的角度正确的上电流程应该是这样的PMU按序释放各路电源 → 等待电源稳定建议至少5ms→ 释放RESETB → 等待PHY拉高DIR表示初始化完成→ 读取Function Control寄存器地址0x04确认PHY版本 → 配置XcvrSelect和TermSelect → 开始正常的枚举流程。这个顺序一步都不能错。图3USB2.0上游端口接收状态机最后说一个调试技巧如果仿真里PHY的CLK始终不出来不要只盯着PHY看。用逻辑分析仪抓一下ULPI总线上的DIR、STP、NXT信号如果DIR一直为高且NXT没有变化说明PHY卡在初始化状态如果DIR为低但STP被Controller异常拉高说明是总线冲突导致的死锁。区分清楚是PHY的问题还是Controller的问题才能对症下药。
景芯SoC USB2.0 PHY上电后CLK不输出60MHz，Controller一直挂死——问题到底出在哪？
做数字SoC集成USB2.0 PHY上电后CLK不输出60MHzController一直挂死——问题到底出在哪景芯训练营一位学员在流片前的仿真回归测试中发现USB2.0模块上电后Controller状态机始终停在 IDLETrace了一下发现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的数字逻辑正确走完上电复位流程。图1USB2.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输出也就永远起不来了。图2UTMI与ULPI接口映射关系还有一个极易被忽略的点——REFCLK的时钟质量。USB3320支持两种模式Input Clock Mode外部直接供60MHz到CLKIN和Output Clock Mode外部供24MHz到REFCLKPHY内部倍频。学员用的是24MHz Output Clock Mode这个模式下REFCLK的抖动Jitter必须控制在±50ppm以内占空比要在45%~55%。如果SoC的时钟树为了省面积用了一个品质很差的RC振荡器去驱动REFCLKPLL Lock的时间会大幅拉长甚至直接Lock不上。从SoC系统集成的角度正确的上电流程应该是这样的PMU按序释放各路电源 → 等待电源稳定建议至少5ms→ 释放RESETB → 等待PHY拉高DIR表示初始化完成→ 读取Function Control寄存器地址0x04确认PHY版本 → 配置XcvrSelect和TermSelect → 开始正常的枚举流程。这个顺序一步都不能错。图3USB2.0上游端口接收状态机最后说一个调试技巧如果仿真里PHY的CLK始终不出来不要只盯着PHY看。用逻辑分析仪抓一下ULPI总线上的DIR、STP、NXT信号如果DIR一直为高且NXT没有变化说明PHY卡在初始化状态如果DIR为低但STP被Controller异常拉高说明是总线冲突导致的死锁。区分清楚是PHY的问题还是Controller的问题才能对症下药。
