《 From YChart to Seamless integration of Application Design and Performance Sim译文.docx
《《 From YChart to Seamless integration of Application Design and Performance Sim译文.docx》由会员分享，可在线阅读，更多相关《《 From YChart to Seamless integration of Application Design and Performance Sim译文.docx（20页珍藏版）》请在冰豆网上搜索。
《FromYCharttoSeamlessintegrationofApplicationDesignandPerformanceSim译文
从Y图到程序设计和性能仿真的无缝整合
摘要
在嵌入式系统设计的架构探索阶段，性能仿真技术扮演着重要的角色。
现代移动设备支持多种程序，这些程序因移动平台高速增长的计算能力而变为可能。
在为评估平台上新程序的可行性而进行程序建模之后，需要进行快速的性能评估。
为了减少性能仿真的建模开销和上市时间，程序建模和性能仿真阶段必须被无缝整合在一起。
在这个领域的里程碑式技术是围绕着一些我们最先解释的重要概念发展起来的。
接着，我们探究了每个技术的成果，说明了它们的解决方式，扩展并/或应用这些重要概念。
在提及这个领域中完成的相关工作之后，我们详细说明了方法和工具，这些能够用来作为实现程序设计和性能评估无缝整合目标的潜在解决方法。
关键词：
性能模型，程序模型，平台模型，Kahn进程网络，Y图，UML
.简介
嵌入式系统应用在市场的各个角落，包括消费电子、医疗设备、工业控制、网络和通信、自动化和办公自动化[1]。
移动手持多媒体设备正在凭借多样的应用程序而高速发展。
新的多媒体应用程序的使用正在对手持终端的平台、性能和能量限制同时提出挑战。
为了高效地开发这些产品，在程序设计阶段为系统级性能评估提供蓝图是很重要的，这样减少了耗费在其中的时间和精力。
我们以应用在这个领域的重要概念开始，然后解释这个领域中的重要成果。
之后我们集中注意力到我们的终极目标，阐述了实现程序设计和性能仿真无缝整合阶段所需的这一整套工具。
本文剩余部分组织如下：
第二章介绍了性能仿真技术应用的重要概念。
第三章详细描述了这个领域里程碑式的成果。
第四章我们集中注意力确定了能够用来实现程序设计和性能仿真无缝整合的整套工具和技术。
这套工具叫做ApplicationWorkloadbasedPerformancesimulation。
接着实现了这套方法，我们展示了GENESYS程序模型如何被扩展成作为基于性能仿真的ApplicationWorkload的蓝图。
第六章列出了结论，并在最后给出了参考文献。
．重要概念
Y图[7]概念用性能模型隔开平台仿真模型和程序模型，如图1所示。
图1性能模型的主要组件
程序模型映射到对应的平台模型，并且如图2所示进行协同仿真。
图2Y图
设计者获取性能指标，并且更新任一个模型或两个模型均得到更新。
如果性能指标满足目标性能需求，则结束架构探索，进入开发阶段。
如果优先目标是架构探索的话，以上工作需要不断重复。
A.平台模型
性能评估使用的所有里程碑式技术，都在更高抽象层次上对平台进行建模。
每个技术都以不同的方式处理抽象问题；有些使用更高层次的交易级模型，这些模型强调从通信中分离出计算；有些通过图表的方式对平台架构进行建模。
此外，Kahn进程网络[5]也已经在平台建模中被广泛应用，如图3所示。
图3用来性能评估的平台模型
B．程序模型
对于性能仿真，不需要在仿真进行时执行完整的功能说明，但是对于重现程序如同实际在系统架构上执行的仿真来说，是需要的。
性能模型不需要是完整和明确。
一些性能评估技术采用交易级的方法。
Trace也已经被用来在高抽象层次上，对程序行为和架构中它们之间的相互作用进行建模，这样避免了在架构探索时需要一个完备的函数模型。
程序模型也使用Kahn进程网络[5]计算模型，或者如图4所示分层的ApplicationWorkload建模方法。
图4用来性能评估的程序模型
C．Kahn进程网络
Kahn进程网络[6][9][10]由代表进程的节点和代表这些进程间信道的边组成。
为了对并行计算进行建模，在网络中一些自治计算节点使用通信线路进行互连。
为在一些或者所有输入线路上产生输出，给定的节点利用一些自己的存储器对通过输入线路的数据进行计算[5]。
通信线路在未知并且有限的时间内传输信息[5]。
节点也随时在它的其中一条输入线路上计算或者等待信息[5]。
每个节点紧跟着一系列程序[5]。
D．映射和协同仿真
性能评估策略需要系统中进行计算时的数据利用记录、通信资源和瓶颈的识别。
在定义了程序和架构模型之后，下一步是将程序子任务映射到架构资源和片上系统（SOC）workload的描述。
为了实现量化的性能分析，程序模型被首先映射到架构模型，然后与架构模型进行协同仿真。
在此之后，能够评估出每个程序--架构组合的性能。
E．指令集模拟器（ISS）
指令集模拟器（ISS）是一种仿真模型，它通过“读”指令和保持代表处理器寄存器的内部变量来模仿主机或者微处理器的行为。
指令仿真用在对另一个硬件平台[12]的机器代码进行仿真，来监视和执行机器代码指令[12]并提高包括处理器核心在内的仿真速度。
.重要的性能仿真方法
为性能仿真而开发的各种方法因不同的目的而采用不同的方式，不是利用所有第二章中提到的核心概念就是利用其中一部分。
我们现在阐明实现这些概念的方式，并巧妙地转向使用这个领域中里程碑式技术来获取目标相关的特定性能评估。
A.SPADE
该方法提出了一种在系统级对信号处理架构进行探索的策略。
它使用trace驱动执行单元作为平台架构组件来快速定义平台架构模型。
SPADE将程序与架构分开建模。
程序模型是函数性的，相对脱离架构。
架构模型定义了架构资源，以至于它们能被所有测试程序使用。
耦合保证了程序和架构模型的重用，并促进了探索性设计过程。
这些过程中，程序模型能够被连续映射到架构模型。
不构建完整功能性架构模型，这为设计者节省了大量时间，保证了可选架构的探索。
SPADE方法如图5所示[10].
图5在SPADE中应用的程序和平台模型
1）程序模型。
程序使用进程网络[5]计算模型来进行建模。
Kahn进程网络的执行是确定的，对信号处理程序建模效果相当好。
它也帮助程序设计人员来结合通信单元。
2）平台模型。
架构模型不对函数行为进行建模，但是确保函数正确性。
该模型能够用对架构中不同资源进行建模的通用组件库来进行构建。
加工资源通过拖拽不同组件来创建。
具有可配置数量的I/O端口的trace驱动执行单元（TDEU），以它们放入trace和连接TDEU的I/O端口和通信资源接口的顺序来说明trace入口。
3）映射和协同仿真。
进程被映射成TDEU。
映射可以是多对一的。
进程的trace入口使用TDEU来调度[10]。
进程端口被映射为I/O端口。
通道被映射到通信和存储资源的连接处，并且能够包含用户定义块[10]。
4）工具支持。
程序模型的仿真是基于Pamela的多线程环境[13]。
架构模型的仿真目前是基于TSS（系统仿真工具[14]）.通用组件库由TSS模块组成。
SPADE允许使用用户定义的TSS模块[10]。
SPADE为程序建模提供程序编程接口（API）[10]。
B.SESAME
这是一种当设计空间很广时，对多层嵌入式系统进行架构探索的规范方法。
大部分理想的备选架构是在更高的抽象层次上挑选出来的，然后降低层次，为进入下一个更低的抽象层次而加入细节，为达到叫做trajectory的最终架构铺路。
这是通过使用在特定的抽象层次上对选定的架构进行分析性建模，以及为在某个抽象层次选取最佳架构而进行多对象优化来实现的。
程序和平台建模以及它们之间的映射如图6所示。
图6程序模型，平台模型以及Sesame的映射层
1）程序模型。
对于程序建模，使用Kahn进程网络（KPN）计算模型[5]很好地满足了媒体处理目标程序。
KPN不允许对中断建模，这样限制了用时间相关行为对程序进行建模的能力。
2）平台模型。
架构模型在交易级[15]操作，并仿真由程序模型产生的计算和通信事件的性能序列。
架构模型从包括处理核心、通信媒体和多种存储器的性能模型模板的通用组件库来构建[9]。
3）映射和协同仿真。
设计者通常根据协同仿真列出进一步进行评估的最终候选映射，如此程序模型在架构模型上的最优映射才是终极目标。
虚拟处理组件和用于通信的FIFO缓冲器，通过虚拟处理器提供给中间的映射层。
程序模型中的Kahn进程与映射层中的虚拟处理器之间存在一种一对一的关系。
用来处理从虚拟处理器到架构模型组件程序事件的机制，确保了来自不同事件trace程序事件的无死锁调度[17]。
4）工具支持。
程序模型也可以由一个叫做Compaan[18]的框架产生，也可以由C/C++代码序列手动产生。
执行引擎像运行使用Pthread的独立线程一样运行由C++编写的Kahn进程。
在YML中描述了程序模型结构[19]。
架构模型用Pearl[20]或者SystemC[21]来实现。
对于SystemC架构模型，为SystemC提供了一种叫做SCPEx的附加库。
C.TAPES
这是一个基于trace的架构探索策略，该策略以平台资源trace的形式捕捉架构功能。
图7给出了作为架构探索循环一部分的性能评估过程中的高层设计。
从详细说明或完整的函数模型开始并考虑初始架构来建立架构模型，这是性能评估架构这一步的输入[6]。
根据分析结果，架构被反复修改直到满足设计要求。
架构探索结果产生在随后实现阶段使用的架构的详细说明。
在保证符合详细说明的同时，进行功能验证[6]。
图7更高层设计流的TAPES视图
1）程序模型。
Kahn模型是用来对那些对流处理建模效果很好的程序进行建模。
它使程序设计人员容易地结合通信部件。
使用写函数经处理端口向通道写入数据[6]。
执行函数只产生trace入口，在程序级报告处理行为。
2）平台模型。
在平台模型中，任务的处理被它们对相应资源的执行延时所取代。
每个资源的功能由一系列与外部交易交互的处理延时来描述。
共享通信资源并没有抽象成相同的程度[6]。
为了捕捉因来自类似资源的交易而产生资源冲突的动态信息，在通信资源模型中实施竞争判定机制[6]。
在仿真开始时，仿真模型从抽象资源类库中被实例化出来。
与交易相关的模块构建系统架构。
为定义架构功能，用户必须提供架构中使用的模块的详细功能说明。
仿真模型通过为所有架构资源指定trace来捕捉系统功能[6]。
3）映射和协同仿真。
根据不同部分的决定，每个资源围绕着一个或多个与不同处理序列相关的trace。
Trace驱动架构资源的相互作用使能了系统行为仿真。
共享资源模块实施冲突访问的判定机制，在所谓的模块中产生了因仲裁延时和处理时间而伸展的trace。
图9中给出了图8所示trace的开始。
图8Trace的例子
图9给出了CPU和加速器的阻塞互动。
在一个写交易中，请求数据先被写入加速器，紧接着读取结果。
在写操作之后，触发对应的加速器trace的执行。
随后的读交易阻塞CPU直到加速器结束，然后结果传回CPU[6]。
图9执行时CPUTrace的转换
4）工具支持。
Kahn模型将程序分成一套类似的通信进程。
SPADE也为程序设计人员进行程序建模提供程序编程接口（API）。
IV.程序设计和性能仿真简介
在详细介绍了性能仿真的重要技术之后，我们现在集中注意力于用于实现紧密相连的程序设计和性能仿真技术的工具和技术。
为减少上市时间，需要一种从程序模型中抽出程序性能模型的策略。
方便地完成程序模型到平台模型的映射，性能仿真也向前推进。
ApplicationWorkload为作为蓝图的程序模型建模，其次平台模型用运行在交易级的模型库来实例化。
实现该方法的这一套工具叫做ApplicationWorkloadbasedPerformancesimulation（ABSULOT）[26]。
GENESYS程序模型能够扩展得到分层的程序模型；能够明确ApplicationWorkload模型中的相应层，来减少建模工作。
我们先讨论基于性能仿真的ApplicationWorkload，然后建立GENESYS跨领域程序建模形式。
接着我们讨论了GENSYS[27]程序模型扩展到可导出的Workload模型对应的那些层的方式。
A.基于性能仿真的ApplicationWorkload
顺着Y图模型，它由两个主要部分组成：
ApplicationWorkload和执行平台模型[7]。
Workload和平台模型是分层的[23]。
首先最终用户需求被建模为面向服务的程序模型，该模型具有层次结构。
最顶层表示用户可见的服务，由子服务组成，并且进一步分解为基本服务。
然后模块的功能仿真用TelelogicTauTML2Tool来实现，不仅为验证提供一系列图表并建立Workload模型。
平台模型由硬件和平台软件构件组成。
结果模型提供了Workload模型使用资源和平台服务的接口[23]。
为得到性能结果，Workload和平台模型被转换成SystemC并协同仿真。
1）Workload模型。
Workload模型是用UML或者SystemC来创建的。
为了协同仿真，UML模型被转换为SystemC。
为了实现该转换，用UML创建平台骨架模型来将Workload模型映射到平台模型，接着通过一个由LUND大学开发的作为TelelogicTauTool插件的工具来将UMLWorkload转换为SystemC。
映射完成之后，模型被结合起来用于交易级性能仿真。
基于仿真结果，我们能够分析比如处理器利用率、存储器通信量和执行时间。
如图10所示。
图10性能建模方法
Workload由如图11所示的各层组成。
图11ApplicationWorkload层
最顶层描述了最高层Workload由一个或更多个嵌入式系统支持的程序组成，来满足不同应用实例。
（1）
其中A1,A2,…,An是不同的程序，Ca是控制符。
在第二层，每个程序细化为一个或多个（平台级）服务。
（2）
其中Cp是服务P1,P2,…,Pn之间的控制符。
在第三层，每个进程Workload表示为一个或多个函数Workload的结合。
（3）
其中Cf是函数F1,F2,…,Fn的控制符。
操作系统模型在进程级上进行Workload的调度。
函数Workload是控制流图。
（4）
其中节点vi∈V是基本块，gi∈G是分支。
Block是用来作为负载特性的基本负载的规则集合。
Load是用来作为负载特性的基本负载的规则集合（?
）。
2）执行平台模型。
平台模型由3层组成：
组件层、子系统层和平台架构层，如图12所示。
组件层由进程、存储和元件互连组成。
子系统层建在组件层之上，并且描述系统组件及它们是如何连接的。
平台架构层通过包含平台软件建在子系统层之上，并在映射过程中将Workload模型连向平台[25]。
图12平台架构模型层
3）映射和协同仿真。
系统模型是在GNU/Linux环境中，使用CMake构建系统和OSCISystemC库来建立的。
仿真器是命令行程序。
在仿真过程中，它在仿真结束后将进程信息打印到标准输出设备上；它显示所有性能结果。
4）工具支持。
C++和基于XML的配置工具VTTCOGNAC用来自组件库的TauUML2工具来草拟平台模型，组件参数使用UML来设定。
该工具从Tau读取XML输出，并通过结合UML产生的SystemCWorkload模型和组件库中的SystemC组件模型，来创建系统模型。
系统仿真器VTTBEER接着执行仿真。
使用一个基于C++的工具VTTVODKA来观察数据，比如用图形显示处理器利用率曲线。
B．GENESYS程序建模
GENESYS是一种面向服务的基于组件的程序方法。
通过描述一系列在GENESYS中定义的足够用来实现建模目标的视图开始建模过程[27]。
这些视图使用UML2.0MARTE概要来实现，并简要描述如下：
1）应用实例视图。
通过应用实例在高抽象层次描述系统功能。
2）结构视图。
通过核心和子系统提供给程序的可选服务来描述程序和平台子系统之间的接口。
3）语法视图。
描述服务方（子系统连同接口）理解的语法。
服务者确认来自不同程序（客户）的消息。
4）行为视图。
描述程序及其服务的行为方面。
C．连接GENESYS程序设计到性能建模
对于性能建模，通过从扩展的GENESYS行为视图映射到分层的Workload模型，接着如图13所示转换成SystemC，用UML创建ApplicationWorkload模型。
图13性能仿真方法
平台建模和程序与平台模型间的映射，与第四章所描述的相同。
1）GENESYS行为视图。
扩展GENESYS行为视图去抽出程序的分层结构。
第一层定义了一个或多个嵌入式系统支持的程序来满足不同的应用实例。
（1）
其中A1,A2,…,An是不同的程序，
是控制符。
在第二层每个程序用使用的平台服务来细化。
（2）
其中
是服务S1,S2,...,Sn之间的控制符。
每个进程运行在一个特定的子系统上。
（3）
其中
是进程P1,P2,…Pn之间的控制符。
在第四层每个进程由内部的子系统服务调用组成。
（4）
其中
是控制符。
子系统服务请求调用函数（子系统内部）去合理地处理服务请求。
如果
是控制符，我们能用第五层来表达如下：
（5）
2）抽取程序负荷模型。
在比较了GENESYSWorkload模型层与ApplicationWorkload模型层之后，我们明确了对应Workload模型中层的程序模型层。
以这样的方式，前者作为后者的蓝图，如图14所示。
图14从程序模型层抽取的ApplicationWorkload模型层
3）映射和协同仿真。
一旦获得了ApplicationWorkload层，它们被映射到平台模型。
在协同仿真之后，通过性能探针获得结果。
结果也以相关者角度来确认非功能性属性是否满足设计[23]。
这是通过在GENESYS语法视图[27]注释非功能属性来完成的，然后从性能探针[23]获得结果。
V．结论
在详细说明了嵌入式系统性能仿真领域中的重要概念之后，我们给出了这个领域的重要成果。
在那之后，我们展示了这个领域的最新趋势，就是程序设计和性能仿真阶段的无缝整合。
详细说明了为实现这个里程碑式技术而发明的一整套工具，该方法用GENESYS程序架构建模形式来展示。
.鸣谢
本文部分在FinnishDIEM计划中受Tekes资助，部分在ArtemisSOFIA计划中受Tekes和欧盟的支持。
参考文献
[1]EmbeddedSystemsArchitecture:
AComprehensiveGuideforEngineersandProgrammers（EmbeddedTechnology）TammyNoergaard,ELSEVIER.
[2]K.Keutzer,A.Newton,J.RabaeyandA.Sangiovanni-Vincentelli,“System-leveldesign:
orthogonalizationofconcernsandplatformbaseddesign”,IEEETransactionsonComputer-Aided
DesignofIntegratedCircuitsandSystems,19（12）,2000,pp.1523-1543.
[3]Lappeteläinen,Anttiet.al.,'NetworkedSystems,Services,andInformation-TheUltimateDigitalConvergence'.1stInternationalConferenceonNetworkonTerminalArchitecture,June11,2008,Helsinki.
[4]Oliver,Ianet.al.,'Sedvice:
ATripleSpaceComputingExplorationEnvironment'.TripcomWorkshop,Galway,April2008.
[5]G.Kahn,“TheSemanticsofaSimpleLanguageforParallelProgramming,”Proc.IFIPCongress74,1974.
[6]T.Wild,A.Herkersdorf,andG.-Y.Lee,“TAPES—Trace-basedarchitectureperformanceevaluationwithSystemC”,DesignAutomationforEmbeddedSystems,Vol.10,Numbers2-3,SpecialIssueonSystemC-basedSystemModeling,VerificationandSynthesis,2006,pp157-179.
[7]B.Kienhuis,E.Deprettere,K.VissersandP.vanderWolf.Approachforquantitativeanalysisofapplication-specificdataflowarchitectures,”inProceedingsoftheIEEEInternationalConferenceonApplication-SpecificSystems,ArchitecturesandProcessors
（ASAP’97）,pp.338–349,Zurich,Switzerland.July1997.
[8]http:
//www.uml.org/#Articles
[9]A.PimentelandC.Erbas,“ASystematicApproachtoExploringEmbeddedSystemArchitecturesatMultipleAbstractionLevels”,IEEETransactionsonComputers,vol.55,no.2,Feb.2006,pp.99–112.
[10]P.Lieverse,P.vanderWolf,K.Vissers,andE.Deprettere,“Amethodologyforarchitectureexplorationofheterogeneoussignalprocessingsystems”,KluwerJournalofVLSISignalProcessing29（3）,2001,pp.197-207.
[11]UML2andtheUnifiedProcess:
PracticalObject-OrientedAnalysisandDesign（2ndEdition）（Addison-WesleyObjectTechnologySeries）
[12]http:
//en.wikipedia.org/wiki/Instruction_Set_Simulator
[13]A.J.C.vanGemund,“Performancepredictionofparallelprocessingsystems:
ThePAMELAmethodology,”inProc.7thACMInt.ConferenceonSupercomputing,Tokyo,
升级会员 