4 Revision B、XL 及 XXL 版本的 IP 核
4.1 概述
到目前为止，本文档主要涉及自 2010 年起可用的基准版本 IP 核（Revision A）。Revision B 和 XL 于 2015 年推出，以适应 Xillybus 用户的数据带宽需求。这些核正逐步取代 Revision A。
Revision XXL 于 2019 年推出。
新版本（B、XL 和 XXL）提供的功能集是 Revision A 的超集，但在使用相同属性定义时功能等效（可能有一些性能改 进）。
最显著的区别如下：
-
更高的数据带宽：对于任何 FPGA，Revision B、XL 和 XXL 版本的 IP 核的聚合带宽分别约为 Revision A 的两倍、四倍和八 倍。
关于如何达到 Xillybus IP 核的带宽能力，请参考 在 Linux 主机上入门 Xillybus 或 在 Windows 主机上入门 Xillybus 的第 5 节。
-
用户接口的数据宽度除了原有的 8 位、16 位和 32 位选项外，还允许 64 位、128 位和 256 位。无论 Xillybus IP 核与所使用 的 PCIe 模块之间的数据路径宽度如何，这些宽度都是允许的。
-
逻辑设计速度更快（更易于满足时序约束），最慢时序路径上的延迟减少约 1 ns。
-
在大多数常见情况下，逻辑资源消耗更低（参见第 4.4 节）。
-
无论 IP 核与应用逻辑之间信号的数据宽度如何，PCIe 模块的带宽都能得到有效利用。这与 Revision A 中 8 位和 16 位字宽 的流效率较低的情况相反。
-
在 AMD 平台上，Revision B、XL 和 XXL 仅适用于 Vivado。
4.2 使用 Revision B/XL/XXL 版本
Revision B/XL/XXL 版本的 IP 核是通过在 IP Core Factory 中复制 Revision A 版本的 IP 核来创建的。
具体操作是点击“replicate as revision B / XL / XXL core”，如下面的 IP Core Factory 截图所示：
无法降级回 Revision A。
只有那些已请求访问这些高级 IP 核的用户才能升级到 B/XL/XXL。此类请求可以通过网站上公布的联系信息发送一封普通电 子邮件来提交。
获得此访问权限没有特殊要求；发出请求的目的仅仅是为了与高端用户保持更紧密的联系。
Revision B 版本的 IP 核是 Revision A 的直接替换。因此，应使用目标 FPGA 的基准 demo bundle 作为起点。由于该 demo bundle 附带 的是 Revision A 版本的 IP 核，希望使用 Revision B 的用户应通过 IP Core Factory 配置并下载它。
另一方面，Revision XL 和 XXL 则需要专用的 demo bundle 才能使用。这些 demo bundle 应通过电子邮件请求获取。
4.3 数据字宽度
虽然 Revision A 版本的 IP 核只允许 8、16 和 32 位的应用数据宽度，但 Revision B/XL/XXL 还允许 64、128 和 256 位宽的 接口。主要动机是使得单个流能够利用全带宽容量。
尽管如此，也可以使用多个流（可能是 8、16 或 32 位宽）来分割带宽，从而使聚合带宽利用全部带宽能力（可能有 5–10% 的性能下降）。
应根据应用逻辑的自然需求来选择数据宽度。
无论更宽的接口是否有助于提高带宽能力，它们都是允许的。例如，Revision B 版本的 IP 核允许 256 位字宽，即使 64 位就 足以利用该 IP 核的带宽。这些数据宽度与 PCIe 模块的接口信号无关。
当使用超过 32 位的字宽时，需要注意：由于 PCIe 总线的自然数据单元是 32 位字，驱动程序中防止流误用的某些保护措施 在数据宽度超过 32 位时将不再适用。例如，对于字宽为 64 位的流，任何 read() 或 write() 函数调用的长度必须是 8 的倍数。同样，在 64 位 宽的流上执行 seek 操作所请求的位置必须是 8 的倍数才能获得有意义的结果。但软件只会强制要求长度是 4 的倍数。
总之，当数据宽度超过 32 位时，应用软件负有更大的责任来确保 I/O 操作与字宽度对齐。字对齐的规则对于所有字宽都是相 同的，但与字宽为 32 位和 16 位的流不同，驱动程序不一定会强制实施这些规则。
4.4 逻辑资源消耗
Revision B/XL/XXL 版本的 IP 核针对速度进行了优化，逻辑资源消耗略低，但代价是随着流数量的增加，逻辑资源消耗的增长略为陡 峭。
为了量化逻辑资源的使用情况，我们生成了针对 Kintex-7、流数量逐渐增加的核。这些核经过综合，并统计了逻辑单元数 量。与第 3.3 节类似，基准测试中上行流和下行 流各占 50%。
以下三张图表显示了逻辑资源消耗，比较了具有相同设置的 Revision A、B 和 XL 版本的 IP 核。所有测试流的字宽均为 32 位。
比较寄存器和 LUT 的数量时，Revision B 在流数量较少时优于 Revision A，但随着流数量的增加，这一优势会丧失。
Revision XL 和 XXL 在所有场景下都比其他两个版本消耗更多逻辑。
块 RAM 的图表显示，与 Revision A 相比，Revision B 和 XL 都消耗了两倍的块 RAM。
建议的结论是：几乎在所有情况下都应优先选择 Revision B 而非 Revision A。即使逻辑消耗显示相反，Revision B 改进的时 序也足以抵消这一差异。在大多数实际场景中，IP 核的逻辑消耗与 FPGA 的容量相比可以忽略不计，因此这一点成立。
另一方面，Revision XL 和 XXL 应仅用于需要其带宽能力的应用，因为它们消耗更多逻辑，并且在时序约束方面也更加困 难。
4.5 优化从主机到 FPGA 的流以获得最佳带 宽
由于 Revision B、XL 和 XXL 版本的 IP 核允许更高的数据速率，它们对 PCIe 模块参数的适当调整越来越敏感。
demo bundle 中的 PCIe 模块已设置为最佳性能。然而，如果 PCIe 总线（属于主机硬件的一部分）以比正常更长的延迟转发数据包，则 可能需要进行轻微调整。
在 AMD 的 FPGA 中，这仅适用于在 Kintex-7 或 Virtex-7 上使用、PCIe 模块限于 Gen2 的 Revision B 或 XL 版本的 IP 核。Revision A 无法达到能使任何改进被注意到的数据速率。
在这个有限的案例集中，可能需要调整 PCIe 模块的参数，以在从主机到 FPGA 的流上实现预期的带宽。
可能需要这样做，因为主机到 FPGA 方向的数据流是通过 FPGA 发出的 DMA 传输请求来驱动的。主机通过发送数据来满足 这些请求。请求与满足请求的数据传输（完成）之间的延迟取决于主机对此类请求的响应能力，并且因 PCIe 总线而异。
为了有效利用 PCIe 总线提供的带宽，FPGA 会并行发出多个 DMA 请求，从而确保主机始终有请求需要处理。然而，PCIe 协议的流控制机制对活动请求的数量施加了限制。由流控制机制分配的有限资源称为 完成信用（completion credits），并在 PCIe 端点处进行配置。一般来说，更多的完成信用意味着允许更大数量的活动请求，同时 FPGA 实现 PCIe 模块也需要更多资源。
主机到 FPGA 方向受信用分配的影响要小得多（如果有的话），因为 FPGA 会在 DMA 请求的同时发送数据。因此，通过修 改信用设置来获得改进的可能性很小，因为信用对 FPGA 到主机方向几乎没有影响。
demo bundle 中的 PCIe 模块已配置为在基于 x86 架构处理器的常见台式计算机上实现最佳带宽利用率。尽管非常罕见，但可能需要更改 配置以在主机到 FPGA 方向上达到宣传的带宽。
可以通过增加完成信用（包括标头和数据）的数量来获得改进。在 Vivado 或 Quartus 中，通过调用 PCIe 模块 IP 的配置并 修改其参数来完成。例如，对于在 Vivado 中配置的 Kintex-7，可以通过选择“Core Capabilities”选项卡并设置“BRAM Configuration Options”来完成。“Perf level”已设置为最高，因此在这方面没有改进空间。然而，启用“Buffering Optimized for Bus Mastering Application”会 增加完成信用，但会以牺牲其他类型的信用为代价。这可能会提高主机到 FPGA 方向的带宽性能，而不会对相反方向产生不利影响。