账号:
密码:
最新动态
产业快讯
CTIMES / 文章 /
提升软硬件共同设计虚拟平台价值的两大神兵利器
台大系统芯片中心专栏(33)

【作者: 葉昱甫,黃鐘揚】2010年02月02日 星期二

浏览人次:【6466】

相较于直接使用SystemC仿真器的Clock Step仿真方法,这个算法充分的利用了待测电路数据相依性的信息,在即使使用原本的SystemC仿真器的情况下,也能大量地减少仿真器与系统模块间不必要的同步排程以增进虚拟平台的仿真速度。



此外,为了让虚拟平台更容易在系统芯片(System on Chip, SoC)上开发软件,本文亦提出了适用于虚拟平台之操作系统快速开机法,加快操作系统开机速度并降低移植操作系统的困难,以提升软件开发的效能与可重复使用性。以上所有实验皆在台湾大学电子所「设计验证研究室」所自行研发之虚拟平台「QuteVP」上完成,采用SystemC与TLM在该虚拟平台上建置ARM Versatile SoC原型,并且成功执行诸多如多媒体应用、数学运算与作业程序开机等程序。目前在该平台上测得的结果是当套用数据相依性感测虚拟同步算法时,其虚拟平台的仿真速度平均可增快约44倍,亦即达到每秒执行数百万个ARM指令的速度,因此,当使用所提出的快速开机法搭配数据相依性感测虚拟同步算法时,则可让一个uClinux的操作系统在约14秒左右即可开机完成。



SoC虚拟平台的两大障碍


为了增进系统芯片(System on Chip, SoC)设计的效率与成功率,目前许多SoC设计者已开始采用ESL(Electronics System Level)方法学。ESL方法学的优点在于利用软件高级语言抽象化能力将设计者所想要验证的电路以模型化方式包装,并加入硬件电路的共同式行为仿真(Concurrent Behavior Simulation)功能,让设计者能够快速地在该虚拟平台上建制SoC原型,提供设计者在设计初期即能有效对软、硬件共同开发、整合与验证的能力,并且透过系统级层次之仿真以达成对系统整体的效能评估。然而,使用虚拟平台建制系统原型时常会遇到两个主要的问题,分别为仿真速度的不足与移植操作系统对软件开发时所造成的困扰,所以以下将会分别详细介绍这个两个问题与提出解决问题的方法。



仿真速度不足的原因在于仿真器以软件方式模仿类似硬件的共同式行为时,为了在每个频率周期内能确保模块间交易行为的正确性,仿真器会使用同步排程方式处理这些模块间交易行为的先后顺序,所以必须对每个模块进行同步行为的探询动作,当系统中模块的数量变多时,探询动作的次数也将成线性成长,此外,当模块间的频率周期不同时,仿真器又必须采用更小的频率周期进行同步行为,如此一来,探询动作的次数将会非常庞大因而耗费大量的仿真时间。当采用目前相关商业软件(例如:CoWare、SoC Designer)所开发之虚拟平台建制如同ARM Versatile等级的系统芯片时,当仿真精确度被要求在频率精准度(Cycle Accurate)的状况下,实验结果显示其仿真速度通常只能达到数十 KIPS(Kilo Instruction Per Second)的仿真效果,这对现今应用程序的仿真而言,执行一次应用程序常必须使用数千万至数百亿之执行指令数,若以此换算仿真时间,则仿真一次该系统执行之应用程序将需耗费数天至数个月不等,根本无法做到大量有效或完整的仿真,所以虚拟平台所带来的好处将因仿真速度缓慢因而大打折扣。



