AXI-A5.7.2 QoS acceptance indicators

 QoS 接受指示机制,不仅仅是简单的优先级排序,而是一种主动的、双向的通信机制,用于在系统资源紧张时做出最优决策。A5.12 所示的 QoS 接受指标是来自slave接口的输出信号,指示其将立即接受的最小 QoS 值

AXI-A5.7.2 QoS acceptance indicators

1. 举例说明什么是接受指示器?

让我们通过一个具体的“交通管理”场景来理解这个机制。

场景:一个繁忙的 DDR 内存控制器(作为从设备)连接着多个主设备:

CPU:处理用户交互和系统任务(产生高、中、低优先级混合流量)

GPU:渲染游戏画面(产生高带宽、中高优先级流量)

DMA控制器:执行后台数据备份(产生大量低优先级流量)

内存控制器内部有多个命令队列来处理不同优先级的请求,但队列深度是有限的。

没有 QoS 接受指示器时的问题

行为:所有主设备都“盲目地”向内存控制器发送请求。

问题场景

GPU 开始渲染复杂场景,其大量中优先级请求填满了内存控制器的中优先级和低优先级队列

此时,DMA 控制器发起一个低优先级的大数据块传输请求。这个请求被接收,但因为前方队列已满,它被阻塞在接口上,无法立即得到处理。

紧接着,用户点击了屏幕,CPU 需要立即处理这个中断,发起一个高优先级的紧急请求

然而,CPU 的请求同样被阻塞了,因为它前面有那个低优先级的 DMA 请求在等待!

后果:发生了 优先级倒置——高优先级任务被迫等待低优先级任务,导致系统响应迟钝,用户体验受损。总线接口被低价值流量阻塞,无法服务高价值流量。

使用 QoS 接受指示器的工作流程

行为:内存控制器通过 
VAWQOSACCEPT
 和 
VARQOSACCEPT
 信号,实时“广播”它当前的服务状态:“我现在只愿意立即接受 QoS 值 ≥ X 的请求”。

智能的工作流程

初始状态:内存控制器空闲,
VAWQOSACCEPT = 0
。这意味着它愿意接受任何优先级的请求。

负载升高:GPU 开始全力渲染,填满了中、低优先级的处理队列。内存控制器将 
VAWQOSACCEPT
 信号的值提高到 8。这相当于宣布:“现在只服务‘高级会员’(QoS≥8),普通会员请稍后。”

主设备的智能决策

DMA 控制器(QoS=2)看到 
VAWQOSACCEPT=8
,知道自己的请求(2 < 8)目前不会被接受。于是,它根本不发起这个请求,而是等待或尝试其他操作。

关键点:DMA 控制器没有阻塞内存控制器的接口,通道保持畅通。

高优先级事务到达:用户点击屏幕,CPU(QoS=15)发起紧急请求。它看到 
VAWQOSACCEPT=8
,发现自己的优先级(15 >= 8)足够高,于是正常发出请求。

结果:内存控制器立即接受了 CPU 的高优先级请求并开始处理。系统的响应性得到了保障。

负载下降:GPU 的渲染峰值过去,内存控制器队列逐渐清空,于是它将 
VAWQOSACCEPT
 值逐步降低,最终回到 0,重新开始接受低优先级请求。

这样分类的原因

引入这种复杂的反馈机制,是为了解决开放式循环优先级系统的一个根本性缺陷:在资源饱和时,静态优先级仲裁会失效。

防止接口阻塞,保障实时性

这是最核心的原因。通过让低优先级事务“知难而退”,确保了高优先级事务的通道始终是畅通的。这对于有严格截止时间(Deadline)的实时任务至关重要。

提升系统整体吞吐量与效率

避免了将宝贵的总线带宽和时钟周期浪费在最终会被长时间停滞的事务上。系统资源可以更集中地用于处理那些当前真正能够被服务的请求,从而提高了有效吞吐量。

实现真正的系统级协作与智能

它将主设备和从设备从简单的“命令-执行”关系,提升为一种“协作”关系。从设备主动报告自身状态,主设备智能地调整行为。这代表了更高级的、分布式的系统设计理念。

规则的诞生背景

QoS 接受指示器的诞生,是系统设计者在应对 “最坏情况执行时间” 和 “资源竞争” 这一经典难题时,从被动应对到主动管理的演进。

实时系统与功能安全的硬性要求

背景:在汽车电子(如刹车控制、引擎管理)或工业控制中,一个关键的控制信号必须在几微秒内得到处理。任何不确定性都是不可接受的。

