仲裁逻辑设计要点

《仲裁逻辑设计要点》由会员分享，可在线阅读，更多相关《仲裁逻辑设计要点（9页珍藏版）》请在金锄头文库上搜索。

1、 EDN 首页 博客首页 captainliuy 的 E 空间 | 站内短信（0） | 退出 ilove314 档案档案 相册相册 特权特权s Blog永远忠于年轻时的梦永远忠于年轻时的梦想！想！ 首页 个人信息个人信息 博主：ilove314 +加为好友 +发站内信 +博客精华 +推荐文章 最近加入的小组最近加入的小组 华为研发书友会 工程师读圣经 基于 FPGA 的快速系统原型开发翻译 Numonyx 存储小组 博客公告博客公告 在实践中学习，在实践中思考，在实践中总结，在实践中提高；也许，在特权同学的原创博文中会有一些不成熟的思考和文字，也非常期待各路好手分享 自己的看法和见解，特权在此

2、先谢过了！_ 你们必认识真理，真理必叫你们得以自由。And you shall know the truth, and the truth shall set you free. -John 8:32 在成功的时候我学习谦虚 在失败的时候我学习坚毅 在快乐的时候我学习节制 在痛苦的时候我学习忍耐 在愤怒的时候我学习冷静 在害怕的时候我学习勇敢 在焦虑的时候我学习乐观 在迷惑的时候我学习分析 在犹豫的时候我学习果断 在懈怠的时候我学习积极 在羡慕的时候我学习知足 在孤寂的时候我学习独立 耶和华是我心中的力量 我我的分类的分类 MCU of 51 （14） FPGA 设计感悟 （110） PCB

3、of Altium Designer （11） 资源共享 （13） DSPs （3） 传输控制 （24） 芯片手记 （6） Altera_TimeQuest （25） LPC2103 -ing （8） WritingTestbench （8） ISE_Timing Analysis （9） 逻辑分析仪 DIY （4） VGA 数码相框 DIY （10） Rapid System Prototyping with FPGAs （8） xilinx fpga （1） SOPC （5） Virtual JTAG （3） 电路设计 （2） 项目日志 （9） 代码移植 （3） NIOS2 （2） 博客日

4、历博客日历 日日 一一 二二 三三 四四 五五 六六 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 博客广告博客广告 BJ-EPM CPLD 学习板、 SF-EP1C FPGA 开发板: http:/ 日志档案日志档案 2010 年份 （56） 2009 年份 （120） 2008 年份 （105） 最新日志最新日志 仲裁逻辑设计要点 Verilog 中宏定义位宽带来的问题 榨干 FPGA 片上存储资源 数据吞吐量预

5、估 守株待兔，收效显著 最新评论最新评论 huangrong1986 评论 2010/8/3 20:01:34 受教了 fangkunwei 评论 2010/7/31 22:50:01 很受启发 T_rui 评论 2010/7/29 21:21:39 哈哈 谢谢罗 ilove314 评论 2010/7/28 19:30:49 只要知道是先执行的先出来就行，只是个示意图，可 jiereliyi 评论 2010/7/28 13:13:19 最后一个图应该是 DCBA 不是 ABCD 吧 友情链接友情链接 弗老大的丰田中心 天祥电子 与非网 我的淘宝小店 书拉密女小站 datasheet ADI 中

6、文 MAXIM 中文 xilinx 中文 altera 中文 德州仪器 校内网 EDA 专业论坛 riple 的博客 FPGA 助学小组 我的母校 wind330 的博客 Rickys 博客 yulzhus 博客 特权的新浪博客 coyoo 的博客 Dais Blog .COM 缺氧 博客统计博客统计 文章：281 篇 评论：712 篇 访问：373715 访客记录访客记录 captainliuy hhx1029 shengning craftor weilujun kuangwenkui 日志档案日志档案 发表于 2010/8/3 22:20:42 标签： 仲裁逻辑 仲裁逻辑设计要点仲裁逻辑

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

8、软件编程方面的知识，再看内容才发现正是我 所寻觅的。 花时间细读了一遍，作者由浅入深，探讨了一种效率高、可靠稳定的仲裁逻辑设计方法，有详细的理论叙述也有一些实例图示，很是形象生动。也许放 到一两年前看到这篇文章，特权同学很可能瞥一两眼就不再搭理，因为用不上； 但是当项目中遇到这方面的难点或是困惑的时候，它的出现绝对就是救命粮草， 受用正当时。呵呵，有些夸张了，也许因为作者提到的一些设计思路和需要注 意的点也正和特权同学现在脑子里的想法相契合，所以 不罗嗦了，下面谈正紧的。特权同学不想规规矩矩的去翻录那篇文章，只 想取精华的内容再结合自己的项目就实践谈理论。特权同学认为以下 4 个点会 是比较容

9、易让设计者纠结的地方。 1 复位状态； 2 切换时序； 3 轮流响应； 4 超时退出。 通常，若是直接采用最底层的与或非等关系来做这个仲裁逻辑，未免让人感觉 难度太大，有时候脑袋都会想大了。因此，利用状态机来实现（当然最终实现 的也就是最底层的与或非逻辑，不过可以把这其间的转换工作交给工具来完成）会大大简化这个设计，帮助设计者理清思路。 特权同学虽然只是面对了多个简单的 2 选 1（最多也只是 3 选 1）仲裁器，但 是在多次思考尝试之后，还是选择了使用状态机来实现。如图 1 所示，基本上 这个状态机示意图已经能够完全涵盖前面提到的 4 个点了。 图 1 首先是复位，需要进入一个中间仲裁状态。

