嵌入式系统软硬件协同设计技术综述熊光泽.docx

嵌入式系统软硬件协同设计技术综述熊光泽.docx

《嵌入式系统软硬件协同设计技术综述熊光泽.docx》由会员分享，可在线阅读，更多相关《嵌入式系统软硬件协同设计技术综述熊光泽.docx（21页珍藏版）》请在冰豆网上搜索。

嵌入式系统软硬件协同设计技术综述熊光泽

嵌入式系统软/硬件协同设计技术综述

熊光泽,詹瑾瑜

（电子科技大学计算机科学与工程学院,四川成都610054）

牗gzxiong@uestc.edu.cn牘

也就是进行可测试性度量。

可测试性度量方法需

满足精确性和简单性两个要求,所谓精确性是指可测试性度

量方法能准确地预计产品测试程度生成的困难,并且定位到

产品的某一部分,从而便于对产品设计进行更改;而简单性要

求则是指度量可测试性的计算量应小于测试程度生成的计算

量,否则,可测试性度量方法就会失去实际的应用意义。

目前

可测试性度量方法主要是针对数字电路系统[34～36]。

4.5.2　可测试性机制的设计与优化

可测试性设计需首先将某种能方便测试的可测试性机制

引入到产品中,再提供获取被测对象内部测试信息,因此合

理、有效的设计可测试性机制是成功提高产品可测试性水平

的基础,现有的可测试性机制设计方法有:

LFSR方法、电平灵

敏设计方法、IDDQ方法、边界扫描机制等[37～38]。

可测试性机

制的引入虽然可以提高系统的可测试性指标、降低产品的全

寿命周期费用,但是会在一定程度上增加产品的成本。

因此,

综合权衡可测试性机制的性能和费用,进行可测试性机制的

优化设计是可测试性设计技术能否成功应用的另一个重要因

素[39]。

4.5.3　测试信息的处理与故障诊断

为了提高产品质量和可靠性、降低系统全寿命周期费用

的目标,要求可测试性技术能够方便、快速地获取有关被测产

品状态的信息,确定产品工作正常与否、性能是否良好、是否

存在故障以及故障类型,以便采取设计调整、故障排除等后续

工作。

在对复杂的对象进行测试时,难点往往不在于如何获

取测试信息,而在于如何对所获取的大量信息进行处理。

例

如,对于一个具有N个测试点的数字电路而言,所能获取的测

试信息的总量为N*2N位,随着N的增大,测试信息总量将呈

指数型增长,因此能否对所获取的测试信息进行有效处理并

对可能存在的故障进行精确诊断是可测试性设计技术成功应

用的关键之一。

4.6　低功耗设计技术

随着嵌入式系统广泛应用于手机、PDA等便携式电子设

备,功耗成为设计中需要重点考虑的性能指标。

嵌入式系统

所采用的CMOS功耗主要由动态功耗、静态功耗和短路功耗

组成,要降低CMOS电路的动态功耗可以通过减小等效电容、

降低电源电压、降低工作频率以及节点的翻转概率来实现;而

要降低CMOS电路的短路功耗和静态功耗则需要调整阈值电

压、电源电压等,低功耗设计技术实际上就是通过改变这些参

数以达到降低系统功耗的目的,改变这些参数可以在不同的

设计层次上进行。

图4　不同抽象层次优化对功耗的改善程度

与嵌入式系统设计流程相对应,低功耗设计技术贯穿于

系统设计、软件设计、逻辑设计、硬件设计等各个阶段,一种常

用的设计层次分类方法[40]是:

系统级/行为级（System/

Behavior）、结构级/寄存器传送级（Architecture/RTL）、逻辑级

（Logic）和电路级/晶体管级（Circuit/Transistor）。

研究表

明[41],抽象层次越高,优化的空间越大,采用低功耗技术可降

低的功耗比例越大,效果越明显,如图4所示,因此嵌入式系

统的低功耗设计技术需要从系统级入手进行研究。

5　结语

嵌入式系统软/硬件协同设计方法学是一个非常广泛的

研究课题,主要包括:

系统建模、软/硬件协同综合、设计功能

和性能指标评价技术、软/硬件协同仿真、软/硬件协同验证、

SoC测试调度技术等方面,并且还分为不同的设计层次。

本

文介绍了嵌入式系统现状,分析了今后的发展趋势,阐述了传

统方法的缺陷,引出了一个新的设计方法学———嵌入式系统

软/硬件协同设计方法学,并介绍了支撑新方法学的相关技术。

近年来,国内外对嵌入式系统软/硬件协同设计方法学的

