Verisity - Functional Verification - Lecture Slides, Slides of Computer Science

Download Verisity - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Verisity VA Notes

Execution Flow Chart

Execution Flow

Flow Notes

• The recursive call for run(), quit() and check() is done depth-first for every struct in the tree of structs, starting form sys. - The parent's function call is done before its child (pre-order).
• The methods of the generate_test() phase are called recursively for all structs in the tree of structs in the following order (starting from sys): - init(), pre_generate(), post_generate(). - The recursive call is done between pre_generate() and post_generate().

Note that if an struct member is marked as do not generate then none of the above will be called for that struct.

• Only stop_run() and quit() can be called explicitly.

Non Extendable Methods

global.generate_test() - generates the tree of structs

struct.generate() - generates a specific struct

global.run_test() - executes the run() method and starts event

threads for all the structs

global.stop_run() - ends the simulation run and calls the quit()

method for all the structs

struct.quit() - deactivates all TCMs and events of the struct

global.check_test() - executes the check() method for all the

structs

Verification Process

The recommended process of constructing a verification environment based on Specman Elite comprises the following steps:

1. Design the verification system surrounding your DUT and determine how you would model it (2.1 Outlining the Test Environment).
2. Determine your overall verification strategy, i.e. how a typical test should look (2.2 Defining a Typical Test).
3. Define what should be tested (2.3 Defining a Test Plan).
4. Model your basic environment in e (3.0 Modeling). Start your implementation with generation, especially non-error generation (4. Recommended Process). Add end-to-end checking for the simple cases (7.0 Checking). Then, your test engineers can start writing random tests for these cases.
5. Finally, gradually add the rest of your verification environment: checks for complex cases, coverage, generation of special cases, etc. To learn more about Generation, Checking, and Coverage, see the corresponding patterns.

2.1 Outlining the Test

Environment

Example: ATM Switch

Input Port

• One 8-bits input port (named Port A).
• This port is usually connected to a controller that programs the

ATM switch by sending commands. Through this port the

connection table can be filled.

• The connection table defines the routing rules of the switch.

This port is also used for device configuration.

• In addition to the configuration and control commands that

write to the ATM switch, there are also read commands that

enable reading back the registers of the ATM switch.

Test Environment

Stubs

• Data Ports:
  • Each port is "full-duplex"
  • Define 2 stubs for each port: one for input and one for output
  • The input stubs generate ATM cells and inject them into the port
  • The output stubs collect cells from port and log them (for later use in checking, reporting, and possibly coverage analysis)

2.1.2 Determining the Abstraction

Level

• Abstraction of A DUT Interface has three components:
  • A struct that represents the stub (the DUT port counterpart entity).
  • A struct that represents the data elements transferred from/to the DUT.
  • A TCM that injects or collects the data elements.
    • This TCM also converts data from e abstraction levels to HDLs

Abstraction/Data Types

• It is important to use higher levels of abstraction for test definition, checking, and almost every other verification sub-task.
• Use packing/unpacking and bit extraction and insertion to convert from higher level e-structs and fields - This conversion is usually done by the TCM.
• What is the right level of abstraction that one should choose for the data items that are injected into or collected from the DUT?
• The decision regarding data abstraction level is very important. It affects effectiveness and efficiency in using the test environment.
• The right abstraction level is one that makes it easy for you to:
  • Define interesting test cases using sequences of the data item
  • Generate meaningful and concise test reports
  • Analyze the test results by looking at a list of data items