漫谈AMBA总线-------AHB之从机响应

以下文章来源于微信公众号“IC解惑君”，作者木飞

原文链接：漫谈AMBA总线-AHB(2)

---

在AHB系列文章的第一篇(漫谈AMBA总线-AHB)文章我们通过对比水果运输总线得到多主机总线的概念：

总线是被总线上所有的部件所共享的一组通路（连线），对于支持多主机的总线，如果某一个主机想要与其他的部件进行通信：

（1）首先需要向总线内部的仲裁器发起使用总线的请求，获得总线授权。

（2）其次需要将地址、数据、命令放到总线上，其他的部件对总线上的信号进行侦听，检查地址数据和命令。

（3）最后相关从机部件对命令做出响应。

[ 复习一下并记住这个概念，之后的文章会用到这个概念 ]

接下来会先引入AMBA协议中的术语：

（1）在AMBA AHB总线中，数据的传输分为三个层次：

Transfer：	AHB bus 数据传输的最小操作单位。在这里，称之为元传输操作。这里的元代表该操作不可分割，不可打断。 这个操作表示： 主机把一次访问的地址和命令放到总线上，总线上对应的从机响应主机的操作。 举个例子：CPU读取0地址处的一个数据，数据的位宽是Word，这个完整的操作就称为一次Transfer
Burst：	多个相同类型的Transfer组成一个Burst。 这里的类型相同指的是： 访问数据的位宽相同，访问命令相同（读/写），但是地址不同。 举个例子：CPU读取0、4、8、C地址处的数据，数据的位宽是Word。在这里面，除了访问的地址不同，数据的其他属性（位宽、读写）都相同。 CPU在访问这些数据的时候，也是完成一次Transfer之后才发起另一次Transfer操作。
用户数据传输包：（由自己定义）	用户想要通过AHB总线传输的总的数据量 比如用户通过AHB总线上的DMA，把数据从UART传送到Mem中，需要传输的总数据量为1MB。这1MB数据就称为用户数据传输包。 想要通过AHB Bus传输这些数据，就需要按照AHB 总线的格式，把总的数据先分成不同的Burst，然后不同的Burst完成不同的Transfer，从而完成整个数据的传输。

如下图：

对应的例子就是：

冬天到了，家里需要拉两吨的煤用来生火，但是家里面只有一辆拖拉机。每次只能运送半吨煤。同时拖拉机的载货箱内部是由一个个单元大小的箱子组成。一个箱子能装50KG煤，因为运输工人卸货的时候一次只能搬一个箱子。所以就需要把这个两吨煤先分解成为拖拉机能装的部分，在此基础上装满拖拉机载货箱内部的单元箱。

类比：

在AHB总线中，每次运输的最小单位就是一次Transfer，表示一个数据的搬移。为了提升搬移的效率，把多个transfer组合成一个Burst进行搬移操作。最后为了完成用户所规定的数据量，需要多个Burst合起来达到用户规定的数据量。

Q1：为什么需要把用户的数据包分割成不同的Burst？为什么Burst的地址范围是1KB？

答：（1）在AHB的协议中，每个Burst的地址范围是不能跨越1KB边界线。举例来说：AHB总线传输的时候就像一列火车，火车的每一节都有一定的载货量，如果一节超出这个载货量火车可能就不会运行，对于AHB总线来说是一致的，用户需要传输的数据量比较大，超过了一次规定的大小（Burst），那么多的数据就需要放到下一个Burst中去。

      （2）在AHB的协议中，1KB的范围是分配一个外设的地址空间最小的范围。Burst不跨越1KB地址范围就是不想让一次访问覆盖多个外设的地址。如下图：

当CPU开始发起一次Burst读操作，因为URT0在第一个1K地址范围内，如果在一个Burst内超过了这个1K边界，就访问到SPI0了，可能就不是我们想要访问的目的了。为了完成这个边界跨越，我们在1KB的边界再重新主动发送一个新的Burst。[其实这一块我认为是AHB想要提醒我们，不要Burst跨越这1KB,除非主动操作]。如果你非要违反他，其实也能正常工作，但是模块就不能和其他的标准IP互联，会产生边界问题。这也提醒我们，在配置标准AHB IP的时候，外设的地址范围是1KB的整数倍并对齐到1KB。

