新思科技, 引领万物智能

 

静态代码验证:从源头解决数十亿门级ASIC设计挑战

作者:Rimpy Chugh, Product Marketing Manager, and Rohit Kumar Ohlayan, Director; Synopsys Silicon Realization Group

专用集成电路(ASIC)的设计规模不断扩大、复杂度不断攀升,这对芯片开发者的能力和所使用的工具都提出了更高的要求。

在之前的文章中,我们探讨过数十亿门级ASIC所面临的跨时钟域(CDC)跨复位域(RDC)挑战,今天我们将共同探讨第三大挑战──静态代码校验

 

高效的代码校验让芯片开发周期左移

代码校验,即对源代码进行自动检查以排查错误,是硬件开发生命周期中非常重要的一环。如果能在RTL开发的早期阶段就开始代码校验工作,评估代码质量以及一旦代码错误会对设计流程的后续环节造成哪些影响,这对开发者来说将会大大提升开发效率,并最终实现开发周期的左移。

现在的代码校验已经远远超出了RTL语义规则检查的范畴,扩展到了综合能力检查、结构分析以及网表/电气规则检查。为实现左移,芯片开发者希望能够在开发流程早期阶段就完成许多复杂的任务,比如在 RTL 内执行更复杂的检查,以及确保 RTL 与下游合成引擎更加一致等等。开发者还希望 RTL 对各种仿真器“友好”并可进行互操作,同时兼容等价性检查器。这些要求都不简单,而这其中真正的挑战就在于如何从源代码中寻找并修复漏洞。

如果把这些挑战放大到数十亿门级ASIC的设计中,可以想想代码校验会有多复杂,因此为了在设计规模和复杂度不断攀升的情况下,依旧实现将开发周期左移,就需要更强大的代码校验工具来帮助芯片开发者们高效完成代码的预先排查工作。

 

管理规则集

代码校验工具需要使用规则集运行,开发者需要创建、管理和编策这些规则集。这些都是非常专业的技能,其中涉及的专业知识通常是小公司不具备的或者想要引入的,所以对小公司而言,入门级的做法就是购买现成的软件包。而大型公司一般有自己的内部代码校验规则集,这些内部规则集对公司来说都是重要的投资。

第三方或行业标准规则集可以降低准入门槛,帮助小规模的设计团队加速代码校验工作流程。新思科技的GuideWare方法学文档和规则集正是为了这一目的而开发的,旨在帮助开发者快速开始采用此技术,并根据需要进一步制定规则。

GuideWare的目标是能够在至少80%的用例中实现RTL移交,从而更大限度地减少创建、管理和编策相关规则所需的专业知识。对小型设计团队而言,GuideWare绝对是一个福音,他们的设计可以实现质的飞跃,生产力也会大幅提升。

新思科技会对GuideWare定期进行更新,以确保规则集的复杂性始终处于行业领先地位。新思科技的IP均已通过代码校验认证,开发者们可以选择新思科技的IP以及GuideWare中的设计复用合规性检查功能,做出符合行业标准的设计。

 

如何处理无用代码?

无用代码或无法访问的代码在开发阶段通常都会存在,有些甚至会保留到流片阶段。为什么会这样呢?

设计的复杂性在开发过程中也会不断演进,开发者会随时进行漏洞修复、增加功能、集成可复用的模块等等,有时还会为了实现功耗和性能目标做全面的代码优化,这样就会导致最初写的一些代码变为无用代码。但是由于产品交付时间并没有因为设计变复杂而延后,迫于时间压力,很多时候开发者没有时间去清理这些无用代码。虽然保留这些代码并不会影响下个代码的正常运行,但是如果追求精简设计,这些代码就必须要处理。

使用代码校验工具来清理无用代码是非常有必要的,有些开发者对工具是否好用持怀疑态度,他们可能会为了以防万一就保留相关代码,但大多数都会秉持“零违例”准则,即“要么修复,要么放弃”。因此,代码校验工具能够准确识别无用代码并知道如何处理它们是非常重要的。

新思科技的静态代码校验工具VC SpyGlass™ Lint采用形式引擎,在识别无用代码上效率非常出众。但开发者通常会有以下几种操作选项:

  • 更新RTL代码从而移除无用代码:这应该是能把无用代码清理的最干净的解决方案,还能够有效移除覆盖率分析中的覆盖率空洞。但这一方法需要重新构思代码,并进行功能验证,所以比较花时间。
  • 把无用代码注释掉并为了以后参考附上相关信息的注释:虽然这种方法也还需要进行功能验证,但它也能提供一个干净的代码并移除覆盖率空洞。

弃用代码校验 waiver 文件中的无用代码:仅确认无用代码的安全性,不对其进行清理,RTL代码库保持不变。覆盖空洞将仍然存在。

 

了解设计复杂性

越复杂的设计所包含的漏洞也就越复杂。但开发者在设计中通常都会追求精简、直观、一看就懂且易于维护的代码结构。不过随着时间的推移,在开发者不断debug修正代码的过程中,代码的整体质量与最初相比会有所下降,他们可能还会突然发现RTL代码怎么好像越改越复杂了,逻辑也越来越难理解了。

衡量并可视化呈现代码的复杂性可以帮助开发者“看见”代码中变得复杂的部分,他们可以利用这一信息对积攒的复杂代码进行评估和推演。针对复杂性风险过高的代码区,开发者会在性能和功能之间做一些权衡,并对部分代码进行重构。

通过同行评议保证鲁棒性很有用,且是一项所有设计团队都应采用的最佳实践,但新思科技的VC SpyGlass Lint有一个独特的优势是其他工具无法比拟的,就是可以衡量代码的复杂性,为开发者提供非常有用的建议。VC SpyGlass Lint利用形式引擎提供功能分析及代码复杂性分析,并通过仪表板呈现结果。

 

远存问题在的误报

在CDC和RDC的文章中,我们讨论过误报问题,这一问题在代码校验过程中同样存在。在数十亿门级的设计中,势必会产生大量违例,数量过大就会有遗漏风险。开发者们希望的是,工具可以帮助他们直观地看到有意义的信息、准确评估信息、正确标记违例、对违例进行分类等等,从而提高处理违例的效率和准确性。

VC SpyGlass Lint利用形式引擎来有效解决误报问题。开发者们无需知道形式验证,也无需具备这方面的专业知识,所有形式验证都将在后台完成。这一工具内置了5000多项检查,而且新思科技仍在不断地对检查项目进行添加和完善。

 

功能校验,加快签核

借助一键式形式验证的功能校验,开发者们可以在验证平台可用前就对功能和覆盖率问题进行测试,从而节省时间并实现左移。功能校验在检查以下控制问题时非常有用:

  • FSM死锁
  • 无法访问状态的检查
  • 覆盖率问题(如常值信号)
  • 无用代码检查
  • 数组边界违例

 

总结来说,如果开发者们能够尽早知道复杂的RTL代码是否能够实现预期的设计结果,他们就可以在设计开发后续流程中节省很多时间和精力,不仅实现开发周期的左移,还可节约成本。新思科技的VC SpyGlass Lint等工具可以完美解决这一问题,它利用形式引擎实现功能分析,可有效帮助开发者们尽早判断他们的RTL代码质量是否满足设计需求,最终加速签核。