另外,由于软件开发与测试常需要有操作系统(Operating System, OS)的协助以避免繁琐的系统低阶设定(例如:驱动程序的撰写)、并提高软件的移植性与可重复使用率。然而移植OS其实是一件相当麻烦的事,其中又以OS开机程序最难,因为OS开机过程包括许多繁杂的程序,其中有些程序(例如:Boot Loader)不仅冗长并且需要独特的硬件配合(驱动这些硬件装置的设定又往往会牵涉到商业机密问题),因而造成操作系统移植上的困难,其次,仿真这些操作系统的开机过程对软件开发而言并无实质的贡献,所以如果无法有效降低操作系统开机程仿真的难度,冗长且繁杂的操作系统移植程序将对采用虚拟平台开发SoC的用户带来更多的不便。




《图一 QuteVP所建立之虚拟系统架构图》




有鉴于此,本文将介绍一种对于虚拟平台上改善仿真速度之算法,这个算法相较于仿真器(例如:SystemC simulator)所采用类似Clock-Step Method的传统仿真方式,其仿真速度增进的效果,以平均值而言约有44倍之多;除此之外,本文亦提出对于虚拟平台上的操作系统快速开机法,搭配上述所提的算法,可以让一个类似Linux操作系统(uClinux, Kernel2.6)开机程序约10数秒内完成仿真。(执行仿真主机为一IBM x3400工作站,采用Intel Xeon,频率为2.66GHz之处理器),此外,采用一个名为QuteVP(如图一所示)的虚拟平台印证实验结果,这个虚拟平台是由台大电子所计验证实验室所设计开发,建置该虚拟平台所使用的描述语言为OSCI(Open SystemC Initiative)机构公布的SystemC2.2与TLM2.0的C/C++兼容语言。QuteVP目前能够完整呈现一个ARM Versatile虚拟平台原型,内容包括了一ARM v5t架构的指令集精准度(Instruction Set Simulator, ISS)的处理器模型,此外,Versatile平台所需的其它硬件模块皆以SystemC2.2与TLM2.0建构成具频率精准度的硬件模型(如:Bus Model、ROM/RAM、Interrupt Controller Model,Timer Model等);关于软件开发的部份,QuteVP中的ROM Model可以自动导入用户透过ARM v5t兼容的编译程序所产生的二进制机械码即可驱动该虚拟系统,透过此方式,该虚拟系统已成功验证了许多应用程序(如:JPEG Encode、MPEG H.264 Decode等),其软件架构与系统关系图如图二所示。




《图二 软件架构与虚拟平台关系图》




虚拟平台的仿真速度问题


传统系统仿真方法造成仿真速度缓慢的原因有二点:第一,仿真器为了仿真硬件模块的共同式行为动作(Concurrent Behaviors),并且确保模块功能行为仿真的正确性,其做法通常采用像Clock-Step仿真方法,让仿真器在每个频率周期内检查每个模块是否需要同步,所以当系统中的模块数量变多时,每个频率周期内需要进行同步排程次数将呈线性增加,除此之外,由于每个模块采取的频率周期可能不同,所以仿真器必须使用更细微的时间颗粒度(Time granularity)做为仿真采样周期,目的是保证模块间交易行为的仿真不会发生漏失的状况,结果则导致仿真器执行再次增加庞大次数的同步探询行为,变成让仿真速度更快速下降的加乘效果;第二,当模块要传递数据时,亦由于采用软件方式仿真硬件交易行为的缘故,所以模块间信息的交换必须透过仿真器才能完成,如图三所示,这些信息交换的行为相对真实计算机(Host Machine)的运作为内存读写的动作,由于在一个复杂的系统中,模块间交易行为会牵涉到的模块可能会有很多个,所以内存读取的次数也会变得相当多,所以也耗费了许多仿真时间。上述二种的状况说明了为什么同步排程与内存读取动作会耗费仿真器大量的仿真能量,但更重要的是这些大量的仿真能量并非使用于系统模块本身功能行为的仿真与验证,所以这将大幅降低虚拟平台对于快速验证其系统功能正确性或效能评估的价值。以下将提供真实范例,当QuteVP采用SystemC simulator所附加之Clock-Step仿真法做一JPEG Encode程序仿真,经由GNU Profiling Tool的分析(为精简篇幅,本文展示实验数据为部份内容,如图四),从这些统计数据显示SystemC 仿真器对于同步排程所使用的函数调用(function call),如sc_simcontext::cruch(bool)、sc_event_trigger()、sc_notify_time_compare其运行时间就占了约整体仿真时间的一半,当做更进一步的统计分析后,结果显示SystemC之仿真器对于同步问题时所有的相关执行函式所耗费时间竟占整体仿真时间竟高达90%以上。