---

前提：简单了解AHB 地址、数据、命令总线的接口信号（链接：漫谈AMBA总线-AHB）。

在通信中，对于主从双方，因为不是同一个体，所以双方都会在通信中出现一些双方内部状态不一致的问题（非通信问题），需要通过进行交换消息让两者同步。

下面通过例子先阐述一下从机部分的问题和这些问题的解决方案，从而引出AHB的SLAVE回复机制：

场景1: 我现在和小明正在对话，我说了一句命令，小明去执行。

我：小明（确定对象），去做1（数据）个俯卧撑（命令）

小明：已经成功做完！（既表示可以处理，同时任务处理完成了）

在场景1下，我（主机）发起一个操作请求，小明（从机）执行这个操作。

可以确定的是我发起的请求和数量，小明根据自己的状态反馈可以接收该命令！（HREADY == 1）同时因为任务简单在表明响应的时候小明也已经完成处理该请求（RESP == OKAY）

类比：

在AHB中，主机发起一个元操作（Transfer），从机回复一个 OKAY && HREADY ，表示从机根据当前状态可以接收该命令，同时在这短暂的时间内已经正确处理完毕这个请求。

场景2: 我现在和小明正在对话，我说了一句命令，小明去执行。

我：小明（确定对象），去做1（数据）个俯卧撑（命令）

小明：哎？俯卧撑多少个？你说啥？俯卧撑多少个？

我：1个~~~~~~~~~~~（持续几秒）

小明：收到，俯卧撑1个成功完毕。

在场景2下，我（主机）发起一个操作请求，小明（从机）执行这个操作。

可以确定的是我发起的请求和数量，因为自身的原因，小明根据自己的状态反馈暂时不可以接收该命令！（HREADY == 0）此时也没有执行命令（默认RESP 回复OKAY），而这时候，我需要保持我当前发出命令的状态，等待小明接收命令。

类比：

在AHB中，主机发起一个元操作（Transfer），从机回复一个 OKAY &&！HREADY ，表示主机你等会，因为个人的原因，内部有点忙。你先保持一下这个传输的状态（占住总线）。让我缓缓再仔细听听这个数据，再回复。

因为HREADY = = 0 ，此时没有接受命令和数据，这个元操作没有完成（不可分割），所以总线也没有释放，还在占用总线资源。

场景3: 我现在和小明正在对话，我说了一句命令，小明去执行。

我：小明（确定对象），去修1（数据）下大飞机（命令）

小明：？？？！！！ 我不会！

在场景3下，我（主机）发起一个操作请求，小明（从机）执行这个操作。

可以确定的是我发起的请求和数量，小明根据自己的状态反馈可以接收该命令！（HREADY == 1）但是因为我发起的这个要求不合理，小明根本完不成，所以反馈错误命令。

类比：

在AHB中，主机发起一个元操作（Transfer），从机回复一个 ERROR && HREADY ，表示从机根据当前状态可以接收该命令，但是因为主机发起的请求，从机根本无法处理（或者超出了从机的能力），所以回复ERROR。

场景4: 我现在和小明正在对话，我说了一句命令，小明去执行。

我：小明（确定对象），去做100（数据）个俯卧撑（命令）

小明：您先忙，我弄完叫你（完成当前的元操作，反馈临时结果）。

我：释放资源给其他人，等小明

小明：我执行完了（反馈最终结果）

在场景4下，我（主机）发起一个操作请求，小明（从机）执行这个操作。

可以确定的是我发起的请求和数量，小明根据自己的状态反馈可以接收该命令！（HREADY == 1）同时因为任务很复杂短时间内执行不完，所以给我回复不了这个任务执行的信息（因为任务很复杂，短时间内是不能有执行信息回复）。所以小明只能先让我不要等了（回复临时的状态信息）完成这个操作请求，释放资源，之后小明做完之后再叫我，回复真正的任务执行状态信息。

[ 我（主机）发起一个操作请求，小明（从机）执行这个操作的时候先让我去做其他（小明已经临时回复，为了释放此次原操作占用的资源），之后再正式回复我任务状况。这个时候小明已经先回复我了他的状态，我就不需要再等待（释放资源），我就可以让出通信资源给其他人然后等待小明回复我。]

