企业官网建设流程全解析

简介：这份资源是 Synopsys DesignWare Cores DDR SDRAM PHY Utility Block "Lite"(PUBL) 的官方 Databook（版本 2.00a，2012 年发布），面向从事 DDR 控制器与 PHY 集成的数字 IC 设计、验证工程师以及存储子系统学习者，用于解决 PUBL 架构理解、寄存器配置、时序约束与信号对接等实际问题。压缩包共 1 个 PDF 文件，约 2.44MB，内容依次覆盖 PUBL 的功能架构（时钟生成、数据传输、控制单元等模块）、自动校准与动态调整等特性说明、时钟频率与数据传输率及 latency 等 timing 规格、信号名称与类型描述、寄存器地址与位域定义，并附有典型应用示例。已有 1314 人学习下载，说明其在 DDR PHY 工程实践中具有一定参考价值。读者可据此掌握 PUBL 的寄存器配置方法与信号时序关系，为 DDR SDRAM 接口的bring-up、校准调试和性能优化提供一手依据，也可作为团队内部培训与设计评审的技术底稿。pdf 单文件结构完整、便于检索。

1. DDR PHY 为什么需要一个"编程模型"：先给结论

调 DDR 的人大概都有过这种经历：板子回来，上电，初始化代码跑完，读写测试挂掉，于是开始怀疑 PCB 走线、怀疑颗粒、怀疑电源。真正被翻到最后的，往往是 PHY 内部那张寄存器表。可这个顺序其实是反的——一颗 ddr PHY 并不是一整块纯模拟的延时线阵列，它内部有一层可编程控制逻辑，负责把"时序参数"翻译成延时线抽头、把"训练"翻译成窗口扫描、把"校准"翻译成交给外部精密电阻的比对结果。PUBL 就是这层逻辑对外的编程模型，是一份控制器工程师必须读的接口契约：它规定了上电后按什么顺序发令、每个参数落在哪个寄存器、训练引擎怎么被驱动。搞懂它，寄存器表就不再是一堆黑匣子，而是可以从时序图上反推出来的状态机。

2. 上电到能读写：初始化为什么不能靠"延时等一等"

多数人写第一版 DDR 初始化代码时，会用udelay(200)这类固定延时去卡上电时序。在慢速、单颗粒、走线短的原型板上，这套写法通常能跑通，于是它被一路复制到量产代码里，然后在某一批板子上集体失效。失效的原因不是延时不够长，而是固定延时假设了"硬件会在某个确定的时间点完成某件事"——可 DLL 锁定时间随工艺角、温度、供电电压漂移，ZQ 校准时间取决于外部电阻精度和比较器收敛速度，DRAM 颗粒内部的状态机还要等自己的电源稳定。你延 200us，它可能 180us 就好了，也可能 260us 还没好。

2.1 三条并行初始化线：DLL、ZQ 与 DRAM 颗粒

PUBL 把初始化拆成三条互相独立、可以并行推进的线，这个拆分方式本身就说明了它对硬件结构的理解。

第一条是 DLL 初始化。DDR PHY 的发送和接收都依赖精确的相位关系：写数据时 DQS 要相对 DQ 偏移约 90 度，让颗粒在数据眼中心采样；读数据时 PHY 要用内部产生的多相位时钟去采外部返回的 DQS。这些相位不是靠反相器链凑出来的，而是靠延时锁相环（DLL）锁定到一个参考时钟周期上，再抽头出 0/90/180/270 度。DLL 锁定是一个闭环收敛过程，锁定时间与参考时钟频率、延时线级数、供电都相关，所以它必须有一个"锁定完成"的状态位可查，而不是靠猜。

