为FPGA软处理器选择操作系统

在本文中，我们研究了选择嵌入式操作系统的各种方案，并且针对嵌入式和实时操作系统，讨论一些选择标准，并强调由可编程逻辑解决方案引入的设计折衷。阐述了一个典型实例，这里我们以在莱迪思半导体公司的FPGA 上运行的LatticeMico32软处理器设计为例提供一个典型方案的讨论。
　
引言

操作系统能够提高可移植性，并提供多种经过测试的抽象层，服务层和应用模块层以供选择，从而加快产品上市时间并减少应用程序出错的可能性。然而，选择一个嵌入式操作系统( OS )从来就不是一个简单的过程，因为集成嵌入式软件的方式选择余地很大，你可以完全都由自己来编写，或通过商业定制专门实时操作系统，也可以直接购买通用操作系统不作任何修改，现成的通用操作系统。FPGA性能的提高和软处理器核的出现，直接导致了可编程逻辑SoC解决方案的产生，随着这一变化，关于选择标准，设计方案以及折中考虑等传统经验也需要与时俱进以适应这些新的开发方式。

在本文中，我们研究了选择嵌入式操作系统的各种方案，并且针对嵌入式和实时操作系统，讨论一些选择标准，并强调由可编程逻辑解决方案引入的设计折衷。阐述了一个典型实例，这里我们以在莱迪思半导体公司的FPGA 上运行的LatticeMico32软处理器设计为例提供一个典型方案的讨论。

传统经验

根据传统经验，一个操作系统的选择有四个主要方式。

无操作系统

许多简单的嵌入式系统不需要操作系统。该代码通常始于设立堆栈指针和初始化几个时钟和外设寄存器。然后，该代码进入主循环(也称为超级循环) ，以执行产品的功能。编写中断服务程序( ISR)用以处理异步事件，以提供一些响应而不是轮询设备方式来进行服务。 ISR的响应通常是在0到10微秒的范围。如果 处理器速度 足够 快，以及超级循环是小而紧凑的，这是一个完全可行的选择。然而，如果进行更复杂的操作，如执行控制循环，提供图形显示服务，使用文件系统或网络堆栈( TCP / IP协议或其他)，超级循环将无法正常工作。如果考虑一个 快速和 功能强大的 处理器， 如开放源 代码LatticeMico32软处理器， 应该选择一个操作系统。

自己编写操作系统

对于一些特定需求，现有的解决方案无法满足需要，或者现有的解决方案成本太高，通常就需要考虑自己编写操作系统。自己编写RTOS (实时操作系统)通常不是一个好的选择，因为总是严重低估所需付出的努力。一个简单的“tasker”要写几天或几周，但更艰巨的挑战是需要对实现鲁棒性商业产品的努力。例如，一个商业的RTOS ，如μC/OS-II可能包含超过10000行的代码，已经在各种各样的产品中得到了现场验证，并可能已被认证应用于，如电子和医疗产品等。如果选择你自己编写，谁将确保长期维护，并且完成详细的文档?

从商业的观点来看，自己编写的RTOS不是一个好的选择。

商业RTOS

实时操作系统是一个管理微控制器，微处理器或DSP时间的软件。最重要的一个特点是它对实时事件的响应，通常不到25微秒。这种响应通常是确定性，在某些情况下，甚至相当稳定。一个实时操作系统以应用编程接口( API )的形式为应用程序员提供了许多“服务”。当选择一个实时操作系统时，从技术和业务问题方面考虑会有数十种选择。

技术问题可以大致分类为：

* RTOS对应用作出的响应够吗?

* 实时操作系统提供了所需的功能吗?大多数实时操作系统提供相同的基本功能：任务管理，时间管理，信号量，消息队列，事件标志等。

* RTOS可以实时用于不同的CPU (即代码可以移植吗)吗 ?一个 实时操作系统，如μC/OS-II已移植到超过45种不同CPU 架构， 所以在这种 情况下，可移植性不会成为问题，产品和其一部分的长寿性是得到保证的。如果使用一个新的架构，移植 到一个 CPU通常需要一两个星期。

* 使用RTOS是否有足够的ROM和RAM?根据所需的特性RTOS的空间可以减少吗?例如，μC/OS-II是可以升级的，代码 空间的要求在6千字节到24 千字节的之间，最低只需要500字节的RAM 。

从商业角度，事情并非那么容易解决。具体来说，嵌入式开发者需要从操作系统供应商那里得到满意答复，了解价格结构，支持结构和供应商的声誉和稳定性。寻找一个ROTS操作系统或RTOS的供应商时，调查通常是一个好的开端。

当系统响应速度是最重要时，如控制和监测应用程序，就会选择商业的RTOS，因为它们很依赖于软件的执行功能。如果你可以选择用硬件实现时间至关重要的功能，通常就不需要由RTOS提供严格的时间保证。

UNIX操作系统