为了解决上述问题,将尝试从另一个角度思考,是否有其它方法可以让仿真器不必使用大量执行同步排程也能达到正确仿真模块功能行为的目的,针对这个想法,首先观察模块数据交换时的行为,发现即使仿真器不在每个频率与其它模块采取同步排程,其大部份模块功能行为的仿真结果并没有错误,会有差异之处则是在于该虚拟系统所执行应用程序时所耗费的「虚拟系统时间」,换句话说,在仿真中,若用户不需要时时刻刻查询系统时间时,若能找到发生仿真错误的原因并且修正,那么仿真器就有机会不需要采用大量的同步探询动作,至于正确的虚拟系统时间则可在模块功能仿真完后再进行修正。



《图三 系统模块信息交换范例:Processor Model对RAM Model读取数据必须经过8次信息交换》


《图四 仿真时间分析统计图》


为了找出发生仿真错误的原因,将更进一步对交易行进行分析,结果发现模块功能行为仿真的正确性其实是建立在模块间所交换的数据是否存在相依性问题的基础上,所以提出了名为「数据相依性感测虚拟同步算法」(Data-Dependency Aware Virtual Synchronization Algorithm – DAVSA,如图五所示)去改善传统Clock-Step仿真法造成仿真速度缓慢的问题,其算法的特点有二:第一,如图五中的第7~20行,是让Simulator有能力感测模块间数据交换时的内容是否有相依性,如果交易的内容具有相依性问题才通知仿真器进行同步排程,相反状况则予许仿真器针对模块功能持续仿真,其模块内部时间可以不跟系统总体时间(System Global Clock)相同,直到该模块之交易内容具相依性问题或仿真结束而停止,这个方法最大的优点就是避免仿真器执行大量的同步排程而有效增进仿真效率并且仍然能够维持模块功能仿真的正确性;第二,如图五中的第21~26行与上段文章所提及的时间修正问题,主要是计算仿真器仿真时没有考虑系统中在同时间可能有其它多个模块也在进行交易而导致的延迟时间,采取这个措施的目的是让仿真器在功能行为仿真完成后能将正确地将系统到底耗费多少虚拟系统预估出来以维持仿真的精准度。




《图五 DAVSA (Data-Dependency Aware Synchronization Algorithm)》




如同上述所说要完成上述DVASA则需要完成侦测数据交换时内容的相依性、直接式模块数据读取法与完成延迟时间修正的三件工作,以下将分别详细介绍。



第一步


为了让仿真器辨认一般的虚拟嵌入式系统中模块间数据交换时内容是否存在相依性问题,主要要注意两种数据相依性,分别为静态数据相依性与动态数据相依性。所谓的静态数据相依性指的是针对嵌入式系统中会主动发出要求进行数据交换的模块建立其分享式内存数据相依性表格(Shared Memory Data-Dependency Table),这些表格的数据只需要参照系统规格在仿真前就可以标记完成会造成数据相依性问题的内存区域(如:RAM Module的内存位置或一般外围模块所使用缓存器的位置);对动态数据相依性来说则较为麻烦,重点仿真器除了要标计仿真时的造成数据相依性问题的内存位置,还必须额外记录数据相依性问题发生的时间点,这样才能正确还原时间以达成时间修正的目的。为了让读者更容易了解,以下将用一嵌入式系统中常会用到的Processor Module与DMA Module对于数据搬移做为范例,如图六所示。



