快速进化的验证计划

虽然很多公司有验证计划,要求这些计划正在改变的速度比大多数公司可以发展。

受欢迎程度

验证计划正在快速的从机制来跟踪验证进展到多方面的协调车辆数与不同的团队目标,使用复杂的资源管理分布在多个抽象和工具。

新系统要求汽车等行业正迫使这些计划进行更紧密的整合与需求管理和产品生命周期的发展。因此,今天的验证计划必须封装整个开发方法。

验证麦凯乐已成为一个巨大的挑战,”科林说,副总统的验证平台想象力的技术。“大转变我们看到最近的计划需要更符合产品要求,从安全的角度来看,需求或产品需求。它包括问这样的问题,“我的软件运行在这个设备吗?“这不再是硬件验证。这是产品验证。”

这是上面的验证团队在过去一直在做的。“他们继续计划定期保险,”鲍里斯Gommershtadt说,研发组主任Synopsys对此。“然后他们需要的软件验证计划,电源管理,现在的故障覆盖率。对于所有这些他们必须在不同的工具跟踪进度。在过去,人们的覆盖率结果模拟器和将注释验证计划。这是高级用户。他们现在有进口来自多个源的报道结果。”

但最主要的目标改变了吗?“验证计划的基本面没有改变,”罗布·范Blommestein断言营销主管OneSpin解决方案。“芯片开发团队必须从设计规范的所有特性验证,并输入他们的验证计划,确定哪些工具将被用来验证功能,注释结果的核查计划的所有工具,并收集覆盖率结果从所有的工具来作出准确的评估验证彻底性。”


图1:多级验证。来源:尼尔·约翰逊;导师,西门子业务

随着时间的推移演变。“从历史上看,当人们面对一个复杂的问题在设计过程中他们看着简化问题,”普拉卡什Narain说,总裁兼首席执行官真正的意图。“这是通过定义一个完成的方法。然后您可以构建分析的方法有效地帮助解决问题。通过启用持续集成和通过缩短验证周期的一部分,我们已经能够左移,将某些问题纳入设计域。”

既有自上而下和底部方面问题。“从根本上你要问,我的产品是正确的产品?“想象力的麦凯乐说。“这是每个人的真正的问题。很多人被挂在了大量的细节。他们有99.7%而不是99.8%的覆盖率?我们仍然做很多单位验证,问题空间并没有消失。最大的挑战是回答当我们完成。但单位验证不是今天最大的问题空间。更好的看待问题的方式是自顶向下与自底向上。”

这个新计划
一个现代的核查计划比过去复杂得多。拉里悟道,产品管理总监节奏,休息到3个领域:

  • 引擎扩张。正式的、模拟、仿真、原型-现在post-silicon成为有趣的数据可以收集和收集滚入验证图片。
  • 要求和需求的可跟踪性。这些核心功能需求的设计,它必须做什么。现在有一个扩张到负面测试领域,作为安全的需要。需求包括如何确保如果发生了糟糕的事情,这个问题包含。
  • 方法。有很多的扩张向持续集成方法,回归管理和多站点发展,加上扩大从内部向云计算平台。方法结合计算资源可用性和部署创建一系列的问题如何让所有的测试运行在不同的设施,你多久运行它们,当你运行它们,如何获取数据和收集。

大多数团队可以不再避免软件。说:“有很多事情来验证Synopsys对此Gommershtadt。“你验证设计的正确性与功能规范。你验证软件正确性/功能规范,根据电力需求和你验证规范。有各种各样的规范和要求,和验证计划的细节以及如何验证什么,以及如何衡量你验证。”

进一步复杂化的事情是多代方面产品。“谈到性能,从概念的90年代,性能分析,然后你改变一些优化和使它更好实际上是执行多个项目,”Frank Schirrmeister说,高级组的产品管理和营销总监节奏。“你可以做具体的修复,但你计划之外的一个芯片一般。你计划在某些水平在当前芯片,但某些物品将留给下一个项目,你将看到权力和性能根据实际芯片数据从之前的项目。”

最后,验证并不是绝对的,它是风险管理。“很多的计划是尽可能早地得到最好的答案,”麦克拉说。“在建筑阶段,我可以在一些宽容和接受的性能PPA吗?如果我可以,那么我年底降低风险水平。我可以,早在这个过程中,软件插入一个早期的硬件模型可用吗?我可以开始问问题,并确保我们在高水平最小化问题的机会吗?”

抽象的角色
抽象允许我们专注于杂乱细节图片前的重要元素,不可避免地导致执行慢得多。的软件抽象必不可少的。“当你购买一个处理器的手臂,你把它插在做集成测试完成,”Simon Davidmann说的首席执行官治之软件。“胳膊做了1015验证周期的核心。你知道这是一个手臂核心,你知道RTL在规范是什么。你不能有一个cycle-accurate参考模型,因为你不能写。你可以从RTL创建它,但事后,没有之前的事实。他们也太慢了。如果我们能得到一个系统启动和运行的软件,这意味着当他们试着运行它的RTL他们将会失去最容易的问题。你必须做验证在多个水平。”

它还需要一个分离的问题。说:“这里有两个进程Schirrmeister。“在更高层次的抽象的概念验证将在硬件软件界面。第二个是当有人说我将建立一个全芯片SoC模型SystemC和使用高级合成(HLS)。有一些分治,但从验证计划的角度需要考虑整个芯片。它变得有趣,当你把软件开发人员的照片,我们需要一个更高层次的抽象,比如使用一个混合的解决方案。需要计划的一部分,但有挑战性的组织问题。”

