Zynq DDR控制器PL侧过载可能性及DRAM访问最坏情况分析问询

1. CPU与AXI端口联合访问的请求挂起/丢失问题 #

• 确实可能出现请求长时间挂起的情况：Zynq7000的PS侧包含多个AXI端口（如AXI_GP、AXI_HP），当双核CPU与PL侧大量DMA同时发起高带宽DRAM访问请求时，DDR控制器的仲裁器会按预设优先级调度请求。若高优先级请求持续占满总线，低优先级请求会被长时间挂起，超出业务允许的合理范围。
• 请求丢失一般不会发生：AXI协议自带完整的响应机制（如OKAY、SLVERR等），只要硬件设计符合规范，请求不会无故丢失。但如果出现严重总线死锁（比如错误的AXI握手时序、不合理的仲裁优先级配置），可能导致请求被永久挂起，表现上类似“丢失”，但本质是死锁而非协议层面的丢失。

2. DRAM访问最坏情况的估算方法 #

• 带宽与延迟拆解法：
  • 先计算DDR理论最大带宽：根据DDR型号（如DDR3-1600），用公式带宽 = 数据总线宽度 × 时钟频率 × 2（DDR为双倍数据率）。
  • 拆解各访问源的带宽需求：CPU的指令/数据访问带宽、每个DMA的传输带宽（单DMA带宽=传输字节数/传输时间），累加所有访问源的峰值带宽。
  • 最坏场景为所有访问源同时发起峰值请求，此时每个请求的等待时间=（总请求数据量 / DDR实际可用带宽）+ 单请求基础延迟。
• Xilinx工具分析：
  • 使用Vivado的System Generator或AXI Interconnect Analyzer搭建系统模型，模拟多访问源并发场景，获取最坏情况下的访问延迟和带宽利用率。
  • 查阅Zynq7000官方数据手册，获取DDR控制器的最坏情况延迟参数（如突发访问最大等待周期），结合实际访问模式计算。
• 硬件实测验证：
  • 在PL侧搭建测试逻辑，生成可控的DMA访问流，同时让CPU运行满负载内存读写任务，用逻辑分析仪抓取AXI总线时序，统计请求的最大挂起时间。

3. PL侧使Zynq DDR控制器过载的可能性及分析方法 #

• 完全可以通过PL侧使DDR控制器过载：PL侧的AXI_HP是高带宽端口，支持多DMA并发传输，当多个DMA同时发起连续数MB级的大带宽传输请求时，极易让DDR控制器带宽饱和，甚至超出其处理能力。
• 分析方法：
  • 带宽饱和分析：计算PL侧所有DMA的总峰值带宽，与DDR控制器的理论最大带宽对比，若总峰值带宽超过理论值，必然导致过载。
  • 仲裁优先级影响分析：若PL侧DMA使用的AXI端口优先级高于CPU端口（如AXI_HP默认优先级高于AXI_GP），即使总带宽未达理论峰值，PL侧持续的高优先级请求也会挤占CPU访问资源，导致CPU侧请求延迟剧增，从系统层面属于“过载”。
  • 时序与握手分析：用逻辑分析仪抓取PL侧AXI总线与DDR控制器的交互时序，若出现WAIT信号持续拉高、请求队列溢出等情况，即为过载的典型表现。
  • 系统性能监控：在PS侧读取Zynq内置的性能监控寄存器（如DDR控制器的带宽利用率、请求等待周期寄存器），实时监控PL侧传输时的DDR负载，判断是否过载。

内容的提问来源于stack exchange，提问作者Lucas