本节描述CHI额外支持的若干feather:
1. QOS机制
QOS机制在AMBA的后续协议中基本属于保留项目,都会增加这个feature来平衡带宽和延迟等内容;系统可以利用QoS方案来实现:
• 保证特定stream中事务的最大延迟。
• 请求流的最小带宽保证。
• 提供给特定流请求的带宽和延迟的最佳effort值
• Qos值越大,优先级越高
• 当一个事务以特定的QoS值发送时,允许以不同的QoS值(通常更高)再次发送相同的事务。需要Completer将这种情况作为多个不同的请求来处理。在这种情况下,如果其中一个事务接收到RetryAck响应,则允许它取消事务并返回信用
2. Data Source ID
新增的一个feature,就是允许读取请求的完成人来指定数据的来源,目前是5bit数,bit[3:0]表示数据来源的位置,比如哪一级cache等信息,bit[4]表示是当前的chip还是remote chip的数据信息等。
不是必须的feather,和设计相关;
3. SLC Replace hint
新增的特性,主要目的是将缓存替换的信息,从请求方传递到下游互连的缓存中,在chi中采用一个7位字段来支持对应的信息, spec 11-3表描述了该处行为。
4. RME
4.1 简介
RME是Arm机密计算机体系结构(CCA)的一个组成部分。与Arm CCA的其他组件一起,RME支持在Arm PE上运行动态、可验证和可信的执行环境(也称为Realms)。RME提供基于硬件的隔离,允许执行上下文在不同的安全状态下运行,并共享系统中的资源。
4.2 Physical Address Space, PAS
RME定义了四种物理地址: secure/non-secure/Root/Realm
在CHI-F之前,只定义了安全和非安全物理地址空间;
MPAMSP | Partition Description |
---|---|
00 | Secure |
01 | Non-secure |
10 | Root |
11 | Realm |
4.3 Cache Maintenance
a. Cache Maintenance Operations
CleanInvalidPoPA
WriteBackFullCleanInvPoPA;
WriteNoSnpFullCleanInvPoPA;
WriteNoSnpPtlCleanInvPoPA;
新增了4个额外的缓存维护操作为物理地址空间之间的内存颗粒的动态转换提供了支持;
为了支持新的缓存维护操作,在系统中定义了一个点,物理混叠点(PoPA)。
在PoPA点上,对一个PAS中某个位置的更新对所有其他物理地址都是可见的空间。
可能需要对多个PAS进行缓存维护操作,以确保之前写入的任何数据对预期的物理地址空间完全可见。
b. Remote Invalidation
RME需要能够使映射为远程非共享可缓存的内存失效。
远程使内存失效的能力消除了依赖于可能将内存映射为非共享可缓存的每个PE上的缓存维护的需要
4.4 对DVM影响
定义了额外的DVM操作和字段来支持:
a. 在RME使能时,会增加PA的位宽;
b. The invalidation of Realm Protection Unit entries
4.5 对MPAM影响
MPAM为每个PAS定义了独立的PartID空间,用2位MPAM Space (MPAMSP)属性进行编码
5. Compeleter Busy
chi中用来指示处理事务的compeleter的当前活动水平的机制。该信息可以向请求程序提供额外的信息,说明它在生成投机活动以提高性能方面的积极程度。
CBusy - completer busy。一个适用于适当的DAT和RSP包的3位字段。当对单个读请求使用单独的Data和Comp响应时,可以独立设置每个响应中的Busy指示。
但以下transaction不适用该信息:
• NCBWrData / • NCBWrDataCompAck / • CBWrData / • WriteDataCancel / • CompAck
5.1 Usage Case:
1. 给一个例子:
Cbusy[2]: 1 : 表明多个核心正在主动发出请求
Cbusy[1:0]: 表示在completer上的fullness<满的程度>为:
00 - less than 50% full
01 - greater than 50% full
10 - greater than 75% full
11 -greater than 90% full
2. 请求程序上的预取器可以使用Cbusy字段值并微调预取器
结合Cbusy的信息,可以采用预取器采用不同的预取策略来完成预取的同时,也不会较多影响正常访问的效率;
6. Trace Tag
该feather是向每个通道增加一个TraceTag,用于系统的调试,跟踪以及性能测量的增强支持;用法和规则如下:
§ TraceTag位可以由RN或ICN设置
§ 如果组件在每个接收到的数据包中都设置了TraceTag位,那么它必须在响应该接收到的数据包而生成的任何响应数据包或衍生数据包中保留并反映该值。否则,响应和生成的数据包中的TraceTag位可以取任何值
§ 如果接收到的数据包产生多个响应,例如写入请求导致单独的Comp和DBIDResp响应,或生成单独的DataSepResp和RespSepData响应的读请求,如果生成数据包设置了TraceTag位,则所有此类生成的响应都需要设置TraceTag位。
§ 如果组件可以接收与单个事务关联的多个数据包,那么对于它依次生成的每个数据包,只有在关联的接收数据包中设置TraceTag值时才需要设置该值。
§ 当ICN接收到TraceTag位设置的报文时,必须保留该值,不能重置该值