ZYNQ上玩AURORA 8B/10B，一个高速BANK不够用？手把手教你合并GTPE2_COMMON资源

ZYNQ-7000多AURORA IP核设计实战：QPLL资源共享与GTPE2_COMMON优化策略

在ZYNQ-7000系列FPGA开发中，当我们需要实现多个高速串行通信接口时，经常会遇到一个棘手的资源瓶颈——单个高速BANK的GTPE2_COMMON资源无法满足多个AURORA IP核的需求。这个问题在XC7Z015这类仅配备单个高速BANK的器件上尤为突出。本文将深入剖析这一问题的根源，并提供一套完整的工程解决方案，而不仅仅是简单地更换更大规模的FPGA。

1. 问题诊断与资源分析

当我们在Vivado中尝试为两个AURORA 8B/10B IP核生成比特流时，经常会遇到这样的错误提示：

[Place 30-640] Place Check: This design requires more GTPE2_COMMON cells than are available in the target device. This design requires 2 of such cell types but only 1 compatible site is available in the target device.

这个错误的核心在于GTPE2_COMMON资源的争用。要理解这个问题，我们需要先了解ZYNQ-7000系列的高速串行接口架构：

• Quad结构：每个高速BANK(Quad)包含4个收发器通道(Channel)和1个GTPE2_COMMON模块
• 时钟资源：每个Quad包含1个QPLL(Quad PLL)和4个CPLL(Channel PLL)
• 速率限制：
  • CPLL支持速率：1.6GHz~3.3GHz
  • QPLL支持速率：
    • Lower Baud：5.93GHz~8.0GHz
    • Upper Baud：9.8GHz~12.5GHz

当我们的AURORA IP核配置为6.25Gbps线速率时，CPLL无法满足要求，必须使用QPLL。这就是问题的关键所在——在单高速BANK器件上，我们只有一个QPLL资源，却需要支持多个AURORA IP核。

2. 解决方案对比与选择

面对这一资源限制，工程师通常有以下几种选择：

对于大多数实际项目，QPLL资源共享是最具实用价值的解决方案。这种方法不需要更换硬件，也不降低性能指标，只需要对Xilinx提供的Example Design进行适当修改。

3. QPLL资源共享实现步骤

3.1 工程准备与问题定位

首先，我们需要创建基本的AURORA IP核设计环境：

1. 在Vivado中创建工程，选择正确的器件型号(XC7Z015)
2. 添加两个AURORA 8B/10B IP核，配置如下：
   • 线速率：6.25Gbps
   • Shared Logic：Include Shared Logic in Example Design
3. 为每个IP核生成Example Design
4. 将两个Example Design集成到顶层模块

此时尝试生成比特流，就会遇到前述的GTPE2_COMMON资源冲突错误。

3.2 关键问题分析

查看Example Design的目录结构，我们会发现每个AURORA IP核都包含以下关键模块：

aurora_8b10b_X/ ├── aurora_8b10b_X.v ├── aurora_8b10b_X_support.v ├── aurora_8b10b_X_gt_common_wrapper.v <-- 包含GTPE2_COMMON实例 └── aurora_8b10b_X_gt_wrapper.v

问题就出在gt_common_wrapper模块上——每个IP核都实例化了一个独立的GTPE2_COMMON，但在单高速BANK器件上，我们只能有一个GTPE2_COMMON物理资源。

3.3 具体修改步骤

以下是详细的资源共享实现步骤：

1. 识别主从IP核：

   • 选择一个IP核作为"主"(保留GTPE2_COMMON)
   • 另一个IP核作为"从"(移除GTPE2_COMMON)

2. 修改从IP核的支持文件：

   • 打开aurora_8b10b_1_support.v
   • 注释掉gt_common_wrapper的实例化
   • 添加主IP核的QPLL时钟输入端口

3. 修改顶层连接：

   // 原连接方式 aurora_8b10b_0 u_aurora_0 (...); aurora_8b10b_1 u_aurora_1 (...); // 修改后连接方式 aurora_8b10b_0 u_aurora_0 ( ... .gt_qpllclk_quad1_out(gt_qpllclk), // 新增输出 .gt_qpllrefclk_quad1_out(gt_qpllrefclk) ); aurora_8b10b_1 u_aurora_1 ( ... .gt_qpllclk_quad1_in(gt_qpllclk), // 新增输入 .gt_qpllrefclk_quad1_in(gt_qpllrefclk) );

4. 时钟约束调整：

   • 确保两个IP核使用相同的参考时钟
   • 添加适当的时钟约束，保证时序收敛

注意：修改后的设计需要重新验证时钟域交叉和时序约束，确保资源共享不会引入新的时序问题。

4. 工程验证与性能测试

完成上述修改后，我们需要进行全面的验证：

1. 编译验证：

   • 检查是否能成功生成比特流
   • 验证资源利用率报告中GTPE2_COMMON的使用数量

2. 功能测试：

   # 示例测试脚本 launch_hw program_fpga -bitfile design.bit reset_aurora_cores start_traffic_generation monitor_link_status

3. 性能指标对比：

从测试结果可以看出，共享QPLL方案在保持性能基本不变的情况下，成功解决了资源冲突问题，还带来了一定的功耗优化。

5. 进阶优化技巧

对于需要更高可靠性的设计，可以考虑以下优化措施：

1. 时钟质量提升：

   • 使用更低抖动的参考时钟源
   • 优化PCB布局，减少时钟路径噪声

2. 动态重配置：

   // 示例：动态调整QPLL参数 always @(posedge reconfig_clk) begin if (rate_change_req) begin gt_common_wrapper_inst.GTPE2_COMMON_inst.DRP_EN <= 1'b1; gt_common_wrapper_inst.GTPE2_COMMON_inst.DRP_ADDR <= 8'h28; gt_common_wrapper_inst.GTPE2_COMMON_inst.DRP_DI <= 16'h0100; end end

3. 故障恢复机制：

   • 监控QPLL锁定状态
   • 实现自动重初始化流程

6. 替代方案评估

虽然QPLL资源共享是解决此类问题的主流方案，但在某些特殊场景下，其他方法可能更合适：

1. CPLL替代方案：

   • 当线速率≤3.3Gbps时，可考虑使用CPLL
   • 需要修改AURORA IP核配置：

     set_property CONFIG.CPLL_USED true [get_ips aurora_8b10b_0] set_property CONFIG.QPLL_USED false [get_ips aurora_8b10b_0]

2. 时分复用设计：

   • 单个AURORA IP核分时处理多路数据
   • 需要复杂的调度算法

3. 协议层优化：

   • 采用更高效率的编码方案
   • 减少协议开销，提高有效载荷率

在实际项目中，我们往往需要根据具体需求权衡各种方案的利弊，选择最适合当前约束条件的解决方案。