当Processor Module需要DMA Module协同合作搬移数据时,Processor Module会先在DMA Module的缓存器分别设定数据搬移的来源与目的地之内存起始位置与结束位置,最后才致能DMA Module进行数据搬移之功能,当致能DMA功能后,则代表Processor Module与DMA Module可能在图中重迭之内存位置内,产生数据相依性问题,但Processor Module会跟DMA Module在这重迭之内存位置内,对「相同内存」「同时」存取数据而造成数据相依性问题的机会其实不高,所以比对时间与动态式数据相依性表格后,依照实验的统计数据而言,会造成仿真器需要进行同步排程的次数将会大幅减少,减少的幅度通常对数千万指令集的应用为单位时,平均可达数104~105之等级。




《图六 造成数据相依性之重迭内存示意图,以Processor Module与DMA Module为例》




第一步


直接式模块数据读取法指是仿真模块间数据交换时,如何让发出要求的主动式模块能直接得到目标模块(Target Module)的数据以减少仿真器对真实计算机之内存所做的存取动作,如图三所示,依照传统的方法,若一个简单的Processor Module对于RAM Module的数据交换行为要求就需要要求8次的数据拷贝(Data Copy)动作而引发内存存取,当仿真对象为一复杂系统时,这种数据拷贝所引发真实内存读写动作的次收也将大量增加,但是对于虚拟系统来说,由于所有模块都是由软件所构成的模型,其实数据交易行为可以利用指针(Pointer)并配合函数调用方式,让要求交易的模块(例如:Processor Module)可以直接存取目标模块的数据,所以许多原本需要经由仿真器传递数据动作将能大幅减少,因而减少大量的因内存存取所耗费的仿真时间。



第一步


第一、二步骤主要的目的在于提升仿真效能,可是却漏失了仿真精确度,为了克服这个缺点,在仿真系统模块交易行为采用DAVSA的同时也采用了Trace-Driven仿真技术,做法是在每个模块进行数据交换时记录交易时间,虽然这种时间记录似乎只能呈现每个模块对于本身交易的先后关系,但加入系统架构拓朴图信息与系统传输规则后(例如:总线传输协议),则可以将这些信息、规则转换成数学函式,与其它模块的时间记录互相比较并计算其延迟时间(如:模块忙碌、总线阻塞(Bus Contention)等所造成的延迟等),不准的虚拟系统时间信息将可被修正、还原,而仿真精确度也可获得补偿,所以其仿真的时间信息依旧可以做为有意义的系统效能评估参数。



最后在图七显示DAVSA对于加速仿真的效果,所采用的实验测试数据为一JPEG Encode应用程序,结果显示仿真套用DAVSA与搭配Trace-Driven仿真技术后,主要的仿真能量可以被用在系统功能仿真上,其比例可从原先的12.70%提升至87.3%,而仿真速度的提升也高达约44倍并且维持在原始的仿真精确度。




《图七 以JPEG Encode应用程序为例,采用DAVSA加速仿真的实验结果》




在虚拟平台上的操作系统快速开机法


软件开发的能力通常决定了一个系统是否能够快速推向市场,其中的关键因素就在于有无操作系统的协助,透过操作系统,软件开发者能专注于应用程序开发,避免浪费时间在撰写低阶且繁琐的系统设定程序;再者,有了操作系统的协助,软件程序的移植性将能大幅提升而增加软件的可重复使用性(Reusability),进而强化软件开发的能力,所以目前许多的嵌入式系统都会采用操作系统以支持软件开发。



