Current verification technology

To deal with the complexity of today’s designs, verification teams have developed elaborate methodologies. In most cases, the methodologies center on the creation of a set of test benches at varying levels of the design hierarchy. The figure below depicts a typical verification environment where there are test benches at the full-chip, the block, and the module level. Usually, the full-chip and block level test benches are developed by engineers in the verification team. Module level tests are often created by RTL designers to ensure that their RTL designs are at least minimally functional. Some teams take module verification one step further and perform module-level formal property verification, though this requires a totally different methodology.

Verification process

The verification process usually entails several steps:

1. Create set of functional requirements
• Describes how the design should operate and what constitutes correct behavior
• May be derived from a specification document
2. Create verification plan
   • How to test the design
   • Who writes what
   • Scenarios to test
   • Metrics to help decide when testing is done
3. Write test bench code
• Directed tests that provide specific stimulus to check specific parts of the design
• Constrained random test generators
• Reduces amount of work required to generate a large number of tests
• Hopefully check parts parts of the design that the verification engineer never thought of.
4. Measure comleteness with "coverage model"
   • Ensure that interesting and importance scenarios have been tested
   • Provide confidence that the design has been sufficiently tested

Of course, there are many variations of the above. Not all teams do all the above steps nor do all teams do every step in strict linear order.

Test benches

The test benches themselves can be can be quite complicated. The next figure below shows the current state-of-the-art test bench methodology as described in the Verification Methodology Manual (VMM) ¹. This diagram shows many concurrently communicating software modules that together form the test bench for the design. Each of these modules comprises a significant amount of code that verification engineers must write. The concurrency between the software modules, combined with the sheer amount of code, often means that there as many or more bugs in the test bench as there are in the design under test. Added to this, verification engineers often need to use several different languages (e.g. Verilog, E, PSL, SystemC, C++, and Perl) in the development process. Each of these has its own learning curve and complexities. On top of all this, a typical verification team runs the test benches on a farm of servers, numbering in the teens to several hundred. Managing a simulation farm and the results coming from it is often a job in and of itself.

Next steps

Read about characteristics of a better verification solution.

¹Bergeron, et. al. System Verilog Verification Methodology Manual