从RTL到波形：DWC_pcie_ctl_ep链路训练全程拆解

这是DWC_pcie_ctl_ep实操系列的第6篇。前几篇我分别聊了环境搭建、寄存器初始化、TLP读写通路怎么跑通这一篇把重点放到PCIe链路最前面的那个环节——Training。如果手上有DesignWare的PCIe Endpoint Controller RTL不管是做验证还是做调试第一步需要回答的问题永远是链路训没训上去Training走到哪一步停了。这篇就从RTL代码和仿真波形两条线同时切入把Training整个过程拆开看一遍。这篇文章主要面向三类人正在做PCIe IP验证的验证工程师、在FPGA上集成DWC_pcie_ctl_ep做原型验证的同学、以及需要通读PCIe控制器RTL去定位问题的IC设计工程师。内容不会贴大段受NDA保护的源码但会把关键模块、信号名、状态跳转思路、仿真波形观察方法讲清楚。你可以把这些方法直接套到自己的环境和代码里。1. 拿到RTL先看整体DWC_pcie_ctl_ep的模块骨架与角色1.1 模块划分DWC_pcie_ctl_ep严格来说是Synopsys DesignWare Cores PCI Express Controller的Endpoint版本。这个IP在SoC里的位置很清晰一侧接应用层比如DMA、中断控制器、AXI主从接口另一侧通过PIPE接口接PCIe PHY。PIPE接口在RTL里是你理解Training的重要窗口因为训练序列的收发、电气空闲检测、PHY状态反馈都从这组接口走。代码组织上顶层模块一般叫dwc_pcie_ctl_ep或者是pcie_ctl_ep_top之类的封装。往下拆通常能看到几个核心子模块链路训练状态机模块负责LTSSMLink Training and Status State Machine这是Training的核心。数据通路模块负责TLP/DLLP的组包拆包、流量控制、ACK/NAK重传。配置空间模块实现PCIe配置寄存器组包括链路能力、链路状态、设备控制等。应用层接口模块把PCIe事务转换成内部AXI或自定义协议。拿到RTL后我习惯先用一个简单的层级树把模块关系画出来然后沿着“配置空间→LTSSM→PIPE接口”这条线把每个模块的端口列表过一遍。很多同学一上来就扎进某个状态机的always块里结果看半天不知道这个状态机是谁在驱动。先看端口、再看子模块例化、最后才看逻辑这个顺序很重要。还有一个容易被忽略的点DWC_pcie_ctl_ep的资料分两部分一部分是RTL源码一部分是用户手册Databook。RTL里的信号命名和Databook里的寄存器/信号描述基本是对应的。分析时一定要把Databook放在手边比如ltssm_state在RTL里可能是一个多比特寄存器但在Databook里有明确的编码定义你不看手册光猜状态值会很痛苦。1.2 为什么Training是分析第一站Training之所以值得花一整篇来聊是因为它决定了后续所有事务能否发生。链路训练要完成的事情包括检测链路对端是否存在。完成符号锁定和位锁定建立可靠的数据传输基础。协商链路宽度x1、x2、x4、x8等。协商数据传输速率Gen1、Gen2、Gen3、Gen4。完成通道编号分配和极性/通道翻转处理。最终进入L0状态此时TLP和DLLP才能正常收发。换句话说Egress和Ingress的TLP能不能发、能不能收完全取决于训练有没有走到L0。LinkUp信号如果一直拉不起来后面所有的配置读写、BAR访问、DMA操作全都是空中楼阁。实际项目中我见过很多同事一上来就查TLP为什么发不出去查了半天发现是Training卡在Polling链路根本没建立。所以验证PCIe的第一个case永远是Training没有之一。LTSSM状态机是一个有限状态机核心状态包括Detect、Polling、Configuration、L0、L0s、L1、L2、Recovery、Disabled、Hot Reset、Loopback。常规训练路径是Detect→Polling→Configuration→L0。每个状态都有进入条件、退出条件和超时定时器。理解这套状态机的跳转逻辑是RTL分析和波形分析的基础。2. RTL级卡位训练状态机的实现细节2.1 LTSSM状态跳转逻辑在代码里的样子在RTL里LTSSM通常用一组状态寄存器加组合逻辑实现。DesignWare的代码风格一般是把所有状态编码放在parameter/define里然后在一个大的always块里做状态切换。你会在代码里看到类似这样的定义命名可能因版本而异localparam LTSSM_DETECT_QUIET 5d0; localparam LTSSM_DETECT_ACTIVE 5d1; localparam LTSSM_POLLING_ACTIVE 5d2; localparam LTSSM_POLLING_CONFIG 5d3; localparam LTSSM_CONFIG_LINKWIDTH 5d4; localparam LTSSM_CONFIG_LANENUM 5d5; localparam LTSSM_CONFIG_COMPLETE 5d6; localparam LTSSM_L0 5d7;状态机跳转的条件来自几个方面PIPE接口信号比如phystatus、rxelecidle、rxstatus。训练序列解析模块送过来的结果比如收到的TS1/TS2中的link number、lane number、speed ID。内部超时计数器比如DetectQuiet超时、PollingActive超时、ConfigurationIdle超时。举个例子从Detect.Quiet进入Detect.Active的条件通常是接收检测电路发现对端存在在PIPE接口上表现为rxelecidle拉低。如果这个信号一直保持高电平说明PHY眼里根本看不到对端状态机就会在Detect里打转永远进不了Polling。理解这段逻辑的关键是不要只盯着状态寄存器看要把输入条件一起拉出来看。状态机的每个跳转都是一个组合判断判断条件里任何一个信号不对状态就卡住。这也是为什么波形分析不能只看状态值还要同时看PIPE接口信号的原因。2.2 训练序列TS1/TS2的生成与解析Training的核心是训练序列Training Sequence Ordered SetTS1和TS2。这些序列在RTL里规模并不大但设计得很精巧。TS1/TS2是由一连串符号组成的其中包含符号00x1CCompliance模式相关标志。符号10xAA链路号Link Number。符号20x55链路号反转用于校验。符号30x00通道号Lane Number。后续符号速率ID、训练控制字段、CRC等。在发送方向LTSSM状态机控制一个发送使能信号让“发送TS1/TS2”的模块把序列按字节组装好送到PIPE接口的txdata上同时用txdatak标记哪些字节是数据、哪些是控制符号。在接收方向PHY恢复出rxdata和对应的rxdatak训练序列解析模块做对准和字段提取判断对端的能力。RTL分析的重点在接收侧。因为发送侧的逻辑比较简单无非是根据状态机要求把序列灌进去而接收侧要处理字对齐、字段解析、多lane间的一致性校验。实际调试中90%的Training问题都出在接收侧要么是TS1没被正确识别要么是解析出来的链路号跟本端不匹配。2.3 RTL里最容易埋雷的几个点从RTL角度找训练问题有几个固定的高发雷区我每次做代码审查都会重点看第一极性反转处理。PCIe允许通道极性反转发送端TX/TX-接反时接收端要靠Training中的极性反转标志来适应。如果RTL里极性反转逻辑只在某些状态生效而另一些状态没处理就会出现“Training一开始正常跑到一半状态机疯掉”的诡异现象。第二通道翻转与通道号映射。多通道链路里通道翻转后每个物理lane对应的逻辑lane号会变化。RTL里如果用错了映射表TS2交换通道号时会发现两边对不上。第三复位时序。训练状态机对复位特别敏感。上电后如果PERST#没有保持足够时间或者内部软复位和硬复位互相打架状态机可能一直在Detect里空转。这个问题我在后面波形部分会展开讲。第四参考时钟配置。PCIe的Gen速率对参考时钟频率有明确要求100MHz差分。如果参考时钟给错了PHY的PLL根本锁不住link partner的那一侧从波形上看起来完全没反应。这些雷点在代码阅读阶段就能提前引以为戒别等仿真跑到天荒地老才猛然想起来。3. 从波形复现Training全过程实操步骤3.1 仿真准备仿真Training推荐用Synopsys VCS或者Mentor的QuestaSimPCIe PHY模型通常由IP供应商提供或者测试平台里例化一个PIPE PHY model。跑一个基础training case之前要确保三件事就位第一测试平台的参考时钟和复位激励正确。PCIe仿真里refclk一般是100MHz差分布局复位包括PERST#和一些内部软复位。很多人上来就仿真复位时间短得离谱Training当然跑不出来。第二PHY model被正确例化并配置到合适的速率。PHY模型通常会带一些参数比如默认Gen速率、lane数、是否使能Gen3 equalization。这些参数要跟DWC_pcie_ctl_ep的配置一致。第三仿真波形dump的范围覆盖LTSSM模块和PIPE接口。很多时候dump波形时省事只dump了顶层信号结果内部ltssm_state根本看不到Debug时长直接翻倍。建议用类似下面的方式把整个DUT的信号都dump出来fsdbDumpfile test.fsdb fsdbDumpvars 0 tb_top.dut.pcie_ep all这里我习惯直接dump整棵DUT树。PCIe控制器RTL规模虽然不小但仿真波形文件相对于整个SoC来说还在可接受范围内宁可文件大一点也别在要查的时候没有信号。跑完仿真后打开波形文件把几个关键信号组加到波形窗口里。我用Verdi比较多会按下面的方式分组LTSSM组ltssm_state、link_up、ltssm_state_idle。PIPE组txdata、txdatak、rxdata、rxdatak、phystatus、rxelecidle。时钟复位组pclkPIPE时钟、core_clk、perst_n。训练序列组tx_training_seq_type、rx_training_seq_type。3.2 波形上先看什么拿到波形我建议按从大到小的顺序看不要一上来就放大到具体byte上。第一步先看ltssm_state从复位释放后是不是按Detect→Polling→Configuration→L0的顺序跳变。正常情况下状态值会在一段时间内连续变化最后停在L0。如果停在任何其他状态问题就锁定了方向。第二步当发现状态停住再放大看该状态的PIPE接口信号。如果卡在Detect看rxelecidle有没有拉低如果卡在Polling看rxdata/rxdatak上有没有持续出现TS1序列如果卡在Configuration看TS1/TS2里的链路号和通道号有没有正确解析出来。第三步把link_up信号跟ltssm_state对齐来看确认进入L0的时候link_up正好拉高。如果link_up没有跟着拉高说明状态机虽然到了L0但DWC_pcie_ctl_ep内部的“链路确认”逻辑没被触发这个问题往往要回到RTL里查link_up的生成条件。第四步如果有多个lane看每个lane上的训练序列是否能对齐。多lane链路训练时所有lane训练完成后需要同步进入下一状态。如果某个lane一直没有达到同步条件整个链路会卡住等待。波形上可以看到对应lane的rxdata上一直没有理想的序列输出。3.3 正常与异常波形差在什么地方我拿自己实际跑过的case举个例子。一个正常的Gen2 x4训练波形典型特征是复位释放后Detect阶段很短几百纳秒内rxelecidle就拉低。Polling阶段能看到txdata上重复发送TS1序列两边来回交换。进入Configuration后TS2序列出现并且能看到链路宽度从x1协商到x4。最后ltssm_state跳到L0link_up拉高之后开始DLLP的初始化。异常波形常见的形态有几种rxelecidle一直为高Detect死循环。Polling阶段只看到TX方向的TS1RX方向一片空白。Configuration阶段不断重复TS1/TS2里链路号对不上。状态机在L0和Recovery之间来回横跳。我之前遇到过一次卡在Polling的情况。波形上TX方向TS1一直在发RX方向却完全收不到任何TS1。我一开始怀疑PHY模型有问题后来把参考时钟波形拉出来一看发现PHY的PCLK跟控制器期望的频率差了快一倍。PIPE接口的时钟频率不对PHY的符号恢复逻辑根本没法工作。最后把参考时钟改成正确的频率训练一气呵成。这个事提醒我波形分析一定要把时钟源的波形先连同复位拉出来看一眼很多稀奇古怪的问题实际上是时钟域内部不匹配导致的。4. 训练问题排查速查与经验4.1 问题与排查方向速查表现象可能根因优先排查点卡在Detect.QuietPHY检测不到对端、无参考时钟rxelecidle、refclk波形、PHY model配置卡在Polling.Active收不到TS1或符号锁定失败rxdata/rxdatak、极性、时钟频率卡在Configuration.Loop链路号/通道号不一致、宽度协商失败TS1/TS2字段解析、翻转映射表LinkUp不拉高状态到L0但内部确认逻辑缺失link_up生成条件、DLLP初始化L0后跳Recovery时钟不稳、SKP补偿异常、EQ失败phystatus、速率协商、EQ事件这个表是我每次接手新Training bug都会先拿出来对照的清单。有了这个清单排查效率会高很多。4.2 复盘一个卡在Polling的问题定位全程有一次帮同事调试现象是模拟器里DWC_pcie_ctl_ep一直不发LinkUp。波形打开ltssm_state卡在Polling.Active。TX方向TS1是正常的每过一段固定时间就发一串节奏稳定RX方向rxdata上却没有任何TS1痕迹连杂散的符号都很少。我怀疑点落在两个地方一是PHY模型本身的数据通路是否使能二是控制器的接收数据通路是否被复位锁住。先看PHY模型的配置发现它被设置为Gen3速率而控制器这边配置成了Gen1。两边速率不匹配PHY虽然在工作但恢复出来的数据格式跟控制器期待的不一样解析模块根本认不出TS1。把两边速率统一到Gen1后RX方向立刻就出现了TS1链路顺利完成训练。这个case给我的经验是Training问题不要只盯LTSSM状态机本身还要检查控制器的配置寄存器设置跟PHY模型是否一致。速率、通道数、参考时钟频率这三个参数只要有一个不一致训练就会在某个状态上卡住。很多时候看起来是RTL的问题实际是配置环境的问题。4.3 平时容易忽略的几个实操细节第一个细节golden波形保存。我习惯把“首次完全正常的Training波形”单独存一份带注释的版本放在项目共享目录里。后面每次改完RTL或者调完PHY参数都拿新波形跟golden波形对比。Verdi支持直接叠加对比信号虽然不如仿真回归自动化但胜在快、直观。第二个细节断言和自动打印。与其每次打开波形慢慢数状态不如直接在测试平台里加几行打印逻辑实时输出state_changealways (posedge pclk) begin if (ltssm_state ! $past(ltssm_state)) $display([%0t] LTSSM state: %s, $time, ltssm_state_to_string(ltssm_state)); end这个方法在批量回归时特别好用。日志里直接看每一个状态的跳变时间点能用字符流的方式快速定位问题大致范围再打开波形精确确认。第三个细节DFT插入对复位和训练的影响。有朋友问过DFT插入的复位修改怎么在RTL里体现。这个需要留个心眼控制器复位路径一旦被DFT逻辑插入可能会出现复位被强制释放后某个信号落在默认值上的问题。比如训练序列发送使能如果被DFT输出强制拉低那TX方向的TS1自然就发不出来波形上看起来像是控制器根本没有开始训练。遇到这种情况不要盲目改RTL先查DFT scan_en是否在功能模式下被正确固定。第四个细节RTL波形分析和高速电路仿真是两条线。有人把PCIe的IBIS模型和RTL仿真混淆在一起。IBIS模型主要用于信号完整性分析做的是PCB/封装层面的通道仿真关注的是眼图、抖动、插损属于模拟领域而RTL波形分析关注的是数字协议逻辑。两者不在一个层面但可以相辅相成。在高速链路调试中先用IBIS做链路通道的SI仿真验证PHY能否正常工作再回到RTL层面看协议状态才是完整链路。我通常在项目里分开处理RTL仿真是功能验证IBIS仿真是物理层验证。这几条经验看着零散但都是实践里沉淀下来的。特别是自动打印状态和保存golden波形这两件事几乎是提高PCIe调试效率最划算的投入。最后再分享一个我实际工作中养成的小习惯。每次接手一个新的PCIe工程我第一件事不是急着改代码而是先把“复位释放→Detect→Polling→Configuration→L0”这条训练链路的波形完整跑出来保存成参考资料。有了这个参考波形后面再遇到任何LinkUp拉不起来的问题拿过来一对比是PHY没准备好、是TS序列没发出来、还是状态机逻辑跳飞了基本一眼就能定位。PCIe训练问题的根因大多在复位时序、PIPE接口时序和时钟配置这三个方向先把这三件事核对完再回头看LTSSM逻辑调试路径会顺很多。