来自同辈的压力导致验证团队采用UVM但是是时候让人们谈论替代UVM石门。
炸毁UVM是我几年前在我自己的博客上。考虑对UVM变化不大,它继续主导验证圈——我认为这是一个讨论值得重新启动。在我看来,这不是太迟去炸毁UVM向前迈了几步。
有点历史…这个想法炸毁UVM是出于一个幻灯片快照发布到twitter在DVCon早在2013年。近3年过去了,我仍然爱这快照,因为它提供了一个机会,一个非常有建设性的谈话围绕UVM的未来;对话对我来说是一个长时间(长)来了。
2013年,张代表来自同辈的压力验证团队面临符合一个超UVM标准。现在2016年,我会说来自同辈的压力至少翻了一番,UVM巩固了testbench发展成为行业标准。在功能验证圆圈围绕UVM讨论。如果一个团队还没有采用UVM——或者做艰苦的工作正如肯尼迪可能建议——他们计划。如果他们不打算…嗯…也许他们并不感兴趣可重用、可互操作的,行业标准testbench IP !
建设性的新讨论我一直希望,一个全新的方向作为朋友指出的那样,是一个人们谈论替代UVM石门。我叫UVM庞然大物因为它到底是什么。这是一个大的包,包括一切;所有的点成为frankenmess交织的妥协和善意。例子:UVM注册包。好主意和模块化的绝佳机会。唉,这是扔进同一个uvm_pkg成为庞然大物的一部分。
现在,你可能会说“仅仅因为它的一部分uvm_pkg并不意味着注册包不是模块化的”。我不完全同意'ish但这是正确的。站在它自己的和我可以告诉注册包的依赖关系仅限于宏。如果你不想使用它,唯一的影响是额外的代码通过编译器。也适用于TLM1 TLM2,大部分的监控和记分牌,大多数其他零碎(边注…使用uvm_heartbeat是谁?任何人? ?)和弃用功能尚未完全放弃。同样是不正确的,然而,对于音序器config_db或报告或事务记录器或工厂。那些有你是否正在使用他们,喜欢还是不喜欢。如果你认为音序器很难理解,config_db危险不透明,报告设计和记录不到有用的,他们是一个集成的一部分UVM无法摆脱;太糟糕了。
这给我带来了另一个。我提出了开放验证平台(OVP)早在2013年就在原来的职位。没有人带我呢,如果一开始你不成功…
OVP是绝对不通用的也不是功能齐全。这是极简主义者为模块化testbench发展起点。OVP的价值是它的一个平台上用户集成或构建组件来满足他们的发展目标。简而言之,OVP之上是一个平台,人们创建解决方案虽然UVM是一个解决方案,适用于他们的问题。
给你一个想法的相对于UVM OVP可能会是什么样子,一个选择是开始整个UVM库,然后删除一切除了uvm_component和uvm_transaction。这留给你一个基本组件,基地事务和run-flow定义;3 testbench的关键部件。没有更多的。您的平台。
第二步是将数千行删除代码和分成一组插件兼容的平台。会给你定序器插件,config_db插件,插件注册,TLM1 / TLM2插件,记分板插件(s),心跳插件,等等。
至于开放部分OVP,开放意味着它的用户驱动的,所以任何人都可以发布插件无论多么复杂,简单,优秀的或完全站不住脚的他们可能(形成鲜明差异贿赂的方法来维护UVM)。问题是,OVP就是用户驱动的经验,他们的想法。我认为创造力和竞争在插件开发。虽然标准化在我看来不是目的,最终可能产生某种程度的一致性和插件找到一个伟大的思想出现的用户基础。
最后,信徒UVM可以安慰的事实可以完全重建的OVP堵起来的一切。所以如果你爱UVM,继续工作。如果你不,你有机会后退一步,自己决定如何前进,确切地说,你带着你。
所以我们开始讨论替代UVM怎么样?OVP是一种选择但是我打赌我们100人能想到的。除非你认为UVM是永远存在的,现在可能是合适的时间开始。
|
|
|
|
|
|
|
|
|
别忘了,应该更好的测试的代码。
我也到此为止,说它应该更好的封装(命名pseudo-protected东西的东西“m_whatever”建议他们不能使用)。理想的内部类也应该保持隐藏,但这是不可能的由于语言。
这里有更多的说(愚蠢的命名约定,“更多的方法来做这件事,因为我们建在太多的普遍性”症状,等等)。
我完全同意,一个用户定义的插件架构对OVP来说是有意义的。当我看着世界上最受欢迎的内容管理系统,WordPress,采用这种哲学。所有最好的给你OVP,现在的时间是。