AMBA AXI - transaction order记录

AXI协议支持5通道,读写分离的传输策略,在之前看AXI时,有很多基本的策略都会有点困扰,比如,通道依赖,传输顺序,以及交织等等之类的内容。所以觉得有必要搞一下这些知识点,把这些东西梳理和整理一下,也方便查阅,不然时间一长,总要重新翻Spec。

  1. 常规的AXI传输

上面两幅图都是简单的AXI传输,其中一笔完整的传输叫transaction,比如A传输,而组成A传输的各个小的传输成为transfer,比如A*。

图一展示的是当读写通道的transaction分别是不会overlap的传输。

图二展示的当读写通道的transation的请求会在前一个transation没完成之前来到,传输就顺序正常的完成。

这两种都是比较常规的AXI传输,放在这其实有点多余,不想看就可以跳过。

  1. Transfer IDs

Transfer id感觉我更愿意说成transaction ID,因为对于同一笔Transaction ID域的不支持修改的。同时,这种ID的机制引入就让transation有了所谓的乱序执行的机会了。这也就可以提升总线的效率,这是为啥呢?因为当可以乱序的时候,那transation就不用排排坐了呀,后来的准备好的就可以先做了,这样就省了时间,也最大化了使用带宽。

介绍完transfer ID的基础概念,再来看看规则吧:

  1. 所有transfer都需要有一个ID;
  2. 一个transaction的所有transfer需要一样;
  3. Master侧需要可以支持给多个transaction分发不同ID的能力,一个ID的话,当我没说;
  4. Slave侧的话,通常需要支持可配的ID宽度,方便适配Master侧的ID;

OK,絮絮叨叨把ID的基本概念和规则描述了,下来看看transation咋用吧。

    1. 写transaction order规则

Arm给的三条军规:

  1. 军规1:W通道的写数据的顺序需要和AW通道的顺序保持一致;
    这里

    |---|----------------------------------------------------------------------------|
    | |
    | | |

    A的请求比B先来,那写数据也要比B先来。

  2. 军规2:不同ID的transaction的完成顺序没有要求;

这里看A/B的ID不同,transaction的响应就可以乱序回。

  1. Master侧可以对同一个ID有oustanding能力,但是必须顺序的执行和完成<对slave侧的要求哈>。
    1. 读transaction的order规则

ARM一样对于读也提了三个军规。

  1. 军规1:不同ID的读数据在R通道上没有保序要求;也就是slave可以随便回哈
  1. 军规2:不同ID的读数据在R通道上可以interleaved, RID和AR对应可以看出来是谁的请求;
  1. 军规3:对于同一个ID的transaction,R通道上的读数据需要保序。

比如A/C, 这种保序的要求是指整体的transaction保序,不是指transfer的概念;

    1. 读写通道的顺序

Ok,看完了读写行为的分别保序的法则,下来就看看读写通道之间的顺序吧。

简单来说,读写之间没有order关系,如果需要保证读写顺序,这是软件需要在行为上保证的哈。

  1. 非对齐起始地址访问

AXI协议支持起始地址是非对齐的,但是非对齐只影响第一个transfer,之后的传输就是对齐的,在传输上,slave侧不需要关注是不是对齐。

所以什么是非对齐呀?

协议里就是说地址没有和transaction宽度对齐,比如一个32bit data packet传输的起始地址是0x1002而不是32bit边界对齐。

按照上图的说明,如果是32bit对齐的地址的话,最多可以传20Byte,但是因为地址不是对齐的,是0x1,所以只能传19byte,第一笔transfer只能有3byte。

再举个例子吧。

比如要发一个5-beat 16bit size的transaction,地址开始于0x03:

所以可以看到开始也是不对齐的。所以和上一个例子一样,第一笔传输是非对齐的,之后是对齐的。

AXI 协议不要求slave针对unalgined的访问做啥特别的处理。

  1. 读写接口的属性

说实话,从AMBA3到AMBA5,AXI的属性越来越多,支持的功能越来越多,对于这个需要单独再记录一下,每个都能开一章讲。

这一节描述一下接口的属性信息:

|----------------------------------|---------------------------------------------|
| 写接口属性 ||
| Write issuing capability | 表示master最多可以发多少写请求 |
| Write interleave depth attribute | 表示从属接口对于已经active write,可以接受的写数据的数目 |
| Write acceptance capability | 只在AXI3上体现。 表示从属接口可以接受写请求的能力 |
| Write interleave capability | 只在AXI3上体现。 表示主接口可以针对当前的active write的传递数据的能力 |

对于读而言也类似:

|----------------------------|--------------------------|
| 读接口的属性 ||
| Read issuing capability | 表示master最多可以发多少写请求 |
| Read acceptance capability | 表示slave可以接受的能力 |
| Read data reordering depth | 表示从接口可以针对已经发出的read乱序回的能力 |

相关推荐
万少1 小时前
用 TraeWork 给小孩做一个家庭工作台
前端·人工智能·后端
2601_963870181 小时前
【计算机毕业设计】基于Vue + Spring Boot的社区养老服务管理平台设计与实现
spring boot·后端·课程设计
前端开发张小七1 小时前
Java 学习笔记 · 第二课:面向对象核心(封装、继承、多态)及接口与异常
java·后端·程序员
颜进强1 小时前
Calude Code - 23 用 MCP 把 Jenkins 变成 AI 队友:一次对话完成自动化发布
前端·后端
Awna2 小时前
Golang 大小写可见性规范
开发语言·后端·golang
神奇小汤圆2 小时前
分布式事务没有银弹:从CAP定理到AT与TCC模式的选择指南
后端
YuePeng2 小时前
不写一行接口,让 DBeaver 直连你的指标层——背后只用了一个端口
后端·架构·github
董员外3 小时前
RAG 系统进化论(七):Multimodal RAG(多模态 RAG),当知识存在于表格、图片和页面中
人工智能·后端·设计模式
用户667675093793 小时前
Java 是如何操作Redis的?从 Spring Data Redis中RedisTemplate 源码分析 ZSet 调用链
后端
凌虚4 小时前
Kubernetes 编年史:从 Borg 到云原生操作系统
后端·程序员·kubernetes