第二条是阻抗校准（ZQ）。DDR3 的 DQ、DQS、地址线都要求输出阻抗和板上传输线特征阻抗匹配，通常是通过一个外接的精密电阻（典型 240Ω）作为基准，PHY 内部的 PU/PD 电阻阵列用比较器逐位逼近，调出一组码值使得等效阻抗对上这个基准。这个过程本质是一次二分搜索或逐次逼近，收敛步数固定但每步的稳定时间受模拟电路影响。校准结果是一组码值，会一直用到下次校准为止，所以 PUBL 里同时有控制寄存器和状态寄存器：一个负责发起，一个负责回报收敛是否成功、码值落在什么范围。

第三条才是 DRAM 颗粒侧的上电初始化。JEDEC 规定了一套严格顺序：CKE 拉低等电源和时钟稳定，CKE 拉高后发 NOP/DES 等待，然后 PRECHARGE ALL，再按 MR2、MR3、MR1、MR0 的顺序写模式寄存器，最后发 ZQCL 做颗粒侧的长校准。注意这一条的前提是前两条已经就绪——如果 PHY 自己的 DLL 没锁、输出阻抗没校准，它发给颗粒的命令本身可能就是错的。

提示：三条线可以并行，但并行不等于无序。正确的编排是先把参数写进寄存器，再同时触发 DLL 和 ZQ，等两者都回报完成后，才触发 DRAM 初始化。把 DRAM 初始化提前，等于让一个还没校准好输出级的 PHY 去驱动命令总线，命令可能在颗粒端被采样成别的东西。

2.2 PIR 与 PGSR：一个"发令—回执"的握手协议

PUBL 用一对寄存器完成所有初始化动作的触发与回报：PHY Initialization Register（PIR）写位来发起，PHY General Status Register（PGSR）读位来确认。

/* 典型的 PUBL 初始化编排：先落参数，再发令，最后轮询回执 */ static int publ_init(void) { u32 rid; /* 1. 版本识别：确认软件按对的寄存器地图在操作 */ rid = publ_read(RIDR); if ((rid & RID_MASK) != EXPECTED_RID) return -ENODEV; /* 2. 时序与拓扑参数必须在触发之前落地，否则状态机会用旧值跑 */ publ_write(PTR0, calc_phy_timing0()); /* PHY 内部 tDQSCK 等 */ publ_write(PTR1, calc_phy_timing1()); publ_write(DTPR0, calc_dram_timing0()); /* tRCD / tRP / tRAS */ publ_write(DTPR1, calc_dram_timing1()); /* tRC / tRFC / tWR */ publ_write(DCR, calc_dram_config()); /* 容量 / 位宽 / rank */ publ_write(DSGCR, calc_sys_config()); /* DDR 类型 / CS 映射 */ /* 3. DLL 与 ZQ 可以同时发起，两者互不依赖 */ publ_write(PIR, PIR_DLL_RST | PIR_ZQ_INIT); /* 4. 轮询回执，绝不写死延时 */ if (publ_poll(PGSR, PGSR_DLL_LOCK, TIMEOUT_DLL)) return -ETIMEDOUT; if (publ_poll(PGSR, PGSR_ZQ_DONE, TIMEOUT_ZQ)) return -ETIMEDOUT; /* 5. 前两级就绪后才让 PHY 驱动颗粒完成 JEDEC 初始化 */ publ_write(PIR, PIR_DRAM_INIT); if (publ_poll(PGSR, PGSR_INIT_DONE, TIMEOUT_DRAM_INIT)) return -ETIMEDOUT; return 0; }

这段代码里真正值钱的是顺序和轮询，不是寄存器名字。PIR的每一位对应一个可以独立发起的动作，PGSR的每一位对应一个可以被软件观测的完成事件，两者构成一个最小化的握手协议：软件写一位发起，硬件做完置一位回报，软件清掉再发起下一个。这种设计的直接收益是初始化流程可被打断、可被分阶段调试——你可以在 DLL 锁定后停下来读一次延时线抽头值，确认锁定质量，再去发 ZQ。