10、对于这个 2 选 1 仲裁器，在这 个中间仲裁状态，应该可以确保产生的请求 1 或者请求 2 都可能得到响应。对 应的这个中间状态就是 DIDLE，若某一时刻请求 1 和请求 2 都无效，那么将一直保持原状态（DIDLE）不变；如果请求 1 或者请求 2 有一方有效，则进入相 应的响应状态（状态 DWRS1 或 DWRS2）；如果请求 1 和请求 2 同时有效， 则优先级高的请求首先获得响应（即进入对应的响应状态中）。 切换时序，其实前面描述 DIDLE 的状态保持或状态迁移就包含切换的概念。再说已经进入的某个响应状态（DWRS1 或 DWRS2），如果每次响应完 成后只是简单的返回中间仲裁状

11、态，也许没有问题，相对也不容易出现各种因 仲裁响应切换带来的问题，但是在一些系统吞吐量要求很高的场合，这种简单 的切换会照成仲裁响应性能的下降。因此，就很有必要像图 1 一样，在某个正 在响应的状态中，一旦当前响应结束，就可以继续仲裁并响应下一个有效的请求。对于这个 2 选 1 的仲裁来说，如果当前处于仲裁请求 1 的响应状态（DWR S1），一旦响应结束，那么下一个状态就可以继续仲裁并决定是停留在当前状 态继续响应请求 1、进入另一响应状态（DWRS2）以响应请求 2 的请求或者无 请求返回中间仲裁状态（DIDLE）。这里要强调的不仅仅只是提高响应速度 （降低因切换状态照成的性能下降），更多

12、的需要设计者注意对切换过程中（尤其是不同响应状态的切换中）具体相关的锁存信号的赋值。因为，很可能 在切换时快一拍（一个时钟周期）或者慢一拍而照成整个数据的锁存紊乱（特 权同学吃过这个亏，所以印象深刻，给各位提个醒）。 轮流响应，在Arbiters: Design Ideas and Coding Styles文章的最后一部分，提到了 Round-Robin Arbiter 的设计。Round-Robin Arbiter 要是深入 探讨也是很有趣的，有机会特权同学也愿意专门撰文论述。其最核心思想就是 要在有优先级响应的情况下，依然需要制定一套轮流响应的机制，以避免某些 优先级高的请求长期霸占总线

13、。这对于大多数设计是有用的，就拿特权同学手 上的这个仲裁器来说，SDRAM 的写入有 AV 视频信号、也有 MCU 图像 DIY 层的写入信号，如果其中一方长期霸占总线，使得另一方的数据缓存 FIFO 溢出， 那么很可能导致在液晶显示的时候部分图像的数据丢失，甚至出现某一帧图像 的闪屏。因此，这里的轮流响应机制的加入就会大大降低这种事件发生的概率。在具体实现中，比如图 1 的 DWRS1 是可以在响应结束时选择下一状态，它的 优先级关系就是 DWRS2 DWRS1 DIDLE；与此不同的是 DWRS2 的下一 状态优先级关系为 DWRS1 DWRS2 DIDLE。基本的思想就是：我响应完了，就

14、先考虑你的请求，然后再考虑自己的请求，若是都没有请求，咱们就回 到中间状态。 最后要提超时退出机制，这对于很多应用也是必要的。它可以有效的防止 在某些不可预料的情况下，状态机不明不白的“死去”。这也算是一个健壮的状态机必须具备的条件。这里特权同学要拿调试过程中一个很生动的“死去”的例 子让大家引以为戒。在没有超时退出机制的情况下，出现过上电瞬间视频显示 死机（图像定格），但是只要 MCU 执行 SDRAM 写入（产生新的仲裁请求）， 则死机解除。这个现象出现的概率非常低，并且只发生在上电瞬间的图像显示 切换后（感觉上电期间有很多不确定的因素），以至于很难确定到底问题出在了什么地方。有一点是可以

15、肯定的，那就是视频采集写入 SDRAM 的请求长期 得不到响应，状态机“死”在了另一个响应状态里，直到新的变化条件出现。所 以，在加入超时退出机制后，问题不再复现。可以肯定的是，超时退出机制对 解决此类突发问题相当有效。 说到这里，想说的 4 个点都讲完了，但是回头却发现围绕一个简单的例子谈了很多理论。其实感觉很多时候，对于一个做具体开发的工程师来说，细节 的东西是很难用文字分享出来的，能够把设计思想和设计理念阐释清楚，本身 就是一件相当不简单的事。细节的设计实现，需要工程师在思路清晰的状况下 认真细致来完成。 系统分类: CPLD/FPGA | 用户分类: 项目日志 | 来源: 原创 | 【推荐给朋 友】 | 【添加到收藏夹】 该用户于 2010/8/3 22:22:19 编辑过该文章 1 阅读(63) | 评论(0) | 收藏(2) | 举报 最新评论最新评论 标题 re:仲裁逻辑 姓名 capta