你应该遵循一个证明自己验证路径或大火?
在我18岁的时候,我买了一个胡蜂属“67:著名的意大利摩托车。它已经很老,很破旧,但幸运的是我有一个朋友谁拥有一个汽车修理店打来,他好心地给我一些晚上访问。
几个星期以来,我自学的艺术金属车身,结束了一个漂亮的金属67胡蜂属天蓝色的。上帝,我爱那台机器!
然后有一天,我开始听到奇怪的声音在引擎。这几周的夜间开始调试。我将等待汽车商店空出来,然后我将拆卸踏板车,将其分解成部分,试图找到这个问题。但我有一个规则:总是重新组装过黎明破晓,拿出来的商店。
这是我第一次真正的工程工作。我没有担心,我只是知道我能理解它如何工作和修复它,仅仅通过调试。我认为有必要读也没有规范和银行开始前的一些知识。我变得如此擅长拆卸胡蜂属的引擎,我想我仍然可以做到今天,比大多数人。毕竟,我最终取代一元金属针,我固定的问题。
天蓝色的胡蜂属从1960年代
今天我一个验证工程师,领导,老师,和我领导Vtool公司发明了Cogita调试平台。
当涉及到工程,总有一个权衡按部就班,使用定义良好的和经过验证的方法,和探索自己的道路,看问题好像第一次发现你能想到的最好的解决方案。
普遍的验证方法,或UVM,例如。我们大多数人忘记了UVM实际上是(或几乎完全)e重用方法(eRM)开发了一些15年前,主要是在以色列,主要验证挑战当时大沟通asic。方法论的发展随着时间的推移,首先将新兴SystemVerilog语言(OVM技术),然后UVM,支持和推动的所有主要EDA供应商。
UVM是一个著名的、高度使用方法,因此,它有许多优点。事实上,人们会说同一种语言时验证计划和实现是一大亮点。
UVM架构示例——为什么这些总是那么简单吗?
方法,任何方法,还有另一个优势。这让较弱的工程师更有效,更快。如果你是一个天才,独自工作,你会自己解决给定问题不需要方法论挂在你的头,限制你的创造力。但如果你是一个组织与数以百计的验证工程师,一些初学者和一些简单的不是最聪明的,你需要UVM火炬点燃的方式。
最近,我遇到了一个我知道的唯一大型组织不顾UVM,开发大型和复杂的验证系统使用自己的方法。它仅仅是建立更好的设计类型和他们面临的挑战。我认为他们开发了一个很好的方法,但更多的我喜欢思考它。当我在Vtool教验证,我们的新工程师或大学的学生,我试图鼓励人们从一个全新的视角看待问题,每次和想出新的办法来解决它们。最后,就像那个小男孩,决心解决他心爱的胡蜂属,你必须带足够的创造力和激情的过程为了真正吓跑这些bug。
|
|
|
|
|
|
|
|
|
|
美极了!
希望听到更多来自Arbel先生。