技术分析：改用 Deterministic ICE

Deterministic ICE 中也许已完美地将电路内仿真 (ICE) 与基于软件测试的虚拟环境相结合。

笔者承认自己有所偏爱。举个例子，笔者特别喜欢吃意大利美食，也会偶尔品尝下日本生鱼片。同样，针对硬件加速仿真的部署模式，笔者也有所偏好。笔者不青睐电路内仿真 (ICE) 模式，这个观点已在笔者众多文章中表达过。

需要指出的是，ICE 模式曾经是硬件加速器的第一种部署方式。在这种模式中，硬件加速器需要插入物理目标系统上的插孔，以此代替待开发的芯片，从而利用实时数据支持运行和调试硬件加速器内部映射的被测设计 (DUT)。

与 ICE 模式相比，笔者更喜欢虚拟环境模式中的部署，且该模式拥有基于软件的测试环境。与寄存器传输级 (RTL) 相比，它是在更高抽象层次上进行编写的，以此代替物理目标系统。（参见下表）。

正如意大利的一句流行说法："让凯撒得到他应得的"。或者如美国的一句流行语，"即使对不喜欢的事物也要公平对待"。显然，ICE 最大的好处就是可以通过真实流量来运行 DUT，进而减少耗时并且避免测试平台创建过程中可能出现的错误。赶紧在实际应用中全面施行这一流程吧。想必，要在模糊的设计区域里寻找令人厌烦的隐匿错误，实际应用会比任何基于软件的测试平台都更为有效。

ICE 的另一个独特性在于它能支持与目标系统连接的自定义和专有接口，而该目标系统基于的高度机密 IP 内容是硬件加速仿真的终端用户绝无法向外界披露的。将这种方法与创建和调试测试平台比较。如果出现错误，设计人员最后总是会问："这是测试平台错误还是设计错误？"很显然，调试测试台会延长验证任务的总分配时间，而用于验证的时间从来都是不够的。

ICE 验证方法伴随着众多问题，其中大部分问题源于该方式的硬件本质。这些问题包括缺乏灵活性、有限的复用性、存在潜在不可靠性以及各种影响部署的不便性。更别提，ICE 还会产生额外成本以及功耗，这些可通过虚拟方式降低或快速消除。

其中最突出的一个问题就是：当调试 DUT 时，它缺少确定性或者可重复性。

设计调试

设计调试是无法提前规划的一种探寻过程。这是因为，错误往往因为未知的原因，在未知的地方和时间，出其不意的出现。

如果将其应用于包含大量嵌入式软件的几亿门片上系统 (SoC) 设计时，调试过程需要较长序列。为了在硬件或者软件设计中找到隐藏于未知角落的错误，这些序列需要运行，即使不是几十亿次，也得是几百万次的验证周期。

在以上示例中，存在三个关键未知因素：地点、时间和事由。这三个因素足以延误整个测试计划的进度，即便该计划已经过深思熟虑。请谨记，在竞争如此激烈的市场中，若一项生命周期为 24 个月的新产品延期一个月上市，那么它将造成 相当于潜在总收益12%的损失。若产品生命周期为 12 个月，如现代智能手机，其潜在损失将大幅增加，约占总收益的 25% 或四分之一。

潜在的损失足以说明验证解决方案的价值所在。

硬件加速仿真就是此项任务的最佳选择。硬件加速器的性能极为快速，与硬件描述语言 (HDL) 软件仿真器相比，其执行和调试速度高出了几个数量级。事实上，它们的快速执行速度便是它们的设计初衷。对于疑似隐藏设计问题的区域，它们即便在运行了几十亿次周期之后，仍能快速缩放。

虽然相较于基于软件的验证解决方案，硬件仿真价格更高昂，但在从每个验证周期来看，它们却是最便宜的验证引擎。

ICE 调试问题

然而，在 ICE 模式中调试芯片设计会显得过于繁琐而又令人沮丧。这是由于物理目标系统缺少确认性以及可预测的行为，从而妨碍了错误的发现并延长了发现时间。

使用硬件加速器追踪 DUT 的错误，就需要基于特定时间触发，全速地把每个设计寄存器的活动捕获到追踪存储器中。追踪存储器容量很有限，仅能容纳几百万次周期的波形深度，这相较于几十亿次全速运行的周期是非常少的。

连续运行时，会在不同的时间/区域内显示相同的设计错误或者根本不显示任何设计错误。

因此，用户为了找到自己感兴趣的调试窗口和转储正确的波形最终需要进行多次--很可能是数百次的运行。由于 ICE 模式行为具有随机性，每次运行都可能会在不同的时间点内检测出相同的错误，甚至更糟糕的是，根本检测不出任何错误（参见上图）。它具有随机性。很显然，在 ICE 模式中复现错误是一项挑战，其对于快速找到错误根源至关重要。

来看下SoC大量使用第三方 IP 的例子。经常，一个能单独工作的IP核在内嵌于SoC时却无法工作。利用 ICE 模式对深埋于 DUT 的 IP 进行调试可能会导致验证团队没日没夜地加班。