所有这些任务都有一个共同点：他们需要数十亿次的仿真循环。只要设计人员认识到，他或者她无法像其他那些仿真那样管理数十亿次循环时，他们的情况就像撞到了墙，我把这种情况称为“十亿次循环挑战。”

    当然，第一个挑战就是运行十亿次仿真循环需要多长时间。对平均规模的设计来说，寄存器传输级（RTL）仿真需要大约10天的量级。如果在RTL代码上修改一条连线，并且需要重新运行所有的测试来保证没有问题，那么所需的耗时就很不切实际了。花费几分钟倒还可以，难道不是这样吗？

    第二个挑战是在这么多次循环中保持芯片繁忙所需的带宽。让我们用一个可以实时处理3 gigabit数据的HDTV芯片来做例子。如果设计团队有十天时间用于十亿次仿真循环，测试平台只需要向该设计提供约10 kbit的数据--这是一个合理的数目。这也是为什么每个人都容易忘掉带宽的原因。如果目标是在几分钟内完成仿真，那就意味着向设计提供200 megabit量级的数据。要移动这样量级的数据需要特殊种类的测试平台。

    第三个挑战是调试。设计人员如何在十亿次循环中进行查找呢？如果，仅仅是一种可能，在像快速信号数据库（FSDB）这样的压缩格式中进行完全RTL级追踪，将会占用硬盘上4 terabyte的数据。只是从快速硬盘上读取文件就需要数天时间。完全的数据查询也同样是不可能的。

    跟房地产行业一样，答案就是“位置，位置，位置。”设计人员希望能在不同的抽象层次之间进行查找。嵌入式软件处在最高层，而可能产生问题的级别包括：

    * 操作系统已经完成引导了吗？

    * 进程是否卡在某个中断处理中？

    * 为什么设备的驱动器不能正确处理数据？

    一旦设计人员完成了定位--在较高层次--发生问题的地方，他或她就可以开始对这个区域进行放大，并进入较低的抽象层次。接着可以在监控、检查和断言的帮助下缩小问题的范围并跟踪出可能的根源。只有在设计人员在这两个级别检查了所有的信息之后，他们才可以进入信号级别，并获得已完成识别的某段RTL波形。在不同抽象层次之间查找问题的能力，也就是从软件开始逐渐进入硬件的过程，可以避免在大量的仿真中迷失方向。只有同时解决了上述三个挑战，设计团队才算真正克服了“十亿次循环挑战。”