【PalladiumZ2 使用专栏 5 -- 模拟电路是否可以仿真?】

Overview

SOC 设计中 DDR/PCIe PHY上都会有TAP，但是只有硅后才能验证 PCIE PHY 上的TAP，EMU 平台上使用的是假模型，为何不能使用真实的 RTL去验证它们呢？

1. TAP 在 PCIe PHY 上的作用

• TAP（Test Access Port） 一般指 JTAG/DFT 测试端口，在 PCIe PHY 上它可能扩展为 DFT、BIST 或厂商特有的 PHY Debug TAP。

• TAP 主要用于：

  • 观测/调试 PHY 内部信号（均衡状态、锁相状态、误码信息）。

  • 配置 PHY 内部模拟电路（如 PLL、EQ、偏置电流）。

  • 在硅后做实验室 bring-up、收发眼图测试、链路稳定性调优。

因为它主要面向 硅后调试与测试，很多时候 RTL/EMU 阶段 TAP 功能会被 Stub 掉。

2. 为什么 TAP 只有在硅后才能真正验证？

• PHY 内部含有大量模拟电路（PLL、CDR、SerDes、EQ），这些部分在 RTL 中根本无法准确建模。

• TAP 对应的寄存器/扫描链需要访问这些模拟模块的观测点（例如锁相环的锁定信号、CDR 相位、EQ tap 值）。

• 在 FPGA/EMU 平台，模拟部分是用 抽象的 Behavioral Model 或简化的 Fake Model 替代的，没有物理特性 → TAP 的值也就不可验证。

• 只有硅片出来以后，真实的 SerDes + 模拟电路 + TAP 接口 才能工作，因此 TAP 相关的 bring-up/验证只能在硅后进行。

3. 为什么 EMU 平台不能用真实的 PHY RTL？

几个关键原因：

1. RTL 保密性

   • PCIe PHY 通常是第三方 IP（如新思 Synopsys、Cadence、Rambus）。

   • 出于 IP 保护，供应商不会提供完整的 RTL，只会给一个抽象模型（加密 netlist 或黑盒）。

   • 你拿到的“PHY 模型”通常只保证接口时序和功能行为，不包含 TAP/模拟实现。

2. 性能与容量限制

   • PHY RTL 里包含 数百万门级逻辑 + 模拟建模，在 FPGA/EMU 上实现不了。

   • 就算给你 RTL，编译到 Palladium/Zebu/Protium 这种仿真器也会超资源，运行速度极慢。

   • 所以供应商只提供 轻量级的 Transaction-Level Model（TLM）或硬化黑盒。

3. 验证目标不同

   • EMU 平台主要验证的是 Controller + SoC Integration（寄存器访问、DMA、链路训练状态机、配置空间读写）。

   • PHY 的 TAP/模拟部分不是 EMU 的目标，只在硅上调试。

• PCIe PHY 的 TAP 是硅后调试接口，依赖真实模拟电路，所以只能在硅后验证。

• EMU 上使用的是假模型（Behavioral PHY Model），它只保证数字接口正确，不能替代真实 PHY。

• 真实 PHY RTL 通常不会开放，即便开放，EMU 平台也跑不动，更不可能体现 TAP 的功能。

TAP 属于 硅后 bring-up 的 Debug 特性，它依赖真实 SerDes 模拟电路，在 EMU 阶段用假模型无法验证，而真实 PHY RTL 出于 IP 保护与性能限制也不会用于 EMU。

PCIe PHY 验证阶段对照表