高级合成中起着至关重要的作用。”的一个关键HLS的价值主张是,你不需要做任何事在RTL设计的很晚,等各种工具之后,“说Maximillian Odendahl,首席执行官Silexica。“你可以做任何事在C级别。因为你可以更快的模拟,你也可以迭代速度更快。你可以在算法层面上进行迭代。现在你已经有了一个好主意都是如何表现,它会如何的面积和性能。你还需要做最后的验证硬件place-and-route和一切之后,但希望这是最后一块——而不是核心。你不想要做的核心部分一遍又一遍。”

HLS也有助于理解各种组件如何影响整个系统一旦融入它。“人们仍在隔离的设计,最后他们认为他们可以把一切都在一起,这将是好的,”Odendahl说。“可能在一次工作,但它不工作了。”

混合仿真,这可能是很多球队的新概念,是另一个相同的主题。“当有人跑模拟,他们通常会核实真实的软件,或者他们想要验证的某些方面的力量,“Gommershtadt解释道。“当他们达到仿真阶段,他们不希望在RTL发现bug,特别是对于大IPs如处理器或GPU。是没有意义的减缓模拟或增加的能力和把所有模拟器内部,即使它是可能的,人们这样做。所以那些碎片放入虚拟样机运行速度不够快,跟上模拟器。”

RTL虚拟块并不相同,所以混合意味着什么验证吗?“如果我们运行代码,我们不需要重新验证,在RTL”Davidmann说。“你不要在RTL验证Linux。你可能运行在硅和你可能有点RTL上运行。您不需要运行在RTL,和你做出的假设软件编译器映射到ISA和ISA实现编译器预计什么。”

再次回到风险水平。“用户可以决定他们需要运行验证混合模型上的内容的90%,剩下的10%与完整的RTL与完整的准确性,将验证“Gommershtadt补充道。“混合模型不是周期准确,但即使处理器通常会运行异步系统的其余部分。所以系统的处理器不需要cycle-accurate,和行为表现出的行为模型仍然是一个合法的行为。”

对于那些想要增加信心,“你可以看看的增加使用原型说人们想确保软件结果他们看到混合和虚拟平台上与真正的RTL”音符节奏的悟道。“推动更快、更准确的平台,获得额外检查timing-accurate硬件上运行的软件,或者检查点cycle-accurate给你。所有这一切都归结到多少抽象的评价将你从现实和你如何缩小这一差距。人们会找到方法来这样做。”

新产品进入市场来解决。Aldec刚刚宣布之间的混合仿真和原型,利用FPGA中的处理器核心。“我们的新混合co-emulation平台大型ASIC和SoC设计汇集了我们的硬件仿真系统和嵌入式系统,”博Zalewski说,硬件部门的总经理Aldec。“嵌入式系统板特性Xilinx FPGA,其中包含一个四核手臂Cortex-A53。两个产品之间的桥梁让ARM内核共享模拟器,这意味着软件团队成员可以在硬件时钟速度快和受益于快速原型系统启动。”

增加功率和性能
验证功率和性能仍然是新生的问题。麦凯乐声称“更可容纳的力量。”“你必须得到代表向量,通过正确的工具。希望这些向量代表。在RTL估计对权力比甚至有人要容易得多。更容易,使用模拟器或实现工具,得到合理的可接受的数字可能变化率和IR降的设备。然而,我们仍然是一个级别的地方最终产品的人会像我们一样。”

的结构验证的权力相当简单,经常的驱动吗趟车文档。“你可以生成基于UPF值覆盖,“Gommershtadt说。“你要确保你已经覆盖所有的电源域和电源状态以及它们之间切换。这是活动从一个正确的观点。UPF值的目的是提高能力。人们会需要生成的数据模拟,通过侧格式或工具,测量芯片的功耗下现实的软件负载。人们可以获得这些诊断测量,然后计划。所以他们想看到的电力消耗小于一定在这些测试用例。”

行业的展望便携式刺激(PSS)和类似的内部工具来创建这些代表向量。

挑战现状
新需求放在项目,他们必须时刻警惕,他们使用最好的技术可用,他们没有被更新,更有效的方法。“我们需要问,‘那是正确的测试吗?“麦克拉说。“我优先测试的正确方式最大化我的进步和最小化工程错误以后被抓的机会吗?除非你接受这种类型的问题你永远不会真正的进步。你只会盲目添加东西。”

正式的为优先级提供了很多这样的例子。“今天的正式的引擎容量的增加意味着可以选择更广泛的设计特性来验证主要由正式的工具,“OneSpin的范Blommestein说。“一些特定的功能可以被正式应用连接检查,浮点验证,RISC-V验证和遵从性,和其他方面的设计。在所有情况下,结果从正式的工具必须注释回验证计划统一视图的验证进度。”

集中工具解决了一些严峻的挑战。“两疾病预防控制中心和RDC解决meta-stability问题,”指出真正的意图的规定。“传统上,这些都是无法解决的静态时序分析和功能仿真。RDC问题空间变得更大尺寸的增加SoC的设计,包括电源管理。由于设计方法和实践的进步,新的失效模式正在形成。”

在过去的5到10年我们看到了硬件设计和验证组利用持续集成和混合敏捷自动化和提高工作流的方法。“不断增加的设计复杂性加上需要覆盖驱动之间的过渡,testplan驱动和需求驱动的验证方法带来了现代项目管理的挑战,只有生命周期管理解决方案可以解决,”马克凯利说,产品工程师导师,西门子业务。“与追溯,它提供了优化的认识发生在项目的生命周期,确保最好的使用时间和资源,提高生产力,并减少投放市场的时间。”

结论
早期验证计划提供了一个正式的机制来定义testbench应该是什么样子,并跟踪进展已建立的目标。今天,这一计划定义最重要的方面的设计和验证方法,包括开发的所有阶段,并确保产品周期之间的连续性。它需要密切关注,以确保它仍然是有效的和有效的。



留下一个回复


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

Baidu