oracle仲裁机制,仲裁逻辑设计要点

前阵子，特权同学提过希望找一些仲裁逻辑设计方面的资料，用中文在google中搜索“仲裁逻辑”，结果很令人失望，除了一些PCI总线仲裁方面的论文只言片语的谈到那么点详细的仲裁设计细节外，其他的文章基本无任何参考价值。不过，树挪死人挪活，咱可以改用English搜，特权同学用“Arbitration logic”、“Arbitration design”、“Arbiters”等各种可以想到的相关词汇，终于找到了几篇不错的文章，这里推荐一篇叫做《Arbiters: Design Ideas and Coding Styles》的文章。初看标题，还以为要说软件编程方面的知识，再看内容才发现正是我所寻觅的。

花时间细读了一遍，作者由浅入深，探讨了一种效率高、可靠稳定的仲裁逻辑设计方法，有详细的理论叙述也有一些实例图示，很是形象生动。也许放到一两年前看到这篇文章，特权同学很可能瞥一两眼就不再搭理，因为用不上；但是当项目中遇到这方面的难点或是困惑的时候，它的出现绝对就是救命粮草，受用正当时。呵呵，有些夸张了，也许因为作者提到的一些设计思路和需要注意的点也正和特权同学现在脑子里的想法相契合，所以……

不罗嗦了，下面谈正紧的。特权同学不想规规矩矩的去翻录那篇文章，只想取精华的内容再结合自己的项目就实践谈理论。特权同学认为以下4个点会是比较容易让设计者纠结的地方。

1．  复位状态；

2．  切换时序；

3．  轮流响应；

4．  超时退出。

通常，若是直接采用最底层的与或非等关系来做这个仲裁逻辑，未免让人感觉难度太大，有时候脑袋都会想大了。因此，利用状态机来实现(当然最终实现的也就是最底层的与或非逻辑，不过可以把这其间的转换工作交给工具来完成)会大大简化这个设计，帮助设计者理清思路。

特权同学虽然只是面对了多个简单的2选1(最多也只是3选1)仲裁器，但是在多次思考尝试之后，还是选择了使用状态机来实现。如图1所示，基本上这个状态机示意图已经能够完全涵盖前面提到的4个点了。

图1

首先是复位，需要进入一个中间仲裁状态。对于这个2选1仲裁器，在这个中间仲裁状态，应该可以确保产生的请求1或者请求2都可能得到响应。对应的这个中间状态就是DIDLE，若某一时刻请求1和请求2都无效，那么将一直保持原状态(DIDLE)不变；如果请求1或者请求2有一方有效，则进入相应的响应状态(状态DWRS1或DWRS2)；如果请求1和请求2同时有效，则优先级高的请求首先获得响应(即进入对应的响应状态中)。

切换时序，其实前面描述DIDLE的状态保持或状态迁移就包含切换的概念。再说已经进入的某个响应状态(DWRS1或DWRS2)，如果每次响应完成后只是简单的返回中间仲裁状态，也许没有问题，相对也不容易出现各种因仲裁响应切换带来的问题，但是在一些系统吞吐量要求很高的场合，这种简单的切换会照成仲裁响应性能的下降。因此，就很有必要像图1一样，在某个正在响应的状态中，一旦当前响应结束，就可以继续仲裁并响应下一个有效的请求。对于这个2选1的仲裁来说，如果当前处于仲裁请求1的响应状态(DWRS1)，一旦响应结束，那么下一个状态就可以继续仲裁并决定是停留在当前状态继续响应请求1、进入另一响应状态(DWRS2)以响应请求2的请求或者无请求返回中间仲裁状态(DIDLE)。这里要强调的不仅仅只是提高响应速度(降低因切换状态照成的性能下降)，更多的需要设计者注意对切换过程中(尤其是不同响应状态的切换中)具体相关的锁存信号的赋值。因为，很可能在切换时快一拍(一个时钟周期)或者慢一拍而照成整个数据的锁存紊乱(特权同学吃过这个亏，所以印象深刻，给各位提个醒)。

轮流响应，在《Arbiters: Design Ideas and Coding Styles》文章的最后一部分，提到了Round-Robin Arbiter的设计。Round-Robin Arbiter要是深入探讨也是很有趣的，有机会特权同学也愿意专门撰文论述。其最核心思想就是要在有优先级响应的情况下，依然需要制定一套轮流响应的机制，以避免某些优先级高的请求长期霸占总线。这对于大多数设计是有用的，就拿特权同学手上的这个仲裁器来说，SDRAM的写入有AV视频信号、也有MCU图像DIY层的写入信号，如果其中一方长期霸占总线，使得另一方的数据缓存FIFO溢出，那么很可能导致在液晶显示的时候部分图像的数据丢失，甚至出现某一帧图像的闪屏。因此，这里的轮流响应机制的加入就会大大降低这种事件发生的概率。在具体实现中，比如图1的DWRS1是可以在响应结束时选择下一状态，它的优先级关系就是DWRS2 > DWRS1 > DIDLE；与此不同的是DWRS2的下一状态优先级关系为DWRS1 > DWRS2 > DIDLE。基本的思想就是：我响应完了，就先考虑你的请求，然后再考虑自己的请求，若是都没有请求，咱们就回到中间状态。

最后要提超时退出机制，这对于很多应用也是必要的。它可以有效的防止在某些不可预料的情况下，状态机不明不白的“死去”。这也算是一个健壮的状态机必须具备的条件。这里特权同学要拿调试过程中一个很生动的“死去”的例子让大家引以为戒。在没有超时退出机制的情况下，出现过上电瞬间视频显示死机(图像定格)，但是只要MCU执行SDRAM写入(产生新的仲裁请求)，则死机解除。这个现象出现的概率非常低，并且只发生在上电瞬间的图像显示切换后(感觉上电期间有很多不确定的因素)，以至于很难确定到底问题出在了什么地方。有一点是可以肯定的，那就是视频采集写入SDRAM的请求长期得不到响应，状态机“死”在了另一个响应状态里，直到新的变化条件出现。所以，在加入超时退出机制后，问题不再复现。可以肯定的是，超时退出机制对解决此类突发问题相当有效。

说到这里，想说的4个点都讲完了，但是回头却发现围绕一个简单的例子谈了很多理论。其实感觉很多时候，对于一个做具体开发的工程师来说，细节的东西是很难用文字分享出来的，能够把设计思想和设计理念阐释清楚，本身就是一件相当不简单的事。细节的设计实现，需要工程师在思路清晰的状况下认真细致来完成。