硬件实时操作系统信号量管理的设计与实现

    随着嵌入式技术的发展，实时操作系统RTOS(Real Time Operating System)被越来越多地应用在嵌入式系统中，但是对现有基于软件实现的RTOS，单纯依靠改进调度算法已经不能使系统的实时性有很大提高。为提高系统的响应能力，国内外一些研究机构提出RTOS硬化的方法，并开始做这方面的研究工作[1]。目前，软件硬化常用的有两种方法：(1)微程序方式，特点是成本较低，方便灵活；(2)组合逻辑方式，特点是速度快、可靠性高，随着大规模集成电路的发展，这种方式逐渐显示出优越性[2]。信号量管理是RTOS中频繁运行的程序段之一，如果将这一部分用硬件实现，对提高机器的速度将有很明显的效果。本文采用组合逻辑方式参照μC/OS-II将信号量管理及ECB管理硬化到一片芯片上，作为独立的模块与处理器并行工作。

1 信号量管理的工作原理

    μC/OS-II中信号量主要数据结构由两部分组成：(1)信号量的计数值Cnt。当数值为正时用于记录可使用的资源数，当数值为负，其绝对值表示等待当前信号量的任务个数；(2)等待该信号量的任务列表。信号量的基本数据结构需要申请一个ECB来存储。一个任务或ISR可以通过ECB向另外的任务发信号，一个任务可以等待另一个任务或中断服务子程序给它发送信号，多个任务可同时等待同一个事件的发生[3]。当事件发生后，等待该事件的优先级最高的任务进入就绪状态，触发一次任务调度[3]。任务或者中断服务子程序都可以给ECB发信号，对ECB进行操作。

    信号量管理的工作原理框图如图1所示。信号量管理模块以及事件控制块管理都是独立于CPU的逻辑结构，都可以直接从数据总线上获得数据信息进行处理，在信号量管理模块与ECB的存储模块间建立一条数据通路，在不增加总线负担的情况下加快二者间的通信。这些硬件逻辑独立于CPU工作，减少了CPU的工作，从而提高系统的响应能力。

2 信号量管理的硬件设计与实现

2.1 ECB的设计与实现

    ECB是实现信号量管理的基本数据结构，因此在设计实现信号量管理之前，要先完成ECB管理的设计与实现。本系统中ECB的结构参照μC/OS-II中ECB的结构设计。每个ECB存储单元包含一个EventType（事件类型），用于标记当前ECB被分配给信号量、互斥型信号量、邮箱还是消息队列；当一个ECB被分配给信号量时，Cnt做为信号量的计数器；ECB中的等待表lut用于存储等待当前信号量任务的优先级(μC/OS-II中没有两个任务有相同的优先级)[3]。

    ECB中等待表硬件实现的结构示意图如图2所示。等待表的结构类似一个8行8列的矩阵，存储单元编号从00~77。当一个任务在申请当前信号量而没有获得时，应将当前任务设置为等待状态，令Wr有效，以申请该信号量任务的优先级为地址，进行译码，选通相应单元后再进行写1操作。例如，申请该信号量的任务优先级Sid为111111时，对其进行译码，高三位行地址译码为10000000，低三位列地址译码为10000000，选中77单元向其写入1，则优先级为111111的任务进入等待状态。若要将一个处于等待表中的任务删除，令De有效，同样，根据地址线选通某一存储单元，向单元内写0，从而删除某一处于等待状态的任务。在控制电路中设置EventGrp 8位寄存器，用于记录当前各行中是否有等待任务；如图2所示，第i行中某一位置为1，EventGrp(i)=1，图中状态EventGrp(7)=1、EventGrp(6)=1、EventGrp(0)=0。Rd有效时，控制电路根据EventGrp采用一定算法生成优先级的高三位；根据EventGrp读出某行后生成优先级低三位；下一时钟送出最高优先级。以上为对等待表进行基本读写操作的过程。

    该硬件系统中ECB基本存储单元通过调用系统的IP核来实现，根据存储数据的不同，采用不同的IP核；多个基本单元通过一个上层文件生成一个ECB单元，每个单元再作为一个基本器件用于实现整个ECB的存储体。通过地址的译码选通ECB单元，根据控制信号对数据做读写操作。

