新闻中心

EEPW首页 > 手机与无线通信 > 设计应用 > 虚拟机和随机调度技术简化无线设计

虚拟机和随机调度技术简化无线设计

——
作者:Mike Woodward时间:2005-09-12来源:EDN电子设计技术 收藏

虚拟机和随机调度技术简化无线设计

本文引用地址:http://www.eepw.com.cn/article/8481.htm

一种新的无线设计方法使设计师们能将多种基于分组的标准融合到资源受限的手机硬件中。
  系统设计人员有时将用户设备手机的传统栈开发方法称为“基于竖井”的开发方法,因为这种开发方法在软件和硬件之间是极端纵向集成的,而且缺乏与其它栈的横向集成(图 1)。在实现多种基于分组的标准时,这种竖井方法就不适用了,因为它假设协议栈开发人员“拥有”基本的硬件资源,因而能够做出有关资源的假定,例如临时的和永久的缓存器分配。这些可用性假设在多模式环境中是毫无意义的,因为在基本时序上相互可能“冲突”的栈都会竞相获得各种资源,例如存储器。
  竖井方法假设你可以在设计时配置最坏情况下的系统装入,从而使你可以在系统设计期间,而不是在运行时分配资源。但是,这种方法基本上不适用于多通道的基于分组的系统,因为其峰值资源装入与平均资源装入相差很大。另外,竖井方法还假设一个设计小组对系统进行编码,并在开发期间,标准不会发生重大变化。对于现代通信系统来说,两种假设都可能是错误的。
  基于竖井方式的开发常常会使各种功能实现方法的资源使用率、调用格式以及行为等假设泄漏到设计的其它部分中,导致许多不良的设计习惯打着效率的旗号而付诸实现。例如,由于知道各种功能要花多少时间(以周期计)来执行,又知道每种功能函数需要多大的临时存储器,系统设计人员就会常常编写出静态的临时存储器调度程序,从而使得时间上不重叠的多个例行程序使用一个公共缓存器,由此避免代价可能很高的对 malloc()和 free()的不确定调用。但是,这样的设计往往是脆弱的。如果你要重新实现任何引擎,造成资源分布特性、时序两者之一或同时变更;如果基本硬件也要改变;更糟的是,如果某个栈与另一个栈一起共享基本资源(多模式问题),则从零开始的重新设计就不可避免了。


图 1 传统竖井方式开发采用纵向实现方法,缺乏与其它栈的横向集成。

  替代方法
  与任何极为复杂的设计问题一样,这一问题的最佳解决方法是将问题划分为可以自主处理的不太复杂的块。这种替代方法的基本概念模型在本文中称为虚拟机方法,它假设一个通信栈的第一层被分解为执行件、虚拟机(运行期内核)和引擎(图 2)。


图 2 一种替代的开发方法将第一层软件体系结构建立在虚拟机的基础上。

  对运行中的第一层软件的分析表明:该软件把 80~90% 的执行时间用于与无线设备相关的计算密集的信号处理变换。这些资源消耗大的功能包括傅里叶变换、矢量乘法、FIR 滤波器和采样抽取器。实际上,这些变换在不同的无线设备中表现出高度的共通性。这些资源消耗大、基本与应用系统无关的元件,要么用专用硬件来实现,要么用平台高度优化的软件来实现。推荐的体系结构用一种特殊的方式处理资源消耗大的功能,即生成“引擎”。具体地说,这种体系结构要参照与其行为上等效的产品,对一些引擎进行性能试验,剖析其性能,实现独特形式的资源仿真。
  剩余的 10% 处理资源(即执行元件)本质上是一种起控制作用的状态机,可按专门的无线标准要求进行变换。执行程序通常是极其复杂的,但其所需的处理资源却较少。这些资源消耗小的、基本上专用的元件很少包含天生就接合到基本硬件衬底上的资源。实际上,无论它们用硬件还是用软件来实现引擎,它们都可以移植到使用相同虚拟机运行期内核的任何其它设计中。执行功能的实例在第三代设计中有:一个数据平面的总数据流表达式、采集与跟踪逻辑以及各平面的通道生成和删除。
  替代方法建立在一个以瘦虚拟机运行期内核为核心的体系结构上。这种体系结构能将执行元件与高 MIPS 引擎分开。在其最简化的级别上,它为半导体硬件和 RTOS 提供了使用可移植基带软件的抽象层。这种功能并不取代 RTOS;系统仍然使用引擎位于处理器(通常是一个 DSP)中的 RTOS 服务。虚拟机运行期元件需要识别公共的线程、中断、内存和资源管理模型,然后设计师将这些模型映射到可用的原语中,以通过运行期实现方法生成任何第三方 RTOS。虚拟机还包括复杂的资源管理功能,这些功能对于解决第一层无线开发的瓶颈是至关重要的(图 3)。


图 3 虚拟机运行期具有资源管理和调度功能,可将执行元件与引擎分离开来。

  从资源调度的角度看,如果高层代码要直接调用引擎的话,则所有这些努力都将是徒劳的。直接调用或多或少会影响基本的执行顺序和线程模型,而这对于高效的实现方法来说又非常关键。更糟的是,调用者要负责为基本引擎建立适当的存储器,这实际上导致显式的资源调度。在本文所述方法中,只有一个中间件服务(即虚拟机运行期内核)可以调用一个引擎。具体来说,该运行期内核包括一个调度程序,从效果来说,这一调度程序是一个跨越所有执行过程和逻辑线程的范例。它使用一种插入式的调度策略来决定把这些任务中的哪一个提交给基本的 RTOS 去执行,决定它将使用多少 RTOS 线程,并决定采用哪种优先级和逻辑时间步长。
  仿真是关键
  尽管你必须保证你的系统是正确的,但对资源管理做出适当判断也是同样必要的。当然,最坏情况分析是不恰当的,在多模式设计时会给出过于悲观的结果,因而造成浪费。但是,利用性能仿真可以揭示出各种栈在时间上互相“冲突”的相关性。当执行元件调用引擎时,虚拟机资源仿真并不运行引擎本身,而是相当简单地更新一张“资源使用记录表”。在周期精确的仿真期间,或者在实际硬件执行期间,你都能通过一个性能剖析过程单独采集到各个引擎的资源使用信息。这一剖析包含了一个相应独立变量(例如矢量大小或位宽度)在某一范围的数值对各种类型资源(内存、周期、总线带宽等)的使用记录。它可以随机地表达出引擎资源的概况,例如,某个任务需要的周期数并不简单地是其输入范围的确定函数。(例如,一个涡轮式编码器处理较不完整的输入矢量就要花更多的周期。)一个参量表保存着每个引擎的资源成本,它是引擎元件化描述的一部分



关键词: RadioScape 有限公司

评论


相关推荐

技术专区

关闭