在过去几年中，嵌入式应用中采用的32位处理器平台的性能和功能得到了极大增强。今天，即使软处理器，如LatticeMico32提供达到50至100 DMIPS的计算能力。随着可用资源的性能和功能的增强，提供丰富的功能集和抽象层的操作系统已成为一种可行的可选嵌入式解决方案。UNIX提供了非常丰富的编程环境，对多处理器的应用有相当的规模，以及在网络的应用方面拥有丰富的历史。通过文件操作，它提供了一个统一的设备抽象层，使平台之间的应用可以快速移植。一些UNIX版本也可获取开放源代码授权：Linux是最著名的变种，有非常庞大的用户群体和许多嵌入式应用(如WLAN路由器，打印机，VoIP电话)。Linux系统甚至对不包括MMU (内存管理单元)的处理器提供了有限的支持。各种BSD (伯克利软件分发)版本可能不太为人所知，但它们在许可证上限制较少。

一些实时扩展为Linux提供了在Linux执行层的顶部(或者说，下面)的最佳的软实时层。RT/ Linux、 RTAI和Xenomai是实时扩展的例子。通过多种已知的API从其他的RTOS (在Xenomai，此功能被称为“skins”)，一些实时层输出其功能 。

Linux系统提供了丰富的应用，可以很容易地集成到一个嵌入式应用程序，如Web服务器，协议栈，数据库引擎，图形库和网络管理。这些功能可以添加到任何嵌入式应用，而不需要“从草图”开发。随着Linux的先进I/O子系统的出现，和全面支持的非易失存储技术(从闪存到SATA硬盘) ，甚至可以集成“大”的应用(如在NAS应用中，跟踪照片的数据库应用)。

广泛使用的操作系统技术，例如Linux，其中一个最大的好处是在互联网上可获取大量的可用信息，有许多专业设计公司可以提供专业服务。虽然源代码的许可证是免费的，Linux的复杂性和大小会压垮许多用户。在这种情况下，专门设计公司，如Theobroma Systems可提供专业支持，培训和总承包设计服务。重要的是要记住，“开放源代码组织”并不能给你提供工业质量的支持，只有有经验的工程人员才行。

使用FPGA解决方案时，有与大型操作系统如Linux相关的性能和响应时间方面的问题，可以用硬件实现。在这种情况下，操作系统功能作为一种资源监管，大部分关键时间工作用硬件来完成。这个方法的一个例子是在UART内利用一个大的FIFO，以减少至操作系统 的中断次数。当然，此方法有一定的局限性和复杂性，但与一个专用的CPU芯片相比，有更多的灵活性。

另一方案：使用可编程逻辑

FPGA为系统设计者提供了一系列的权衡选择，这是现有的ASIC/ASSP解决方案无法提供的。正如图1所示 ，当一个处理器集成至FPGA时，设计者可以各种方式实现功能例如：

* 软件控制硬件

* 仅软件

* 软件功能，控制或数据流，通过硬件加速(SW/HW)

* 仅硬件，与CPU没有直接的互动，但是硬件可与任何功能进行交互。

图1 FPGA中的多种选择

使用提供这些权衡的可编程逻辑解决方案，SoC设计者有控制结构的多种选择。相反，控制结构的选择涉及到如何实现所需的功能。

一个简单的便携式媒体播放器示范了操作系统如何控制硬件，以及如何使用一个FPGA提供一系列改善硬件/软件的权衡选择。图2从硬件的角度展示了播放器的功能。所需硬件的数量在很大程度上取决于所期望的系统响应。有了RTOS，许多硬件模块可以比在Linux应用中简单得多。总而言之，FPGA的可编程逻辑为任何操作系统提供硬件权衡选择。

图2 从硬件角度观察便携式媒体播放器

设计者在系统中用什么附加硬件，和如何用附加硬件有更多的灵活性，这可以从软件的角度来观察，如图3所示。

一个键盘扫描器或许可以作为RTOS任务来执行，也作为硬件通过Linux任务来访问。事实上，用硬件实现的键盘扫描器在系统中是隐藏的，因为它被包装在一个任务中。其优点是大大减少了对操作系统的中断。轻松地权衡添加硬件或者使用软件为系统设计师带来了一种新的灵活性。

图3 从软件角度观察相同的便携式媒体播放器

与FPGA相关的操作系统选择

基于FPGA的应用引入了一个将时间紧迫任务用硬件实现的重要方法，使选择操作系统在时间约束方面得到缓解，参见图4。这张图显示了本文中讨论过的各种选择的响应范围。因为它是可编程逻辑，FPGA为设计者提供了精细的增量控制执行。因为它是硬件，它对实时事件的响应极快。如图所示，该响应可用于扩大服务范围，甚至更大的操作系统。

图4 响应范围

结论

用可编程逻辑的SoC平台的设计，如FPGA芯片里的LatticeMico32，给系统设计师提供了难得的机会，因为他们可以选择自己喜欢的硬件支持和轻载功能。这使得系统设计师通过转移软件到FPGA中执行数据路径，来满足时间上的限制。这一做法改变了对操作系统的标准选择判据，使得在实时操作系统和通用操作系统解决方案之间有更灵活的选择。虽然商业实时操作系统在确定中断响应方面仍然有其优势，但通过使用FPGA中实现的减负引擎后，通用操作系统的解决方案(如Linux )可能成为适合于较大的应用领域。“软实时”的解决方案，如RT Linux或Xenomai，这时就显得不那么理想了，因为使用减负引擎可以提供更好的响应而没有额外的工程费用。