相关专题：
一种新的无线设计方法使设计师们能将多种基于分组的标准融合到资源受限的手机硬件中。
系统设计人员有时将用户设备手机的传统栈开发方法称为“基于竖井”的开发方法，因为这种开发方法在软件和硬件之间是极端纵向集成的，而且缺乏与其它栈的横向集成（图 1）。在实现多种基于分组的标准时，这种竖井方法就不适用了，因为它假设协议栈开发人员“拥有”基本的硬件资源，因而能够做出有关资源的假定，例如临时的和永久的缓存器分配。这些可用性假设在多模式环境中是毫无意义的，因为在基本时序上相互可能“冲突”的栈都会竞相获得各种资源，例如存储器。
竖井方法假设你可以在设计时配置最坏情况下的系统装入，从而使你可以在系统设计期间，而不是在运行时分配资源。但是，这种方法基本上不适用于多通道的基于分组的系统，因为其峰值资源装入与平均资源装入相差很大。另外，竖井方法还假设一个设计小组对系统进行编码，并在开发期间，标准不会发生重大变化。对于现代通信系统来说，两种假设都可能是错误的。
基于竖井方式的开发常常会使各种功能实现方法的资源使用率、调用格式以及行为等假设泄漏到设计的其它部分中，导致许多不良的设计习惯打着效率的旗号而付诸实现。例如，由于知道各种功能要花多少时间（以周期计）来执行，又知道每种功能函数需要多大的临时存储器，系统设计人员就会常常编写出静态的临时存储器调度程序，从而使得时间上不重叠的多个例行程序使用一个公共缓存器，由此避免代价可能很高的对 malloc()和 free()的不确定调用。但是，这样的设计往往是脆弱的。如果你要重新实现任何引擎，造成资源分布特性、时序两者之一或同时变更；如果基本硬件也要改变；更糟的是，如果某个栈与另一个栈一起共享基本资源（多模式问题），则从零开始的重新设计就不可避免了。
图 1 传统竖井方式开发采用纵向实现方法，缺乏与其它栈的横向集成。
替代方法
与任何极为复杂的设计问题一样，这一问题的最佳解决方法是将问题划分为可以自主处理的不太复杂的块。这种替代方法的基本概念模型在本文中称为虚拟机方法，它假设一个通信栈的第一层被分解为执行件、虚拟机（运行期内核）和引擎（图 2）。
图 2 一种替代的开发方法将第一层软件体系结构建立在虚拟机的基础上。
对运行中的第一层软件的分析表明：该软件把 80～90% 的执行时间用于与无线设备相关的计算密集的信号处理变换。这些资源消耗大的功能包括傅里叶变换、矢量乘法、FIR 滤波器和采样抽取器。实际上，这些变换在不同的无线设备中表现出高度的共通性。这些资源消耗大、基本与应用系统无关的元件，要么用专用硬件来实现，要么用平台高度优化的软件来实现。推荐的体系结构用一种特殊的方式处理资源消耗大的功能，即生成“引擎”。具体地说，这种体系结构要参照与其行为上等效的产品，对一些引擎进行性能试验，剖析其性能，实现独特形式的资源仿真。
剩余的 10% 处理资源（即执行元件）本质上是一种起控制作用的状态机，可按专门的无线标准要求进行变换。执行程序通常是极其复杂的，但其所需的处理资源却较少。这些资源消耗小的、基本上专用的元件很少包含天生就接合到基本硬件衬底上的资源。实际上，无论它们用硬件还是用软件来实现引擎，它们都可以移植到使用相同虚拟机运行期内核的任何其它设计中。执行功能的实例在第三代设计中有：一个数据平面的总数据流表达式、采集与跟踪逻辑以及各平面的通道生成和删除。
替代方法建立在一个以瘦虚拟机运行期内核为核心的体系结构上。这种体系结构能将执行元件与高 MIPS 引擎分开。在其最简化的级别上，它为半导体硬件和 RTOS 提供了使用可移植基带软件的抽象层。这种功能并不取代 RTOS；系统仍然使用引擎位于处理器（通常是一个 DSP）中的 RTOS 服务。虚拟机运行期元件需要识别公共的线程、中断、内存和资源管理模型，然后设计师将这些模型映射到可用的原语中，以通过运行期实现方法生成任何第三方 RTOS。虚拟机还包括复杂的资源管理功能，这些功能对于解决第一层无线开发的瓶颈是至关重要的（图 3）。
图 3 虚拟机运行期具有资源管理和调度功能，可将执行元件与引擎分离开来。
从资源调度的角度看，如果高层代码要直接调用引擎的话，则所有这些努力都将是徒劳的。直接调用或多或少会影响基本的执行顺序和线程模型，而这对于高效的实现方法来说又非常关键。更糟的是，调用者要负责为基本引擎建立适当的存储器，这实际上导致显式的资源调度。在本文所述方法中，只有一个中间件服务（即虚拟机运行期内核）可以调用一个引擎。具体来说，该运行期内核包括一个调度程序，从效果来说，这一调度程序是一个跨越所有执行过程和逻辑线程的范例。它使用一种插入式的调度策略来决定把这些任务中的哪一个提交给基本的 RTOS 去执行，决定它将使用多少 RTOS 线程，并决定采用哪种优先级和逻辑时间步长。
仿真是关键
尽管你必须保证你的系统是正确的，但对资源管理做出适当判断也是同样必要的。当然，最坏情况分析是不恰当的，在多模式设计时会给出过于悲观的结果，因而造成浪费。但是，利用性能仿真可以揭示出各种栈在时间上互相“冲突”的相关性。当执行元件调用引擎时，虚拟机资源仿真并不运行引擎本身，而是相当简单地更新一张“资源使用记录表”。在周期精确的仿真期间，或者在实际硬件执行期间，你都能通过一个性能剖析过程单独采集到各个引擎的资源使用信息。这一剖析包含了一个相应独立变量（例如矢量大小或位宽度）在某一范围的数值对各种类型资源（内存、周期、总线带宽等）的使用记录。它可以随机地表达出引擎资源的概况，例如，某个任务需要的周期数并不简单地是其输入范围的确定函数。（例如，一个涡轮式编码器处理较不完整的输入矢量就要花更多的周期。）一个参量表保存着每个引擎的资源成本，它是引擎元件化描述的一部分。仿真程序执行“真实的”执行代码，但却用引擎的执行代替对引擎的资源使用率的粗略估算。
因为资源仿真比周期精确仿真快得多，所以允许你将大量信息通过一个候选系统设计，并检查两个栈之间交互作用的许多情况。这一优点对复杂多模式系统和基于分组的系统的设计师有很大帮助。资源仿真可在一系列运行条件下对系统行为作出有代表性的评估。一旦你计算出这种数据，你就可以利用它做出两种设计时间的决定，一种是跨硬件基础的软件分割；另一种则是作为运行期预测（随机）调度程序的一个输入。
多模系统
多模系统包括许多你必须通过单一物理线程进行调度的独立执行元件。设计师可以假定：虽然引擎资源概况和引擎调用序列映射是可以实现的，或者无论如何是可以推导出来的，但明确的截止期信息却是难以得到的。于是你的问题就变成：为一个已指定装入的系统导出一个有效的串行调度计划，你可以把它表述为一组系统参数，例如有源通道数或最大吞吐比特率。每种资源都有一个 100% 的限制，这就约束了任何此类调度计划在上边界的效率。（例如，任何用到 120% 可用存储器的调度计划在某一点是无效的，或者至少需要进一步的工作来阐明其互斥等待行为。）但是，低于这一点，某些加权会决定“适合度”。例如，设计师可能认为存储器分配保持在 50% 以下的串行调度计划是可取的，因此可对整体度量进行适当加权。
与简单的调度策略（如先到先服务的策略）相比，多模式问题的解决方案需要进行更复杂的处理。具体地说，一种更复杂的调度策略是必不可少的。当前的策略既不在很大程度上使用已知引擎资源成本，也不试图进行预测。此外，由于处理具有事件驱动的性质，在一个实时系统中使用截止期常常是不现实的，特别是在引擎级使用。一种更复杂的资源分配策略是必要的，你必须将其当作调度程序的一个组成部分。
随机调度
设计师可以对在资源仿真时收集的数据进行处理，以构建一个引擎请求概率矩阵。该矩阵基于执行元件通过虚拟机运行期内核对引擎的调用（图 4）。导出的矩阵是稀疏的，具有许多次“0”转换和很多次“1”转换。但是，一个有分支的典型栈会产生一些介于 0 和 1 之间的概率，这是首次将随机行为引入到系统中。
图4 你可以根据仿真数据推导出一个引擎状态转换概率矩阵的概念模型。
在任意给定的时刻，控制执行元件中的各种逻辑线程仅向运行期调度程序提出考虑执行的下一个决定引擎的请求。调度程序可以使用前述的转换矩阵，以及通过引擎资源使用概况而获得的引擎执行成本，获得一些供评估使用的可能性前瞻情况。
但是，即使 “无穷尽地”看到未来状况是可能的，那也会在探讨的状态空间内造成各种组合的剧增。考虑一个一致的“固定”跳距数也是不可取的，因为有些调度程序可能比其它调度程序更有前途。这里的问题与下棋软件所面临的问题一样：即必须考虑各种走法可能的未来结果。它并不考虑所有的结果（例如，即使有两步预测的限制），而是采用一套启发式的方法来决定进一步发展哪一种方案。随机调度策略面临着同样的难题。
有了生成方案的启发式方法，下一个所需做的步骤就是提供一套计划度量标准。你可以利用这些度量标准来分析由启发式生成方法产生的每个候选方案的价值，最终用 一个标量“品质因数”值来表示每个方案。
这些计划量度标准的整个域通常跨越下列“目标”度量中的某些或大多数度量。这些根据每个时间片和每个组评估的度量是：总的存储器使用率、总的组使用率、发现时与截止时间接近程度和电源使用率等。
你也可以使用很多其它启发式度量方法。再回来看一看用象棋软件作类比的情况，目标度量就类似于基于各部分的价值去评估最终位置的价值，而启发式就类似于一个规则，如“放在开放对角线上的象的价值高于只控制较少自由方格的象”。
系统设计师可以设置传递函数曲率——实际上是决定系统对资源短缺作出响应是早还晚。此外，系统设计师还可以确定给每个计划度量赋予的加权，其总和即为最终的一个标量值。
这种虚拟机范例所使用的方法（随机调度）是多模式问题的一种解决方案。它使用了一些在仿真运行期间构建的预测引擎请求转换可能性的表，还用到各引擎资源的使用状况，使运行时的调度策略能在时间上有前瞻性，并且能动态地平衡多个并行栈的需求。
很显然，至关重要的是：随机调度带来的好处要超过其实现时在周期和存储器方面的成本。你可以采用很多专有技术来使每个时间片的重新计算需求降至最低程度。只要在运行期内核中利用安装合适的插件式调度策略资源仿真程序来进一步检查系统性能，你就能确定各种推想实现方法的效率。
随机调度策略具有优于通用方法（例如“最早截止期优先”）的效率，因为它们具有可用的额外信息，而且比静态RMA（速率单调性分析）技术更适合于通信系统。
资源互斥等待
互斥等待出现在必要的系统处理没有及时发生时，之所以会出现互斥等待，乃是因为没有适当的资源可用来调度这种处理。在很多情况下，一种“更聪明的”调度策略可以产生好得多的性能，但是，随着负载增加，最终会到达即使最复杂的策略也无法应付的程度。这时，系统必须能系统地舍弃某些请求。实际上，这种舍弃可能就是预想到的并被公众所接受的系统行为的一部分——这是为在突发环境中存在而必须付出的代价。重要的事情是，调度程序要采取行动，使系统性能逐步降低，而不是引发灾难性的故障。
虚拟机方法下的随机调度成功地为很多类型的多模式方案（竖井方式对其无效）生成了有效的串行调度计划。此外，它具有比“简单 RTOS”调度方法有更好的性能。具体说，随机调度可通过使用常规方法无法得到的额外信息，在运行期对多个竞争栈之间的突发需求进行平衡，从而具有显著的优势。资源分布特征引擎（资源消耗大的基本变换）的虚拟机范例是这种努力的核心，一方面是因为它向调度程序提供有关最重要资源消耗者的额外推断信息，另一方面，如果要高效地执行多模式系统的大型蒙特卡罗通信流量仿真，就必须采用这一方法。
虚拟机资源仿真程序是必不可少的，因为它为每个执行元件提供引擎请求转移概率矩阵。静态调度计划不适合用于突发和多模系统，因为它们的峰值资源使用率与平均资源使用率往往相差很大，而设计时的静态调度计划往往关注于最坏情况下的分析，导致设计低效或者不切实际。只要将执行元件与其希望调用的引擎分离，虚拟机的运行期调度程序就成为防止开发人员落入“竖井模式”陷阱，并且使他们实现资源共享的必要步骤。不只是周期，所有的重要资源都需要调度。因此，你也必须调度存储器。存储器调度程序可以使最终系统具有接近竖井模式技术的效率，即在设计时就确定所有或大部分的缓存器，并仍然考虑到突发性与多模式多供应商实现方法的冲突。
这种替代有问题的竖井式开发的方法，是一种基于使用虚拟机运行期内核的设计方法与工具包。它消除了执行软件对基本半导体硬件的依赖性，与此同时还有利于基本引擎的实现。创新的仿真和优化技术使最终产品的性能和成本效率得到最大限度的提高。这种体系结构允许独立的无线执行元件利用虚拟机内核来安全地共享基本的高 MIPS 引擎。只要创造多标准选购件，为未来的复杂用户设备提供必要的灵活性和成本效率，该方法就具有明显的优势。
摘自《END技术》
