Obsidianʼs coverage-driven verification methodology utilizes functional coverage goals in conjunction with the RAVEN® random test generator to achieve optimal results. RAVEN may be used in a simulation, emulation or post-silicon environment to generate vast amounts of valid and interesting stimuli. Tests are typically generated using the customerʼs Instruction Set Simulator (ISS) with results compared against the RTL.
The Importance of Random Test Generation
Random test generators offer the advantage of automatically hitting coverage points without the need to directly author each test sequence. Modern generators automatically create valid sequences of processor instructions with associated data values, initial values for multilevel caches and initial processor register values. This saves time normally wasted on repetitive register setups and generating invalid test sequences.
Hitting Coverage Goals
Coverage metrics are the dominant method for measuring verification progress in the industry today. Coverage points are normally designated by design engineers according to functional definitions and risk assessment. Obsidianʼs verification methodology begins by generating large numbers of purely random tests. Coverage monitors report the points hit by these tests and are used to identify regions which require further testing.
Closing Coverage Gaps
As the number of coverage points hit by random tests begins to decline, generator templates are updated and constrained toward specific regions of the verification space. Some coverage points may require a long series of events before the targeted behavior takes place. In this case, directed tests and directed templates are used. Directed tests are used to target the most difficult coverage points while directed templates are written to allow as much random behavior around the coverage point as possible.
The RAVEN software retains knowledge of how to reach key verification coverage points including:
- Every instruction executed following every other instruction
- FPU overflows and underflows
- All paths of state transitions throughout the memory hierarchy
- All possible load / store orderings and conflicts
- Using instructions to create all possible exceptions
- Accessing all possible paging modes and physical memory size boundaries
- Memory sharing with multiple bus masters or multiprocessor tests
