在与数百位ASIC设计人员进行了长达数年的验证策略讨论之后,我终于醒悟了:我们正处在一个设计人员需要管理数十亿次仿真循环的阶段。

目前在视频芯片领域,标准和高清电视都很热门,这些芯片的设计人员需要完成数百次一致性数据流仿真,才能确保芯片可以出货。在无线手持终端市场,固件则是关键。最终器件需要引导Linux系统并在LCD屏幕上运行Java应用程序。网络路由的设计人员需要通过伪随机交通加大芯片的负荷,从而得到像丢包率这些关键性能参数的基准。

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

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

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

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

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

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

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

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

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

作者:Alain Raynaud

技术总监

EVE公司