有效地发现和修复错误使用SystemVerilog编码援助。
芯片设计和验证的关键原则是,必须找到bug和固定尽可能在开发过程的早期。人们常说,抓住一个错误在每个连续的项目阶段成本比率乘以10。错误,逃避硅验证和使他们的方式非常昂贵和耗时的修复。理想是捕捉尽可能多的类型的问题是设计者输入寄存器传输级(RTL)设计和验证工程师代码中的testbench硬件验证语言(等)。今天,两组最有可能使用SystemVerilog作为他们的输入格式。
硬件设计和验证过程看起来更像软件开发工程师编写、测试和调试代码。考虑到代码协助工具已经存在了多年的编程语言,似乎SystemVerilog容易开发一个类似的解决方案。然而,这是一种极其复杂的语言与RTL构造,断言,支持constrained-random testbenches和面向对象的编程(OOP)的能力。只是解析完整的语言,并检查适当的语法是一个重大的努力,但更多的是需要在开发所需的“左移位”发现和修复许多类型的bug。
SystemVerilog代码必须完全编译和阐述,让所有的部分设计和testbench连接,使复杂的检查。Pseudo-synthesis也需要在一些层面上分析信号,检测死代码,和认识时钟和重置。理想情况下,解析、编译、精化和合成所有发生的“动态”,以便检查每次用户类型发生在新代码或编辑现有的代码。一个易于使用的交互式编辑和探索界面必须立即由强大的语言引擎运行检查,报告结果和建议在可能的情况下“快速修复”。
这个过程必须有弹性的编码错误,运行的关键在发展早期设计和testbench时不完整的。交互式界面,从检查错误和警告标记的直接相关的部分代码。用户可以同时打开多个视图,所有的超链接。点击问题报告中的一个错误或警告窗口直接导航到相关代码在相关文件中。检查规则必须是可配置的,每个用户,基于或全公司的基础上,实施一致的编码风格。用户必须能够添加自定义规则和在适当的时候放弃警告。
芯片设计一个有效的检查解决方案和验证代码必须满足额外需求。它必须支持完整的SystemVerilog语言和内置的通用知识验证方法(UVM)。这提供了验证团队的好处,因为他们编写和调试testbenches。检查必须包括检测不可到达的(死)代码,无限循环和递归零类处理,动态铸造侵犯,数据类型不匹配,禁止入内的访问,“独特”的侵犯,并在约束和断言错误。其他检查确保代码符合流行的模拟、仿真和调试解决方案。
更有效的找到并修复问题编码比调试期间testbench仿真失败。模拟不能开始,直到大部分或全部testbench和设计准备好了,但是代码检查项目中更早地发现这些问题。在许多情况下,它不仅报告一个问题,但也使一个快速修复的建议。如果建议被接受,代码生成尽可能多的信息填写,“TODO注释添加需要用户输入的地方。规则检查可以在团队成员之间共享和跨项目和组织实施。
内置的规则必须检查UVM testbench代码符合IEEE 1800.2标准和其他类型的错误。UVM的深刻理解,使先进的检查和快速解决问题的建议。模板提供了许多常见结构,和这些用户可以扩展自定义模板。许多UVM组件非常复杂,因此添加从一个空白的屏幕编辑是单调乏味,而且容易出错。一旦验证工程师开始输入代码,例如定义一个新类,一个模板提供指导完成所需的所有信息。
必须有额外的援助让编写代码更快,更容易,更准确。当用户开始输入一个名称,自动完成提供了一个已经定义的名称列表,可以匹配。是更有效的从列表中选择输入长名称。内容辅助显示相关的选项,例如可用的选择类的成员。用户可以选择其中一个成员和使用它作为一个模板。定义在这个过程中,任何新的名字以及名字的变化在一般情况下,在所有相关文件可以自动传播。没有必要手动遍历文件使得每一个同样的变化。
设计师的早期代码检查也有很多好处。testbenches的许多功能也与RTL设计相关的代码,包括编译和细化检查,综合检查,可定制的规则,死代码和界外访问检测、违规,快速修复建议,自动补全和内容辅助。专门设计检查检测编码错误和实践可能妥协的正确操作。这些必须包括组合循环,意想不到的门闩,闭塞的人字拖,时钟和复位问题,司机违反/负载和宽度不匹配。设计师可以接受建议修正或放弃的警告。
Synopsys对此欧几里德的解决方案满足所有这些需求。代码查看和导航选项让它更容易理解设计和testbenches继承。SystemVerilog初学者学习语言更快,甚至有经验的工程师受益于快速修复和代码模板。动态检查检测多种类型的错误来源,提高代码质量。常见的编码风格和方法可以执行项目广泛的简化设计和testbench集成。结果是提高工程效率,缩短项目进度和降低芯片将由于错过了错误的机会。
有关更多信息,白皮书是可用的。
|
|
|
|
|
|
|
|
|
|
留下一个回复