阶段	验证重点	能验证的内容	不能验证的内容
RTL 仿真（Pre-Silicon Simulation）	功能正确性、接口时序	PHY + Controller 的接口协议（PIPE 接口） Link Training/状态机 LTSSM 的状态转换 配置空间访问、寄存器读写 基本电源管理流程（L0s/L1/L2 Entry/Exit）	模拟电路行为（PLL 锁定、CDR、均衡算法实际收敛） 信号完整性 (SI)、眼图、误码率 TAP（Test Access Port）的硅后调试寄存器值
硬件加速 / EMU（Palladium/Zebu/FPGA Prototyping）	SoC 集成、软件驱动验证	控制器与 PHY 数字接口的集成 上电复位/配置序列（PERST、clk req/ack） 多核 SoC 内核软件对 PCIe 配置空间和 BAR 的访问 DMA、MSI/MSI-X 等功能	模拟电路相关：PLL 上电锁定、EQ 自适应调节 高速串行通道训练（实际物理 32GT/s SerDes 训练） TAP（JTAG/DFT）的模拟测试功能
硅后验证（Post-Silicon Bring-Up）	信号完整性、物理调试	真实链路训练（速率切换、信号均衡） PLL/CDR 锁定时间、抖动容忍度 眼图、BER 测试、compliance 测试 通过 TAP 或 DFT 接口读取内部调试状态 实验室条件下测试电压/温度对 PHY 的影响	无法通过仿真完全覆盖，依赖真实硅片和实验环境

SoC 设计如何保证 PCIe PHY 能正常工作（即便不能完全硅前验证）

• 供应商提供的硬化 PHY

  • PCIe PHY 一般是 IP 厂商（Synopsys、Cadence、Rambus）提供的 Hard Macro（硬核），经过硅验证和工艺库优化。

  • SoC 集成方不需要验证模拟电路，只需验证 数字接口（PIPE/PCS 层）。

• 行为模型（Behavioral Model）

  • IP 厂商会提供一个 PHY Behavioral Model，用于仿真/EMU，保证 Controller 与 PHY 在协议层交互正确。

• Spec + Integration Checklist

  • 通过 IP Vendor 提供的 Integration Guide 确认：

    • 时钟/复位时序满足要求（如 PERST、REFCLK、AUX_CLK）。

    • 电源域和电压 rail 符合要求。

    • 确保 LTSSM 训练过程中寄存器配置符合 PCIe Base Spec。

• 硅后验证计划（Post-Silicon Validation Plan）

  • 在 SoC Bring-Up 阶段，必须有实验室验证计划来确认 PHY 的物理特性。

也就是说，SoC 设计团队依赖 IP 厂商硅验证过的 PHY 硬核，只做数字接口和集成验证，物理层的可靠性由厂商保证。

为什么模拟电路部分无法在 Palladium/Zebu 上验证

(1) Palladium/Zebu 的特点

• 这是 硬件仿真/加速平台，本质上还是 数字逻辑仿真器。

• 能加速 RTL 仿真，但 只支持门级/RTL 级的数字电路。

• 时钟速度通常是几 MHz 级，不可能跑真实的 PCIe 32GT/s 链路。

(2) 模拟电路的特殊性

• PCIe PHY 的关键部分是 SerDes 模拟前端：PLL、CDR、Equalizer、TX Driver、RX Sampler。

• 这些电路是基于 晶体管级 SPICE 仿真 + 工艺库校准 的，无法用纯 RTL 或 FPGA 逻辑表示。

• 例如：

  • PLL 锁定过程依赖模拟环路带宽、电容电流、抖动输入。

  • CDR 需要高速采样触发器，基于模拟电路。

  • EQ 需要调节电流/电阻，模拟参数。

Palladium/Zebu 无法运行 SPICE/AMS（Analog Mixed-Signal）仿真，只能跑纯数字 RTL，因此不能验证模拟电路。

(3) 为什么不能放真实 PHY RTL

• 供应商不会给完整 PHY RTL（大部分是 Hard Macro）。

• 就算给了，也包含大量工艺库单元（transistor-level），EMU 平台无法综合。

• 所以只能用 Stub / Fake Model 来替代。

总结

• 仿真阶段：验证 PCIe 协议功能和 Controller-Phy 接口。

• EMU 阶段：验证 SoC 集成、软件驱动，但不能验证 PHY 模拟特性。

• 硅后阶段：验证 PHY 的 TAP、PLL、EQ、信号完整性等真实特性。

• SoC 设计保证机制：依赖厂商硬核 PHY + 集成验证 + 规范的 bring-up 测试计划。

• 模拟电路无法在 Palladium/Zebu 验证：因为它们是纯数字仿真器，不支持 SPICE/AMS，也没有真实 SerDes 电路的物理特性。