1516_AURIX TC275总线设计以及SRI总线

全部学习汇总： GreyZhang/g_TC275: happy hacking for TC275! (github.com)

翻看了一个新的章节，关于TC275的总线介绍的。看起来，这部分设计是十分复杂的，因此这部分的学习可能也会延续很久。今天先看一部分SRI的介绍。

1. 首先需要知道，在TC275中的总线是有两个的，一个是SRI还有一个是SPB。前者是连通各个CPU以及一些交互的桥，后者则主要是用于外设访问。

2. SRI和SPB都会用到DMA，但是使用的目的不是很相同。前者主要是用来传输命令和数据，使用的场景都是高速访问。后者则主要是进行CPU与外设之间的信息搬运，进行的都是中低速的传输。

1. SRI 是有ECC功能的，但是这个ECC只能够提供报错不能够进行纠正。如果报错了，相应的错误会报到SMU，这种模式在AURIX的MCU上似乎是比较通用的做法。

2. 相比之前的MCU，这里的SFI的双向桥改成了单相桥。这个其实我在看第一页的拓扑图的时候发现了，而且还写了一个疑问。其实，这个疑问的另外一半现在也没有得到确认。这样设计的目的是什么？这个模块的功能主要是什么？

3. SRI/SBCU多了控制寄存器的写入保护。

1. Xbar_SRI是一个核心模块，这上面集成了很多种菜等模块。SRI上的信息交互式基于主从模型实现的，这样的交互式支持并行的。

2. 从点对点的拓扑图中是可以看得出来多路并行的可能的，但是这个并行的数目暂时不知道有什么限制。

3. SCI以及MCI，我觉得这两个缩写可能是从连接接口以及主连接接口的一个缩写。

1. 每一个主从模型中的从模块在Xbar_SRI这个中心模块中都有一个对应的专用仲裁器。

2. 优先级主要是仲裁的依据，以此来保证性能。

3. 这个表对于各个模块的功能属性进行了描述，SCI部分可以看出来，这里的主从并行应该是有15或者16个通道，其中一个是默认的连接。

这一页相比之前的信息没有什么特别需要注意的，但是后面的这个主从交互过程需要注意一下。其实，主要是分为三个阶段：准备阶段、处理从模块需要关注的信息、确认是否成功或者是否有故障。

1. 从模块无法发起事物，只是做一下响应的处理，因此处理的过程要简单得多。

2. 从模块能够传输的操作码，主要包括数据大小的单位以及数据包邮多少个。这里有一个组合出来的可能性结果，还是比较灵活多样的。

1. 如果出现错误会让slave停止发送，并且把错误传给SMU。

2. 如果访问一些预留的存储，会导致上面说的错误。因此，这个可以用来作为这个功能的一种测试手段，用来注入测试信号。

3. 这里不能混淆，SRI的ECC不支持纠正，但是SRAM的是可以的。

1. Xbar_SRI是最靠近CPU的模块，因此对性能的影响比较大。

2. 这里有了对于我前面猜测的缩写的解释，看起来我前面猜测还是准确的。

3. 仲裁的时候用到的这个优先级应该如何使用？是否是一个用户可以配置的？目前，类似的信息看不出来。或许，这里提供的模块控制寄存器可以控制修改？

1. 这里出现了一个新的概念叫做请求饥饿算法。

2. 主模块会根据轮训请求的情况，检查饥饿请求的情况。

3. 前面看到的15号是一个专用的模块，主要是用来做默认的处理。如果有不存在的slave那么默认都会走这一组通道，并且向SMU进行报错。由此，前面思考过的一个问题答案可能就明确了。可以并行处理的应该最多15路，不然的话默认以及错误就无法处理了。

SRI所有的错误都会经由默认的主从模块来处理，如果出现问题之后会产生系统中断并且把错误报给SMU。但是，这个错误检查的功能是可以通过控制寄存器来关断的。