然而,要让嵌入式的系统搭配操作系统增进软件开发能力有二个重要考虑因素,第一是如何减少操作系统移植的代价;第二为如何快速完成操作系统开机流程。由于操作系统移植通常必须撰写许多系统底层的硬件配置程序(例如:低阶assemble 硬件驱动程序),而且必须了解其硬件规格,可是有关硬件规格与设定又常会牵涉到厂商的商业机密,所以造成操作系统移植上的困难;其次,执行应用软件测试必须等待操作系统开机程序完成,可是操作系统的开机程序包含了许多流程,而这些流程常常耗费数亿至数十亿的指令运行时间,这对于软件开发常需要执行重启动而言是相当没有效率的。针对以上所述状况,其实也会发生在虚拟平台开发系统上,因此本文将提出一个在虚拟平台的操作系统开机法以简化开机时繁复的流程,达成快速开机的目的。



为了解释如何简化开机流程,先以Linux的操作系统说明操作系统的生成方式与开机流程中的几个重要步骤,如图八所示,图的上方为操作系统的生成步骤,生成步骤为由右至左,有关于系统任务排程、文件系统配置等操作系统核心程序在最右边,透过其编译程序后则产生了「image」的bin档,其后为了节省内存空间,所以会对image档做一次压缩而产生了「piggy.gz」,最后,则是加入硬件厂商所提供的硬件驱动程序而产生zImage,因此操作系统的开机程序其实就是上述操作系统的生成步骤倒过来执行(如图八下方的流程所示),让系统执行至操作系统中核心程序后再开始执行开发的软件。由图八可知,操作系统开机程序主要包含了四个部份,1. Bootloader:纯粹由硬件控制将压缩后的OS图像文件加载,2. Bootstrap loader:创造虚拟环境方便解压缩操作系统之图像文件并重新寻址linux kernel,3. Kernel vmlinux: 由linux kernel对系统掌控,侦侧系统并设定对应系统参数,4. Kernel main.o:进入main.c,开始对所开发之软件程序服务。




《图八 操作系统编译过程与开机流程》




了解操作系统开机过程后,发现操作系统开机流程的前两个步骤对于软件开发来说其实是毫无意义的,因为它们的目的是让系统在启动电源后,硬件装置在没有操作系统协助下能够自动将操作系统的图像文件加载系统内存(通常为ROM或Flash Memory)中,并且填入操作系统所需之系统参数信息至默认内存内,再让操作系统启动并将系统控制权交由操作系统掌控,对此,我们的想法就是提出一个方法让操作系统开机程序可以跳过这些繁琐的流程,直接启动操作系统,并让操作系统可以直接对软件开发之应用程序进行系统排程、内存管理、档案管理等任务,达到帮助软件开发之目的。



由于虚拟平台所建构之系统全是由软件所达成,所以可以让系统中所有硬件模型皆能透过指针方式进行模块内数据的存取,善用虚拟平台的这个优点将所有操作系统启动时所需要的默认内存信息记录起来后,再如同图九所示,分别达成以下工作以快速完成操作系统开机程序:




  • 一、将未压缩过的操作系统图像文件(Image)复制在定义好的系统内存区块内。



  • 二、将ROM File System也复制在定义好的系统内存区块,请注意此ROM File System存放着软件开发之应用程序的执行档,所以此步骤不能省略。



  • 三、将处理器的程序计数器(Program Counter, PC)初始值调成操作系统图像文件所存放之内存地址,并启动该系统,让操作系统启动后,再经由内存地址默认值找到对应的ROM File System,经由操作系统所支持指令的输入后即可执行该应用软件。






《图九 虚拟平台作业快速开机流程图》




相较于传统操作系统开机流程,本文的方法避开了如图八的前两个步骤,直接跳到与软件开发之应用程序相关的部份,这种做法的好处是避开了繁杂的系统底层设定,并且不再需要依赖厂商所提供控制的Boot Loader相关硬件模块驱动程序,使得系统开发者能够摆脱该驱动系统对于商业考虑因素所造成的限制,进而便利且弹性地移植操作系统至想要发展的虚拟平台上。



