1517_AURIX TC275 SRI中的仲裁功能

Posted 2022-11-12

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

前面简单看了一下TC275的一些总线设计的概述简介，这一次看一下SRI相关的仲裁功能。

这个仲裁模块前面接触的时候描述，设计的目的其实是为了提升处理的性能。而性能上的提升，其实很多表现的形式通过任务优先级的概念进行了继承。这个仲裁的过程是一个大量的模块以及信息并行处理的过程，因为一个主模块可以选择不同的从模块，而一个从模块也可能由不同的主模块请求。由此，必须进行并行的处理判断，而这个判断主要是通过地址的匹配实现。

然而，这里有一个一直都在描述的概念一直灭有弄清楚，那就是优先级。一共有15个可以自由配置的主从对儿，加上默认的可以达到16个，可以做同时的并行处理。那么，优先级如何仲裁呢？是否会有相同的优先级存在？另外，前面看OP的时候至少是没有看到优先级的信息的，那么这个优先级的信息来自于哪里？

1. 前面从图中其实已经可以看出来了，仲裁的过程中涉及到一个地址的匹配判断过程。

2. 仲裁有两种模式，一种是基于优先级进行仲裁，另一种基于轮训。这种概念，跟OS的概念是很相似的。

3. 轮训其实是默认的仲裁模式，而轮训是在固定的优先级2或者5上进行的。

4. RR仲裁模式其实是也有一个优先级的处理，因为有两个优先级。一组处理完再来一组，而同组的处理ID号高的优先处理。

5. 如果采用优先级的仲裁，那么不允许出现相同的优先级号。然而，2和5优先级是除外的。如果想要进行优先级的切换，也需要先切换到2或者5优先级作为缓冲再转到其他的状态，避免同优先级请求的冲突。

6. 如果出现了错误，那么相应的信息可以有默认的SRI从模块来进行信息的收集。

1. 多主请求一从的时候，谁的优先级高谁将会获得仲裁的结果。

2. 中间介绍的这种调度机制，我在总结上一页的笔记的时候已经写了。

3. 如果某一个MCI持续请求，即使是优先级一直最高也至少会有2个时钟的延迟。

1. 这里给出来了默认的轮询模式下的分配情况，这回答了我前面的疑问。

2. 在OS中经常会考虑解决一些资源使用带来的饿死问题，这个MCU的设计中也考虑了。通过接计数器机制来防止高优先的主机不断请求而导致其他的主机请求事件饿死的情况产生。

这里针对饥饿计数器机制进行了详细的说明，我觉得这是很有意思的，绞尽脑汁也想不明白如何通过硬件来实现。我觉得喝个在处理的原则上已经很有OS的味道，其实是一个硬件资源的使用规则分配。不过，如果面对复杂的现实世界进行处理，我倒觉得有时候这种优先级仲裁的方式不见得会是最好的选择。虽然，它能够带来性能上的改善，但是让处理变得有些不可捉摸。让整个系统的可测性也变得更加复杂，而轮询模式则简单得多。

默认的从机的主要功能有三个：1，控制以及配置寄存器的接口； 2，对不存在的地址的访问处理； 3， 错误处理。

当进行错误处理的时候，会对错误的一些类型和地址进行进行记录。

1. 需要注意的是，处理错误的时候只能够捕捉到第一个错误。

2. SRI总线三个相关的中断源：1，协议错误； 2， ID错误； 3， 饥饿超时。

3. 通过TAG ID的机制可以实现寄存器的保护功能。可以独立的禁用每一个TAG ID对于总线的写入访问。但是，被禁用之后，使能寄存器依然是可以通过了EndInit机制之后进行访问的。而Endinit的机制是由SCU中的看门狗提供的。我觉得这样的功能，在考虑功能安全相关的设计的时候可以利用起来。

复位之后，寄存器的保护其实是默认打开的。

协议主要包括两个部分：1， 寻址； 2， 数据读写。

DMA以及SFI都会忽略ECC，但是相应的错误会发送给SMU。

如果SRI向SRAM中写入数据的时候出现了ECC错误，那么相应的从机不会执行。

这里介绍了一下用到的ECC机制，我并没有看懂，接下来还得专门找一点资料了解一下ECC保护的大概实现。