在第二个范例中，当MAC HW处理控制帧时，全局定时为：

窗口编程时间=T+tprg_winexp，故系统中，HW对及时打开发送窗口的指令进行编程。

与此同时，现有的SPEAr板起到了很大的帮助作用，因为在板上测出了AES-CCM引擎的性能。因此能够推断出硬件中存在AES-CCM，因为AES-CCM软件算法给不出所需要的性能。

挑战

被测设计(DUT)或被测单元(UUT)的测试对任何设计方法学来说都是最关注的一个方面。在开发的初始阶段，即架构评估阶段，必须需要一个高性能的性能仿真环境。具有行为功能TLM平台能够满足这一需求，并对将要执行的功能进行功能检查。当进入到低级抽象设计阶段时，仿真性能大大降低，这成为有效验证IP的一个问题。

软硬件的系统级仿真与软硬件的协同仿真一块进行。ST有自己的平台，这是一个包含硬件(RTL)的混合平台，软件利用SystemC书写(见图2)。该平台的瓶颈是环境中所引入IP的RTL，而且注意到这将大大地降低性能。正如预期，这是所遇到的约束，而且对是否能够比主仿真运行更快的可能性进行了评估。该方案基于Xtreme服务器硬件仿真，使得运行速度至少要比NCSIM仿真快10倍。

图4：配有软件的Xtreme服务器配置。

图4所示的该技术对第一次仿真特别实用，不需要任何有关环境配置方面的工作量。其概念是在Xtreme的FPGA中运行RTL IP。开始时，引入的时钟为软件时钟，但结果相当可喜，还简化了RTL的系统验证和调试。配置过程中，整个仿真环境是类似的，仅有的改变是用VHDL RTL IP替代SysC IP。试验结果是仿真速度快了10倍。因此，Xtreme服务器平台满足了RTL验证/调试所用平台的需求。最重要的方面是具有与ncsim同等水平的调适能力。还提供了与SystemC环境的无缝集成。

调试功能

硬件方面的一个更具挑战性的问题是调试。当自检失败时，就需要一个相关的测试范例。为了验证该测试范例，在检查失败原因时必须检查所有的主要信号。所以需要对信号进行存放，验证，从而找出具体的原因。利用基于XTREME服务器的平台可以很容易地执行所有这些功能，无须额外的工作量。通过将实际硬件移入独立的FPGA，可以很容易地改善仿真速度，不过这种方法提供的调试功能较少。因此，基于XTREME服务器的平台不仅改善了仿真速度，还能提供非常好的调试功能。图5给出了分析结果。

图5：A）不同平台上的仿真性能。B）不同平台上的调试复杂性。