TIMEOUT_*这几个超时值需要按最坏情况给，通常取典型收敛时间的 5 到 10 倍。给太紧会在低温或低压角误判成失败，给太松会让真正的硬件故障表现为"开机很慢"而不是"开机失败"，反而更难定位。我的习惯是把超时值配成可调的模块参数，量产固件里收紧，调试固件里放开。

2.3 旁路模式：为什么允许你跳过自动流程

PUBL 提供 Initialization Trigger and Bypass 机制，允许软件部分或全部绕过自动初始化流程。这个设计初看很危险——谁会想跳过校准？但它在两类场景里是必需的。

第一类是硅后验证和 ATE 测试。测试程序需要逐个验证 DLL 抽头、逐档扫描 ZQ 码值、单独观察 DRAM 初始化状态机的每一步跳转，自动流程把这些中间态都封装掉了，测试拿不到观测点。旁路模式把每个子步骤暴露成独立可控的动作，让测试能停在任意一步。

第二类是上电恢复和低功耗退出。系统从自刷新（Self Refresh）退出时，DRAM 颗粒内部状态是保留的，不需要重跑完整的 JEDEC 初始化，只需要重新锁 DLL、可能补一次短校准。这时候跑完整流程不但浪费时间，还会破坏颗粒里已有的模式寄存器配置。旁路模式让软件只触发需要的那一步。

代价是责任转移：一旦旁路，软件就必须自己保证 DLL 已经锁定、ZQ 码值有效、模式寄存器内容正确，硬件不再兜底。这条边界在调试时特别容易踩坑——有人为了"加快启动"关掉 ZQ 自动校准，忘了手动补一次，结果整机在高温下偶发读写错误，查了两周才发现是输出阻抗漂了。

3. 寄存器地图：四十多个寄存器如何用三层结构覆盖一颗 PHY

把 PUBL 的寄存器从头翻到尾，会发现它不是一个平铺的地址空间，而是明显按"谁影响谁"分了三层。理解这个分层比记住任何单个寄存器的位定义都重要，因为调试时九成的困惑来自"我改的这个寄存器到底作用在哪一层"。

3.1 三层划分：全局、DRAM 侧、字节通道侧

最外层是全局层，管的是整颗 PHY 共用的东西：RIDR报版本，PIR/PGSR管初始化握手，PGCR/PGSR管通用配置与状态，DLLGCR/ACDLLCR管 DLL 的通用控制与 AC 侧延时，DSGCR管系统级拓扑（DDR 类型、CS 映射、rank 组织），ACIOCR管所有 AC 信号共用的 IO 特性（压摆率、驱动强度、片上端接）。

中间层是 DRAM 侧，描述"外面那颗颗粒长什么样、要遵守什么时序"：DCR描述容量、位宽、bank 数、page size；DTPR0-2装 JEDEC 定义的那一堆 tRCD/tRP/tRAS/tRC/tRFC/tWR/tWTR；MR0到MR3直接对应颗粒里的四个模式寄存器，PUBL 只是把它们做成可写寄存器，初始化时由硬件搬到颗粒去；ODTCR管片上端接的时序。

最内层是字节通道层，也就是DXn*系列——DXnGCR、DXnGSR0-1、DXnDLLCR、DXnDQTR、DXnDQSTR。这一层的特点是带n下标，意味着每个字节通道（byte lane）各有一套。为什么必须分开？因为 DDR3 的 fly-by 拓扑下，命令/地址/时钟到每颗颗粒的走线长度不同，DQS 与 CK 的偏斜在不同字节通道上是不一样的，读写延时必须在字节通道粒度上独立调整。把所有通道强行配成同一个值，等于假设 PCB 完全对称，这在多颗粒、多 rank 的板子上不成立。

还有一类寄存器是"引擎"级的：DTAR/DTDR0-1给数据训练提供地址和数据，DCU*是硬件训练引擎的地址/数据/运行/循环/配置/时序/状态，BIST*是内建自测的图形、掩码、地址、状态、错误记录。它们不描述静态配置，而是描述"让硬件自己去跑一段测试"的输入输出。

