1. Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang

2. Outline  Chapter 1 – Introduction  Chapter 2 – Definitions  Abstraction levels  Verification of a design  Definition of a test  Chapter 3 - Methods for Determining the Validity of a Model  Stimulus generation methods  Results analysis methods  Conclusion

3. Introduction (cont.)  The functional verification takes 70% of the total effort on a project  Manufacturing verification  Functional verification  Why functional verification is needed?  Most modern designs need a testing method that can be used before a prototype is built

4. Introduction  The goal of functional verification  To prove that a design will work as intended. 1. determine what the intent is  Even the intent may not always be clear  The spec. itself may have mistakes 2. determine what the design is  A model may be built first 3. compare the two to ensure that they match 4. estimate the level of confidence Test Stimulus Design under Test Design under Test Response Check Response Check Simulator Pass/Fail

5. Outline  Chapter 1 – Introduction  Chapter 2 – Definitions  Abstraction levels  Verification of a design  Definition of a test  Chapter 3 - Methods for Determining the Validity of a Model  Stimulus generation methods  Results analysis methods  Conclusion

6. Abstraction levels  Behavioral Model  To examine the basic operation  There may not be any timing information May embed cycle information in code  Register-Transfer-Level Model  Detail function description  Provide accurate cycle-level timing information No subcycle timing – EX: propagation delays  Gate-Level Model  Each individual logic element is specified  Have subcycle timing information Highest simulation speed Most detail

7. Verification of a design  White box model  The test is aware of the inner workings  Allow the test to directly monitor internal states  Black box model  Verify at the boundaries of the design  Require more simulation cycle and more logic to verify  Reasons of using A test is often focused on verifying the intent Clock Reset Increment State Black Box Clock Reset Increment State0 State1 State2 White Box State

8. Definition of a test  Device under test + test stimulus generation + checking Stimulus Generation Stimulus Generation Checking Device Under Test Device Under Test HDL Simulator Stimulus Generation Stimulus Generation Checking Device Under Test Device Under Test HDL Simulator Link Verification Language Different simulation languageSame simulation language

9. Outline  Chapter 1 – Introduction  Chapter 2 – Definitions  Abstraction levels  Verification of a design  Definition of a test  Chapter 3 - Methods for Determining the Validity of a Model  Stimulus generation methods  Results analysis methods  Conclusion

10. Stimulus Generation Methods  Test vector Generation  Stimulus Capture  Transactions  Assertions

11. Test vector generation  Specify exactly what values are to be sent to every input  Advantage  It is simple to understand and simple to use  Disadvantage  It can be only used in trivial design The vectors can be large for modern design  Little modification to the spec. will have significant impact on the vectors.

12. Stimulus File Results File Stimulus Capture  When a device already exists that is similar to the design being created.  One can capture vectors from existing device  Advantage  A large number of vectors can be easily captured Existing Design Real System

13. Transactions (cont.)  This allows a test to be written in a more abstract fashion  Specify the transaction to be done  Not all the details about how an operation is to be executed Test Core Write (Addr, data) Data = Read (Addr) Test Interface Write Operation Read Operation Other Operations Bus driver Transactor Device Under test Processor Bus

14. Transactions  Aspects of transactor  Encapsulation The transactor contains the knowledge of the protocol of the group of signals that make up the bus  Abstraction The test is not involved in any lower-level issues  User interface A standard set of routines that a test can call  Modularity Ex: Separate the processor bus transactor and the test

15. Assertions (cont.)  An assertions is a statement about a design that is expected to be true.  Logic component equation  Temporal component Under what time constraints the equation is expected to hold true  Ex: When reset is asserted, state must be idle within four cycles Request without grant – Grant must be asserted within n cycles of a request  White box method is needed

16. Assertions  Dynamic assertions  Simulation-based environment  Important If the assertion did not trigger, it may also mean that there was insufficient stimulus generation  Static assertions  Use a mathematical model  Advantages Stimulus generation can be very time-consuming Engineer doesn’t have to create operations to test certain rules  Disadvantages Assertions about multiple block become much more complex  Require too much computation power and time

17. Outline  Chapter 1 – Introduction  Chapter 2 – Definitions  Abstraction levels  Verification of a design  Definition of a test  Chapter 3 - Methods for Determining the Validity of a Model  Stimulus generation methods  Results analysis methods  Conclusion

18. Result Analysis Methods  Eyeballing  Golden File  Automated Result Analysis  Assertions  Monitors  Predictors

19. Eyeballing  Advantage  It can be easily performed at first time  Disadvantage  Not suitable for any project greater than a few hundred gates  It is difficult for humans to analyze the information  It is no ability to perform an automatic regression test

20. Golden files  Compare the output of a simulation to a stored version of the expect output  Advantage  perform an automatic regression test  Disadvantage  Modifications made to the design have great impact on the golden file  Golden file produced by behavioral model is not always right

21. Automated Result Analysis (cont.)  Assertions  Self-checking  Continue to check for an invalid condition as more tests are added  Assertions are often not as well suited to follow data as it passes through a system as simulation methods might be.  Defining a complete set of assertions for a more complex sequence is usually not practical for complex device  Assertions alone are not the ideal way to verify a system

22. Automated Result Analysis (cont.)  Monitors  To check the bus protocols are being followed at all time  May be simply a group of assertion statements  It can also be used to record the bus  Characteristic Encapsulation Abstraction User interface Modularity

23. Automated Result Analysis (cont.)  Predictions  Assertion can’t deal with large complex systems  How to predict result in simulation-based verification  Reference model Cycle-accurate reference model  The comparison is done at every cycle  Take time to write the model in the first place  The accuracy of the model is of critical importance Behavioral reference model  Differences in the outputs between the behavioral model and the design may look quite different

24. Automated Result Analysis (cont.)  Predictions (cont.)  Self-checking Tests To embed the information directly into the test EX: Store the right answers in memory and compare them with the result Advantage  The test and the checking criteria are kept together

25. Outline  Chapter 1 – Introduction  Chapter 2 – Definitions  Abstraction levels  Verification of a design  Definition of a test  Chapter 3 - Methods for Determining the Validity of a Model  Stimulus generation methods  Results analysis methods  Conclusion

26. Conclusion  Assertions and simulation-based methods each have different strengths and weaknesses.  The methods are not mutually exclusive  The size of a project  Availability of tools and resources  No single best method