2.2 创建/删除一个信号量

    ECB是公共数据结构，在传统的操作系统中创建一个信号量时，首先需要申请一个ECB，初始化后才可以对这个信号量进行P/V等操作；在删除一个信号量后，要对信号量占用的ECB进行释放。创建信号量时，信号量管理模块首先要申请一个空ECB，查找ECB的整个存储体判断是否有空余的ECB。如果没有空余ECB，则信号量管理模块将获得一个申请失败信号；否则将获得一个空ECB的地址，并将其返回给创建该信号量的任务；再根据地址初始化ECB[3]。如果用硬件实现信号量管理后，按照以上过程进行操作会浪费很多时钟，数据在模块间来回传送增加通信次数，必然降低系统的执行速度。针对这个问题，提出了在信号量管理模块中设置一个用于记录ECB使用情况的映射表，如图3所示。为方便讨论，假设系统中ECB有64个(可以根据系统中ECB的个数来改变表的大小)，表的每个位置对应一个ECB，当某一位置为0时表示该位置对应的ECB空闲，为1时表示该位置对应的ECB被占用。如图3所示，第1行、第8列为1，表示偏移地址为000111的ECB被占用；第2行、第2 列为1，偏移地址为010010的ECB被占用。

    在创建一个信号量时，查找ECB映射表，判断是否有为0的位置。如果没有则返回申请失败；否则寻找一个为0的位置，生成ECB的地址，返回给创建该信号量的任务。在映射表中相应位置写1表明该ECB已经被占用，下一时钟对申请到的ECB进行初始化，写入信号量初始值。在删除一个信号量时，首先根据信号量的ECB地址查询映射表中对应位置是否为0，如果为0，则表示该信号量已经被其他任务删除，返回删除错误；否则清除该信号量在映射表中的记录，通知ECB管理模块将等待该信号的所有任务置为就绪态，触发一次任务调度，清除ECB中的该信号量的所有信息。以上过程中不需要频繁地去ECB管理模块中进行整体查询，因此节省了大量的通信时间。

2.3 申请/释放一个信号量（P/V操作）

    信号量管理中的主要操作就是P/V操作，P/V操作实现的RTL图如图4所示。

    (1)P操作（申请某个信号量）。令pend_sem有效，首先应判断申请信号量的任务是否为中断服务程序（在μC/OS-II中，中断服务程序不允许申请一个信号量），如果是则返回申请错误信息（pend_err为高），否则进行以下操作：令read_cnt有效去ECB管理模块读Cnt值；读回后判断Cnt的值。如果Cnt>0，当前申请任务获得该信号量，任务继续执行，返回申请成功信号pend_err为低；否则pend_err为高阻，根据申请类型Pend_type(申请类型在μC/OS-II中分为有等待申请和无等待申请)来决定是否修改Cnt值，是否将申请信号量的任务置为等待态。

    (2)V操作（释放某个信号量）。令post_sem有效，通过硬件电路使read_cnt有效，同时给出信号量的ECB地址，下一时钟读出Cnt值，并判断；如果Cnt>0则表示没有任务等待当前信号量，修改Cnt值；如果Cnt<0则表示当前有任务等待该信号量，修改Cnt值，令select_h有效，从ECB任务等待表中找出优先级最高的任务，通知任务管理器将该任务置为就绪态，触发一次任务调度。

3 功能仿真

    为验证设计对系统性能的影响，采用ISE 8.2软件对各个模块进行时序仿真。P/V操作仿真结果如图5所示。P/V操作需要在两个模块之间进行读写数据，操作过程中，P/V信号始终有效。

    （1）pend_sem有效(P操作)。申请信号量任务的优先级为01，申请信号量的地址为05。pend_sem有效，令read_cnt为高，根据地址pend_addr读当前信号量的值Cnt，下一个时钟返回数值Cnt_in为0002，大于0；任务获得信号量继续执行，wr_cnt为高，Cnt值进行减1操作后送Cnt_out写回ECB。

    （2）post_sem有效（V操作）。根据地址读Cnt值，Cnt值为FFFE<0（Cnt值以补码形式存储）。下一个时钟Cnt进行加1操作后写回ECB，同时Select_h为高，从等待该信号量的任务列表中选择出优先级最高的任务设置为就绪态，触发一次任务调度。

    （3）申请一个信号量。申请信号量任务的优先级为03，申请的信号量的地址为09。如果下一个时钟读回的Cnt值为FFFD<0，并且申请类型为高（有等待申请），则修改Cnt值写回，令wr_sid为高，将当前申请任务的优先级送pend_prio_out写入等待该信号的任务列表中。如果pend_err为高，则通知任务管理器将当前申请信号量的任务阻塞，并触发一次任务调度。

    （4）申请一个信号量，读回的Cnt值为FFFA<0，但当前申请类型为低（无等待申请），不进行任何操作，返回申请失败，通知任务管理器将当前任务阻塞。

    用户程序在创建、删除一个信号量以及申请某类共享资源进行P/V操作时，用软件实现信号量管理中，一般先从用户态转到系统态，然后进行基本数据的查询、读出、比较、判断等，再转相应的程序入口，最后还要从系统态转回用户态。而用硬件实现信号量管理后进行以上操作只需一条读或写指令，并且这条指令在用软件实现的信号量管理中也是必须的，其他操作都由硬件逻辑来实现，简化了操作过程。从仿真结果看，进行P/V操作时只需要3个时钟节拍，整体的执行速度远远高于软件。同时，RTOS中信号量的个数为多个，信号量管理在RTOS中频繁运行。因此，硬化信号量管理后对整个机器速度的提高是非常明显的，特别是对资源种类多、数量大的计算机系统，速度的提高就会更加明显。另一方面，由于硬件的可靠性远超过软件的可靠性，所以硬化后可提高RTOS的可靠性。