3.2 时序寄存器的换算：ns 与时钟周期不是一对一

JEDEC 手册里的时序参数都以纳秒给出，而 PHY 内部的一切都以时钟周期和延时抽头计数。这个换算看起来只是除法，实际有两个容易翻车的点。

第一是向上取整的方向。tRCD 是"从行激活到列地址可以发"的最小间隔，如果算出来是 5.3 个周期，你必须取 6，取 5 就违反时序。但反过来说，有些参数（比如某些建立时间）在 PHY 内部是"最多"约束，取整方向相反。分清每个参数是下限还是上限，比会做除法重要得多。

第二是换算用的时钟周期是谁的周期。DDR 的时钟和 PHY 内部工作时钟可能不同频，命令总线上一个周期对应的时间，和数据通路上一个周期对应的时间不一定一样。参数写进PTR和写进DTPR，用的换算基准可能就不是同一个。

/* 把 JEDEC 的 ns 级参数换算成周期数，注意取整方向 */ #define DIV_ROUND_UP(a, b) (((a) + (b) - 1) / (b)) /* ns_x100: 以 0.01ns 为单位的参数值，避免浮点 * tck_ps : 当前 DDR 时钟一个周期多少皮秒 * 返回 : 周期数，向上取整，用于"最小间隔"类参数 */ static u32 ns_to_cycles_ceil(u32 ns_x100, u32 tck_ps) { u64 ps = (u64)ns_x100 * 10; /* 0.01ns -> ps */ return (u32)DIV_ROUND_UP(ps, tck_ps); } /* 寄存器字段宽度有限，换算结果必须做上限钳位 */ static void write_dtpr0(u32 t_rcd_ns_x100, u32 t_rp_ns_x100, u32 tck_ps) { u32 t_rcd = ns_to_cycles_ceil(t_rcd_ns_x100, tck_ps); u32 t_rp = ns_to_cycles_ceil(t_rp_ns_x100, tck_ps); /* 字段只有 4 bit 时，超过 15 个周期的值会被截断，必须先钳位 */ t_rcd = min(t_rcd, DTPR_T_RCD_MAX); t_rp = min(t_rp, DTPR_T_RP_MAX); publ_write(DTPR0, (t_rcd << DTPR_T_RCD_SHIFT) | (t_rp << DTPR_T_RP_SHIFT)); }

钳位这一步不是防御性编程，而是必须做的事。低频配置下 ns 换算出来的周期数很小，不会溢出；一旦切到高频，同一批参数换算出来的值就可能在字段边界上溢出，溢出后不是报错，而是静默截断成一个小值，表现为"频率提上去以后偶发数据错"。这种错因为不报错，非常难查。

3.3 写进去不生效：影子寄存器与更新时机

PUBL 里有一批寄存器存在"写进去但行为没变"的现象，典型的是跟延时线抽头、DLL 相位相关的那些。常见的实现思路是：这些寄存器背后有一组影子寄存器（shadow register），软件写的是影子，硬件在某个确定的事件点才把影子搬到工作寄存器——这个事件可能是 DLL 重新锁定、可能是发起一次初始化、可能是专门的更新触发位。

为什么这么设计？因为延时线抽头不能在工作过程中被单步修改。你正在用抽头值 12 采样数据，突然把它改成 7，采样点的相位会跳变，正在进行的那笔突发传输直接读错。要么整体原子切换，要么等通路空闲再切，两者都需要一个"何时生效"的控制点。

调试上的后果是：改了DXnDQSTR的延时值，读回确认写成功了，但眼图完全没变化——因为更新事件还没触发。这时候需要的不是怀疑寄存器坏了，而是找到触发位或者重新跑一次训练。判断方法很简单：先把值改成两个差异很大的数，分别读回确认写入通路没问题，再去找触发条件。

4. 数据训练：DQS gate 与 read eye 到底在扫描什么

