基于FPGA原型设计 能为您做些什么？

止的软件改进方法就遇到了障碍。另一方面，相比于通用的计算机软件而言，与嵌入式软件互动的系统，其设定的使用模式和环境条件都更容易确定。而且，为较简单的系统开发的嵌入式软件可以比较简单，也就更易于全面验证。

举例来说，控制车辆子系统或电子玩具的 SoC 比在实时操作系统 (RTOS) 上运行许多应用和流程的智能手机更容易
进行全面测试。

如果我们更加仔细地观察运行在这类智能手机上的软件，例如图 2 所示的 Android 软件，我们可以看到一种多层布置，这称为软件协议栈。（该图基于软件设计师 Frank Abelson 在其所著的《Unlocking Android》一书中的原始图。
）

在观察软件协议栈时，我们会发现，协议栈的最底层——也就是那些最接近硬件的部分，主要是为了满足将软件映射到 SoC 硬件上的需求。这就需要对硬件有绝对的了解，甚至包括地址和时钟周期等。软件协议栈最底层的设计人员往往称自己为平台工程师，他们的工作就是准确描述硬件，以便协议栈的更高层次能够识别和重复使用。这种描述被某些 RTOS 厂商称为板支持包(BSP)，与我们日常使用的 PC 的基本输入/输出系统 (BIOS) 类似。

协议栈从下往上第二层包含 RTOS的内核以及将较高层次的软件与被描述的硬件相连的必要驱动程序。在这些协议栈的最底层中，平台工程师和驱动程序开发人员需要在真实的 SoC 或完全准确的SoC 模型上验证他们的代码。这个层面的软件开发人员需要全面了解各时钟周期软件的行为。

作为软件开发人员的另一极，在协议栈的顶层，我们可以看到用户空间，在这里可以同时运行多个应用，比如像智能电话中的联系人管理器、视频显示器、互联网浏览器和实际呼叫的电话子系统。这些应用中的每一个都不能直接访问 SoC 硬件，而且实际上在某种程度上违背了所有硬件考虑事项。这些应用依赖运行在协议栈较低层的软件代表自己与 SoC 硬件及系统其他部分通信。

我们可以归纳为：在协议栈的每一层，软件开发人员只需要一个足够准确的模型来让自己的代码认为自己运行在目标 SoC 上即可。超过必要的准确度只会让模型在模拟器上的运行速度下降。实际上，任何层面的 SoC 建模，都要求我们把硬件和协议栈描述为比当前层面更低的一层，以便进行验证。而且在理想的情况下，我们应该只要求够用的准确度，以实现最高性能。

举例来说，协议栈顶层的应用开发人员可以在真实的SoC或 SoC 模型上测试代码。在这种情况下，模型的准确度只要能够让应用认为自己运行在真正的 SoC 上就足够，它不需要精确到时钟周期，也不需要了解硬件的细致结构。但这里速度非常重要，因为在许多情况下有多个应用会同时运行，并与真实环境中的数据接口。

这种只为软件层提供“够用的准确度”的建模方法为不同的软件开发人员提供了多种不同的建模环境，供他们在SoC 项目的不同阶段使用。可以采用SystemC 这样的语言进行事务处理层面的建模，创建出一个准确度低但速度足够快的仿真器模型，用来同时运行许多应用。如果实时的真实数据的处理不是很重要，那么考虑采用虚拟原型方法比较好。

不过，必须完整运行整个软件协议栈或必须处理真实环境中的数据时，最适合采用基于 FPGA 的原型方法。

使用原型验证软件的实例只有采用基于 FPGA 的原型方法才能够打破建模方法中准确度与性能之间内在的相互牵制关系。采用 FPGA，我们既能实现实时的速度，又能以完全的 RTL 周期精度建模。这样，单个原型不仅能供低层软件验证要求的准确模型使用，又能供高层应用开发人员需要的高速模型使用。实际上，整个 SoC软件协议栈都可以在单个基于 FPGA的原型上建模。德克萨斯州奥斯汀市Freescale Semiconductor公司移动产品部的 Scott Constable 及其团队开展的项目就是采用 FPGA 验证软件的一个很好的例子。

Freescale非常想加快 SoC 开发进程，因为手机市场上产品生命周期短，需要产品尽快打入市场。这不仅是为了赢得竞争，也是为了避免迅速过时。通过分析流程中耗时最多的环节，Freescale发现通过加快手机3G协议测试工作可以带来最明显的效果。如果测试工作能够在流片前完成，Freescale就可以将项目时间缩短数月。与通常只有一到两年的产品生命周期而言，这非常重要。

协议测试是一个复杂的过程，就算以较高的实时速度进行，也需要一天才能完成。使用 RTL 级仿真需要花上数年，而在较快的仿真器上运行也要数周时间，这都不切合实际。采用 FPGA 是因为这是实现必要的时钟速度，及时完成测试的唯一途径。

协议测试需要开发产品的各种软件特性，包