除此之外,由于这种操作系统开机方式是直接跳到图八中的第3阶段,此阶段对于大部份操作系统来说,其所需要驱动程序的编辑方式已经能够被高阶的语言所支持(如C语言),所以对软件工程师来说将能更有效率的撰写所需要的驱动程序。最后的一种好处是这种操作系统开机方法可以省略大量对解压缩操作系统影像压缩文件时所需要的仿真(此段仿真过程为如图九中的传统操作系统开机程序中的第一步骤与第二步骤),促使操作系统开机更加快速,依照实验数据,若采用传统方式的操作系统开机方法,所有的开机过程约需150~250百万指令数(依照对应的BootLoader与操作系统所支持之驱动程序多寡而有所变动),相对的,本文对于虚拟平台上所提的操作系统开机方法,只需耗费约30百万指令数,如图十所示,配合DAVSA后,成功让一uClinux的操作系统在约14秒时间内在一个仿照ARM Versatile的虚拟系统上完成开机程序。




《图十 uClinux操作系统开机完成与相关仿真信息》




让虚拟平台与真实SoC接轨


由于用户可以利用虚拟平台快速建立SoC原型以达成系统功能验证,并且在虚拟平台上轻易并弹性地调整其系统架构,找出对系统最佳的软硬件配置(Hardware/Software Partition)方式,以提升SoC设计的正确率与效率。所以如何让系统设计者有意愿采用虚拟平台,第一个前提就是必须提升虚拟平台的仿真速度至MIPS(Million Instructions Per Second)等级,如同在采用FPGA所建置的系统原型一般。因此本文提出一个加速虚拟平台仿真速度的算法(DAVSA),这个算法让系统仿真的精确度在频率精准度的条件下,依然能达到3~5 MIPS的仿真速度,藉由DAVSA的帮助,让相较于那些采用像RTL仿真方式(其仿真速度通常只有数KIPS,甚至不到)的SoC设计者,能够在有限的时间里进行更多的系统功能仿真。



除此之外,一个系统是否能够快速且成功地推向市场,软件开发能力是一个指针性的因素,为了提升软件开发能力通常会采用操作系统,操作系统的功用是让程序设计者能集中注意力在应用程序的开发而非花费大量时间在对付繁琐的系统底层设定,因此本文亦提出一个在虚拟系统中对于操作系统的快速开机法,做法是善用虚拟平台优点去避开操作系统开机流程最繁琐的部份,这种方法的优点在于不但可以加快操作系统开机的速度还可以降低操作系统移植的难度,另外,这种开机方法也可以配合前面所提的DAVSA让整个操作系统开机仿真更加迅速,所以用户就可以在有操作系统协助下并且具MIPS仿真速度等级的虚拟平台上去解决真正SoC设计时所须面对的问题。



---本文由台湾大学电子工程学研究所设计证验研究室所提供,该研究室目前由黄钟扬博士负责,主要研究领域包括正规方法验证、电子系统层级设计与验证等相关研究---



相关文章
浅谈高密度闪存效能与可靠性提升之管理机制
使用多相位补偿的除小数频率合成器
硅光子与光链接应用优势探讨
60GHz CMOS单芯片收发机设计
全喷墨软性电子元件制程之探讨
comments powered by Disqus
相关讨论
  相关新闻
» 意法半导体突破20奈米技术屏障 提升新一代微控制器成本竞争力
» Pure Storage携手NVIDIA加快企业AI导入 以满足日益成长的需求
» ROHM推SOT23封装小型节能DC-DC转换器IC 助电源小型化
» 意法半导体先进高性能无线微控制器 符合将推出的网路安全保护法规
» ST推先进超低功耗STM32微控制器 布局工业、医疗、智慧量表和消费电子市场


刊登廣告 新聞信箱 读者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 远播信息股份有限公司版权所有 Powered by O3  v3.20.1.HK83T1FO5UASTACUKE
地址:台北数位产业园区(digiBlock Taipei) 103台北市大同区承德路三段287-2号A栋204室
电话 (02)2585-5526 #0 转接至总机 /  E-Mail: webmaster@ctimes.com.tw