在SoC设计中用SystemC虚拟平台预览USB的性能

现在的程序员和系统架构师有比以往更多的软件可用于SoC（单片系统）设计，但也面临着一个日益困扰他们的问题：如何在设计前期，在硅片拿到手以前评估和优化软件的性能。为解决这个问题，程序员们转向虚拟平台，这种平台采用软件来对目标硬件的架构和功能建模。

当设计师们小心地在其它软件工具帮助下完成这个任务时，这些平台被证明是有效的方法，可以对很多重要性能的度量做出早期评估，如有关嵌入软件功能好坏及其与现有硬件的互相影响。虚拟平台可以预测CPU效率、数据传输率以及缓存失中率、中断等待时间、功能性热点，以及其它性能的度量。

为了便于理解和体会虚拟平台的性质与价值，考虑这样一个例子：评估一个USB系统软件栈的性能。开发者的选择是有相当的理由，因为USB2.0有480Mbps的传输速率，是承载实时音、视频数据的常见选择。因此，USB在多媒体产品中得到日益广泛的应用，如机顶盒和手机。

由于USB的互动中包含有复杂的协议和软、硬件之间大量的相互依赖，因此特别需要这种平台的帮助。这种情况下，不仅要求软件架构尽早确认USB系统软件，而且要估算出软件在CPU上的负载，

此外还有中断等待时间的影响，从而保证USB确实是一个可行的选择。

这种性能预估要求虚拟平台能够对实际硬件功能，包括处理器、缓存和系统内存、USB外设、USBEHCI（扩展型主控制器接口），以及USB设备等，建立非常接近的模型。此外，还需要一个剖析工具来寻找软件栈中的功能热点，精确地预测出完成功能所需时间。开发人员用平台得到的结果，与理论预测值做对照调整，而平台也可以检验USB栈在实际硬件上实现性能的稳定性。另外，当开发人员修改软件栈时，平台还可以精确地反映出性能的变化。

在本例中，设计师想出一种评估USB系统软件栈性能的方法，该软件栈运行在嵌入机顶盒芯片中的DVR（数字视频录像机）子系统中。DVR含有一个录/放音、视频数据流的USB硬盘驱动器。USB软件栈包括一个单线程DVR应用实例，它用驱动器完成一系列读、写操作。

功能平台非常详尽地模仿DVR硬件的运作，揭示出重要的时序参数。特别是该平台建立了一个USB主控制器、硬盘驱动器和系统内存与缓存的模型。平台有一个新颖的功能，它含有一个用SystemC写成的事务级模型，以此证明该方案能够用于建立评估复杂嵌入软件的虚拟平台。开发人员一般采用RTL（寄存器传输级）模型建立系统硬件的模型，与事务级模型相比，这种方法的抽象层次较低。

平台设置

虚拟平台包括一个USB2.0EHCI、一个USB硬盘驱动器、一个缓存仿真器、一个主处理器指令集仿真器，以及系统内存。USB2.0EHCI模仿主控制器的功能，提供480Mbps数据速率下的精确时序值，以及基于内存模型的内存访问时间，还有EHCI寄存器的读、写时间。EHCI亦作为一个DMA主控，可以不通过缓存访问系统内存。

为了跟踪所有的指令与数据存取，USB软件栈运行在一个在事务级硬件模型上建立的指令集仿真器上。指令与数据记录通过虚拟平台，测量CPU使用率、缓存失中率以及中断等待时间等。另外，用一个高度可配置、可扩展和模块化的剖析工具Flexperf判别功能热点，帮助完成软件栈的排错。

系统在寻址硬盘驱动器时是按照划分为扇区的I/O文件，符合海量存储设备规格，包括USB实施者论坛的“bulk-only”规格。于是，它可以通过端点0执行所有标准的设备请求。它还可以执行一个SCSI命令的子集，通过端点1和2与DVR相关。

