{"id":14079,"date":"2020-04-06T07:35:28","date_gmt":"2020-04-06T14:35:28","guid":{"rendered":"https:\/\/blogs.mentor.com\/verificationhorizons\/?p=14079"},"modified":"2026-03-27T08:44:53","modified_gmt":"2026-03-27T12:44:53","slug":"verification-methodology-reset","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2020\/04\/06\/verification-methodology-reset\/","title":{"rendered":"Verification Methodology Reset"},"content":{"rendered":"

Discussion around verification methodologies have been going on for a couple decades. It started back around 2000 with the emergence of the various hardware verification languages (HVLs). Verification specific languages lead to the divergence of design and verification and the creation of the verification engineer. It was HVLs that enabled the transition of directed testing toward constrained random. Early in constrained random adoption it became obvious supporting infrastructure was necessary to be productive; early frameworks included RVM, eRM, AVM, VMM and various homegrown alternatives. The first step in consolidating an approach to constrained random happened with OVM; the final step was UVM which is where we are now.<\/p>\n

As time passed and habits formed, UVM became the thing most of us identify with when someone says the word methodology<\/i>. Constrained random is assumed to be part of that equation being that it\u2019s the workhorse for most teams in our industry. Reuse, also closely associated with methodology, is the primary driver of technical integration with emerging techniques like portable stimulus; UVM, of course, helps form the foundation for that technical integration.<\/p>\n

Even if you think beyond UVM, verification methodology radiates from a verification point of view. While born of exploding design complexity, methodologies live solely within verification teams.<\/p>\n

Verification_methodology.reset().<\/p>\n

I propose reevaluating our current definition of verification methodology. I\u2019d like to see renewed focus on design being the central deliverable and verification methodologies conceived and driven by the needs of design. I\u2019d like to see us break a design into a series of abstractions, identify options for verifying each abstraction, employ techniques best suited to each abstraction and integrate those techniques so transitions are made effectively.<\/p>\n

That\u2019s a mouthful. Agree or disagree I think it makes for worthy discussion.<\/p>\n

In breaking a design into a set of abstractions, here are five that I identify with: line, block, feature, feature set and system.<\/p>\n

A line of code is self explanatory; that\u2019s as low level as it gets. Code block is next; also self explanatory though important to note that code blocks are localized within a design unit (I almost said module<\/i> there but changed it so I didn\u2019t lose anyone!). Features are where we cross the threshold into characteristics that users identify with yet still don\u2019t provide much value on their own. Simple features will still be localized but more complex features will have a distributed implementation that crosses design unit boundaries. Next are feature sets; definitely distributed across subsystems and the first indication of an actual deliverable. Our highest design abstraction is a complete system where integrated feature sets delivery real-world value.<\/p>\n

Examples from each abstraction to help you identify\u2026<\/p>\n