技术分析:改用 Deterministic ICE

时间:2016-04-26 17:50:07 来源:与非网 有0人参与

更多

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


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

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

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


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

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

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

设计调试

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

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

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

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

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

ICE 调试问题

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

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


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

Deterministic ICE

于是,问题变成了:是否可让 ICE 的调试环境具有确定性?很高兴,答案是肯定的。

如果设计人员在精确序列中的首次运行中,捕捉到激励和响应,然后移除物理目标系统(内在非确定性)并不断回放激励,那么调试环境将具有可重复性和确定性。这就称为 Deterministic ICE。

基本上,这种方法是将物理 ICE 环境转变为等效的虚拟环境,从而让设计人员获得虚拟环境的所有特征和功能优势。它们可以检查断言与覆盖率收敛、执行低功耗分析和功耗估计,并进行嵌入式软件调试。