研究开始重视,但是仍处于发展状态,许多相关技术仍未成熟

和实用化,没有成型的商业产品问世,这给我们带来了机遇和

挑战。

参考文献:

犤1犦　ADAMSJK牞THOMASDE.TheDesignofMixedHardware/Software

Systems犤A犦.33rdDesignAutomationConference犤C犦.1996.

犤2犦　HENKELJ牞ERNSTR.AnApproachtoAutomatedHardware/Soft-

warePartitioningUsingaFlexibleGranularitythatisDrivenbyHigh-

LevelEstimationTechniques犤J犦.VeryLargeScaleIntegration牗VL-

SI牘Systems牞2001牞9牗2牘牶273-289.

犤3犦　GUPTAR牞MICHELIGD.Hardware-SoftwareCosynthesisforDigital

Systems犤J犦.IEEEDesign＆Testofcomputers牞1993牞26牗4牘牶29-

41.

犤4犦　ERNSTR牞HENKELJ牞BENNERT牞etal.TheCOSYMAEnviron-

mentforHardware/SoftwareCosynthesisofSmallEmbeddedSystems

犤J犦.MicroprocessorsandMicrosystems牞1996牞20牗3牘牶159-166.

犤5犦　HENKELJ牞ERNSTR.High-LevelEstimationTechniquesforUsage

inHardware/SoftwareCo-Design犤A犦.ProceedingsofIEEE/ACM

AsiaandSouthPacificDesignAutomationConference犤C犦.1998.

353-360.

犤6犦　ELESP牞PENGZ牞KUCHCINSKIK牞etal.SystemLevelHardware/

SoftwarePartitioningBasedonSimulatedAnnealingandTabuSearch

犤J犦.DesignAutomationEmbeddedSystem牞1996牞2牗3牘牶5-32.

犤7犦　FILBOFC牞MACIELP牞BARROSE.APetriNetBasedApproach

forHardware/SoftwarePartitioning犤J犦.IntegratedCircuitsandSys-

temsDesign牞2001牞15牗7牘牶72-77.

犤8犦　DANIELR牞PETERS牞PAULS.ADetailedCostModelforConcur-

rentUsewithHardware/SoftwareCo-Design犤A犦.Proceedingsofthe

39thConferenceonDesignAutomation犤C犦.2002.269-274.

犤9犦　LEVMANJ牞KHANG牞ALIREZAIEJ.Hardware-SoftwareCo-Syn-

thesisofPartiallyRe-ConfigurableEmbeddedSystemsOptimizedfor

ReducedPowerConsumption犤A犦.ProceedingsoftheIEEECanadi-

anConferenceonElectricalandComputerEngineering犤C犦.2003.

1835-1840.

犤10犦　PARAMESWARANS.CodePlacementinHardware/SoftwareCo-

SynthesistoImprovePerformanceandReduceCost犤A犦.Proceed-

ingsofDesign牞AutomationandTestinEurope犤C犦.2001.626-

632.

犤11犦　DOBOLIA.IntegratedHardware/SoftwareCo-SynthesisforDesign

ofEmbeddedSystemsunderPowerandLatencyConstrains犤A犦.

ProceedingsofDesign牞AutomationandTestinEurope犤C犦.2001.

612-619.

犤12犦　LEVRNANJ牞KHANG牞ALIREZAIEJ牞etal.Hardware-Software

Co-SynthesisofPartiallyRe-ConfigurableEmbeddedSystemsOpti-

mizedforReducedPowerConsumption犤J犦.ElectricalandComput-

erEngineering牞2003牞5牗3牘牶1835-1840.

（下转第764页）　

760　　　　计算机应用2006年

理论也开始应用于嵌入式系统的软/硬件验证。

断言抽象本来是一种验证纯软件系统正确性的形式化验证方

法,首先由Graf和Saidi在文献[19]中提出,近年来很多学者

对其进行了改进,同样使其应用到了软件和硬件并存的系统

验证中。

LuisAlejandroCortes等人提出了PRES（Petrinet

basedRepresentationforEmbeddedSystem）形式描述方

法[20～21],用Petri网对传统嵌入式系统软件和硬件进行描述,

再用Alur等人在文献[22]中提出的基于混合自动机模型对

此模型进行验证。

清华大学蒋屹新等人提出了基于Petri网

的模型检验研究[23],但是此方法是一种仅针对软件系统的形

式化验证方法,没有硬件方面的考虑,无法直接有效地应用于

验证嵌入式产品。

综合分析上述的方法,它们都只是针对传

统的嵌入式系统或特定的软件系统的验证方法,没有考虑到