初始化和寄存器配置解决的是"时序参数对不对"，数据训练解决的是"物理通路能不能用"。这两件事在概念上完全分开，混淆它们是最常见的定位错误：参数全对但训练不收敛，问题在信号完整性；参数有错但训练能过，问题会在高低温或长时间运行后才暴露。

4.1 DQS gate training：找 preamble，而不是找数据

读操作时，DQS 是由 DRAM 颗粒驱动、和 DQ 一起返回 PHY 的。但总线空闲时 DQS 处于三态或弱下拉，PHY 的接收电路不能一直开着——一直开着会把总线上的噪声、反射、串扰全部当成数据采进来，接收器会疯狂翻转、白白耗电。所以 PHY 需要一个门控信号（gate），只在真正的 DQS 脉冲群到达时打开接收窗口。

问题在于：这个窗口对准哪里？DQS 从颗粒出发经 PCB 到达 PHY，延时是走线长度和负载决定的，不同字节通道不同、不同板子不同、同一块板子在不同温度下也略有差异。gate training 做的事就是扫描 gate 的起始位置，找到一个能让窗口完整覆盖 preamble 到 postamble 的位置。

判别标准通常是"能不能采到正确的数据"，但更聪明的做法是专门检测 preamble。DDR3 的读 preamble 是一个固定宽度的低电平，postamble 是一个固定宽度的高电平后回到三态。硬件训练逻辑可以在不同 gate 位置下检测这两个特征是否完整出现，从而定位脉冲群的实际边界，再把窗口放到中间。这比"试读数据看对不对"快得多，因为它不需要真的完成一次完整的读传输。

4.2 Read eye training：扫描一条延时线，取窗口中心

找到了门控位置只是第一层。门控打开后，DQ 上的数据在什么时刻最稳定？这就是 read eye training 要回答的。做法是把 DQS 的内部采样延时线逐档扫描，每档跑一轮读写、统计错误数，最后画出"延时 vs 错误数"的曲线，在零错误区间里取中点。

def read_eye_scan(lane, delay_min, delay_max, step, iterations=64): """对某个字节通道的接收延时做一维扫描，返回窗口中心""" result = [] for d in range(delay_min, delay_max + 1, step): # 写入该通道的 DQS 接收延时档位，注意可能需要触发更新才生效 write_reg(DXnDQSTR(lane), d) trigger_update(lane) # 用硬件引擎跑环回：写已知图形到某地址，再读回比较 # 相比软件逐次读写，这步由 DCU/BIST 完成，速度快一到两个数量级 err = run_loopback(lane, iterations) result.append((d, err)) good = [d for d, e in result if e == 0] if not good: return None # 无零错误区间，通路本身有问题 return (min(good) + max(good)) // 2 # 取中点，留最大裕量

扫描步长和迭代次数是两个要权衡的参数。步长太粗会漏掉窄窗口——高频下有效窗口可能只有几十皮秒，粗扫会直接跳过；步长太细，扫描时间线性增长，产线上不可接受。迭代次数决定统计显著性：只跑 8 次，误码率 1e-2 的错误可能一次都碰不到，扫出来的窗口是假的；跑到几千次，扫描时间又太长。常见做法是两级扫描：粗扫用大步长少迭代定位大致范围，细扫在小范围里用小步长多迭代确认中心。

run_loopback这一步的性能是训练总时间的大头。软件通过配置端口逐次写数据、触发读、比较，每次都要走一遍总线往返，几百个延时档位乘上几十次迭代就是几万次往返。硬件引擎把整个"写—读—比较—计数"做成状态机，软件只写一次地址、数据、循环次数、扫描范围，然后等状态寄存器报完成，速度差一到两个数量级。这是 PUBL 里DCU*那一组寄存器存在的全部理由。

4.3 Write leveling：fly-by 拓扑带来的必然代价