传统解决方案的不足:传统的优先级仲裁只能保证一个请求在仲裁器中获胜,但不能保证它在忙碌的从设备(如内存控制器)中不被前面堆积的低优先级请求阻塞。

创新:QoS 接受指示器提供了从前端(主设备)预防阻塞的能力,使得计算和保证最坏情况延迟成为可能,这对于通过 ISO 26262 等功能安全认证至关重要。

高性能计算中“内存墙”的优化

背景:在服务器CPU和多核SoC中,内存带宽是最大的瓶颈。如何让宝贵的内存带宽被最需要的任务使用,是提升整体性能的关键。

观察:研究发现,当内存控制器内部队列过满时,管理开销会急剧上升,反而降低效率。同时,低优先率的后台流量(如数据备份、缓存预取)会挤占关键工作负载的资源。

解决方案:通过QoS接受信号,内存控制器可以在自身负载过高时,主动“流控”低优先级的后台流量,将带宽保留给关键的前台应用,从而在高压下保持更高的有效带宽。

对“活锁”与“饿死”问题的防范

背景:在极端情况下,如果高优先级任务持续不断,低优先级任务可能永远得不到执行,称为“饿死”。但更糟糕的是“活锁”,即大量低优先级任务占满了所有队列,导致系统虽然忙碌但没有任何实质进展,高优先级任务也无法切入。

解决方案:QoS接受机制通过暂时拒绝低优先级任务,实际上为系统创造了一个“喘息”和“重置”的机会。这允许资源管理软件(如操作系统或固件)监测到这种情况,并采取更高级的全局调度策略,而不是让硬件在泥潭中挣扎。

QoS 接受指示器是 AXI 协议中一项面向未来的高级特性。它超越了静态的优先级仲裁,引入了一种动态的、基于反馈的、预防性的系统性能与实时性保障机制。它承认了一个关键的现实:在复杂系统中,知道“何时不发送”请求,与知道“如何发送”请求同等重要。这套机制使得构建能够满足最严苛的实时性要求、同时在高负载下保持高效能的高可靠性SoC成为了可能。它是协议从“被动响应”到“主动管理”演进中的重要里程碑。

2.VAxQOSACCEPT使用建议

术语 VAxQOSACCEPT 统称 VAWQOSACCEPT 和 VARQOSACCEPT 信号。 VAxQOSACCEPT信号的规则和建议如下:

        • 下级将接受QoS 级别等于或高于VAxQOSACCEPT 的任何请求。

        • QoS 级别低于 VAxQOSACCEPT 的任何请求都可能会停滞相当长一段时间。 规范并未定义下级服务器必须在指定时间段内接受达到或超过指定 QoS 级别的请求。但是 ,考虑到时钟域交叉率等实现因素,预计对于给定的下级服务器,接受事务所需的最大时钟周期数将确定。

        • 允许下属接口接受低于 VAxQOSACCEPT 信号指示的 QoS 级别的请求,但预计该请求可能会受到相当大的延迟。

         • 虽然下属可以延迟优先级低于 QoS 接受级别的请求,但建议不要无限期地延迟此类事务。

继续使用“智能交通管理”的比喻,对上面的四条规则进行详细解读。

场景:同一个 DDR 内存控制器,通过 
VAWQOSACCEPT
 信号来管理其写入通道的负载。

规则一:明确的接受阈值

规则:“任何 QoS 级别等于或高于 VAxQOSACCEPT 的请求都会被从设备接受。”

举例

内存控制器当前设置 
VAWQOSACCEPT = 8

CPU 发起一个 QoS=10 的请求 → 被立即接受(10 >= 8)。

GPU 发起一个 QoS=8 的请求 → 被立即接受(8 == 8)。

DMA 发起一个 QoS=2 的请求 → 可能被长时间停滞(2 < 8)。

工作方式:这就像高速公路在高峰期只允许客车及以上车辆(QoS≥8) 驶入,而货车(QoS<8) 被要求在服务区等待。

规则二:非确定性但有限的接受时间

规则:“本规范未定义从设备必须在多长时间内接受达到或超过指示QoS级别的请求。但期望对于一个给定的从设备,在考虑时钟域交叉比率等实现因素后,存在一个确定性的最大接受时钟周期数。”

举例

虽然协议不强制要求内存控制器在 10 个周期内接受一个 QoS=15 的请求,但它的设计应该是可预测的

系统架构师在设计时知道,该内存控制器在最坏情况下,会在 50 个时钟周期内 保证接受一个高优先级请求。这个“50周期”就是一个确定性的最大值

这个确定性对于计算最坏情况执行时间 至关重要,尤其是在汽车和航空电子等实时系统中。

