使用Synopsys智能监视器提高Arm SoC的系统性能

在使用 AXI 总线移动大量数据的 SoC 中，AXI 总线的性能可能会成为整体系统性能的瓶颈。SoC 中日益增加的复杂性和软件内容，因此需要使用实际数据有效载荷在硅前进行左移性能验证。硬件辅助验证平台 - Synopsys ZeBu®仿真系统和Synopsys HAPS® FPGA原型系统 - 是运行如此大的有效载荷的必要条件。

如何提高 AXI 总线的吞吐量

如果使用 AXI 总线进行频繁的批量数据传输，则实现良好的吞吐量非常重要。吞吐量可以通过计算观察窗口期间在AXI接口上捕获的每个节拍（RVALID/BVALID）中所有数据字节（AxSIZE）的总和，然后将总和除以观察窗口的持续时间来计算。显示低吞吐量的窗口通常并不意味着问题，除非期望快速移动大量数据。吞吐量降低的几个原因可能是：

经理行为：理想情况下，经理应该在同一周期断言 AWVALID 和 WVALID。此外，管理器应该能够通过在连续周期上保持 WVALID 高电平来驱动多个节拍。如果不是这种情况，则管理器将限制写入事务的吞吐量。

有效/就绪握手：如果 xREADY 在经理和下属端始终处于高电平，则可以实现最佳性能。但是，当内部管道已满时，现实世界的 DUT 最终必须取消断言 xREADY。因此，理想情况下，经理/下属应将未完成的交易保持在 DUT 流水线限制内，以确保不会停滞不前。

请求到响应延迟：从属可能需要几个周期来响应写入/读取请求。当响应在下一个周期到从属对请求进行采样时，将达到峰值性能。但是，复杂的互连路由和内存访问通常需要几个周期才能驱动响应。

如何提升AXI总线的事务性能？

Arm AMBA 3 AXI 和 Arm AMBA 4 AXI 互连支持未完成事务，没有任何限制，甚至允许使用同一 ID 进行多个未完成事务。ID（或其中的几位）通常用于将响应从属路由到具有唯一 ID 的正确经理。如果经理可以发出多个未完成的交易，则只有在下属也支持的情况下才应这样做，否则它将简单地取消断言 xREADY 信号并导致停滞。即使从属支持未完成的事务，也只能在其内部管道未满的情况下执行此操作。因此，如果管理器发出等于或小于次级管道深度的未完成事务，则可以获得最佳性能，这允许互连处理多个事务而无需任何序列化。

图 2：Synopsys 平台架构师中显示的每个观察窗口的未完成事务计数

图 4：读取 Synopsys 平台架构师中显示的事务计数/吞吐量

用于 Arm AMBA AXI 接口的智能监视器允许用户测量 AXI 总线性能，以便在实际硅流片之前优化设计以获得所需的性能。为了进一步调试到窗口中，需要分析 AXI 流量以跟踪导致性能下降的事务。最后，需要检查设计是否存在可能导致交易中观察到偏差的原因。

适用于 Synopsys ZeBu EP1 的智能监视器如何帮助分析 AXI 总线性能

用于 Arm AMBA AXI 接口的智能监视器是基于 DPI 的事务处理器，但它们是仅用于捕获总线流量的无源组件。监视器可以处理协议数据以进行功能验证或性能分析。对于性能分析，显示器支持 3 种模式。

基于 Python 的批处理可视化

面向验证工程师的基于 Synopsys Verdi® 性能分析仪的性能可视化

Synopsys 平台架构师™为软件工程师提供基于虚拟原型解决方案的性能可视化

这些模式中的任何一种都可以根据需要用于分析 AXI 总线性能。

智能监视器提供生成以下性能指标的功能：

读/写数据字节计数

读/写数据吞吐量

读/写请求计数

读/写已完成事务计数

读/写未完成事务

请求 （AW/AR） 到响应 （B/R） 延迟

Synopsys ZeBu EP1 仿真和原型系统支持在 SoC 上运行实时软件有效负载。智能监视器架构允许用户以与不使用监视器几乎相同的运行时性能生成性能测量数据。此外，监视器可以动态配置为在用户希望查看功能调试的事务详细信息的情况下转储详细的事务数据。

审核编辑：郭婷