UVM的未来

 现在是坦率讨论UVM未来的时候了。鉴于UVM的使用情况以及依赖它的团队数量如此增长，我想准备这个对话已经很长时间了。 

 是继续使用UVM做正确的事情吗？我们是否有坚实的证据支持我们继续使用UVM？我们实际上是从中受益，还是只是我们认为从中受益？ 

 当它首次推出时，我们是否接受UVM有充分的理由吗，或纯粹因为接受专家的建议？ EDA认为这是一个自然而然的步骤。我们看到了成功的故事。标题<Company X>使用UVM使SoCTapes-out意味着成功。但是人们发布错误的频率如何？我们多久看一篇题为采用UVM的开发计划的文章。我们什么时候见过会议论文，深入了解过度设计的UVM测试平台如何导致2倍的计划超限？ 

 或者，这可不是建议。尽管没有明确的迹象表明UVM比我们以前做的要好，但也许我们接受UVM是因为我们想要;因为它很酷。工程师喜欢优化，UVM为我们提供了各种各样的选择。我们喜欢可移植性的概念（以至于下一个新事物（指verification3.0）的名字中包含“便携”这个词！），UVM提供了很多便携性。 UVM可以轻松推广职位发布和排名候选人（熟练使用UVM已经是验证工程师的必备技能，而被写入简历中）。我们不要忘记，UVM是如此的闪亮（注1）。有很多东西需要学习，这对工程师来说是一个很大的吸引力。尽管它是软件语言，但语言和BCL包装让我们摆脱了软件理论中的一些棘手问题。  

 但回想过去15年以来以UVM为核心的功能验证的发展，我们是否曾考虑过UVM是功能验证可能出错的地方？我们应该考虑一个没有UVM的未来？ 

 或者......嗯......呃......  
 咩。 

 没关系。 

 让我们抓紧时间来坦率地讨论UVM的未来。举出证据赞成和反对是可以忽略的，因此讨论它可能没有意义。因为我们是在谈论UVM的未来，所以让我们继续将UVM视为功能验证的通用基础。让我们继续向UVM中添加这些功能，以产生它自己成功的轶事证据。让我们把它超越仿真。让我们继续使用它来填补会议计划，筛选合格的求职者，磨练我们的伪软件技能（注2），加大设计和验证之间的差距，加强对培训和相关EDA工具的需求等等。让我们继续做我们正在做的事！除了一个微小的差别： 

 让我们不太可能用UVM失败。 

 仅仅因为我们没有看到失败的案例发布，但这并不意味着它们不会发生。你知道他们发生了。他们在外面;每周日程安排下滑;这个可笑的复杂测试平台。你见过他们。我知道你已经看过他们，因为你告诉我你已经看过他们。许多人！而且，除非我们迈入未来 -  少使用UVM，否则他们将继续发生。 

 为了让我们开始，我想提出一套适用于UVM未来发展的规则： 
  

 规则1：features实际上必须工作。这看起来似乎是一件容易的事，但目前这个规则正在被打破。不起作用的feature得到修复或删除。例如Phase jumping…如果你想正确使用，前提是有人最近修正了相位跳跃。 

 规则2：建议使用所有功能。如果不推荐使用某项功能，那么其存在的主要目的就是误导毫无疑问的验证工程师。不要推荐没有人使用的某项功能，为了给验证工程师省却麻烦，将其删除吧。与run_phase同时运行的所有phase......现在我正在看着你。   

 规则3：限制代码库的大小。面对它，在大几千行的代码行，而且在不断增长，规模和复杂性是限制UVM的使用阻力。如果继续支持它是一个长期目标，那么我们将需要限制复杂性。最简单的客观方法是限制代码库的大小。如果您想要添加一行代码，使UVM超出上限，您需要首先删除其他代码行......这意味着您需要知道人们实际使用的功能......这是另一次讨论...。 

 规则4：使用新功能的代价。新功能是在错误修复中添加的。在新的UVM功能发布之前，您需要为使用该功能付出代价 - 即修复一些现有的bug。一个功能/任务的缺陷修复，五个针对一个类，15个针对一个包+ 13，针对每个改变都打破了向后兼容性。 

 规则5：所有新功能都经过回归测试。除了步骤1-4，这是我个人的最爱。您的新功能或错误修复必须通过验证其正常工作的测试才能交付。测试进入回归套件，该套件随代码库的每次更新而运行。 

 就这样。一套简洁的规则，为我们所有人改善UVM的未来。谁知道这些步骤将在未来十年采取何种措施，但我知道这会让团队在过去的十年里仍然处于更加容易的使用UVM的状态。并且开始旨在简化UVM使用的框架和论文的人们已经开始了这条道路。想象一下，如果这些人很容易使用它们，他们可以做些什么！  

 附注...我写这篇文章的初衷是去完全不同的方向。但有趣的是，一旦你真的开始行动，事情往往都会脱离轨道。 

 1. 在二十一世纪早期，功能验证的承诺是闪亮而新颖的，并且它在大部分时间里遵守了这一承诺。无可否认，RVM和VMM的光芒万丈是让我首先进入验证领域的动力，然后我才有机会深入了解UVM。 

 2. 我不是软件开发人员，但是当我使用UVM时，我觉得我是时，我很感激。