规则三:允许接受但警告延迟

规则:“允许从设备接口接受低于 VAxQOSACCEPT 信号指示的 QoS 级别的请求,但预期该请求可能会受到显著延迟。”

举例

内存控制器设置 
VAWQOSACCEPT = 8
,但此时恰好有一个空闲的处理槽位。

一个 QoS=2 的 DMA 请求到达,内存控制器可以选择接受它

但是,就在它接受这个请求后,突然涌入了多个 QoS=15 的 CPU 请求。这个已经被接受的 QoS=2 的请求必须等待所有这些高优先级请求完成,因此经历了“显著延迟”。

这个规则给了从设备灵活性,让它可以在资源空闲时做好事(处理低优先级任务),但同时管理了低优先级请求的预期(告诉你可能会很慢)。

规则四:禁止无限期停滞

规则:“虽然从设备停滞一个优先级低于QoS接受水平的请求是可接受的,但建议此类事务不会无限期延迟。”

举例

如果内存控制器一直设置 
VAWQOSACCEPT=15
,并且持续有高优先级请求,那么所有 QoS<15 的请求将永远无法前进。

这被称为 “饿死”

因此,协议建议从设备需要实现某种机制来防止这种情况。例如,内存控制器可以:

周期性降低阈值:每 1000 个周期,临时将 
VAWQOSACCEPT
 降为 0,清空积压的低优先级请求。

老化机制:将一个被停滞了很长时间的低优先级请求,临时提升其内部优先级,以防它被永远遗忘。

表 A5.13 所示的 QoS_Accept 属性用于定义接口是否包含 QoS 接受指示信号。

AXI-A5.7.2 QoS acceptance indicators

 这样分类的原因

这些细致入微的规则,旨在平衡 效率确定性 和 公平性 这三个常常相互冲突的目标。

在灵活性中注入可预测性

规则二(确定性最大延迟)是功能安全系统的生命线。它确保了即使在高负载下,系统行为仍然是可分析、可认证的。没有这一条,QoS机制对于硬实时系统就是无用的。

防止最坏情况发生

规则四(禁止无限期停滞)是一个安全网。它承认了纯粹基于优先级的调度可能存在缺陷,并要求设计者考虑系统的长期健康,避免出现部分任务完全无法执行的病理状态。

提供实现自由度

规则三(允许接受低优先级请求)和规则二的非强制性,给了硬件实现者优化的空间。一个设计精良的从设备可以在不违反协议精神的前提下,智能地利用空闲资源,提升整体吞吐量。

 规则的诞生背景

这些规则的诞生,是工业界在将理论上的 QoS 概念应用于严酷的现实世界过程中,经验教训的结晶。

功能安全标准认证的硬性要求

背景:诸如 ISO 26262(汽车)和 DO-254(航空)等标准要求对系统的最坏情况性能进行严格的分析和证明。

挑战:早期的 QoS 方案只关注平均性能提升,但其行为在极端情况下是不可预测的,无法通过认证。

解决方案:规则二应运而生,它虽然没有规定具体时间,但强制要求了确定性边界的存在,使得最坏情况分析成为可能。

数据中心和云计算的教训

背景:在云服务器中,低优先率的后台任务(如数据备份、虚拟机迁移)如果被长期“饿死”,可能导致服务等级协议违约或系统状态不一致。

问题:纯粹的优先级调度会导致“不重要的任务永远没有机会运行”。

解决方案:规则四的建议促使硬件设计者从计算机操作系统的调度算法中汲取灵感(如引入“老化”概念),确保所有任务最终都能有所进展,从而维持系统的整体健康和可用性。

对“实现多样性”的包容

背景:不同的应用场景对从设备的要求截然不同。一个面向消费电子的内存控制器和一个面向网络处理器的内存控制器,其优化目标不同。

解决方案:协议通过使用“期望”、“建议”、“允许”等词语,而非“必须”,创建了一个灵活的框架。这使得简单的设计可以快速实现,而复杂的设计可以充分发挥其优化潜力,所有实现都能在同一个协议下互操作。

总结:关于 
VAxQOSACCEPT
 信号的这些规则,将 AXI QoS 从一个简单的“优先级排序器”提升为一个成熟的、工业级的、适用于关键任务系统的服务质量控制框架。它不仅在正常情况下提升性能,更在压力情况下保障了系统的可预测性稳定性公平性。这套规则体现了协议设计者的深远考量:他们不仅定义了硬件应该如何工作,更定义了系统应如何优雅地应对过载和竞争,这是构建下一代可靠计算平台的基石。

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
none
暂无评论...