基于IP核和构件重用的嵌入式系统软/硬件协同验证相关问

题,这是今后研究的重点。

4.3　性能指标评价技术

嵌入式系统是以应用为中心、对系统功能和性能指标都

有严格要求的专用计算机系统。

标准评价各性能指标是保证

嵌入式系统需求的必要条件。

4.3.1　成本

系统成本由开发成本、生产成本等多种因素组成,不考虑

开发成本而仅考虑系统实现软件和硬件的成本是片面的、不

现实的。

成本参数有累加的特点,若将系统划分成几个子系

统,则系统总成本等于各个子系统成本之和。

系统成本公式

描述如下:

C（system）=∑i∈systemCi

4.3.2　面积

随着嵌入式系统相关技术在消费电子、智能家电和通信

设备等领域的广泛应用,嵌入式硬件的集成度越来越高,产品

对硬件面积的要求也越来越严格,众多体积小、重量轻的嵌入

式产品纷纷问世。

系统硬件面积和各硬件组成部分直接相

关,基本上可以通过各个硬件单元面积累加的方法获得。

系

统硬件面积公式描述如下:

S（system）=∑i∈hardware（system）Si

4.3.3　功耗

功耗已经被公认为是一个设计现代电子产品的重要指

标,它是针对增加便携式产品电池的使用寿命提出来的,同时

还要考虑到尽可能降低芯片封装和冷却装置的成本,提高系

统可靠性以及环境因素等。

由于电池材料技术满足不了系统

日益增长的功耗需求,功耗问题已经成为系统设计过程中要

重点考虑的性能指标之一。

随着设计层次不断提高,为降低

系统功耗所做的响应处理也被提到了更高的层次。

系统功耗由静态功耗和动态功耗两部分组成,其计算公

式描述如下:

P（system）=Pstatic+Pdynamic

Pstatic=∑i∈systemPstatic（i）

Pdynamic=∑i∈system,Task∈Task（software（system））P（i,Task）

4.3.4　时间性

大多数嵌入式系统都是实时系统,它们对系统的时间性

有着或多或少的要求,时间性成为嵌入式系统设计的一个重

要性能指标。

时间性由硬件运行时间和软件运行时间组成,

硬件运行时间是系统硬件运行所用的时间,可以通过将各个

硬件单元运行时间进行累加得到;软件运行时间是系统中所

有任务运行所用的时间,它与系统CPU的类型和任务数量有

关。

系统运行时间的公式描述如下:

T（system）=Thardware+Tsoftware

Thardware=∑i∈hardware（system）Thardware（i）

Tsoftware=∑i∈hardware（system）,Task∈Task（software（system））T（i,Task）

4.4　SoC测试调度问题

随着微电子技术的飞速发展,集成电路制造技术不断进

步,芯片的特征尺寸越来越小,系统集成度越来越高,使得制

造SoC成为可能[24],为了适应现代电子产品快速增长的功能

需求和日益紧迫的时间需求,设计者通常采用可重复使用的

IP核来搭建SoC,不仅能够简化设计过程,还有利于缩短产品

制造周期和开发成本,因此SoC技术逐步成为当前嵌入式产

品设计的主流技术。

对于一个成熟的嵌入式产品,人们总是追求成本最小化,

嵌入式产品成本一般包括设计费用、制造费用和包装测试费

用。

SoC设计方法可以缩短设计周期,降低设计费用。

但仅

仅降低设计费用是不够的,还需要尽可能降低测试费用,即要

缩短产品的测试时间[25～26]。

随着设计复杂度的增加,SoC上

重用的IP数量越来越多,为了缩短芯片测试的时间,需要尽

可能并行地测试芯片上的IP核。

芯片上的IP核规模有大有

小,各IP核所需要的测试数据端口也有多有少,而片上的封

装引脚和测试总线数目是一定的,为此这样可以将几个较小

的IP核输入输出端动态分配到同一测试总线上,允许它们同

时进行测试,因此需要在SoC设计中进行测试调度[27～28]。

SoC测试包括三个子问题:

测试访问机制（TestAccess

Mechanism,TAM）设计问题、核封装设计问题和测试调度问

题[29～30]。

在SoC中,IP核嵌入到芯片中作为芯片的一部分,因此

无法从芯片引脚直接访问到IP核的输入输出端口,必须要为

IP核提供相应的测试访问通道。

测试访问机制是将测试激

励从芯片的输入引脚传送到核输入端口上,再将核输出端口

的测试响应传送到芯片的输出引脚上,常用的TAM结构有并

