18.luck新利
的意见

Exascale仿真调试的挑战

的长度测试,失败繁殖,产生的庞大的数据量对模拟造成麻烦。

受欢迎程度

多年来,半导体行业调查显示,功能验证是芯片开发的主要阶段,调试验证是最耗时的任务。问题是恶化的在当今时代exascale调试、软件应用程序驱动测试的十亿多周期运行超过十亿门的仿真设计。芯片系统(SoC)设计的服务器、网络、图形、移动、机器学习和人工智能(AI) /应用程序达到或超过这个调试的复杂性度量。这些设备的验证提出了三个主要挑战:减少努力找到时间窗口在一个测试失败的根源,确定性繁殖出根本原因,使用可伸缩waveform-based调试来确定确切的根源。

第一个exascale调试挑战来自测试的长度。仿真测试一般包括重置SoC设计,启动一个操作系统,开始各种各样的系统服务和用户应用程序运行。这个过程通常需要至少二十亿模拟时钟周期。如果一个应用程序发生故障或操作系统挂起,失败的根源往往发生在更早的阶段。例如,损坏内存位置由于缓存一致性错误在设计可能发生在操作系统启动而不是阅读十亿次或更多。传统waveform-based调试是有效的窗口只有几百万周期或更少。去测试失败的根源,发现设计缺陷通过迭代向后成千上万的波形窗口是不切实际的。

第二个主要挑战是繁殖失败由于高吞吐量仿真要求。运行缓慢的模拟与仿真同步testbench是非常低效的,因为它可以离开时模拟器空闲模拟追上了。为了避免这个问题,可以设置模拟测试与设计和testbench并发运行。问题是,这将导致非确定性自testbench可能与设计沟通在不同的时间取决于服务器负载或接口流量。如图1所示,重新运行相同的测试可能不复制失败,使它几乎不可能调试底层设计错误。


图1:运行一个典型的仿真测试多个testbench接口不得复制失败

exascale调试的第三个挑战是庞大的结果今天的出类拔萃。如果失败可以复制和适当的调试窗口可以识别,数据必须倾倒的模拟器用于调试目的。现在在g的数据量,远远超过megabtyes经验的老和更小的设计。这种原始调试数据,通常只是状态元素的值,必须扩大成一个完整的转储文件为所有信号值。这个过程可能需要一个小时或更多,导致许多g的转储文件。最后,时间将数据加载到一个waveform-based调试工具已从几分钟到一个小时。再乘以转储、扩展和负载调试数据可以大大增加时间找到并修复设计错误。

幸运的是,现代仿真技术可以提供解决方案这三个exascale调试的挑战。根源识别可以加速如果模拟器能流系统级抽象日志等数据接口、关键事件,跳棋,断言,选择信号。用户可以利用这些数据来缩小的问题,关注特定窗口几百万周期适合波形调试。流媒体的高层数据必须是连续的整个测试运行(“无限深度”)。进一步,模拟必须运行没有停顿,以防止任何降低吞吐量。

复制失败确定性的最好办法是模拟器记录在测试运行期间testbench的刺激。如果发生故障,仿真可以再次运行测试,重演刺激文件,消除任何非确定性由于testbench响应的变化。此外,模拟器应该支持保存和恢复,这样一个测试可以运行从一个中间点而不是重置在时间为零。一旦用户确认调试窗口,仿真可以从接近这个窗口保存/恢复点。如图2所示,这个过程加速调试通过波形更加迅速。


图2:保存/恢复点重新运行较短的测试调试数据转储失败的根源

最后,仿真器必须支持一个exascale调试数据转储流尺度。原始数据必须能够流模拟器通过高速接口的tb /秒或更多。高性能并行扩展能力必须能够转换原始调试数据转储文件在几分钟内完成,而不是时间。波形调试工具必须加载转储数据高效、快速响应交互式命令。例如,选择一个信号并将它添加到波形通过拖放应该不超过一秒。有效的调试需要脆交互性能和最小的循环时间在仿真运行测试并将结果变成调试工具。

今天Synopsys对此提供了一个exascale调试解决方案瘤牛服务器4威尔第。这种组合提供了所有上述解决方案,已被应用在许多SoC项目。AMD在2017年提出的一个案例研究设计自动化会议(DAC)提供了一个示例。AMD团队模拟大型图形IP块在瘤牛运行所有非图像部分的SoC在虚拟平台上连接到一个虚拟机建模一个主机电脑。他们捕获的所有I / O信号所以失败测试可以运行确定性仿真没有任何软件的虚拟模型。团队还定义定期恢复点的测试可以有效的调试。

exascale调试的时代来了,昨天的技术不规模减少根源解决的三个关键挑战,确定性繁殖问题的根源,缩放waveform-based调试。一个可行的解决方案,应对这些挑战是可用的今天,启用调试的最大和最复杂的testbenches SoC的设计。



留下一个回复


(注意:这个名字会显示公开)

Baidu