Download
1 / 18
180 likes | 346 Views
一种基于实时操作系统仿真的嵌入式系统设计和验证方法. An RTOS-Based Design and Validation Methodology for Embedded Systems. 摘要与关键词：. 摘要： 这篇论文展示了一个基于一种在嵌入式的设计和验证的方法之上的实时操作系统 . 我们方法的核心是从很早系统设计阶段使用一个实时操作系统的仿真模型 . 一个 jpeg 解码的应用实例被用来展示我们方法的有效性 . 关键词 :RTOS, 共仿真 , 嵌入式系统. 1, 背景介绍.
E N D
一种基于实时操作系统仿真的嵌入式系统设计和验证方法一种基于实时操作系统仿真的嵌入式系统设计和验证方法 An RTOS-Based Design and Validation Methodology for Embedded Systems
摘要与关键词： • 摘要：这篇论文展示了一个基于一种在嵌入式的设计和验证的方法之上的实时操作系统. • 我们方法的核心是从很早系统设计阶段使用一个实时操作系统的仿真模型.一个jpeg解码的应用实例被用来展示我们方法的有效性. • 关键词:RTOS,共仿真,嵌入式系统
1,背景介绍 • 实时嵌入式系统的函数已经被持续增加.例如,最近手机的功能已经远远不止是打电话了,现在的手机不仅能收发邮件,浏览网页,照相,录放电影.看电视节目.用GPS来显示使用者当前位置的地图.等等,在这样复杂的嵌入式系统里,实时操作系统在管理整个系统上起着一个十分重要的作用.包括软件和硬件.在这篇论文里,我们展示了一个实时操作系统为导向的方法,这个方法是在嵌入式平台的设计和验证.核心部分是用实时仿真模型在早期做的. • 鉴于此,系统的当前和相互作用的行为可以被专门计算.验证的有效性和执行的平滑行.这种方法是基于一种灵活的仿真平台和一个标准实时操作系统的完整仿真模型,我们可以聚焦于合仿真的应用上.但是不去描述如何去在嵌入式系统设计的内容里使用它. • 这篇论文,另一方面展示了一个在设计与验证嵌入式系统的实际方法. • 这篇论文是按照下面所说的组织的.第二段说明了一些相对的工作.第三部分描述了我们的设计和验证方法,第四部分展示了一个研究的例子.第五部分包括这篇论文当前的地位和未来的发展工作.
以往做的工作 • 在过去的研究中我们不难发现在进行软硬件统一设计和仿真时,我们很少注意到实时操作系统尽管他们在嵌入式系统里的重要作用.很多早期的研究表明统一设计是用系统专门写在像c,c++这样的软件程序语言. 然而单单用c在明确系统的功能是不够灵活性的,因为c/c++不能获取多任务的当前值而这个值是用来相互通信的.事实上,这些早期的研究努力假定了一个非常简单的系统模型包括一个信号和一些应用任务,并不考虑到实时操作系统.而其它的一些系统假设用一些像任务图表之类的抽象模型来代表系统参数. 使用这些模型可以不用实时操作系统就可以描述当前的状态.
对比和倡议： • 大多数过去的抽象模型不能提供任何的仿真系统参数的实际解决办法.在复杂嵌入式设计中,广泛的仿真系统参数用来验证这功能校正是非常重要的. • 一些最近的研究者们用了遗传实时操作系统模型,为系统水平设计和统一仿真.这种实时操作系统模型被用于应用软件的自然执行,这种软件包括实时操作系统服务的要求.在基于验证的仿真之后,实时操作系统指令被真正的实时操作系统指令所代替,他是用来在最后的执行器里去获取最终的软件代码.在第五部分,展示了一种自动的产生实时操作系统依靠的用c描述的软件的方法. • 这种方法代替了c系统在同时性和与实时操作系统服务指令的通信的限制。
作者的想法： • 为了使得模型更加具有普遍性和独立于特定的实时操作系统.例如,在第三部分里提到的实时操作系统模型仅仅有十六条服务指令.然而,即使再小的实时操作系统内核也会提供更多的服务.例如μITRON标准指令集就是一种很流行的专门为小规模嵌入式系统设计的实时操作系统内核.有多于80条服务指令. 这些指令或许会被充分利用为了写一个高质量的软件.然而,很容易想到那些用以前的方法自动产生的软件的质量明显低于用这种经典的实时操作系统独立软件. • 在这篇论文提到的设计和验证方法里,一个设计者首先选择了一种实时操作系统然后描述系统参数使用由实时操作系统提供的服务指令.因为这些规范取决于特定的实时操作系统,所以在不同的操作系统平台上移植是一件不易的事.根据我们的经验,然而,很多工厂设计团队并不会在实际中使用很多不同的实时操作系统.他们往往在几年里会使用一些非常有限的实时操作系统指令集为了可以重复利用已经有了的软件.我们的方法适用于这种设计团队或者这样的一些应用领域,在这里一个或很少的少时操作系统在很长的时间里用到,实际上,我们采用了一种标准化的实时操作系统. μITRON,来开发CAD工具(包括仿真平台和实时操作系统仿真模型)来支持我们的方法.
μITRON标准 • μITRON,是一种从小到中型的嵌入式操作系统,它不是一种特殊的实时操作系统产品,但是是一个应用程序接口标准.他仅仅定义了一组API应用函数集.而且这些函数体的执行或许会因基于实时操作系统的μITRON,不同而不同.因此我们的方法是有效的只要设计者们使用符合μITRON标准的实时操作系统,注意到我们的方法不仅限于基于实时操作系统的μITRON,其它包括有仿真模型的实时操作系统也可以被使用. • 在第六七部分,用了一种不同方法用来嵌入式软件设计,在他们的方法里,首先分析应用软件,并且在最终的实时操作系统里仅仅包括了在应用中使用到的实时操作系统服务部分,这种工作就像是我们的那些在应用软件中使用的服务指令集是提前定义的一样.主要的不同是他们把精力集中在如何定制一个实时操作系统而我们的方法是基于一个标准的操作系统.
图一总的说明了我们用于设计和验证嵌入式系统的方法,在这种方法里,系统设计开始于决定一个实时操作系统并用c作为一个应用任务的指令集来描述系统规范,同时性和内部任务通信是通过实时操作系统的服务指令集来描述的.因此,所谓的系统规格就是系统功能函数的软件执行. 为了验证应用软件的正确性,软件通过和实时操作系统仿真模型一起编译和链接之后生成目标代码.这些代码然后在主计算机上执行.由于是本地执行所以仿真速度非常快,如果一个设计错误被发现的话,软件就会被修改然后仿真又一次执行,在图一中,UT的意思是不限时间的. • 下一步是评估软件性能,一个目标过程的仿真器指令集适用于对执行周期计数的,这个过程在图中是用(IS)来表示的,其含义是指令集水平,如果性能达不到要求的水平,一部分系统函数需要用硬件来实现.仿真器指令集用来找出那些需要用硬件代替软件来实现的关键功能,在图一中, “HW/SW Partitioning”.来表示在这个标准里,共同仿真被提前形成用来验证转换部分的正确性,在那里软硬件都用直接在主计算机上执行, 图一中用“Cosimulation (UT-HW & UT-SW)”表示.
在统一仿真之后,就是寄存器转移标准(RTL)的硬件部分的设计和软件部分的优化同时进行.他对硬件部分的描述包括动作综合或者是手册设计,他的设计需要被仿真以用于验证功能函数的正确性,在这个阶段,RTL设计是用HDL仿真器来执行的,而软件主要是在宿主计算机上进行.软件服务作为一个测试平台来产生要输入硬件的数据并接收来自硬件的输出数据..在图一中用“Cosimulation (RTL-HW& UT-SW)”来表示. • 与RTL硬件设计的同时应用软件的优化也在进行,这样做是为了更充分的利用硬件结构,在这个阶段硬件的设计也许并没有完成,因此用一个无时限的硬件模型来验证优化的软件,这些软件在本地或者是一个指令集仿真器上执行如图一“Cosimulation (UT-HW & IS-SW)”所示. • 在这些软硬件设计完之后,以周期为精确度的共同仿真平台,提前形成用于验证系统的正确性,如图一“Cosimulation (RTL-HW& IS-SW)”所示,
我们的方法的核心是在系统设计很早的时期使用一种实时操作系统仿真模型.归因于此,系统的当\前行为和相互通信可以被精确的描述,有效的验证和平滑的执行..另一个关键问题是这个灵活性仿真平台,他支持各种各样的软硬件抽象标准..我们的方法的核心是在系统设计很早的时期使用一种实时操作系统仿真模型.归因于此,系统的当\前行为和相互通信可以被精确的描述,有效的验证和平滑的执行..另一个关键问题是这个灵活性仿真平台,他支持各种各样的软硬件抽象标准.. • 为了实现建议的方法,我们已经开发了一个统一仿真平台和一个实时操作系统的仿真模型,这个RTOS仿真模型支持所有的在μITRON 4.0的标准,并用c来实现,所以它可以在计算机上直接执行,统一仿真平台也很有灵活性,他包括了加和乘指令集,HDL仿真器,和一些c/c++中的一些功能硬件模型,
4,一个设计的例子 • 我们用我们的方法设计了一个JPEG解码系统,图二表明了JPEG解码器的解码流程,主要包括四个任务:VLD, Dequantization IDCT和YUV2RGB另外,还有另一个任务就是显示,显示解码后的图像在主计算机上的窗口里,
首先,我们用c语言把所有的任务都写出来,这些任务然后就和RTOS仿真模型一起编译链接之后产生可执行的二进制代码,通过执行这些二进制代码我们验证了JPEG程序的正确性,仿真时间是9百万秒,首先,我们用c语言把所有的任务都写出来,这些任务然后就和RTOS仿真模型一起编译链接之后产生可执行的二进制代码,通过执行这些二进制代码我们验证了JPEG程序的正确性,仿真时间是9百万秒, • 第二,我们运行仿真在一个指令集仿真器中(ISS)用来估计JPEG应用在目标处理器的执行时间.我们用ARM9核作为目标处理器,我们用ARM公司给的汇编语句来编译JPEG程序.并且和一个实际的实时操作系统来链接,例如, TOPPERS/JSP内核,然后在把产生的代码在一个ISS上执行,例如ARMulator,这个仿真用了23.8秒,需要强调的是我们根本不需要改变应用程序因为我们完整的RTOS仿真模型,这个仿真结果表明JPEG应用在目标处理器上的执行时间将是62.7百万个周期,
IDCT的软硬件分配 • 从使用ISS仿真的结果可以看出,39.8%的执行时间被用于IDCT这个任务上了,为了提高性能我们决定用硬件来执行IDCT这个任务,我们用c做了一个IDCT功能硬件模型,这个是通过把源IDCT主程序体复制到硬件模型里实现的, 另外的用于软硬件通信的代码在IDCT模型的入出点上插入.在软件任务上,主体被带有存储器映射的I/O访问口和软硬件同步的RTOS服务所取代.然后就是统一仿真的执行了,软件任务在RTOS仿真模型下编译和链接并生成目标文件,IDCT硬件模型也被编译来获得一个目标文件,然后这两个文件在我们的统一仿真平台上执行用来验证系统功能的正确性,在计算机上的仿真时间是46秒. • 之后我们进行IDCT电路的RTL设计,我们用VHDL来设计IDCT电路,上个阶段我们用了统一仿真来验证软硬件的系统功能的有效,这里我们用到HDL仿真器,例如ModelSim这个仿真的时间用了182秒,在强调一下这里的软件是不需要改变的.
在设计IDCT硬件的同时,我们可以进行软件优化并且可以在ISS上看看我们的优化效果,在这个试验我们不能优化软件,我们仅仅验证了应用软件的有效性在ISS上,因为IDCT的RTL设计在那时还没有完成,我们用c函数模型来仿真结果是71秒,在设计IDCT硬件的同时,我们可以进行软件优化并且可以在ISS上看看我们的优化效果,在这个试验我们不能优化软件,我们仅仅验证了应用软件的有效性在ISS上,因为IDCT的RTL设计在那时还没有完成,我们用c函数模型来仿真结果是71秒, • 在完成了硬件设计部分之后,我们用HDL仿真器和ISS来统一仿真,在仿真中我们可以看出,JPEG应用的执行周期是39.1百万个周期,,这表明执行时间相对于只用软件执行的方法减少了38%,这个仿真结果需248秒, • 正如我们所见,仿真时间的不同很大程度上取决于软硬件的提取水平,在我们的设计和验证方法里仿真执行仅仅是在一个必需的抽象水平之上.
5 结论 • 在这篇论文里,我们给出了一种基于的实时操作系统的嵌入式系统设计和验证的方法,我们方法的核心是在系统设计的早期就使用一个RTOS仿真模型,这个模型使得我们在很早就知道了准确的系统参数和有效的验证和平滑的执行,我们也看到了一个说明我们的方法的有效性的例子. • 总而言之,我们已经开发了一个统一仿真的框架和一个RTOS的仿真模型,这个仿真模型是一个主要部件来实现我们建议的方法,现在我们在扩展\我们的RTOS模型和统一仿真平台来支持多处理器嵌入式系统..
6 参考文献 • [1] S. Honda, T. Wakabayashi, H. Tomiyama, and H. Takada, “RTOScentric • cosimulator for embedded system design,” IEICE Trans. • Fundamentals, vol.E87-A, no.12, pp.3030–3035, Dec. 2004. • [2] D. Desmet, D. Verkest, and H. De Man, “Operating system based • software generation for systems-on-chip,” Proc. Design Automation • Conference (DAC), pp.396–401, 2000. • [3] A. Gerstlauer, H. Yu, and D. Gajski, “RTOS modeling for system • level design,” Proc. Design Automation and Test in Europe (DATE), • Embedded Software Forum, pp.130–135, 2003. • [4] H. Yu, A. Gerstlauer, and D. Gajski, “RTOS scheduling in transaction • level models,” Proc. Int’l Conference on Hardware/Software • Codesign and System Synthesis (CODES+ISSS), pp.31–36, 2003. • [5] F. Herrera, H. Posadas, P. Sanchez, and E. Villar, “Systematic • embedded software generation from SystemC,” Proc. Design Automation • and Test in Europe (DATE), Embedded Software Forum, • pp.142–147, 2003. • [6] L. Gauthier, S. Yoo, and A.A. Jerraya, “Automatic generation and • targeting of application-specific operating systems and embedded • systems software,” IEEE Trans. Comput. Aided Des. Integr. Circuits • Syst., vol.20, no.11, pp.1293–1301, Nov. 2001. • [7] S. Yoo, G. Nicolescu, L. Gauthier, and A.A. Jerraya, “Automatic • generation of fast timed simulation models for operating systems in • SoC design,” Proc. Design Automation and Test in Europe (DATE), • pp.620–627, 2002. • [8] H. Takada and K. Sakamura, “μITRON for small-scale embedded • systems,” IEEE Micro, vol.15, no.6, pp.46–54, 1995. • [9] ITRON, http://www.assoc.tron.org/itron/ • [10] Mentor Graphics Corporation, http://www.mentor.com/ • [11] ARM Corporation, http://www.arm.com/ • [12] TOPPERS Project, http://www.toppers.jp/