行直接访问结构、串行访问结构、测试总线访问结构、可寻址

测试端口访问结构等。

核封装提供一个IP核与TAM间的界面,它可以提供多

种操作模式,如正常工作模式、核测试模式、互连测试模式和

分流模式,另外核封装还能匹配核端口数量与TAM宽度。

测试调度是一个确定SoC中各IP核测试开始与结束的

时间过程,它的原则就是尽可能缩减测试时间。

目前已经有

很多国内外专家从事这个问题的研究,并取得了一些初步成

果。

Chakrabarty[31～33]证明了SoC测试调度问题的一个NP-

Complete问题,并建立了测试调度问题的整数线性规划

（IntegerLinearProgramming,ILP）模型,虽然基于ILP的测试

调度方法取得了很好的实验效果,但是其计算复杂度高,不适

合于测试大规模SoC,目前一些专家从事采用启发式算来解

决SoC测试调度问题的研究。

4.5　可测试性设计技术

随着嵌入式产品复杂性的增加,根据设计或研制完毕的

系统来制定测试方案已经无法适应实际生产的需要,要求在

系统设计时提早考虑测试的问题,即衡量一个系统设计的好

坏不仅要看其功能和性能的优劣,还要考察其测试的方便程

度。

因此需要从可测试性度量、可测试性机制的设计与优化、

测试信息的处理与故障诊断等方面进一步研究嵌入式系统的

可测试性设计技术,提高设计效率,缩短设计周期。

4.5.1　可测试性度量

要提高产品的可测试性,首先要对产品的可测试性水平

759第4期熊光泽等:

嵌入式系统软/硬件协同设计技术综述　　　　

;

（2）设计自动化层次低。

系统级设计由设计人员手工完

成,设计的好坏依赖于设计人员的经验,而随着系统规模不断

提高,设计复杂度将往往超出人的思维范围,导致设计不当;

（3）设计过程串行化增加了设计周期。

目前的设计流程

主要采用先硬件后软件的开发模式,即实现了硬件的物理原

型后才开始开发软件,因此串行设计不能充分及时地进行全

系统综合考虑,导致设计失误增加,设计过程拖延;

（4）缺乏设计重用支持。

目前的嵌入式系统设计几乎都

是从零开始的,没有很好地利用过去开发的成果,导致产品问

世周期增长,市场竞争力下降。

图2显示了嵌入式系统设计复杂性和设计生产率的增长

趋势。

由此可知,目前设计生产率的提高速度赶不上设计复

杂度增加的速度,设计方法和工具成为制约嵌入式系统发展

的瓶颈,嵌入式系统设计方法学期待革新。

图2　设计复杂度和设计生产率的增长趋势

3　软/硬件协同设计方法

针对嵌入式系统设计面临的问题与挑战,研究者们开始

探索新的设计方法学———软/硬件协同设计（Hardware/

SoftwareCo-Design）方法学。

软/硬件协同设计方法学的研究

始于20世纪90年代初期,第一届InternationalWorkshopon

Hardware/SoftwareCodesign会议于1993年召开,它标志着软/

硬件协同设计方法学的研究正式展开,软/硬件协同设计领域

正式确立。

软/硬件协同设计不仅是一种设计技术,同时也是

一种新的设计方法学,其核心问题是在设计过程中协调软件

子系统和硬件子系统。

与传统的嵌入式系统设计方法不同,软/硬件协同设计强

调软件和硬件设计开发的并行性和相互反馈,如图3所示,克

服了传统方法中把软件和硬件分开设计所带来的种种弊端,

协调软件和硬件之间的制约关系,达到系统高效工作的目的,

软/硬件协同设计提高了设计抽象的层次,拓展了设计覆盖的

范围。

与此同时,软/硬件协同设计还强调利用现有资源,即

重用构件和IP核,缩短系统开发周期,降低系统成本,提高系

统性能,保证系统开发质量。

图3　嵌入式系统软/硬件协同设计流程

4　软/硬件协同设计方法学

目前嵌入式系统软/硬件协同设计方法学研究还处于发

展阶段,许多技术仍未成熟和实用化,但是它将给嵌入式系统

设计带来革命性的变化,极大地提高设计生产力,软/硬件协

同设计方法学及其相关技术的研究意义重大。

4.1　软/硬件协同综合技术

嵌入式系统是软件和硬件一体化的系统,系统中很多功

能既可以由硬件来完成,也可以由软件来实现,硬件速度快,

而软件成本低,这就需要权衡系统的时间、成本等性能指标之

间的关系。

设计嵌入式系统时,要分析不同的软件和硬件组