缓存仿真器对一个可配置的缓存建模，该仿真器包括一个环绕式处理程序Dinero、一个追踪驱动的开放源缓存仿真器。作为系统处理器，围绕指令集仿真器的处理程序为一个216MHzSTMicroelectronicsC2CPU内核建模。仿真器将处理器的内存访问转换为事务级模型。开发者将系统内存建模为一个RAM阵列，所有模型的连接都通过一个大体上基于ARMAHB（先进高性能总线）的精确事务通道和一个开发者在USB上松散建模的通道。

调用该平台对软件性能参数的评估是一个分两步走的过程（图1）。第一步，USB栈运行在ST20指令集仿真器上。这个过程生成一个追踪文件，它记录了所有的指令内存和数据内存访问，以及硬件启动的任何中断。第二步，有一个流量发生器对追踪文件进行语法分析，并在一个精确事务的通道上生成等效的事务级操作。

两步走的评估过程体现出芯片设计的一般步骤。在第一步中，设计师将设计分解为独立的功能块，它们并行运行实现所需的应用功能。因此，第一个平台只包括功能模型，而没有参考时间。设计师用相同的功能块，可以有不同的实现方法（主要是时序和性能模型），这就是第二步完成的任务。这个方案可以让用户使用一组相同的基准功能，尝试各种微架构的实现。

结果就是一个基于SystemC的公共平台，它没有外部依赖性，SystemC仿真器的时间作为评估性能的基准。同样，系统将指令与数据内存抽象成为SystemC事务级模型，准确地仿真访问时间。这种两步走方案还简化了缓存仿真器与流量发生器的连接，这是一种在硬件上对缓存影响建模的方法。

性能参数

虚拟平台生成的性能值是从运行应用程序的SystemC仿真器上获得的总时间，相当于在实际硬件上运行的总时间。应用程序的运行时间依次与指令访问时间以及与EHCI、缓存和其它功能相关的等待时间有关。从这些值中，可以确定重要的性能度量，如CPU占用率、数据传输率、缓存失中率，以及中断的次数。

当然，CPU占用率是评估栈性能的最重要参数，它是CPU在执行软件栈时所花费时间的百分比。它表示CPU无法运行其它应用程序的时间。但是，要确定CPU占用率，必须首先确定并减掉CPU空闲时间。空闲时间是软件栈在空闲线

程上花费的时间，此时它等待一个硬件产生的中断。这个空闲时间发生在样例DRV应用程序向硬盘提交一个数据块或从硬盘读出一个数据块以后，但在开始下一个传输的硬件中断发生之前。必须将此时间从总时间中减去，因为严格来说，在这个时间内，USB软件栈并不占用CPU。

在这个点上，可以调用Flexperf剖析工具来测量CPU花费在空闲线程上的时间。将输入追踪文件以及一个映像文件馈送给剖析工具，前者中包含程序计数器和相应的时间。映像文件定义了与空闲线程功能有关的起始和终止地址。从这些输入内容中，剖析工具可以计算出在空闲线程上花费的时间，接下来就可以从CPU时间中减去这些空闲时间，获得准确的CPU占用率数字。

还可以将通过USB的总数据量（包括控制、批量和协议信息）除以运行应用程序的总仿真时间，计算出通过USB的数据传输率。但是，USB2.0的480Mbps速率只是一个理论最大值。由于协议开销问题加上从系统内存获取计划表和数据也要消耗时间，尤其是当EHCI缓存较小时，所以实际的数据速率要低得多。软件将数据提交给硬件的速率亦会限制数据的速率。

当你提供有内存流量信息的Dinero开放源缓存仿真器时，它会生成有关指令、数据和总失中率的统计数字。从这个数据中，可以确定最佳的缓存配置。为了在ST20主处理器追踪文件中记录中断的次数，可以累计ST20回绕式处理器捕获的中断数。从这些基本性能数字可以得到一些其它参数，包括指令集仿真器报告的执行指令总数、CPU的执行时间（总时间减去空闲时间）、CPU的总指令执行时间，以及总CPU读、写时间。

本例中虚拟平台获得的性能结果是超出了本文讨论范围的数学推导。但是，这些推导的内容包含最大SCSI缓冲、读/写操作时传输的数据量、系统软件为中断服务花费的时间，以及处理与硬盘驱动器有关的SCSI命令的时间等之间的关系。

