SOC架构上应用程序映射的评估优化.docx
《SOC架构上应用程序映射的评估优化.docx》由会员分享，可在线阅读，更多相关《SOC架构上应用程序映射的评估优化.docx（16页珍藏版）》请在冰点文库上搜索。
SOC架构上应用程序映射的评估优化
SOC架构上应用程序映射的
快速系统级性能评估和优化
摘要：
SOC架构集成了若干种部件到一个芯片上。
各部件提供了不同功能，比如动态电压调节，可重构性，多电源状态等，它们可以在应用程序设计中被用来优化性能。
我们提出了一种通用模型GenM,它可以获得SOC架构类的性能，并且可以促进应用设计中性能的评估和优化。
将GenM模型用作一种抽象的方法，来识别映射到SOC架构上的应用程序的各种定义良好的优化问题。
我们使用GenM模型开发出一种解释模拟器——高层性能评估HiPerE。
HiPerE集成了专用性能评估部件快速地进行系统级评估性能。
MILAN框架将集成了HiPerE的分层仿真和低层的专用部件仿真器集成到统一的环境中。
在将应用程序映射到SOC架构的过程中，分层仿真促进了探索设计空间的高效进行。
一，引言
SOC架构集成了几个层级的部件，比如通用处理器，可重构逻辑，若干DSP，若干
ASIC，存储器。
这些部件具有以下几个特点，动态电压调节，可重构性，多时钟域，以及在应用程序设计过程中为获得优化可采用的多个可实现替代方案。
但是，这些特点也为设计带来了很多挑战。
为了应对这些挑战，应用高层次抽象和系统级性能评估，评估不同专用设计部件的全局性效果，和识别出性能瓶颈和是否可优化是很有必要的。
系统级性能评估和SOC架构设计空间的高效遍历是非常具有挑战性的工作，因为我们缺少SOC架构的高层次抽象、耗时的低层次仿真和在不同专用部件间的标准接口。
（速度，功耗）
GenM提供SOC架构抽象来识别用来进行性能优化的关键架构特性。
GenM能分析
出应用程序映射到SOC架构过程的延时和能耗。
我们可以识别出基于SOC架构的专用GenM上的各种良好定义的优化问题。
基于GenM的快速性能评估工具HiPerE，组合专用性能评估部件评估解释型仿真在系统层次上的性能。
使用HiPerE计算含N个结点和Q条边的任务图表，求出性能评估复杂性是O（N+Q）。
HiPerE也在应用程序执行中提供作业报告来获得每一个部件的状态信息。
在这篇论文中，性能涉及延迟和能耗两个方面。
这篇论文中描述的工作是MILAN工程的一部分。
MILAN通过将多种仿真器件集成
到统一环境中，从而实现嵌入式系统设计和优化的集成仿真框架模型。
设计者通过使用MILAN框架在形式上对目标应用程序和架构进行建模。
使用从模型中获得的信息驱动一个接口不同的仿真器。
层次化仿真涉及在不同抽象和实现层次上，执行单个或多个仿真任务。
多层次的抽象使我们可以控制仿真速度、建模效率和仿真精确性。
在MLAN中，层次化仿真是指包含顶层HiPerE和底层部件专用仿真的两层技术。
层次化仿真高效地执行MILAN中的设计空间探索（DSE）。
DSE用来评估设计空间。
设计者为了获得设计空间，可以选择评估应用程序在架构上的所有可能的映射情况，或者在最初使用优化技术识别相对较小的设计备选方案集合。
一旦选中待评估的设计集合，就可以使用HiPerE来评估设计，并且消除不满足性能要求的设计。
接下来，设计者将使用更加详细的仿真评估HiPerE选出的设计，以此来决定最终的设计。
本论文按照下述结构组织。
接下来的部分讨论相关工作。
第三部分讨论GenM。
第四
部分讨论使用HiPerE的系统级性能评估。
第五部分讨论使用MILAN的快速设计评估的层次级仿真。
我们将在第六部分得到结论。
二，相关工作
我们付出了很多努力从事应用程序设计和通用嵌入式系统的优化，以及SOC架构的优化。
提出HySAM模型进行延迟评估和可重构设计的优化。
GenM模型通过包含支持DVS（动态电压调节）的处理器和不同功耗的存储器扩展HySAM。
Givargisetal提出了建立在样本仿真基础上的cache和总线功耗评估技术。
在某些设计结点上，可以通过执行底层仿真驱动评估所有可能设计的性能。
这种技术不能扩展为异构的SOC架构，因为基于样本仿真派生出良性的功能是不可能的。
Sinhaetal提出了基于指令级的功耗和时间评估的性能仿真。
这项技术仅仅可以应用于基于ISA（指令集架构）的处理器。
现在有几种评估处理器性能的时钟周期精确级仿真器。
但是，这些仿真器是耗时的，因此不能用来遍历一个大的设计空间。
我们要做补充性的工作，因为这些仿真器都提供了使用HiPerE和层次化仿真的专用部件的性能评估。
在软硬件协同仿真领域存在几种系统级评估方法。
Lajoloetal提出了使用Ptolemy框架的各种专用仿真部件的集成。
Lahirietal提出了针对片上通信架构的分析方法。
这些努力都只针对专用架构，比如包含cache和内存的RISC处理器。
我们基于GenM模型的方法可以应对一大类SOC架构问题。
SPADE是一种多层次的系统级仿真方法。
SPADE使用追踪驱动仿真（profel，只看结果），和查找预计算评估表来产生系统级评估结果。
应用程序使用Kahn进程网络建模。
我们的方法在几个方面都不同于SPADE。
由于使用MILAN，我们的方法可以在大量应用程序模型间选择以找到最适合的目标应用程序。
除了应用程序模型，我们还提供了一种明确的资源模型来获得目标架构的处理能力信息。
这有助于识别定义良好的优化问题。
MILAN也提供统一环境来集成不同的仿真器。
这种功能使得在专用硬件上运行的任务的性能自动评估过程，能够更新初始评估值，以此来使用HiPerE获得更好系统级评估结果。
三，将应用程序映射到SOC架构的通用模型
GenM通过为SOC架构建模，获得在将应用程序映射到SOC架构过程中可用的性能优化功能。
GenM包含三个部件：
处理器，可重构逻辑（RL），和存储器，它们都通过图一的interconnect互联。
GenM模型将处理器的动态电压测量（DVS），存储功耗值和RL的重构三者分离。
GenM模型包含下列参数：
V:
处理器操作状态序列，V0-Vv-1，V0代表空闲状态。
电压变化Vi到Vj的时间消耗（功耗）。
C:
RL操作状态序列C0-Cc-1，C0代表空闲状态。
Ci到Cj重构过程时间消耗（功耗）。
空闲状态下处理器能耗
M：
内存状态序列，M0到Mm-1。
内存状态M0到Mj变化过程的时间消耗（能耗）。
Mi状态中每个时钟单元的内存能耗。
处理器/RL和内存间单元数据传输时间。
为了对将应用程序映射到SOC架构的过程建模，GenM模型需要一些额外的参数。
这些参数采集少量应用程序运行细节，为各种计算部件映像上运行的任务提供性能评估，这些评估值就是性能参量。
这些参量是：
T：
任务集T1到Tn。
任务Ti和内存之间的数据输入输出量。
处理器上运行的任务Ti在操作状态Vj（j=1,…,v-1）下的执行时间消耗（能耗）。
RL上运行的任务Ti在操作状态Cj（j=1,…,c-1）下的时间消耗（能耗）。
能耗评估值eij和e’ij是任务执行的平均能耗，它是通过输入数据平均值来评估的。
可以假设在没有任务执行时，处理器处于空闲状态。
决定空闲状态和其他处理器状态的专用操作电压值被称为处理器操作状态。
相似的假设对RL同样适用。
RL的空闲态和由专用配置决定的其他状态被称为RL操作状态。
S代表所有可能的系统状态。
每一个系统状态s，s∈S,代表了
元，它们都是整形数，并且分别代表了处理器，RL，内存的操作状态。
每个状态的范围值为：
。
因此，所有状态的总和是v+c+m。
不同系统状态的转换会引发一定的时间和能量消耗，这取决于原始状态和目标状态的不同情况。
表示系统状态从Si变到Sj的能耗情况，qij的计算公式是：
。
rij也可以类似地计算出来。
上述形式中，我们已经假定任务间通信是通过共享内存完成的。
但是，这种假设也为模型带了局限性。
这里没有必要去定义这些问题。
GenM的用途有三个方面：
一，根据能耗和延时快速评估系统性能；二，使用忽略目标SOC架构和应用程序底层特定实现细节的方法，高效开发应用程序；三，SOC架构上应用程序映射和调度的优化技术开发。
我们提出一个使用GenM定义的优化问题例子。
这个问题可以使用动态编程来解决。
问题是将线性流水线任务映射到系统状态，（背包问题，NP完全问题）这样可以使系统的全局能耗最小化。
为了系统地说明这个模型的问题，我们假定内存只有一个可用状态M0，并且在任何时刻只有一条流水线在执行。
我们给出基于GenM模型参数问题的正式定义。
对于一个线性流水线任务，T1…Tn，任务是按照线性顺序执行的，比如任务Ti必须在Ti+1之前执行，i=1,2,…,n-1.因此，在任何时刻，无论在处理器还是RL上，系统只有一个任务可以执行。
所以，对于任何系统状态s，
或者
，但两者不会同时为0。
这样，在这特殊问题中，系统可能的状态总数是v+c-2。
对于给定的映射，xi表示任务Ti正在执行的系统状态。
Ei,xi表示Ti执行的总能耗。
Ei,ti是下列运行能耗的总和:
1，内存到映射计算单元Ti的数据输入；
1，处理器或RL上Ti的执行；
2，空闲状态中的处理器或RL；
3，Ti执行期间的内存；
4，内存存储Ti输出的数据移动。
上述五个部件的能耗可以按照下列公式计算：
X0表示系统初始状态。
系统全局的能耗按下述公式计算：
因为系统状态转换消耗的时间和能量取决于特定的源状态和目的状态，所以简单的贪心算法也不能保证最佳的解决方案。
相反，可以使用动态规划算法在
时间复杂度上计算出最佳的映射方案。
使用GenM可以为上述问题定义几种有趣的扩展，来达到将应用程序映射到SOC架构上的目的：
1流水线总执行时间的最小化取代系统能耗的最小化。
2当流水线的总执行时间受制于预先限制，将可以实现全局的系统能耗的最小化。
3系统并发执行同一流水线的多个实例。
在下一部分中，我们将描述怎样利用GenM模型设计HiPerE。
四，系统级性能评估
从前面讨论的内容可以知道，我们在系统级性能评估中面对很大的挑战，缺少专用仿真部件的标准接口使得将仿真器集成到SOC架构很困难。
HiPerE产生系统级性能值的解释型仿真，将专用性能评估部件组合来解决这个问题。
描述目标SOC架构的GenM模型是HiPerE的最主要输入值。
此外，性能参数也作为输入值。
我们方法中，在启动HiPerE之前，要执行多种优化。
优化执行时，HiPerE就评估能被优化技术识别出的设计子集。
设计者也可以选择不执行任何优化，而应用HiPerE的快速评估能力直接评估每一个设计方案。
HiPerE需要映射信息才能评估每一个给定设计的性能。
映射能识别出任务映射到的计算部件，如果此部件是处理器的话，映射还能求出其工作电压。
HiPerE用映射信息识别出合适的专用部件评估值。
设计者要初始化所有的性能参数值。
此后，专用性能评估部件要为tij,t’ij,eij和e’ij评估出更加精确的数值。
除了这些输入值，设计者还要给出稳定的应用程序任务执行表。
任务表中规定了任务的执行顺序。
设计者要为存储部件提供电源状态调度。
同时，我们仅在任务规定界限内，支持电源状态的变化。
HiPerE的输出是系统级能耗和延迟评估值。
除这些评估值，HiPerE还能为目标架构的每一个部件给出作业报告。
作业报告确定了不同的电压设置，配置，处理器电源状态，RL和执行过程中各存储部件的情况。
它也能提供处理器和可配置部件中，各个执行任务之间的空闲时间长度。
A，专用性能评估部件
专用性能评估部件对特定电压设置或者配置下，特定任务的参数值tij,eij,t’ij,e’ij进行评估。
多种技术可以评估专用性能评估部件产生的值，比如ComplexityAnalysis,GraphInterpolation,TraceAnalysis和Cycle-accurateSimulation。
除了ComplexityAnalysis不需要仿真器，其他几种技术都需要用到基于适当抽象层次架构模型的仿真器。
我们利用MILAN框架的可分离仿真特点执行专用部件的仿真。
这个特点具有在特定硬件部件上仿真一个简单应用程序任务的能力。
性能评估的结果可以自动更新性能参数值。
MILAN框架具有应用程序模型，资源模型和映射模型三个特点。
资源模型包含GenM模型的全部参数和驱动仿真器的附加参数值。
应用程序模型将应用程序实现细节转化为数据流表。
性能参数Ti,
也是应用程序模型的一部分。
其他性能参数是映射模型的组成部分。
设计者要用C或者JAVA实现每一个任务。
我们选中一个任务进行单独仿真时，MILAN会基于该任务映射的计算单元来产生一个合适的仿真配置文件和实现该任务的源文件。
设计者在建模应用程序时，要为每一个任务提供能产生输入输出的源文件和目的文件脚本。
举例来说，假定FFT是映射到MIPS处理器上的任务，SimpleScalar（学术界作出的仿真器）是被选定的仿真器，MILAN产生了实现FFT和SimpleScalar配置文件的C语言程序。
仿真执行结束后，仿真的评估值作为反馈值提供给MILAN，我们使用它们更新设计者提供的初始性能值。
专用性能评估部件可以提高GenM模型中初始评估值的精确性。
当设计者为特定问题提供GenM模型时，初始的性能评估值也被同时提供。
在做到系统级性能评估之前，我们为每个任务创建出复合的性能评估值。
复合的性能评估值涉及任务执行时所有过程的消耗，包括执行的消耗。
评估值包含了执行代价、数据访问、内存激活、重配置和电压变化情况。
举例来说，假定任务Ti映射到RL上执行，而Cj和Ck的配置就是先前的值。
假定内存的电源状态没有发生转换，则符合延迟计算的性能评估公式为：
相似的，可以由复合评估值ECi推导出任务Ti的能耗。
在下一小段中，任务的专用性能评估部件就会对任务进行综合的性能评估。
B，系统级性能评估
我们使用以下技术来评估系统级能耗和延迟，并以此产生作业报告。
图三显示了映射到处理器或者RL上的样本任务图表。
我们的技术如下所述：
MPi代表任务Ti的映射，Ti映射到处理器上时，Mpi=1，Ti映射到RL上时，Mpi=2。
使用[12]中的技术可以得到Mpi的值。
但是，Mpi是系统级性能评估的输入值。
α表示一列从起始任务表中获得，通过拓扑排序得到的任务列
。
A1、A2分别表示处理器和RL上所执行任务的最早可执行时间。
初始状态下，A1=A2=0。
表示任务
的完成时间。
后续算法中，每个任务都要计算出最早开始时间，同时还不能违反应用程序任务表提供依赖关系信息。
计算部件使用非抢占式调度策略。
算法的伪代码如下：
β表示
的直接前驱。
的最早开始时间是
{A1，A2}的最大值是系统级延迟。
处理器的空闲时间用公式
计算。
因此，处理器的空闲期能耗计算为：
。
类似地，RL的空闲期时间和电量消耗也可以计算。
总的能耗是每个专用部件能耗和部件处于空闲期能耗的总和。
总的能量消耗计算为：
显而易见的是，上述计算的复杂度为
，N和Q分别是任务表中结点和边的数目。
作业表是基于被处理任务表产生的，它包含每个任务映射信息和时间复杂度。
设计者利用作业表找到系统瓶颈和优化的机会。
一种可能的优化方法是利用空闲时间和更低的DVS设置缓慢地执行任务，来达到节能的目的。
HiPerE是使用JAVA实现的，可以运行在Unix和Windows平台。
HiPerE也可以集成到MILAN框架中。
因此，我们可以为HiPerE自动产生输入值，并且执行它来获得性能评估值。
我们目前正在开发在MILAN框架中能自动存储HiPerE输出值反馈机制。
C，例证
为了举例说明HiPerE的使用，我们建模了评估方位的信号处理程序，以及相关坐标中映像目标的评估。
应用程序包含两个主要部件：
Azimuth和Elevation。
Azimuth由图四中的六个任务组成。
Elevation有和Azimuth同样的任务表，但是仅仅在BandPassFilters类型使用上有所不同。
在这些例子中，我们呈现了产生系统级评估值的专用评估部件的使用，以及HiPerE评估和分层模拟的效果。
分层模拟的具体实现细节将在下一部分中讨论。
我们使用两种不同的架构进行实验，它们分别是执行600MHz频率的MIPS处理器，和可以用206、162、59三种频率运行的StrongARM（SA）处理器。
调度方案对于所有的设计方案都是同样的，而且它们都是可以用拓扑排序实现。
600MHz的MIPS，206、162、59MHz的SA分别对应四种完整的映射系统。
使用HiPerE获得的能耗和延迟评估值将和使用低层次仿真器的完整应用程序仿真进行对比。
我们使用SimpleScalar和Wattch（评估能耗的）评估MIPS处理器的时间和能耗，使用JouleTrack仿真SA-1100处理器。
HiPerE为每个映射给出两组值。
对于RE（RoughEstimates）中的值，我们使用JouleTrack在不同运行频率下仿真任务，并且推导出评估不同频率下评估能耗的函数表达式。
我们使用这些表达式求出同一任务在不同频率下的评估值。
[5]中给出了其中使用的相似的技术。
使用一个简单的表达式表示应用程序中使用的四个滤波器。
等式为：
其中f表示运行频率。
SimpleScalar仿真也用到了相似的技术。
另一方面，MILAN列中的值是通过使用每个任务中应用的分离MILAN仿真技术获得的。
我们将GenM模型的部分描述为表一中的AzimuthElevation映射。
表一列举了使用粗略性能评估技术得到的延迟性能评估值。
这些值在后面使用分离的仿真技术进行修改。
完整的GenM模型包含了对延迟，和在MIPS处理器中执行的所有其他四种不同映射中所有任务能耗的评估。
使用专用仿真部件能获得我们期望的更高精确度（错误率小于3%）。
但是，当使用粗略计算时，错误率会超过20%。
StrongARM处理器的结果更加有趣。
我们以三种不同运行频率进行实验。
使用每个任务的专用仿真部件时，对比通过完整应用程序的低层次仿真得到的评估结果，所有六个评估结果的错误率都少于7%。
但是，当与通过粗略评估得出的HiPerE结果比较时，其错误率在3.2%和11%之间。
五，使用MILAN的应用程序优化
MILAN是基于集成仿真框架的嵌入式系统设计和优化模型。
设计者在形式上建模目标应用程序、底层硬件和通过MILAN提供的图形接口的限制条件（延迟、吞吐量和能耗等）。
模型的信息被转化成集成仿真器要求的合适输入格式。
这样，MILAN就具有了使用来自专用系统输入输出格式驱动多个仿真器的能力。
模型解释器将模型转换为系统执行环境可用的形式。
使用层次级仿真可以高效地评估设计空间。
设计空间代表含不同参数的多种设计，比如配置、运行电压及典型SOC架构中可用的实现选择。
设计空间的评估需要对设计空间进行高效的遍历。
层次级仿真要在多个抽象层次上进行仿真，这样就能控制仿真速度，所需建模工作和仿真结果的精确性。
层次级仿真利用HiPerE的处理能力快速地进行系统级性能评估。
HiPerE创建了层次级仿真的最顶层。
层次级仿真在MILAN中由两层构成。
最底层由所有的专用仿真部件组成。
不同抽象层次中，独立部件（处理器，可重构逻辑，内存）都有若干可用的仿真器件。
仿真器件通过考虑速度和精确度提出平衡的方案。
在DSE期间，可以不顾设计者提出的性能限制对设计进行性能评估。
基于层次级仿真的DSE有下列内容：
1，设计者对应用程序以及使用应用程序、资源和映射模型（MILAN可用模型）的目标架构进行建模（在图形化接口中）。
模型能获得所有可能的设计的设计空间。
设计者在初始化时，对GenM模型中描述的不同参数进行粗略的评估。
2，设计者使用一种或多种优化技术，识别出一组设计并将其作为优化输出。
这组设计就是设计的初始值。
设计者也可以选择直接使用所有可能的设计作为设计初始设计集。
3，HiPerE基于专用性能评估仿真部件的初始值和每个设计在初始设置的作业报告，提供系统级的性能评估值。
我们使用这些结果从基于性能约束的设计空间中挑选备选设计方案。
4，设计者针对特定任务选择专用的评估部件，以达到获得更加精确评估值和再次执行HiPerE的目的。
这样我们就获得更加精确的可以优化HiPerE初始选择结果的系统级性能评估。
5，在最后一步中，设计者要识别出合适速度和精确度的仿真器件，对HiPerE挑选的设计方案进行仿真。
在找不到能仿真完整SOC架构的单个仿真器时，HiPerE就要从多个仿真器中获得结果，并进行集成得到最终结果。
在层次级仿真中，最后一步通常是使用最精确的可用仿真器，并识别基于仿真结果和性能约束条件的最终设计方案。
第五章的C部分是对层次级仿真的例子。
表二和表三中的RE列是基于AzimthElevation程序中任务的离线估计值。
StrongARM和MIPS处理器中HiPerE评估的错误率分别是3.2%-11%和>20%。
MILAN列中的值是专用性能评估部件对每个任务的评估得到的结果。
因此，使用HiPerE的评估时，StrongARM和MIPS处理器的评估精确度分别得到了7%和3%的提升。
这些评估值将会与使用SimpleScalar和JouleTrack的完整任务的低频仿真结果进行比较。
六，结论
我们对SOC架构、GenM模型和基于GenM的快速系统级性能评估提出了高层级的抽象。
HiPerE是一种高层级解释器，它对高效SOC架构程序映射使用层次化仿真，以达到探索MILAN设计空间的目的。
GenM模型为良好定义的优化问题提供抽象。
系统级的快速性能仿真拥有广泛的应用前景。
为了在使用HiPerE之后快速地修改设计空间，我们在起始阶段就使用DESERT为DSE提供层次级的方法，DESERT是一种使用有序二进制决策图的符号搜索工具。
最后，我们使用低层级仿真器挑选出最终的设计方案。
我们也会通过研究FPGA的详细建模过程来获得高效能的算法设计和优化，来补充文中讨论的情况。
我们建议生成使用函数化的性能参数值的参数化设计。
应用程序映射到SOC架构的过程将用到这种设计。
升级会员 