讨论是姗姗来迟。至少它必须变得更容易使用。
是时候坦率的讨论的未来UVM。鉴于UVM使用增长和团队的数量依赖于它,我认为这个谈话已经很长时间了。
继续使用UVM正确的做法吗?我们有确凿的证据支持我们继续使用UVM吗?我们是否真正从中受益,我们觉得我们的好处吗?
首次引入时,我们接受UVM理由或接受纯粹的建议吗?EDA建议这是一个自然的一步。我们看到的成功的故事。标题< X公司> Tapes-outSoC运用UVM意味着成功。但是人们多久发布失败?多久我们看到文章标题吗UVM采用了我们的开发进度。当我们看到会议论文深入的细节一个超UVM testbench导致2 x进度超出?
也许这并不是建议。尽管没有明确的指示UVM比我们更好,也许我们接受UVM因为我们想;因为它很酷。工程师喜欢优化和UVM给了我们各种各样的选项。我们爱的想法可移植性(以至于未来新事物有“便携式”这个词对的名字!)和UVM提供了大量的可移植性。UVM便于推广工作职位和候选人排名,。UVM太让我们不要忘记,所以闪亮1。有这么多学习这是一个大画工程师。尽管software-y,可怕的语言和BCL包装保护我们的软件理论。
但回想在过去的15年里,功能验证的进化,最终导致UVM,我们曾经认为UVM是功能验证可能是哪里出错了吗?我们应该考虑一个没有UVM的未来吗?
或者…嗯…啊…
咩。
不要紧。
让我们抓整个time-for-a-frank-discussion-on-the——future-of-UVM的事情。赞成和反对的证据充其量只是粗略的所以可能是毫无意义的讨论。我们,所以我们一直觉得UVM的通用功能的基础验证。让我们保持的特性添加到UVM产生它自己的成功的证据。让我们把它模拟。让我们继续使用它来填补会议程序,过滤出合格的应聘者,磨练我们的pseudo-software技能2、锐化设计和验证的划分、燃料需要培训和补充工具,等。让我们继续做我们所做的!除了一个微小的区别:
让我们与UVM失败的可能性。
只是因为我们没有看到失败发表和庆祝并不意味着他们不发生。你知道他们发生。他们在那里;每周的日程;可笑的复杂testbenchs。你见过他们。我知道你已经看到他们,因为你告诉我你见过他们。他们中的许多人!他们会继续发生,除非我们在future-UVM统治使他们不太可能。
让我们开始,我想提出的一套规则,适用于所有future-UVM发展:
规则1:实际工作特性。这似乎是显而易见的,但目前的规则被打破。固定或删除功能不工作。阶段跳跃…我看你最近…除非有人固定相位跳。
规则2:建议所有功能。如果不推荐功能,它的主要目的是为了误导毫无戒心的验证工程师。而不是建议没有人使用一个特性,我们救人的麻烦和删除它。并行运行的所有阶段和run_phase…现在我看着你。
规则3:限制代码库的大小。面对它,在几个1000行代码和增长的规模和复杂性会最终把这个房子的卡片。如果继续扶持它是一个长期的目标,我们需要帽的复杂性。简单的客观的方法就是限制代码库的大小。如果你想添加一行代码,UVM超出了限制,您需要删除其他行代码首先…这意味着你需要知道哪些特性人们实际使用…这是…另一个时间另一个讨论。
规则4:新特性有一个价格。新功能的价格设置错误修复。你需要支付功能,即解决现有的一些缺陷(s) -在你新的UVM特性。一个bug修复功能/任务,五类和15包+ 13的每一变化破坏向后兼容性。
规则5:所有新功能回归测试。除了步骤1 - 4,这是我个人最喜欢的。你的新特性或错误修复和测试,验证了它的工作原理。测试在一个回归套件运行每次更新的代码库。
就是这样。一套简洁的规则,提高future-UVM为我们所有的人。谁知道这些步骤将future-UVM在未来十年,但我知道它会让生活更轻松的团队仍然在过去十年中迎头赶上。和荣誉的人已经开始走上这条道路的框架和论文是为了使UVM更容易。想象一下这些人能做什么如果很容易使用它自己的!
边注…我开始写这篇文章一个完全不同的方向。有趣的多少东西可以出轨的一旦你真正行动起来。
1闪亮的和新功能验证的承诺在2000年代早期,通过一流的诺言。诚然,RVM的光芒,VMM就是把我拉到验证首先,UVM让我通过。
2我不是软件开发人员,但我很感激当UVM让我认为我是。
|
|
|
|
|
|
|
|
|
我同意所有的点关于未来UVM发展,除了规则3。没有可靠的方法来选择这个数字。埃文如果它是可能的,你真的想看到Perl风格比赛谁能产生最短的代码,做某件事(最有可能牺牲可读性)?同样,如果一切都记录,可以使用UVM像“黑盒”,而不是真正关心的事情是如何实现的。我也患有这种修补的心态,但我想自己从跳BCL代码来找出如何实现的东西,试着尽可能多地依赖文档。
从字面上讲,是的,规则3鼓励人们采取行动完全不负责任的。但是我坚持的想法限制代码库的大小。uvm臃肿。它开始了一顶帽子,它将迫使基于价值的讨论/决定让它成为善意的倾倒场所。
规则5不仅仅是测试。这将有助于创建一个功能内聚和松散耦合的模块设计。这将减少复杂性,这样可以保持更大的代码库。但你是对的,没有价值的增加功能将在另一个方向。
作为倡导单元测试。我们的证据在哪里?
可怕的问题。我发表了一篇文章,包括数据设计诉testbench bug。也为bug发现文章单元测试遗留代码(uvm-utest和一个真正的项目)。远离果断。一个令人信服的论点,我们需要更多的人尝试和测量质量。
尼尔,你谴责的阶段和阶段跳让我觉得有了你的设置。究竟什么是问题?我们多年来一直使用它。有没有论文状态,它是坏了?
布莱恩,找不到确切的参考,但这是一个线程从verifacademy谈论它不被推荐:https://verificationacademy.com/forums/uvm/uvm-phase-jumping。我想我记得它被音序器和司机之间的协议被打破。如果线程被杀错了订单,有一个致命的从一个或另一个。