合情况,决定系统各个模块由硬件完成或是软件完成,这是一

个非常重要的工作,这个划分系统软件和硬件的过程被称为

嵌入式系统软/硬件协同综合或者协同划分。

目前嵌入式系

统软/硬件协同综合相关技术还不成熟,面向SoC的商业化自

动综合设计工具尚在孕育之中,而嵌入式系统结构日益复杂,

开发时间要求日益紧迫,使得软/硬件协同综合问题成为嵌入

式系统软/硬件协同设计方法学的关键问题之一[2]。

现有的嵌入式系统软/硬件协同综合方法主要存在三方

面缺陷:

1）在传统的嵌入式设计方法中,划分软件和硬件的

工作是由设计者手工完成的[3],划分结果的好坏依赖于设计

者的经验,而且效率低下,在系统设计开发过程中变得日益突

出,所以需要一种自动化程度高的嵌入式系统软/硬件协同综

合方法;2）设计一个嵌入式系统不仅要考虑系统功能的需

求,还要考虑其性能需求和限制条件,然而很多嵌入式系统

软/硬件协同综合方法[4～7]只能评价一种或少数几种性能指

标,因此需要一种能够同时评价多种性能指标（如价格、面

积、功耗、时间性等）的嵌入式系统软/硬件协同综合方法;

3）嵌入式系统硬件日益复杂,集成度越来越高,SoC已经成为

设计嵌入式产品的主流技术,然而现有方法[8～13]并没有考虑

到SoC设计的一些特殊要求（如IP核重用问题）,因此需要一

种适应于SoC设计的软/硬件协同综合方法。

4.2　软/硬件协同验证技术

嵌入式产品竞争越来越激烈,只有缩短产品问世时间才

能在竞争中取胜,因此必须在系统设计和开发过程中尽早发

现系统中存在的各种问题和错误。

由于嵌入式系统自身的特

点,系统不仅对功能有特殊要求,同时对各种性能指标（如功

耗、面积、成本、时间性等）也都有严格的限制,如果在系统设

计开发完毕才对各个指标进行评价,那么一旦某些指标不满足

要求势必会推迟系统问世的时间。

因此需要一种新的技术在

系统设计开发完成以前的各个不同阶段根据系统性能指标要

求对设计方案综合评价,以验证系统实际的合理性和可行性。

目前嵌入式系统软/硬件协同验证的研究主要有两个方

向,即仿真验证和形式化验证。

仿真验证方法是在硬件开发以前用硬件描述语言（如

VerilogHDL[14]、VHDL[15]、SystemC[16]和HandleC[17]等）完成

硬件子系统的描述,用软件来搭建硬件以达到系统软件和硬

件并行开发的目的,能够完成系统的联合调试,灵活地纠正软

件和硬件的设计错误,避免了人力和物力的浪费。

但是硬件

描述语言能够描述的硬件只是普通嵌入式系统硬件的一个子

集,不适合描述大型的复杂系统,而且仿真系统与真实系统相

比,功能和性能偏差也很大,因此仿真验证方法通常只能验证

一些简单系统的逻辑需求,对于功能复杂或实时性要求较强

的系统就无能为力了。

形式化验证方法是建立被验证系统的数学模型,然后用

数学方法证明被验证系统的正确性以及各种性能指标是否满

足要求。

形式化验证方法比仿真方法更精确,所以目前更多

的国内外专家都将研究重点转移到形式化验证方法上。

卡内

基梅垄大学计算机系的EdmundM.Clarke教授和他的学生

从20世纪90年代就开始对硬件电路的形式化验证方法进行

研究,提出了一种基于有限状态机的模式检验理论[18],近年

758　　　　计算机应用2006年

期:

2005-10-15　　基金项目:

国家863计划资助项目（2003AAIZ2210）

　　作者简介:

熊光泽（1938-）,男,四川丹棱人,教授,博士生导师,主要研究方向:

嵌入式计算、实时操作系统、普适计算、系统仿真技术;

詹瑾瑜（1978-）,女,黑龙江绥化人,博士研究生,主要研究方向:

VLSI设计与测试、SoC软/硬件协同综合、SoC形式化协同验证、SoC测试调度、

实时嵌入式系统.

1的对比分析可以发现:

WinCE.NET提供的功能比

较多,比较适合作为多媒体终端（PDA、智能手机、移动终端）

的平台软件;RTLinux功能单一,一般适合学校学生学习嵌入

式操作系统用;VxWorks实时性较强,网络组件较多,比较适

合开发通信产品;RTEMS实时性最好,API兼容性最好,它广

泛用于