DDR3 引入 write leveling，原因很具体：为了信号完整性，命令/地址/时钟在板上采用 fly-by 拓扑，从控制器一路串到每颗颗粒；而数据线是点对点，从控制器直连到单颗颗粒。这两类走线的长度不一样，导致 CK 到达颗粒的时刻和 DQS 到达颗粒的时刻有一个不确定的偏斜，而且这个偏斜对每颗颗粒都不同。

写操作时，颗粒用收到的 DQS 去采样 DQ，但颗粒不知道自己的 CK 和 DQS 差多少。DDR3 的解法是让颗粒把 CK 的电平通过 DQ 反馈回来：PHY 发一个 DQS 脉冲，颗粒在这个脉冲边沿采样 CK，把结果放到 DQ 上。PHY 逐步调整自己发出的 DQS 相对 CK 的延时，直到反馈的 DQ 出现从 0 到 1 的跳变，这个跳变点就是 CK 与 DQS 对齐的位置，再往后推四分之一个周期就是采样点。

这个过程的本质是一次相位的二分搜索，每一个字节通道、每一颗颗粒都要独立做一遍。这也是为什么 write leveling 在多 rank 系统里特别耗时——rank 数乘以字节通道数，就是必须完成的训练组合数。

4.4 硬件训练引擎 vs 软件训练：DCU 与 BIST 的分工

PUBL 里存在两套看起来功能重叠的机制，实际分工很明确。

DCU*（地址、数据、运行、循环、通用配置、时序参数、状态）是一套可编程环回引擎：软件给定地址和数据，它自动完成写入、读回、比较、计数，可以循环指定次数，还能按DCUTPR配置的时序节奏跑。它的用途是数据训练和眼图扫描——需要大量重复读写、需要精确控制节奏、需要统计错误率的场景。

BIST*（运行、字数、掩码、LFSR 种子、地址、用户图形、状态、字错误、位错误、失败字记录）是一套内建自测：它可以生成伪随机图形（LFSR）或者固定用户图形，按掩码屏蔽掉不关心的位或字，在指定地址范围内跑完，然后报告字数、字错误计数、位错误位图、以及第一个失败字的位置。它的用途是产线测试和硅后验证——需要覆盖率、需要可复现的失败定位。

两套机制都用硬件跑，都不占软件带宽，但输出信息不同：DCU 报告的是"这一档延时下错了多少次"，用于画曲线；BIST 报告的是"哪些位错了、第一个错在哪"，用于定位坏点。做训练用 DCU，做筛选和失效分析用 BIST，不要拿 BIST 去扫延时曲线，也不要指望 DCU 告诉你哪一根 DQ 断了。

5. 避坑与排查：训练不收敛、校准失败、寄存器读不回

这一节记录的是几类在实际调试中反复出现、但成因完全不同的现象。它们的共同点是：表面症状相似，都在"初始化之后读写不正常"这个宽泛的描述里，但往下的定位路径完全不同。

5.1 训练窗口整体偏移或塌陷

现象：read eye training 能跑完，但扫出来的零错误区间很窄，或者中心位置明显偏离预期——比如所有字节通道的中心都落在延时线的最小端。

原因通常不在训练算法，而在参数基线。如果PTR/DTPR里的基础时序算错了，训练是在一个错误的基础上做微调，扫出来的窗口自然偏。另一个常见原因是读取延时（RL）配置与实际颗粒的 CL 不匹配：颗粒按 CL=8 返回数据，PHY 按 CL=6 去采，采样点落在数据还没到的时候，训练只能在延时线的尽头勉强找到一个假窗口。

解决：先把训练关掉，用固定延时做单次读写，确认数据在某个已知延时下能正确读回，再打开训练。如果固定延时都找不到正确点，问题在时序参数或拓扑配置；如果能找到但很勉强，问题在信号完整性。这个"先关训练"的排查顺序能省掉大量误判。

5.2 ZQ 校准反复失败

