性能参数

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

当然，CPU 占用率是评估栈性能的最重要参数，它是 CPU 在执行软件栈时所花费时间的百分比。它表示 CPU 无法运行其它应用程序的时间。但是，要确定 CPU 占用率，必须首先确定并减掉 CPU 空闲时间。空闲时间是软件栈在空闲线 程上花费的时间，此时它等待一个硬件产生的中断。这个空闲时间发生在样例 DRV 应用程序向硬盘提交一个数据块或从硬盘读出一个数据块以后，但在开始下一个传输的硬件中断发生之前。必须将此时间从总时间中减去，因为严格来说，在这个时间内，USB软件栈并不占用CPU。

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

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

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

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

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

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

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

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

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

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

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

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

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

虽然虚拟平台得到了有希望的结果，但它仍与硬件的工作有不一致的地方。例如，ST20 处理器流量发生器的模型过于简单。它假定每条指令的执行阶段都是一个恒定的平均时间，但事实并不总是这样。此外，流量发生器建模时既无处理器流水线停顿也无任何流水线停顿的情况。不过，这些因素之间有些相互抵消，得到的结果还算准确。
　
现在的工作重点集中在建立更复杂平台和开发无缝的方法上，用于评估任何软件栈的性能。例如，正在进行的是虚拟平台与Flexperf这种剖析工具相结合，使软件编程人员和系统架构师有一个统一的方法，能够评估并增强嵌入式代码的性能。