2. PolarFire器件架构与验证关注点
PolarFire 系列 FPGA 的验证工作，不能只停留在“功能对不对”的层面。它的架构由若干类特性差异很大的硬核资源拼装而成：逻辑单元（LSRAM、μSRAM、DFF）、DSP 数学块、嵌入式存储、时钟网络、SerDes 收发器以及各类硬核 IP。每一类资源的验证重点、风险区域和观测手段都不相同。理解这些差异，才能把有限的验证资源投到真正容易出问题的地方。
逻辑单元：不是简单的 LUT 堆叠
PolarFire 的逻辑单元以 4 输入 LUT 加进位链和寄存器为基础，但真正影响验证的是它的分块结构。每个逻辑块内部包含多个 LUT、专用进位逻辑和可配置寄存器，进位链在块内是连续的，跨块时需要通过专用布线资源。这意味着一个宽位加法器如果被综合工具切分到不同逻辑块，其进位路径延迟会明显增加。
验证时不能只跑功能仿真。建议在综合后网表中检查关键路径的进位链是否被切断，并用静态时序分析确认跨块进位路径的建立时间。一个实用的做法是：构造一个 32 位累加器，在布局布线后查看其进位链是否落在同一逻辑块内。如果被切分，需要调整综合约束或手动例化进位原语。风险区域集中在宽位算术、比较器和优先级编码器上，这些结构对进位链连续性最敏感。
DSP 数学块：精度与流水线是核心
PolarFire 的 DSP 块支持 18×18 乘法、预加器和 48 位累加器，可以级联形成更宽的运算。验证 DSP 时，最容易出问题的地方不是乘法本身，而是累加器的位宽截断和流水线延迟对齐。
以一个 18×18 乘法加 48 位累加为例：如果设计者期望累加结果保留全部 48 位，但配置时误选了 36 位输出模式，高位会被截断，功能仿真可能因为测试向量数值较小而无法暴露。验证时应专门构造接近满量程的输入，例如两个 18 位有符号数的最大正值相乘，再连续累加多次，观察累加器是否溢出或截断。另一个风险点是流水线级数：DSP 块内部有可配置的寄存器级，如果设计者按 0 级延迟编写控制逻辑，而实际配置为 2 级，数据与控制信号会错位。验证方法是在 DSP 输入和输出端同时打拍，用已知的脉冲序列测量实际延迟周期数，并与配置值比对。
存储器：LSRAM 与 μSRAM 的验证差异
PolarFire 提供两类嵌入式存储：LSRAM 用于大容量存储，μSRAM 用于小容量、高灵活性的场景。两者的验证重点不同。LSRAM 支持多种宽度和深度组合，验证时要覆盖所有配置模式下的读写时序，特别是宽度转换时的字节使能行为。μSRAM 则更接近分布式 RAM，常用于小 FIFO 或寄存器堆，验证重点是读写冲突和复位后的初始状态。
一个容易被忽略的风险是存储器初始化。PolarFire 的 LSRAM 支持通过配置文件初始化，但初始化数据在器件上电时加载，仿真时如果未正确加载初始化文件，仿真结果与硬件行为会不一致。验证时应确保仿真模型加载了与硬件相同的初始化数据，并在上电后首先读取已知地址，确认初始值正确。此外，存储器的纠错码（ECC）功能如果启用，需要专门注入单比特错误，验证 ECC 能否正确纠正并报告。
时钟网络：验证的隐形战场
PolarFire 的时钟网络由全局时钟、区域时钟和专用时钟资源组成。验证时钟时，功能仿真往往看不出问题，因为仿真器对时钟树的建模是理想的。真正的风险在硬件上：时钟切换时的毛刺、跨时钟域路径的亚稳态、以及时钟使能信号的时序。
验证重点应放在时钟切换和跨时钟域接口上。例如，一个设计在运行中从 100 MHz 时钟切换到 125 MHz 时钟，如果切换逻辑没有正确处理时钟稳定期，可能导致寄存器进入亚稳态。验证方法是在仿真中强制时钟切换，并在切换后检查关键状态机的状态是否合法。跨时钟域路径则需要用同步器，验证时要确认同步器级数足够，且没有组合逻辑直接跨域。风险区域包括异步 FIFO 的指针同步、复位信号的跨域释放，以及时钟使能信号的建立保持时间。
收发器与硬核 IP：协议层验证不可省略
PolarFire 的 SerDes 收发器支持多种协议，如 PCIe、SGMII、JESD204B 等。验证收发器时，物理层参数（如预加重、均衡）通常在硬件上调试，而功能验证的重点在协议层。以 SGMII 为例，验证需要覆盖链路建立、速率协商、以及数据帧的收发。一个常见的风险是收发器复位序列不正确，导致链路无法建立。验证时应严格按照手册的复位时序，在仿真中检查复位释放后收发器是否进入正常工作状态。
硬核 IP 如 PCIe 控制器、DDR 控制器，验证重点在于配置空间访问、中断处理和错误注入。以 DDR 控制器为例，验证需要覆盖不同突发长度、不同地址对齐方式下的读写，并注入 ECC 错误，确认控制器的错误报告和纠正行为。风险区域包括初始化校准序列、刷新时序，以及多端口访问时的仲裁公平性。
验证策略的取舍
面对这么多模块，验证资源不可能平均分配。一个实用的原则是：先识别设计中真正使用了哪些硬核资源，再根据资源的使用方式确定验证深度。如果设计只用了逻辑单元和少量 LSRAM，那么 DSP 和 SerDes 的验证可以简化甚至跳过；如果设计包含 PCIe 和 DDR，那么硬核 IP 的验证就必须完整覆盖配置空间、中断和错误处理。
另一个关键点是仿真与硬件的差异。PolarFire 的许多硬核行为在仿真模型中做了简化，例如时钟树的延迟、收发器的模拟特性、DDR 的校准序列。验证时不能完全依赖仿真结果，必须在硬件上做补充测试。建议在仿真阶段重点验证功能逻辑和协议交互，在硬件阶段重点验证时序、信号完整性和校准序列。两者结合，才能对 PolarFire 设计形成完整的验证覆盖。