使用虚拟平台，可以得到块的大小、总数据传输量、缓存参数、数据传输机制、栈尺寸、CPU占用，以及其它重要的性能数据等结果。通过虚拟平台的预测与硬件结合起来，可以极大地简化开发确定过程。

例如，虚拟平台表明增加块大小（即每次读、写操作时传输的数据量）可以降低CPU占用率（表1）。但是，块越大，降低的程度越少。平台亦预测CPU使用率会随数据传输量的增加而下降。平台作这些预测的前提是采用216MHz的ST20-C2内核，10ns缓存命中等待时间，160ns的单字内存访问时间，以及可在等待硬件中断前缓冲最多256kB数据。该平台亦假定缓存模型含有8kB、双向、组合式指令与数据缓存，每个有16B的块。另外，它还假定USB的传输速率为80MB/s。

出人意料的是，平台指出缓存大小对USB栈的性能影响不大。一次实验改变了主要缓存的参数，如大小、组合以及块大小。虽然不同参数对整个应用程序的请求丢失有很大的差异，但对CPU占用率的影响不明显。在这个仿真阶段，用初始化的CPU时间（包括设备计数）减去运行应用程序的总CPU时间，得到CPU占用率。结果清楚地显示，硬盘的读、写操作包括对指令内存和数据内存的正常访问，即由于读、写操作在时间和空间上的高度本地化，对硬盘驱动的丢失的总次数近似为恒定，而与缓存参数的变化无关。

表2总结了不同缓存大小的结果。在所有情况下（组合为2，块尺寸为16kB），指令缓存和数据缓存都是一样的。表3显示同为16kB、8kB缓存不同组合值的结果。表4则是组合为2，块大小为8kB缓存的结果。

这些结果均假定有一个5ns的缓存命中等待时间，四个字访问，每个字花费时间为160ns。

缓存大小对CPU效率的影响很小，与此相反，EHCI将数据移入、移出内存的方式之间则有很大不同。拷贝语义学（copy-semantics）方法将数据从缓存区移到一个EHCI可访问的非缓存区。非拷贝语义学（Noncopysemantics）则假设EHCI可以访问包含所需数据的内存区。在这种方法中，内存区是未经缓存的，传给EHCI的是一个指向内存位置的直接指针。

这两种机制的性能数字有着很大的差异，因为在非拷贝语义学情况下，不用将数据从一个内存区拷贝到另一个内存区，这就省去了所有的移动指令，当移动大量数据时极大地减轻了工作量。例如，当重复64次以256kB传送32MB数据时，虚拟平台显示的数据速率和CPU占用率，拷贝语义学方式分别为5051kB/s和6%，而非拷贝语义学方式分别为7700kB/s和40%。

在评估栈大小的效果时，一般预测认为较小的栈会减少CPU占用，而虚拟平台得到与直觉相反的结果（表5）。除CPU占用以外，表中显示较大的栈还会增加一个应用程序执行的指令数。

但是，修改堆的大小时结果保持不变。（堆是一个内存区，应用软件可以作直接分配和解除分配。与之相比，栈的管理是通过编译器，而不是应用程序。）这些结果令人惊讶，因为栈是受到编译器控制，它的大小应该没有关系，而在其他情况下，表现为216MHz处理器时钟速率和10MB/s数据速率。

虽然虚拟平台得到了有希望的结果，但它仍与硬件的工作有不一致的地方。例如，ST20处理器流量发生器的模型过于简单。它假定每条指令的执行阶段都是一个恒定的平均时间，但事实并不总是这样。此外，流量发生器建模时既无处理器流水线停顿也无任何流水线停顿的情况。不过，这些因素之间有些相互抵消，得到的结果还算准确。

现在的工作重点集中在建立更复杂平台和开发无缝的方法上，用于评估任何软件栈的性能。例如，正在进行的是虚拟平台与Flexperf这种剖析工具相结合，使软件编程人员和系统架构师有一个统一的方法，能够评估并增强嵌入式代码的性能。