类比：

在AHB中，主机发起一个元操作（Transfer），从机回复一个 SPLIT && HREADY ，表示从机根据当前状态可以接收该命令，但是从机分析之后发现这个命令自己需要超长的执行时间，所以临时先回复一下主机，说这个任务复杂需要你等我一会（完成这个元操作的过程），主机收到之后就知道任务复杂，所以自己也就不占用总线的资源，释放总线资源给其他的主机使用。这样就提升了总线的利用率，等从机处理完成之后，主机再检查处理回复的结果。

（从机完成当前主机分配的任务之后，提醒该主机）

PS：这个操作是很重要的，直接整体提升了AHB总线的使用效率。关注这一点同时是为了将来引出AXI总线的相关机制。

场景5： 我现在和小明正在对话，我说了一句命令，小明去执行。

我：小明（确定对象），去做1（数据）个俯卧撑（命令）

小明：哎，我听到你说做1个俯卧撑（先响应这个）。但是我现在有点忙，等会你再说一遍（给当前这个请求一个暂时的回复）

等几秒~~~~

我：小明（确定对象），去做1（数据）个俯卧撑（命令）（重发）

小明：收到，俯卧撑1个成功完毕。

在场景5下，我（主机）发起一个操作请求，小明（从机）执行这个操作。

可以确定的是我发起的请求和数量，小明根据自己的状态反馈可以接收该命令！（HREADY == 1）但是因为自己内部还有点问题暂时来不及处理这个命令。所以小明临时回复（RESP == RETRY），释放此次原操作占用的资源。告诉我等会重新试试这条命令，小明可能就从当前来不及的状态就变成可以处理的状态了。过一会后，我估摸着小明缓过来了，这时候我再重新说一次这个命令，小明缓过劲来就可以直接执行。

类比：

在AHB中，主机发起一个元操作（Transfer），从机回复一个 RETRY && HREADY ，表示从机根据当前状态可以接收该命令，但是从机内部还有其他的活没有解决（可以接受，但是没有办法立即执行），所以临时先回复一下主机，说我身上还有点活正在忙，你等会再找我，（完成这个元操作的过程），主机收到之后就知道从机当前还在执行其他任务，所以自己也就不占用总线的资源，释放总线资源给其他的主机使用。过一会差不多了，主机再次重新发起请求，这时候从机缓过来了之后就可以执行主机当前的命令了。

（从机不会再提醒主机，主机一会自己主动尝试联系从机）

总结：在AHB 总线传输的时候，一次Transfer（元操作）是不能分割和打断的，所以占用着总线的资源。所有的改进措施，都是先完成Transfer（元操作）的基础上再进行提升。完成元操作不代表这个操作必须完全执行完成才可以，而是可以先把这个Transfer（元操作）的流程走完结束掉它，之后用其他的途径再进行操作（比如在从机的回复下，主机回滚到之前的地址操作处再进行相同操作）。

从机请求主机等待自己的响应分类：

占用总线 （注意这个）	HREADY == 0  &&  RESP == OKAY	从机无法接受命令且不准备释放总线因元操作未完成
释放总线	HREADY == 1  &&  RESP == SPLIT	任务复杂，暂时不能完成和回复任务响应。稍后从机通知主机查收
	HREADY == 1  &&  RESP == RETRY	从机自己还在执行其他主机任务，暂时响应不了当前主机的任务，让主机等会再试试。
	HREADY == 1  &&  RESP == ERROR	从机认为任务有问题，无法执行

之后在整体的讲解的时候还会再讨论一次我们这里说的从机响应。

所以我们在设计AHB从机的时候是可以根据这两个信号，让主机等待从机。（根据设计，灵活选择让主机等待从机的方式）

---

下文：

AHB Master的回复机制。

AHB仲裁器的仲裁时序

AHB传输的时序图分析

后言：

还是希望大家能够坚持读完本篇AHB系列，按照别的up主或者公众号友都会简单从协议这边介绍一下就完成，但是我个人认为，深入讨论AHB协议之后，我们完全会从AHB协议引出AXI协议的一些特性。所以这也是我想把AHB讲述篇幅这么长的原因。

有问题大家可以后台留言，谢谢大家。

未完待续，下文更精彩。。。。。。。。