Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
Modern verification is carried out using high level languages that we call as Hardware Verification Languages (HVL) in contrast to Hardware Description Languages (HDL). They implement the OOP paradigm of programming found in C++, Java and others. The fundamental idea with OOP is "abstraction" i.e hide details of something, "inheritence" which is use already existing code to create new programs. The HVLs are used to carry out a very specific task which is hardware verification while the other languages are used to create a variety of different type of applications where each domain of applications like games, database application, web application e.t.c will have its own "methodology" in how to write them i.e what tools to use and how to test the application.
The power of the language here means that there are a lot of different ways to accomplish a verification task. A person that has more grasp of the language and the essence of OOP can write much superior testbenches. However, it is very important that testbenches not be written such that they are only useable with a very specific version of a design and also it must be possible to expand the testbench later on. The "software languages" deal with this scenario by providing "abstraction", "modularity" and "reuseability" and HVLs are essentially "software languages" and not hardware description languages.
Abstraction means that we hide the internal detals of something e.g to write to internal port of our design rather than wiggling each individual data signal and then wiggling each individual control signal, we can just write a function called "write_data" and use it. This is a very simple example of abstraction.
Modularity is that rather that writing a single testbench containing 1000s of lines of signal assignments, we split the testbench into multiple parts kind of how we do with the design. Each of thes parts works together to carry out the signal read/write and verifying that the actual output is same as expected output.
Reuseabililty is obvious, we should be able to use part of our current testbench in the future for similar designs. This is made possible using Modularity but we still need to plane the modules in the right way.
Now the thing is that to achieve the above, with the HVLs there are different "disciplines" ("methodology" is perhaps a better word) on how we can write testbenches using these HVLs and there are several such disciplines that have emerged in the last several years. It is important to have a methodology on how we write testbenches to achieve the task of verification with the least time and least resources and take most benefit from the power provided by a HVL. These discipline/methodologies basically based on earlier HVLs like 'e' and 'vera'. Among these are Open Verification Methodology (OVM) and Verification Methodology Manual (VMM) which have been used for a few years in the past. Basically what has happened is that in the last few years, the "experts" have taken the best of the different methologies and created a new methology to replace all others (atleast for SystemVerilog) this new metholody is thus rightly called Universal Verificataion Methodology.
When we talk of UVM there is basically a very specific way to structure the testbench with each of those blocks serving a very specific purpose. If we ever have to use HVL to verify a design it means that the design is beyond doubt a highly complex design. With complex things we like to stay away from the low level details and do all verification at a "higher level of abstraction" (remember difference between wiggling each individual signal and just using a function write_data()). UVM teaches how to do that taking the best of all previous popular methodologies.
Self help is the best help. As far as I know, in EDA we are SUPPOSED to ask exact questions on particular problem areas (at-least for the ASIC & FPGA sub-forums; I am active only in these). The answer to your question can easily be Googled and found out.
And yeah, I am glad that giving -ive points is not a feature here as it could be easily abused!
I also hope that more than one Moderator will agree to what I have said above.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