现象：PGSR里 ZQ 完成位始终不置，或者置了但状态寄存器报告校准码值落在边界（全 0 或全满）。

原因分两类。模拟侧原因是外部基准电阻没焊、阻值错、或者焊到了错误的引脚——这类问题在首板上出现频率远超预期。数字侧原因是校准发起时机不对：在 DLL 还没锁定、或者 PHY 还没退出复位时发起 ZQ，比较器没有稳定的参考，收敛自然失败。

解决：先量外部电阻的实际阻值，再确认发起顺序。还有一类隐蔽情况是校准已经成功但软件读状态寄存器的时机太早——状态位是置了，但码值字段要等几个周期才更新，读早了拿到的是上一次的值。

5.3 寄存器写进去了但行为没变

现象：写某个配置寄存器，立即读回，值是对的，但对应的功能没有变化。

原因在 3.3 节讨论过：影子寄存器还没被搬到工作寄存器，更新事件没触发。也可能是这个寄存器只在初始化阶段被采样一次，运行中再写不影响已经生效的配置。

解决：先确认这个寄存器属于"立即生效"还是"事件生效"。判断方法是在两个差异极大的值之间来回写并读回，确认写通路没问题，然后去找触发位。找不到触发位时，重新发起一次对应模块的初始化（比如 DLL 复位）通常能强制刷新。

5.4 初始化"过了"但读写仍出错

现象：所有状态位都报完成，训练也收敛，但跑长时间读写测试会偶发错误，频率随温度升高而增加。

原因是裕量不足，而不是功能错误。训练取的是窗口中心，但如果窗口本身很窄（信号完整性差、端接不匹配、参考电压偏），中心点也只是勉强可用，温度一漂就出界。这类问题不会在任何状态位里体现，因为硬件认为自己已经"训练成功"了。

解决：把训练结果读出来看窗口宽度，而不只看是否收敛。窗口宽度是信号完整性的直接度量，窄窗口意味着需要在硬件上找原因（端接、走线、电源），软件补偿只能拖延时间。

6. 设计取舍：把训练做进硬件，代价在哪

PUBL 这一代设计最核心的取舍，是把初始化、校准、训练的大量逻辑从软件搬进了硬件状态机。这个选择带来的收益很直接：训练时间从软件逐次轮询的毫秒级压到硬件引擎的微秒级，启动流程可重复、不受软件调度影响，产线测试可以用同一套机制跑。但代价同样明确，而且往往在项目后期才显现。

可观测性这一行是血泪经验。硬件训练把整个扫描过程吞进黑匣子，只吐出"成功/失败"和最终码值，中间那条"延时 vs 错误数"曲线拿不到。窗口窄不窄、曲线是单峰还是双峰、有没有异常的平台区，这些信息在定位信号完整性问题时非常关键，但硬件不给。所以实际项目里通常要保留一条软件扫描的通路，专门用于调试版本，量产版本再切回硬件引擎。

可移植性则是另一个隐性成本。训练算法写进硬件后，它的行为就固化在 RTL 里，换一代 PHY、换一个工艺、甚至换一个频率点，扫描参数都可能要重新评估，而硅片已经回来了。软件训练虽然慢，但至少能在现场改。

我的做法是把这两条路都留着：默认走硬件引擎保证启动时间，同时在固件里保留一个可切换的软件扫描模式，只在调试和失效分析时打开。这个开关在一次高温偶发错误的定位里救过场——硬件引擎报"训练成功"，软件扫描一跑，窗口只有三档宽，问题立刻从"玄学偶发"变成"端接电阻选错"。从那以后我每次拿到新的 PHY 配置，都强制先跑一遍软件扫描看窗口宽度，再切回硬件引擎跑量产流程。希望帮到你。

这份 databook 里完整的寄存器位定义、初始化状态机的时序图、以及 DCU 和 BIST 的配置字段，配合上面这几段代码对着看，能省掉不少来回翻页的功夫。

本文还有配套的精品资源，点击获取